View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002621 | gnunet-gtk | gnunet-fs-gtk | public | 2012-11-05 21:59 | 2013-12-24 20:55 |
| Reporter | LRN | Assigned To | LRN | ||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Product Version | Git master | ||||
| Target Version | 0.10.0 | Fixed in Version | 0.10.0 | ||
| Summary | 0002621: Better Download dialog | ||||
| Description | Current download dialog is, basically, a standard GTK SaveAs dialog with some extra widgets added for user to specify anonymity, etc. This is not optimal from usability point of view. To illustrate it i'd like to use Azureus download dialog as an example (attached). First, this download dialog accumulates torrents. The use-case, AFAIU, is that user will browse web and download .torrent files (which are then opened by Azureus automatically) or open magnet links (which will also be fed to Azureus). At some point user is OK with the selection, and goes back to Azureus to overview it and decide where and how each of the torrents will be downloaded. To that end the dialog has a list of opened .torrent files in its top part. Selecting an item in that list will populate all other widgets in the dialog, changes made to these widgets will be saved automatically (i.e. no Apply button). Multi-select is supported - on the screenshot both torrent files are selected. Now, how does GNUnet address this? Well, it doesn't. GNUnet earch result list and opened GNUnet directory do not support multi-item selection, and even if they did, they still would have had to show you one SaveAs dialog per selected item. Next, the populated widgets. They allow one to specify addition mode (not very relevant to GNUnet), queue position, etc. But, more importantly - download location for the whole .torrent file. By default that entry is set to the last directory used (in this case - C:\Downloads; red highlight means that the directory doesn't exist), but can be changed by typing in something or by browsing for a new directory (uses standard system directorychoosing dialog). Obviously, this affects only the torrent file(s) selected in the list at the top. If multiple torrents are selected, location entry either contains the location where all selected torrents are going to be saved (if it's the same for all selected torrents), or it's empty (which is the case on the screenshot). The location entry is actually a combo-box; its drop-down list allows user to select other previously-used directories. GNUnet has get_default_download_directory() which is about to be patched to get the directory from config file (default config file sets it to "~/Downloads" or "~/Documents/Downloads" depending on the OS). And that is the extent of our ability at the moment. Once GNUnet gets the download directory (from config file or, if that is not available, cwd is used), it appends suggested filename to that directory, and shows that in SaveAs dialog. Once user clicks "Save as", GNUnet gets back the whole filename - which, in case you forgot, might be a combination of [default] download directory, GNUnet-suggested filename and user's input. It's not possible to use that filename to convey new default download directory back to GNUnet: say, i'm downloading "gnunet\bin\gnunet-search.exe" (from a GNUnet directory rooted at directory named "gnunet") to C:\Downloads, GNUnet suggested 'gnunet-search.exe' as the filename, resulting in "C:\Downloads\gnunet-search.exe". If i accept that, GNUnet might deduce "C:\Downloads" as the directory that i prefer for my downloads. But we see that gnunet-search.exe belongs in /bin subdirectory, which itself should be in some 'gnunet' subdirectory (to avoid mixing it with other downloads). So i will either create these directories manually and save 'gnunet-search.exe' as 'c:\Downloads\gnunet\bin\gnunet-search.exe' (in which case GNUnet might think that i'd like to download everything to c:\Downloads\gnunet\bin, which is not true), or i'll have to use recursive download, in which case GNUnet will create the directories using metadata from the gnd file - but i will have no control over which files will be downloaded, GNUnet will download everything (but, OTOH, GNUnet will probably correctly guess that i want to download things to C:\Downloads in this case). The big list at the bottom is the last populated widget, it contains the list of files in selected .torrent file(s), with indentation denoting directory tree structure (on the screenshot there's only one file per torrent, so it's not noticeable). By checking and un-checking the boxes on the left user can choose which files in the selected torrent file will be downloaded. Context menu for each file allows user to save it under different name. As mentioned earlier, GNUnet's recursive downloading downloads everything, so there's nothing more to be said. GNUnet directories (GNUnet equivalents of .torrent files) when opened do look like the file list Azureus uses, but since the file-tree representing a gnd doesn't support multi-item selections in any meaningful way, it can't be conveniently used to choose which files to download. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| related to | 0002522 | closed | Christian Grothoff | Use a separate list for download in progress |
|
|
I'd also like to see how other torrent clients handle this (i'll probably be able to look up Deluge, that's the only client other than Azureus that i've used for the last, like, 5 years). So, first we should decide whether we want a separate download dialog at all (we already have search result list with a ... well ... list of files, and opened gnd tree - if we sprinkle them with a few widgets and enable multi-item selection, we could simply use them instead of a separate dialog), and if we do, then how it will look (and how will it interact with search result list and gnd tree). Also decide which things users should be able to change. And which things of these are the things that users are _likely_ to change. In the Azureus example above i would mostly just open both .torrent files and press OK, because download directory defaults to the right place from the last time, and everything else is just fine as it is by default (renaming files in the tree is rarely needed; opting out of downloading some files is slightly more useful (depends on how things are grouped in a torrent file); priority and add mode are mostly useless to me). |
|
|
>> Now, how does GNUnet address this? Well, it doesn't. GNUnet earch result list and opened GNUnet directory do not support multi-item selection, and even if they did, they still would have had to show you one SaveAs dialog per selected item. << Well, that's because when the user begins the download of a directory, we don't HAVE the contents of the directory already. Still, you can select "recursive" download to get all of them, as that doesn't require knowledge about the details at that stage. I'm not sure we _can_ do better, given the need to download more before we can show users the list of files. |
|
|
>> GNUnet has get_default_download_directory() << In some version (I think 0.8) we used the following: 1) start with ~/Download/ (from config), always 2) if downloading a file in a directory, start with the target path from the parent (i.e., if the parent was FOO/bin.gnd, suggest to store to FOO/bin/gnunet-search) Not sure if that functionality was preserved, but I think that was fine. |
|
|
On multi-selection, I think it is NOT needed if we make it *easy* to download a file without the dialog popping up. I'm thinking "right-click + save as" to be asked, and double-click (or ENTER) to just download without dialog. Again, I think we used to do that at some point. |
|
|
Well, for cases when we only have the directory, and not its contents, it's OK to just download the whole directory (although there should definitely be an option to download directory info only, and then let the user choose what to download). Remind me, do gnd files have the whole directory tree, or only one directory? If the whole tree, then the matter of choosing files for downloading is still important in that case. Also, downloading more than one search result (whether search results are files or directories) falls under this. |
|
|
GND files only have one directory, not the whole tree. |
|
|
<blockquote> <blockquote> GNUnet has get_default_download_directory() </blockquote> In some version (I think 0.8) we used the following: 1) start with ~/Download/ (from config), always 2) if downloading a file in a directory, start with the target path from the parent (i.e., if the parent was FOO/bin.gnd, suggest to store to FOO/bin/gnunet-search) Not sure if that functionality was preserved, but I think that was fine. </blockquote> The (1) means that changing default download directory requires config editing (and restarting gnunet-fs-gtk), or an UI to edit this config value in gnunet-fs-gtk itself. Remembering a number of last download directories (or just one last download directory) might be better. The (2) is fine, but how does it interact with non-existing directories? I.e. when FOO/bin doesn't exist? Does it just show "FOO" directory contents, with filename suggested being "bin/gnunet-search"? We're speaking of GTK+ SaveAs dialog here. Using some kind of custom solution might allow us to work with non-existent paths more easily. Also, the use of SaveAs dialog heavily implies that saving under a name different than the suggested one is something you might be doing often. This is not the case for torrents, and i think it won't be the case for GNUnet either. <blockquote> On multi-selection, I think it is NOT needed if we make it *easy* to download a file without the dialog popping up. I'm thinking "right-click + save as" to be asked, and double-click (or ENTER) to just download without dialog. Again, I think we used to do that at some point. </blockquote> Yes, i can imagine how that would be usable. Also, as long as "Download" menu option does not popup a dialog, selecting multiple files and "Download"'ing them should be fine ("Download as", on the other hand, will be disabled when multiple items are selected). The reason why i still think multi-item selection needed is that even if you can download with just double-click or ENTER, downloading >10 files that way is not very convenient. Doubleclicking 10 files means 20 clicks (or pressing arrow keys + ENTER 10 times; or moving mouse and clicking to select, then pressing ENTER - 10 times); selecting 10 consecutive files (and then downloading the selection) is shift+2 clicks; selecting 10 non-consecutive files (and then downloading the selection) is ctrl+10 clicks (at most). But as i have said, i have an idea about handling the dialog problem, just bear with me until i come up with a mockup. |
|
|
OK, i uploaded my mockup. It's a modified glade that is shown on search results tab. Here's how it goes: 1) The frame with widgets at the bottom is not normally visible. Extra columns in treeview are also normally invisible. 2) You select one or more items in the list and, say, press ENTER, or maybe choose "Download..." in context menu. 3) All normally invisible things appear. 4) You tweak the options (or don't tweak them) and press "Download!" to start downloading, or "Cancel" to not to start downloading. Either way extra widgets turn invisible again. "Download!" will be the default button, so pressing ENTER twice should start the download (one time - to show widgets, second time - to start the download). Selecting different items in the list (after extra widgets become visible) will change widgets' contents: "Download it" will be checked for items-to-be-downloaded and unchecked for other items. It will be checkable/uncheckable, so you can modify the list of items-to-be-downloaded (no need to get it right the first time you select items). When multiple items are selected, and some of them are in the to-be-downloaded list, and some are not, checkbox will be in 3rd state. When it's unchecked for selected item, extra widgets (but not columns - see below) will be visibly disabled and will not be interactable (except for the "Download it" checkbox itself). The label in italics will read "Preparing to download *total number of items* items (*index of selected item*/*total number of items*)", or something like that, and will change as you select different items in the list, helping you to get the total picture. It will probably show something different when selected item is not yet in the list, or when selecting multiple items, i haven't decided yet. Little left-right arrows will change selection in the list, jumping between items-to-be-downloaded, so you won't have to search the (possibly long) list for them. "Left" button will be disabled when topmost item-to-be-downloaded is selected; "Right" button will be disabled when downmost item-to-be-downloaded is selected. When only one item is to be downloaded, both are disabled. "Download into:" combobox is ExactlyWhatItSaysOnTheTin, similar to the one in Azureus, it will contain a list of last N download directories, also allowing you to type something in. The button to the right will allow you to select a directory (will call appropriate dialog). Selecting multiple items will display a placeholder text in that combobox (usually - italic, in gray, to make it visibly different; how will that work with Gnome themes?), which will be replaced the moment you type something in, or select a directory with the dialog, and will change the directory for all selected items. "Anonymity" spin and "Recursive" checkbutton do not require explanation. They also will change between items. Selecting multiple items will make "Recursive" go into 3rd state if items are inconsistent in that regard. Changing it will change "recursive" state for all selected items-to-be-downloaded. Files can't be downloaded recursively (right?), for them it will always be disabled. Same goes for anonymity (-1 when inconsistent? by the way, why it's a spin, not a drop-down list with pre-defined "0 - no anonymity", "1 - normal anonymity", "10 - paranoid" list, like in main window?) Extra columns will show all of the settings above for all items-to-be-downloaded. Cells should be clickable and editable, probably. At least filename column must be (as the widgets at the bottom have no filename entry). However, IMO re-naming files/directories that are to be downloaded is not something i'd like to do every day (and i think that other people won't want to as well), which is why it has no dedicated widget. The cells in filename column will show full filename relative to the directory where it's going to be downloaded to by default (with parent directories and all - up to, but not including, the destination dir). However, it will be changeable to anything (including absolute names?). Missing relative directories will be created automatically (i.e. ~/Downloads/foo/bar/ will be created if i decide to download a file as "foo/bar/ba.z" and "~/Downloads" is the destination directory), absolute directories will not be created (for security reasons; filename is suggested by metadata, so it's not trustworthy enough; destination directory is user-specified, anything relative to it is ok, except for ".."-ing out of it). I haven't decided yet whether items that are not to be downloaded will have something in these extra columns. But consider the case when you uncheck "Download it" on item that was to be downloaded - would be bad to just "forget" all options set up for it; maybe items that _are_ in the list should be shown as bold or italics or something, and items that are not in the list anymore will be shown normally - but will retain their extra columns info, if it's different from the defaults. The good part is that it doesn't pop up any dialogs in your face, unless you decide to press that direcory-chooser button (and you won't do that often). And it stays out of the way most of the time. The "download without asking" thing you've mentioned sounds good - except that we'd have to come up with anonymity level, recursiveness state and download directory for such cases. Download directory is not difficult (and, if it's downloading in a wrong dir, you can move it later). Recursiveness could be adjustable by a config entry (defaulting to "enabled"; obviously it's for directories). Now, anonymity is the problem. If we assume that users often use different anonymity levels, defaulting to any of them is bad. Re-using settings from the last "with asking" download also doesn't cut it (who knows, maybe my last heavily-tweaked download was a special case?). I have no idea whether it's possible to change anonymity, destination filename and recursiveness on items that are being downloaded already. Do we want to implement that at all? If we do, then it may be OK to use meaningful defaults. Otherwise it's better to not to rush things, since the only way to fix improper download options is to cancel the download and start it again (from a search result?). I don't envy myself, if i have to implement all that fancy UI though...Don't envy at all. |
|
|
I only partially like this idea. The additional recursive/destination/anonymity columns would be horrific, the list is already cluttered and too long. Also, the behavior of multi-selection cannot be done cleanly: imagine I pick files A and B and set anonymity to 5, and then I pick files B and C and enable recursive. Then I select files A and C. What do you show? "inconsistent" state for anonymity and recursion for the buttons in the bottom area? What if the filenames for A and B are identical (with different CHK). Now I pick ONE download directory. Clearly we should not try to store A and B both to the same file to disk, but how do we resolve the conflict? So this entire multi-selection part of the concept creates more problems than it solves IMO. A better, simpler method would be to use your idea of widgets at the bottom to address the issue of individual anonymity/recursion/target-directory selection without popping up a dialog: once you select a file, we display at the bottom a suggested target directory, your last anonymity level and the 'recursive' checkbox. User adjusts values if necessary and then confirms with 'ENTER', which starts the download also automatically moves to the next file in the list (if it exists). Sure, to download 100 files, I might have to push ENTER 100x. Or maybe I'm lucky and they are all in a directory and I just have to check recursive once. I still think that's acceptable (especially as we want to encourage directories), and IMO way easier to use (and implement, and check) than your proposal. |
|
|
The additional recursive/destination/anonymity columns would be horrific, the list is already cluttered and too long Yes, i thought so. This can be skipped, but then you'd have to add extra filename widget to the panel (since you won't have clickable-and-editable column cell for it), and it will be difficult to handle many items (you will be able to see only one item at a time). Any better ideas? Also, the behavior of multi-selection cannot be done cleanly: imagine I pick files A and B and set anonymity to 5, and then I pick files B and C and enable recursive. Then I select files A and C. What do you show? "inconsistent" state for anonymity and recursion for the buttons in the bottom area? What if the filenames for A and B are identical (with different CHK). Now I pick ONE download directory. Clearly we should not try to store A and B both to the same file to disk, but how do we resolve the conflict? Each item will have a set of defaults (probably configurable), so by default _everything_ will have, say, anonymity=1, recursive=no (for the sake of this example) and download directory "~/Downloads/". So after your modifications to A, B and C you'll have: A - anonymity 5, recursive = y, "~/Downloads/" B - anonymity 5, recursive = n, "~/Downloads/" C - anonymity 1, recursive = y, "~/Downloads/" If you select A and C, it will show inconsistent state for anonymity (that is why i don't like to use a spin - how can you make spinbutton inconsistent?), same download directory, and "Recursive" checked (unless either A or C are not directories, in which case it will be in 3rd-state; enabling it will obviously not have any effect on "Recursive" option for files - it stays disabled). Filename collisions (also applies to directories) is a separate problem. We could check for collisions, and refuse to proceed until that is fixed (also provide an option for GNUnet-GTK to just automatically add "(X)" or "-X" suffixes to the name), either as a pop-up dialog (yuck!), or yet another widget that only appears when a problem is detected, or an indicator that turns red when problem exists, and is gray/whatever when everything is OK (but that widget still needs to tell the user which files have collisions, somehow...). Maybe re-use filename entry (since it will have to be added, if we don't add extra columns), highlighting it in red if it collides when current filename/destination-directory are used (s/red/configurable color?/ - some colorblind person will eventually ask for that, we may as well anticipate that now). Also applies to overwriting existing files/directories (same problem, different angle). H-m-m-m... In Azureus, once you set up everything and click "OK" to start downloading, it will check for existing files being there (not sure how it handles collisions _inside_ the same torrent - never tried that), and pop up an OK/Cancel dialog with a list of existing files (OK - proceed to [possibly] rewrite existing files; Cancel - go back to download planning). If list is too long, it is cut short at, like, 5 items (list is shown vertically, one line per item). I mostly see that when downloading a different torrent with the same data as some other torrent (or re-seeding some torrent i previously seeded), but otherwise i don't see it much. Do we support resuming downloads (by means other than fetching cached blocks from the datastore)? Is it OK to create new files/directories in existing directory? Does it need extra checks (i.e. downloading gnunet-search.exe as "GNUnet/bin/gnunet-search.exe" relative to "~/Downloads/", when "~/Downloads/GNUnet/bin/" or "~/Downloads/GNUnet/" already exists - could we just go on without making a fuss)? A better, simpler method would be to use your idea of widgets at the bottom to address the issue of individual anonymity/recursion/target-directory selection without popping up a dialog: once you select a file, we display at the bottom a suggested target directory, your last anonymity level and the 'recursive' checkbox. User adjusts values if necessary and then confirms with 'ENTER', which starts the download also automatically moves to the next file in the list (if it exists). Sure, to download 100 files, I might have to push ENTER 100x. Or maybe I'm lucky and they are all in a directory and I just have to check recursive once. I still think that's acceptable (especially as we want to encourage directories), and IMO way easier to use (and implement, and check) than your proposal. Not 100x, 200x :) - that is, if extra widgets are hidden once you issue a download. We could also turn it into a kind of "download mode" - you start it by attempting to download an item, and then the widgets just stay there (and you'd be able to start the download with just one ENTER) until you press a button to explicitly exit that "download mode", in that case it will be "pressing ENTER 101x" to download 100 files. That still requires something for [eventually] already-existing files/directories (because you really had these files there already, or because you've just created them by starting a download). By the way, GTK+ (and everyone else) does this by throwing yet another pop-up at you ("Do you want to overwrite X? - yes/no", AFAIR). Although if you have Gnome 3, it will probably display popups in a nice way (by pretending that they are part of the window that issued them, and not a separate window). Not sure how it does that. Maybe that is just a feature of some apps (GEdit and filemanager come to mind). That, and Firefox, are the things that gave me the 'show extra widgets instead of popping up a dialog' idea. Another option is to do everything as i've said, but use separate dialog after all - it will have its own list of files-to-be-downloaded, to which you can add items from the main window at any moment (dialog won't be modal). With all the problems you've mentioned (and i deconstructed) above (i.e. multi-item selections, collision detection), but without cluttering the search results list with extra columns - this dialog will have its own list with _only_ columns relevant to download preparation, i.e. no description, preview, etc - assuming that the user will already have chosen a file (using that metadata) by the time it appears in that list; the list will also _only_ have to-be-downloaded items, without mixing them with other search results. I.e. user will just "throw" items into it, like a shopping basket (drag'n'drop should [someday] be supported for that - i prefer ENTER or double-clicks, but some people just _love_ dragging...), and then finally tweak the options and initiate the download. |
|
|
I agree with you that your answers (except for anonymity-spin button) are possible solutions, but I think you would agree with me that they are messy and non-obivous. If, OTOH, we prohibit selecting multiple items, then this issue doesn't even arise. And no, we would not need 200x ENTER strokes to download 100 files, as for me what you call "download mode" would be "always on" as soon as a (downloadable) file is selected. Once the download is in-progress, we could even swap the widgets for some that show more details about the download (0000918!). Finally, this would ALSO enable us to get rid of the context menu for aborting a download, and right-clicking is always awkward as most users don't realize that right-click is even an option. We already have the 'preview' and 'meta data' areas which adjust depending on which file is selected --- those ALSO don't work with multi-selection. Adding a third such area for the start-download/monitor-or-stop-download widgets would make a lot of sense to me. The rare case where someone wants to download thousands of files and individual selection (with arrow-up/arrow-down and ENTER) is not something I think we ought to strongly consider. |
|
|
Took a stab at it in r24916 |
|
|
A few comments on 24916. I got a bunch of new compiler warnings (with gcc -Wall), and a new (sadly irreproduceable and possibly unrelated) crash-on-exit. Other than that, yes, this is pretty close to what I was thinking. I think the bottom area could use a bit more padding. Also, somehow the preview no longer disappears if I first pick an image WITH a preview and then one WITHOUT an embedded preview. Not sure why. When I push "enter" with an item selected or pick just "Download" from the context menu, it still pops up a dialog (should just download directly IMO). Pushing the download button works nicely instantly, but fails to auto-select the next item in the list. But clearly a step in the right direction IMO. |
|
|
Ok, was able to reproduce the problem: start > 2 downloads, close download-TAB before they complete (so they go into the "*"-tab), then abort them there, then click on 'clean' (which fails to clean all the first time), click on clean again ("*"-tab now empty). Then try to close gnuent-fs-gtk. On my system, the process then just hangs. Again, not clear if this is related to 24916, but I didn't observe this before... |
|
|
Warnings - will fix later (mostly it's unused variables right now) Padding - why? Preview - already mantissed (and yes, it is probably caused by 24916) Enter pops up a dialog - i didn't delete old code, that'll come later. So right now ENTER still uses it. No auto-select next item - will fix later. Crash-on-exit - whoa, wicked stuff! |
|
|
Yes, it hangs up. Though it's enough to just start one download, close the search tab, abort the download in orphan tab, clean it, then close the main window to trigger that. |
|
|
Fixed preview. Added auto-selection Fixed crash on exit. |
|
|
Warnings: not urgent; padding: just for style, trivial to fix in glade, so no worries. |
|
|
I also now get (on startup): (gnunet-fs-gtk:22901): GLib-GObject-WARNING **: invalid cast from `GtkHBox' to `GtkButton' |
|
|
Diagnostics on the crash on shutdown: Core was generated by `gnunet-fs-gtk'. Program terminated with signal 11, Segmentation fault. #0 0x00007f6880cced94 in GNUNET_GTK_main_loop_get_configuration (ml=0x0) at eventloop.c:172 172 return ml->cfg; (gdb) ba #0 0x00007f6880cced94 in GNUNET_GTK_main_loop_get_configuration (ml=0x0) at eventloop.c:172 #1 0x000000000040ca17 in GNUNET_FS_GTK_get_configuration () at gnunet-fs-gtk.c:98 #2 0x000000000041087d in get_default_download_directory (buffer=0x7fff41d1e980 "\350\204p\002", size=4096) at gnunet-fs-gtk_event-handler.c:365 #3 0x0000000000410c5e in build_relative_name (tm=0x281a290, iter=0x7fff41d1fb10, finished_chain=0x7fff41d1fa2c, root_directory=0x7fff41d1fa68, relative_directory=0x7fff41d1fa60, anonymity=0x7fff41d1fa5c) at gnunet-fs-gtk_event-handler.c:547 #4 0x0000000000410f8b in get_suggested_filename_anonymity2 (tm=0x281a290, iter=0x7fff41d1fb10, download_directory=0x7fff41d1fae8, anonymity=0x7fff41d1fae4) at gnunet-fs-gtk_event-handler.c:648 #5 0x0000000000413f8b in GNUNET_FS_GTK_search_treeview_cursor_changed (tv=0x265ee40, user_data=0x279de00) at gnunet-fs-gtk_event-handler.c:1785 #6 0x00007f687e1cc9a7 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #7 0x00007f687e1e5006 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #8 0x00007f687e1e5852 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #9 0x00007f687fa0c853 in gtk_tree_view_real_set_cursor (tree_view=0x265ee40, path=0x282b850, flags=Unhandled dwarf expression opcode 0xf3 ) at /tmp/buildd/gtk+3.0-3.4.2/./gtk/gtktreeview.c:13298 #10 0x00007f687fa0f633 in gtk_tree_view_row_deleted (model=Unhandled dwarf expression opcode 0xf3 ) at /tmp/buildd/gtk+3.0-3.4.2/./gtk/gtktreeview.c:9130 #11 0x00007f687e1cc6e0 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #12 0x00007f687e1dd750 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #13 0x00007f687e1e56bc in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #14 0x00007f687e1e5852 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #15 0x00007f687f9fc131 in gtk_tree_store_remove (tree_store=0x281a290, iter=0x7fff41d205a0) at /tmp/buildd/gtk+3.0-3.4.2/./gtk/gtktreestore.c:1231 #16 0x00007f6880cd0148 in GNUNET_FS_GTK_remove_treestore_subtree (ts=0x281a290, root=0x7fff41d205a0) at glade.c:144 #17 0x0000000000413d61 in free_search_result (sr=0x282b1a0) at gnunet-fs-gtk_event-handler.c:1728 #18 0x0000000000418c1e in GNUNET_GTK_fs_event_handler (cls=0x0, info=0x7fff41d206a0) at gnunet-fs-gtk_event-handler.c:3733 #19 0x00007f687fe313b0 in GNUNET_FS_search_make_status_ (pi=0x7fff41d206a0, sc=0x2649570) at fs_search.c:60 #20 0x00007f687fe35235 in search_result_suspend (cls=0x2649570, key=0x7fff41d20790, value=0x270faf0) at fs_search.c:1351 #21 0x00007f688006b834 in GNUNET_CONTAINER_multihashmap_iterate (map=0x27b3250, it=0x7f687fe35138 <search_result_suspend>, it_cls=0x2649570) at container_multihashmap.c:326 #22 0x00007f687fe353fc in GNUNET_FS_search_signal_suspend_ (cls=0x2649570) at fs_search.c:1381 #23 0x00007f687fe1c800 in GNUNET_FS_stop (h=0x262c710) at fs_api.c:3026 #24 0x000000000040cc95 in shutdown_task (cls=0x0, tc=0x7fff41d20960) at gnunet-fs-gtk.c:213 #25 0x00007f688009062e in run_ready (rs=0x7f6870016be0, ws=0x7f68700045c0) at scheduler.c:597 #26 0x00007f6880090dfa in GNUNET_SCHEDULER_run (task=0x7f688008a2a0 <program_main>, task_cls=0x7fff41d20c00) at scheduler.c:785 #27 0x00007f688008acc7 in GNUNET_PROGRAM_run2 (argc=1, argv=0x7fff41d20ef8, binaryName=0x427232 "gnunet-fs-gtk", binaryHelp=0x4272b8 "GTK GUI for GNUnet", options=0x62dee0, task=0x7f6880ccf9ef <run_main_loop>, task_cls=0x7fff41d20d60, run_without_scheduler=0) at program.c:270 ---Type <return> to continue, or q <return> to quit--- #28 0x00007f688008ade8 in GNUNET_PROGRAM_run (argc=1, argv=0x7fff41d20ef8, binaryName=0x427232 "gnunet-fs-gtk", binaryHelp=0x4272b8 "GTK GUI for GNUnet", options=0x62dee0, task=0x7f6880ccf9ef <run_main_loop>, task_cls=0x7fff41d20d60) at program.c:305 #29 0x00007f6880ccfd8a in GNUNET_GTK_main_loop_start (binary_name=0x427232 "gnunet-fs-gtk", binary_help=0x4272b8 "GTK GUI for GNUnet", argc=1, argv=0x7fff41d20ef8, options=0x62dee0, main_window_file=0x427298 "gnunet_fs_gtk_main_window.glade", main_task=0x40cf9a <run>) at eventloop.c:912 #30 0x000000000040d791 in main (argc=1, argv=0x7fff41d20ef8) at gnunet-fs-gtk.c:557 |
|
|
HBox warning - fixed in r24925 crash - try r24926 |
|
|
Crash & warning are gone now. |
|
|
OK, i think it's done, more or less. If anything else is missing, do file another bug. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-11-05 21:59 | LRN | New Issue | |
| 2012-11-05 21:59 | LRN | File Added: Azureus_download.png | |
| 2012-11-05 22:07 | LRN | Note Added: 0006533 | |
| 2012-11-06 22:38 | Christian Grothoff | Note Added: 0006538 | |
| 2012-11-06 22:41 | Christian Grothoff | Note Added: 0006539 | |
| 2012-11-06 22:43 | Christian Grothoff | Note Added: 0006540 | |
| 2012-11-06 22:45 | LRN | Note Added: 0006541 | |
| 2012-11-06 22:46 | Christian Grothoff | Note Added: 0006543 | |
| 2012-11-06 23:07 | LRN | Note Added: 0006544 | |
| 2012-11-07 00:59 | LRN | File Added: GNUnet_download_as_alternative.png | |
| 2012-11-07 01:48 | LRN | Note Added: 0006547 | |
| 2012-11-07 23:33 | Christian Grothoff | Note Added: 0006551 | |
| 2012-11-08 03:44 | LRN | Note Added: 0006552 | |
| 2012-11-08 11:58 | Christian Grothoff | Note Added: 0006553 | |
| 2012-11-10 22:38 | Christian Grothoff | Relationship added | related to 0002522 |
| 2012-11-12 17:48 | LRN | Note Added: 0006572 | |
| 2012-11-12 19:53 | Christian Grothoff | Note Added: 0006573 | |
| 2012-11-12 19:54 | Christian Grothoff | Note Added: 0006574 | |
| 2012-11-13 01:53 | LRN | Note Added: 0006575 | |
| 2012-11-13 03:17 | LRN | Note Added: 0006577 | |
| 2012-11-13 07:05 | LRN | Note Added: 0006578 | |
| 2012-11-13 09:18 | Christian Grothoff | Note Added: 0006579 | |
| 2012-11-13 09:27 | Christian Grothoff | Note Added: 0006580 | |
| 2012-11-13 09:32 | Christian Grothoff | Note Added: 0006581 | |
| 2012-11-13 09:44 | LRN | Note Added: 0006582 | |
| 2012-11-13 09:54 | Christian Grothoff | Note Added: 0006583 | |
| 2013-03-14 07:55 | LRN | Note Added: 0006963 | |
| 2013-03-14 07:55 | LRN | Status | new => resolved |
| 2013-03-14 07:55 | LRN | Resolution | open => fixed |
| 2013-03-14 07:55 | LRN | Assigned To | => LRN |
| 2013-03-18 14:57 | Christian Grothoff | Product Version | => Git master |
| 2013-03-18 14:57 | Christian Grothoff | Fixed in Version | => 0.10.0 |
| 2013-03-18 14:57 | Christian Grothoff | Target Version | => 0.10.0 |
| 2013-12-24 20:55 | Christian Grothoff | Status | resolved => closed |
