-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mikkel Kamstrup Erlandsen schrieb: >>> * Hits pane partially obscured on first view >>> >> I don't understand. What do you mean exactly? > > Ok, I was planning to expand that a bit before hitting "send" - I see > I missed it :-) What I meant is also visible in your latest screencast > http://www.k-d-w.org/clipboard/deskbar_newest.ogg. When the results > appear almost half of the UI is fliied with blank space and the result > strings are partially obscured. > > I think it would make sense to hide that right pane, and perhaps show > those actions in another way. I'm wondering if it was possbile to use > the new tooltip api for this. If I'm not mistaken you can have > tooltips on specific cells in a treeview now. The tooltip could look > like this: > > ------------------------------------- > | | > | [Copy to clipboard] (ctrl-1) | > | [View foobar] (ctrl-2) | > | | > ------------------------------------- > > The text in square brackets would be a hoover-button. The keyboard > shortcuts are just enumerated by Ctrl-N for quick access. This might > be a lot of work though. > I think I just hide the actions treeview and if a match is selected hide matches treeview and show the actions treeview. That way only one treeview would be visible at one time and more horizontal space is available.
>>> * Invalidated a whole slew of 3rd party handlers without warning - do >>> you realize how many are out there? I strongly suggest creating a >>> LegacyModuleLoader or something so old handlers work without >>> modification. And this should be done really soon. >>> >> It should open a dialog a startup and warn you about outdated handlers. >> If you didn't see it I have to check the code again. I really don't see >> a posibility to support old handlers as well. The new API is just too >> different from the new one. I now that many people will get mad about >> this, but supporting two different APIs does no good in the long term. > > That really depends on how hard it is to maintain backwards > compatibility. If it is not really tricky I think it is worth it. > I think it is difficult, but I didn't try it, yet. >>> * Not closing result window after match selection. >>> >> You should enable this behavior in preferences. > > What I meant to say is that this should probably be the default behavior. > It is now. >>> IDEAS >>> * History view - how about only displaying either history or the search >>> results? Just show history when the applet is shown without a search >>> string (it should have a visible "History" label somewhere to not >>> confuse people). The mantra should be: "As little in the UI as possible, >>> but shortest route to funtionality". >>> >> hmm, I like the history as it is now. Nevertheless, I won't make sense >> if I remove the menu at the top as Vincent requested. Currently, I have >> no idea where to put the history in that case. > > The current idea with a combobox seems like a good one. But how do you > activate it via the keyboard? > You can press tab to focus the history and then enter to open the combobox, but I will add an accelerator/mnemonic to do this in one step. - -- Greetings, Sebastian Pölsterl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGwBqq1ygZeJ3lLIcRAqp0AKCAWQHCa5T2CNpU4arGkG+/2boE4gCgkkYb hokFPAGgHZ6xEOgj6R2YWsg= =jCCA -----END PGP SIGNATURE-----
_______________________________________________ deskbar-applet-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/deskbar-applet-list
