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.

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.

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 itself

REJECTED/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.

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.

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

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.