Re: [Deskbar] Regressions in new UI

[Sebastian Pölsterl <marduk k-d-w org>]

-----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-----