Re: [Deskbar] Regressions in new UI

["Mikkel Kamstrup Erlandsen" <mikkel kamstrup gmail com>]

2007/8/11, Sebastian Pölsterl <marduk k-d-w org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mikkel Kamstrup Erlandsen schrieb:
> > Hi all!
> >
> > I'm testing out the new deskbar-applet in Gutsy Gibbon and I must admit
> > that it is quite a bumpy ride :-)
> >
> Keep in mind that I commited quite some changes since the 2.19.6.1 release.

Yes, I'm aware things are quite in flux :-)

> > Sebastian, please do not take this as a critique of your work, I really
> > like what you are doing, and I can appreciate that it is hard and tricky
> > work :-)
> >
> > Here's a list of regressions that I spotted on the first go:
> >
> > FUNCTIONALITY REGRESSIONS
> >
> >  * Does not scale to view all results if window is to small
> >
> I'm not sure if it's a good idea that the windoe resizes itsself each
> time when I search for something. I was thinking about adding Tooltips
> for each item in match and actions treeview. Would this help?

I think you are right that the window size should not change. It is
still however a regression compared to the old ui, where in almost all
my searches all results where visible. I can off course just resize
the window and keep it big.

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

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

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

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

Cheers,
Mikkel