View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001966||gnunet-gtk||gnunet-fs-gtk||public||2011-11-26 16:02||2012-02-14 21:16|
|Summary||0001966: GUI master-issue|
|Description||This issue is supposed to host the GUI discussion (mainly - for gnunet-fs-gtk, but also for other gnunet-*-gtk applications), with mockups, concepts, ideas, etc.|
When a particular issue becomes clear and detailed enough, it will be filed as a separate issue, and this issue will be made dependent upon it (P.S. who has the rights to add issue dependencies?). This issue collects sub-issues targeted at GNUnet 0.9. Features/improvements staged for later GNUnet releases will be (hopefully) collected in a separate issue.
Reminder: link to other issues by prefixing their numbers with a hash (shift+3), link to other comments by prefixing their numbers with a tilde (shift+`).
* Pick the next available number and make your suggestion as "NUMBER) SUGGESTION".
* Make it a suggestion, not a question (RTFM/watch GHM 2010 video/chat in IRC before commenting).
* Don't branch suggestions off. Keep the relevant discussion in same-numbered comments, until something is decided upon.
* Once some conclusion is reached, the FIRST comment with that number will be edited (by suggestion author or by a moderator) to contain the result (accepted/rejected/postponed/fixed/etc). Suggestion is enclosed into a "pre" tag, result - in a "b" tag, comment to the result is made in normal text. Sadly, Mantis does not have an "s" tag to strike out completed discussions.
* The rest of the comments with the same number will be left as-is.
|Tags||No tags attached.|
|parent of||0001947||closed||Christian Grothoff||support download-by-URI|
|parent of||0001946||closed||LRN||add button for keyword normalization|
|parent of||0001483||closed||Christian Grothoff||URIs should be copyable/selectable|
|parent of||0001119||confirmed||different view modes for search results (namespaces adaptable)|
|parent of||0001759||closed||LRN||gtk_dialog_run is bad as it stops the GNUnet scheduler loop as well|
|parent of||0001943||closed||Christian Grothoff||gnunet-peerinfo-gtk needs to be fully implemented|
|parent of||0001949||closed||Christian Grothoff||have context menus for various operations|
|parent of||0001950||closed||Christian Grothoff||show 'progress' dialog / window during directory scan for publishing|
|parent of||0001951||closed||namespace list in search dialog should offset our own namespaces|
|parent of||0001952||closed||Christian Grothoff||namespace list in search dialog should have context menu|
|parent of||0001954||closed||Christian Grothoff||Have a nice way to report operational errors|
|parent of||0001944||closed||LRN||mime-type selection|
|parent of||0001945||closed||Christian Grothoff||implement unindex|
|parent of||0001948||closed||act on drop / paste actions of URIs|
|parent of||0001052||closed||Christian Grothoff||Implicit actions triggered by pasting...|
|parent of||0001791||closed||Christian Grothoff||gnunet-statistics-gtk is not implemented|
|parent of||0001083||closed||Christian Grothoff||associate actions to gnunet-gtk in nautilus/konqueror and web browsers|
|parent of||0000918||acknowledged||per block download visualisation|
|Not all the children of this issue are yet resolved or closed.|
Currently unresolved GUI issues that existed before this issue was filed:
0001947 support download-by-URI
0001946 add button for keyword normalization
0001483 URIs should be copyable/selectable
0001119 different view modes for search results (namespaces adaptable)
0001759 gtk_dialog_run is bad as it stops the GNUnet scheduler loop as well
Currently unresolved GUI issues that existed before this issue was filed:
0001943 gnunet-peerinfo-gtk needs to be fully implemented
0001949 have context menus for various operations
0001950 show 'progress' dialog / window during directory scan for publishing
0001951 namespace list in search dialog should offset our own namespaces
0001952 namespace list in search dialog should have context menu
0001954 Have a nice way to report operational errors
0001944 mime-type selection
0001945 implement unindex
0001948 act on drop / paste actions of URIs
0001052 Implicit actions triggered by pasting...
Currently unresolved GUI issues that existed before this issue was filed:
0001791 gnunet-statistics-gtk is not implemented
0001083 associate actions to gnunet-gtk in nautilus/konqueror and web browsers
0000918 per block download visualisation
OK, now, let's start with what i think is wrong with the GUI:
1) Search box should be part of the main window, not a separate dialog (not to mention that search dialog is currently funky - has lots of stuff in it, but it isn't used).FIXED. Fixed in 0001759
That's all for now, until i compile gnunet-fs-gtk and get some fresh impressions.
There was a discussion ( https://gnunet.org/bot/log/gnunet/2010-07-05 ) of a mockup ( https://ng.gnunet.org/sites/default/files/gnunet%20UI%20mockup.png ).
About anonymity slider:
2) Anonymity slider should be separate for every action (i.e. search anonymity, download anonymity, publish anonymity). This is obvious.DROPPED. No slider, change anonymity levels by editing .glade file.
3) The number of positions a slider has should be configurable. I think gnunet_slider_mockup.png shows it. Obviously, a reasonable default configuration will be provided. And of course, all of this will be on some "preferences" tab (since it's not clear how to do dialogues without messing up scheduling), which usually hidden out of sight.DROPPED. No slider, change anonymity levels by editing .glade file.
4) There will be a separate tab to manage your own pseudonyms (add/remove/(rename?change metadata? can you do that after a pseudonym is created?); also sort - since your pseudonyms will be later shown to you in some kind of list when you make a publication).ACCEPTED.
5) There might be a separate tab to view and manage known 3rd-party pseudonyms (AFAIR, pseudonyms might have some meta-data, and users should be able to see it, but we don't want to show it all the time; in other contexts pseudonyms will only be shown by name). You can change their names from automatically-assigned to user-assigned, and sort them. You should be able to add new ones by various means (clicking on a pseudonym URI somewhere else; pasting a pseudonym URI, drag'n'dropping a pseudonym URI; adding pseudonyms from search results will be handled by the search tab).POSTPONED. Will be done at some point, when the number of namespaces increases significantly.
6) Searching in namespaces. Do we want/have a special query language (such as "mime:audio/mpeg size:>=10MiB namespace:coolaudiorecordings crushing nuts")? Or do we put a several editboxes/dropdownlists, each one defining one constraint for a search query? Maybe adding them on the fly, so that there's always an empty one to the right, and when you change its contents, a new empty box appears further to the right. Will we run out of screen space? Do we save queries, if they can become so complex (deniability implications)?POSTPONED. Query complexity will not increase in foreseeable future.
7) Publishing GUI. Metadata editing should be re-made. Right now it's a listbox with two columns "Type" and "Value". Entries are added by selecting the type in yet another listbox, and typing in a value in an edit field, then pressing "Add". Instead the listbox should have editable items - "Type" should be a dropbox (or combobox, if non-standard types are allowed), and Value should change depending on what type it is (for some types it makes sense to use a dropbox, for others - simply an edit field, and for some a spinbox is the right thing). Enties should be added by pressing "Add", which will add an empty (or, to be precise, uninitialized) Type-Value row to the listbox. Alternatively, as a quick hack, "Delete" button could be rigged to change current selection in "Type" listbox, and fill the edit field with the value of the deleted entry. That way you can delete an entry, edit it (since its contents are now in the listbox and the edit field), then add it back.REJECTED/ACCEPTEDMostly rejected. Delete quick hack is accepted.
||Uploaded gnunet-gtk_001.png - a mockup (this time - made in Glade) for (1)|
8) Persistent downloads and publications. People would ask for them. Also, the way things are handled now is somewhat strange: * GNUnet runs as a background daemon, is designed with that in mind. * It can't download (can it publish? I mean indexed files?) without a client application (such as gnunet-fs-gtk or gnunet-download) * gnunet-fs-gtk, when closed, is not put into tray, it IS closed, and closes FS along with itselfREJECTED/ACCEPTED. Persistent (in daemon) downloads are bad. Persistent (across GNUnet client restarts) downloads are implemented, but untested. All publications are persistent (in daemon). gnunet-unindex will also show currently active indexed publications.
9) Controlling GNUnet ARM from within gnunet-fs-gtk. Is that going to be implemented at all? At least, some connection indicator would be nice.REJECTED. At least for now. ARM is controlled by the system, users are not encouraged to mess with it.
||6) If we ever support such complex queries, I'd definitely say have many boxes instead of a complex query language; I'm not sure this feature should be high on our priority list.|
7) Nah, the vision here is very different, going in line with 0001119 the long-term vision is to have content-specific publishing dialogs (i.e. if you publish music, you get a mask that provides entries for meta data that makes sense for music; if you publish books, you get a mask that is specific too books/articles (and maybe a bibTex-import...). Similarly, the vision of 0001119 is that we'll use a similar 'custom' view for the results / directories depending on the content category.
As for the 'generic' publishing dialog, I should say that "custom" / non-standard types are not supposed to be allowed.
I do like the suggestion for 'Delete'.
||8) indexed files remain available even if the GUI is gone. And yes, the 'persistent' downloads issue has been discussed in the past, but is not really practical for various reasons (permissions prevent ARMing such a service, seriously complicates the code, etc.). I think putting gnunet-fs-gtk into tray mode to "background" download is fine. Also better than having stuff go on in the background that the user doesn't know how to stop anymore (and has long forgotten about).|
9) My plan was to have a gnunet-peerinfo-gtk which will provide "connection" information and then there is supposed to be some way to start any of the -gtk GUIs from any of the other -gtk GUIs (so for example a button to start gnunet-statistics-gtk from gnunet-fs-gtk and vice versa; ditto for gnunet-peerinfo-gtk and maybe also for gnunet-setup [but that may cause problems]).
What we need first for this is a way to detect (and communicate with) a running instance of our GTK GUIs. I'm still not sure which mechanism should be used here (D-bus? RPC? GNUnet-IPC? other?). We also need this for URI-dropping, etc.
8) The problem is that closing gnunet-fs-gtk client irreversibly closes the downloads you've had, and there's no way to bring them back. While it might not be feasible to keep downloading without a client application, it SHOULD be possible to save the downloads when quitting the client and continue them once the client is started again.
9) I think it's better to use GTK facilities for URI dropping.
For detection and communication - well, it depends. But i'd like you to NOT to use D-bus, if you can help it. I've had problems compiling D-bus for W32.
||8) There should be a way to show the user which files are indexed.|
8) closing gnunet-fs-gtk will not irreversably close active downloads; they should be safed by default. The code is there, it has just not been tested and is thus deactivated. That's what the comment here is about:
fs = GNUNET_FS_start (GNUNET_GTK_main_loop_get_configuration (ml),
"gnunet-gtk", &GNUNET_GTK_fs_event_handler, NULL,
/* fixme later for persistence/probes */ ,
/* set other options here later! */
Just setting the right flag here will address that issue.
||9) I've also heard not-so-flattering comments about D-bus and I agree with using GTK-facilities for URI dropping. But for stuff like browser-integration, we'll need a way for command-line level interaction (no X11-stuff).|
||8) That's part of 0001945.|
10) i agree that a growing term string similar to newegg's search, and custom dialogs for each data type would make sense, when searching for, and downloading music, books, research papers, etc.REJECTED. Not a suggestion, just an opinion (also duplicates (1) and (7)).
11) i think that uri handling and drag and drop are essential, as would handing opening files with gnunet. you should be able to import keys with a doubleclick, and you should be able to copypaste as well as open uris easily with gnunet.ACCEPTED. Will be fixed in 0001483 and 0001052
as for 9) i agree that we'll want to use the gui toolkit to handle the uri dropping.
8) there really should be a way to minimize active gnunet downloads to the tray, rather than irreversibly closing them.
1) search box should definitely be part of the main dialog.
12) a peerlist with detailed information on active connections, including ip:port and rx/tx information (since this can be easily obtained anyway by monitoring with tcpview or netstat or wireshark or something. if you're not directly connected to a peer, it should indicate that.ACCEPTED. Will be fixed in 0001943 and 0001791
13) easy bootstrap. you'll need to bootstrap more often than "once in your lifetime" so this part should not be neglected. HELLO packets should be able to be copy/paste'd from instant messengers and email and irc.ACCEPTED. Accepted as 0002010
14) "realtime mode" button (i may submit a feature request separately to reference this) should be a button on the main pane, and should automatically be enabled when videocalling (future feature?) or establishing a game-vpn (encrypted low-latency game-oriented virtual private network at layer 2 (tap drivers))REJECTED. Not relevant to gnunet-fs-gtk (this is a suggestion for a low-latency gnunet-based application, while gnunet-*-gtk application group currently has no such application, and it is not planned). Also, it has technical problems.
15) a clean settings/preferences tab should clearly have "cache size" in the main dialog (not in the "advanced" dialog)REJECTED. Not relavent to gnunet-setup (suggestion is based upon gnunet-0.8.1b GUI).
7) The publishing dialog should have custom dialogs for each content type. just as searching should have custom dialogs.
8) Maybe the download process can be seperated from the main gui, so it can separately run until finished, and then close on its own? it could run in the tray separately from the main gui? just an idea, maybe not a good one.
16) regarding the gui, the welcome screen should have basic stats on the bottom, and a search bar on the top which suggests search queries. (i have no idea how that would be implemented) maybe a basic search and an advanced search? the advanced search would open a custom dialog for the content type?ACCEPTED. There is a status bar (currently empty) do display basic stats or something similar. Search bar is implemented in 0001759.
REJECTED. No welcome screen in 0.9 (yet?). Search suggestions are technically difficult and deanonymizing.
ACCEPTED/REJECTED. All searches are uniform (keywords, with optional namespace and/or mime-type keywords), but search results are pre-viewed depending on their contents.
||16) i could create a mockup with Dia if you'd like.|
12) regarding the peerlist, if not directly connected, the number of hops, if known, should be indicated.
17) bandwidth dedicated to gnunet should be configurable in the main edit > preferences dialog, rather than in the advanced dialog. gnunet should try to go out of its way to make use of the bandwidth dedicated to it.FIXED. gnunet-setup already configures bandwidth. gnunet already utilizes it completely (or should do so).
18) a peers tab with highly detailed information on status, bandwidth, connection type (direct/indirect, # of hops, latency, etc) should be colorized with basic status. maybe even two dialogs, one with /connection/ status, versus high-level /peer/ status.ACCEPTED. Will be fixed in 0001943
19) peer identifications should be selectable, and you should be able to right click, and be able to copy a uri containing the identity to clipboard.ACCEPTED. Will be fixed in 0001483
||14) on "realtime mode" the anonymity would be set to "None" (preferably selectively for connections required for realtime communications, such as videoconferencing, while leaving existing downloads at full anonymity levels), in order to lower latency, while maintaining end-to-end encryption, and if necessary, distance vector routing. this would be used mostly by future implementations of gnunet-psyc-gtk|
16) I don't think that search suggestions are possible. Keywords are not shared when search queries are sent, thus there's no good way to collect "what other people are searching" kind of statistics to serve as a base for suggestions. Completing from your own previous searches should be possible, but it might significantly reduce your deniability.
8) Separating downloads is technically possible (gnunet-download IS a separate application, for example). Separating it on the fly might also be possible. Not sure why this would be needed though.
17) and 15) - There is no preferences dialog in gnunet-fs-gtk. Configuration is done via gnunet-setup (if you are referring to gnunet-setup, then i have nothing to say on the matter)
14) Because anonymity is set separately for each action, the application that requires lower latency can certainly do that. Point is, that would be some other application, not gnunet-fs-gtk, because gnunet-fs-gtk is for file-sharing only. Also, i'm not sure that you can get really low (realtime-like) latency, even if anonymity is set to zero.
On most of the other points there's nothing more to say, we agreed to that they are required, the only thing left is implementing these :)
16) okay, probably a bad idea.
17) and 15) okay. gnunet-setup is the generic preferences dialog?
14) i must be thinking of gnunet-psyc-gtk. nvm. i thought this was "the gui thread"
20) on filesharing speed, is there a way to configure how many peers you download from at one time? or is that possible? do you download only from a single peer?REJECTED. Not a suggestion, not even a GUI suggestion.
FIXED. Number of neighbors is configurable. gnunet downloads from multiple nodes.
21) if downloading from multiple peers/multiple circuits is possible, this should be the default, even when downloading by clicking a uri.FIXED. This is the default.
22) clicking download uris should seamlessly start the download, if identifying a specific thing. not sure how search links should be handled. as in, should we go ahead and start the search, or popup a confirm dialog?REJECTED. Seamless download initiation does not allow for anonymity level to be set, thus we have to ask user every time a download URI is clicked. Same for searches.
23) on filesharing speed configuration, you should be able to select a peer, and give it preferential treatment (in other words, prefer traffic from/to it when deciding which packet to send/recv)REJECTED. Handled automatically by the economy.
24) when downloading a file, there should be a way to "burst" the speed, in other words, for a short period of time, dedicate more bandwidth, processor strength, memory, and such, in order to accelerate a downloading or uploading file. this should not freeze the desktop, but should make it noticeably less responsive. When bursting a download or publication, (hurry, hurry!!) the gnunet should attempt to publish or download as quickly as one's peers allow for it, above and beyond normal configuration. if clicked repeatedly, the brief period should be extended by one-half the previous amount. The "Hurry!" button should be omnipresent (outside of the tabs, next to the basic searchbar.)REJECTED. Technically difficult. Non-anonymous. Requires influencing 3rd-party nodes, which is not possible.
25) anonymous atomfeed-like functionality, to recv notifications of new information you are subscribed to, in order to recv a uri to download a new publication automatically. This should be easy to use, especially for publication. you should be able to easily publish video, imagines, and audio to a newsfeed, which would be automatically downloaded by your subscribers.POSTPONED. Technically doable (continuous search in a namespace + automatic download, anonymity levels are pre-configured). Not required by anyone in foreseeable future. Can be implemented in a separate application.
23) Economy model should take care of that to some extent. I'm not sure how preferential treatment would reflect on your (or that peer's) anonymity.
24) It's complex. Also, you can't force other peers to work faster (although you could rise the value of the queries you send; but then, you'd probably not use GAP in burst mode). Also it's probably highly deanonymizing.
25) It could be possible to rig something like "keep searching for FOO indefinitely, and downloading everything you find, automatically". Most likely you'd need a namespace for that.
25) anonymous pubsub /should/ soon be supported by gnunet-psyc-gtk, but that's future roadmap functionality, what we want to ensure is that gnunet-fs-gtk is capable of handling the uris silently, beginning downloads automatically.
25)hmm namespaces might be the answer in the short term, but a dedicated pubsub model using psyc/secushare/sesha would be preferred. hmm. i suppose ..
Indefinite searching for publications by specific identities/addresses/pubkeys -- that could be a juryrigged pubsub-like functionality. you could use someone's identity as the search, and then the specific channel of content as the namespace. combined, you get a "feed" of publications.
This discussion is getting totally unreadable, I was wondering what point there was in having a 'master-issue', and clearly the answer is that it is not terribly useful: can this bug ever be "resolved"? We now talk about FS-GUI, peerinfo-GUI, setup-GUI and also PSYC-GUI in one big mess as if they were even all that related. Dozens of sub-points have been added which might have had reasonable discussions as individual bugs, but here are just getting impossible to follow and implement.
I would urge you to file open points for discussion and open feature requests as separate bugs and discuss them there. To encourage this, I'll not participate in the detailed discussion here anymore ;-).
|2011-11-26 16:02||LRN||New Issue|
|2011-11-26 16:04||LRN||Note Added: 0004987|
|2011-11-26 16:07||LRN||Note Added: 0004988|
|2011-11-26 16:09||LRN||Note Added: 0004989|
|2011-11-26 16:12||LRN||Note Added: 0004990|
|2011-11-26 17:12||LRN||File Added: gnunet_slider_mockup.png|
|2011-11-26 17:14||LRN||Note Added: 0004991|
|2011-11-26 17:32||LRN||Note Added: 0004992|
|2011-11-26 18:22||Christian Grothoff||Relationship added||parent of 0001947|
|2011-11-26 18:22||Christian Grothoff||Relationship added||parent of 0001946|
|2011-11-26 18:22||Christian Grothoff||Relationship added||parent of 0001483|
|2011-11-26 18:23||Christian Grothoff||Relationship added||parent of 0001119|
|2011-11-26 18:23||Christian Grothoff||Relationship added||parent of 0001759|
|2011-11-26 18:23||Christian Grothoff||Relationship added||parent of 0001943|
|2011-11-26 18:23||Christian Grothoff||Relationship added||parent of 0001949|
|2011-11-26 18:23||Christian Grothoff||Relationship added||parent of 0001950|
|2011-11-26 18:23||Christian Grothoff||Relationship added||parent of 0001951|
|2011-11-26 18:23||Christian Grothoff||Relationship added||parent of 0001952|
|2011-11-26 18:23||Christian Grothoff||Relationship added||parent of 0001954|
|2011-11-26 18:24||Christian Grothoff||Relationship added||parent of 0001944|
|2011-11-26 18:24||Christian Grothoff||Relationship added||parent of 0001945|
|2011-11-26 18:24||Christian Grothoff||Relationship added||parent of 0001948|
|2011-11-26 18:24||Christian Grothoff||Relationship added||parent of 0001052|
|2011-11-26 18:24||Christian Grothoff||Relationship added||parent of 0001791|
|2011-11-26 18:24||Christian Grothoff||Relationship added||parent of 0001083|
|2011-11-26 18:24||Christian Grothoff||Relationship added||parent of 0000918|
|2011-11-26 18:24||Christian Grothoff||Summary||GUI master-issue 0.9.0 => GUI master-issue|
|2011-12-05 08:55||LRN||Note Added: 0005009|
|2011-12-08 09:27||LRN||File Added: gnunet-gtk_001.png|
|2011-12-08 09:28||LRN||Note Added: 0005023|
|2011-12-11 02:41||LRN||Note Added: 0005028|
|2011-12-11 14:37||Christian Grothoff||Note Added: 0005031|
|2011-12-11 14:40||Christian Grothoff||Note Added: 0005032|
|2011-12-11 14:43||Christian Grothoff||Note Added: 0005033|
|2011-12-11 14:45||Christian Grothoff||Note Added: 0005034|
|2011-12-11 15:21||LRN||Note Added: 0005035|
|2011-12-11 15:22||LRN||Note Added: 0005036|
|2011-12-11 15:47||Christian Grothoff||Note Added: 0005037|
|2011-12-11 15:48||Christian Grothoff||Note Added: 0005038|
|2011-12-11 15:48||Christian Grothoff||Note Added: 0005039|
|2011-12-12 01:34||LRN||Note Edited: 0004991|
|2011-12-12 01:34||LRN||Note Edited: 0004990|
|2011-12-13 02:50||coyo||Note Added: 0005063|
|2011-12-13 02:51||coyo||Note Added: 0005064|
|2011-12-13 03:03||coyo||Note Added: 0005065|
|2011-12-13 03:06||coyo||Note Added: 0005066|
|2011-12-13 03:11||LRN||Note Added: 0005067|
|2011-12-13 03:12||LRN||Note Edited: 0005067|
|2011-12-13 03:22||coyo||Note Added: 0005068|
|2011-12-13 03:35||coyo||Note Added: 0005069|
|2011-12-13 03:43||coyo||Note Added: 0005070|
|2011-12-13 03:54||LRN||Note Added: 0005071|
|2011-12-13 03:56||coyo||Note Added: 0005072|
|2011-12-13 04:28||coyo||Note Added: 0005073|
|2011-12-13 11:04||Christian Grothoff||Note Added: 0005074|
|2011-12-13 12:27||LRN||Note Edited: 0004991|
|2011-12-13 12:30||LRN||Note Edited: 0004992|
|2011-12-13 12:32||LRN||Note Edited: 0005009|
|2011-12-13 12:34||LRN||Note Edited: 0005028|
|2011-12-13 19:51||LRN||Note Edited: 0005028|
|2011-12-13 19:55||LRN||Note Edited: 0005028|
|2011-12-13 20:24||LRN||Note Edited: 0005063|
|2011-12-13 20:27||LRN||Note Edited: 0005065|
|2011-12-13 20:33||LRN||Note Edited: 0005068|
|2011-12-13 20:34||LRN||Note Edited: 0004990|
|2011-12-13 20:34||LRN||Note Edited: 0005068|
|2011-12-13 20:40||LRN||Note Edited: 0005069|
|2011-12-13 20:43||LRN||Note Edited: 0005070|
|2011-12-13 20:44||LRN||Note Edited: 0005071|
|2011-12-13 20:44||LRN||Note Edited: 0005072|
|2011-12-13 20:45||LRN||Note Edited: 0005073|
|2011-12-13 20:55||LRN||Description Updated|
|2011-12-13 21:00||LRN||Relationship added||parent of 0002010|
|2011-12-13 23:13||Christian Grothoff||Relationship deleted||parent of 0002010|
|2012-02-03 23:12||Christian Grothoff||Assigned To||=> LRN|
|2012-02-03 23:12||Christian Grothoff||Status||new => closed|
|2012-02-03 23:12||Christian Grothoff||Resolution||open => suspended|
|2012-02-14 21:16||Christian Grothoff||Category||=> gnunet-fs-gtk|