Regressions in new UI

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

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

>  * Hits pane partially obscured on first view
> 
I don't understand. What do you mean exactly?

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

> NAVIGATIONAL REGRESSIONS
> I consider these serious because we have a very big
user base that will
> have a forced change of habits, that I assure you will
be frustrating to
> many people. Changing the default navigational patterns
should not be
> taken lightly.
> 
I try to improve usability as much as possible and I'm happy
about every
input.

>  * Does not hide on Esc
> 
I'm working on that.

>  * Type search, hit down-arrow does not focus results
> 
It does that on my machine (might be that I use svn trunk,
but I don't
think so)

>  * Does not go to top if hit down on bottom hit
> 
>  * Does not go to bottom hit if hitting up on from
search entry.
> 
I try to support your request.

>  * Not closing result window after match selection.
> 
You should enable this behavior in preferences.

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

- --
Greetings,
Sebastian Pölsterl

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFGvbEB1ygZeJ3lLIcRAv06AKCJp5IkdlplBXYHFW0uZCMFohOZtgCg
pve/
M0n9fVHQ+d8lboYpKTooxbU=
=Ir9Z
-----END PGP SIGNATURE-----
_______________________________________________
deskbar-applet-list mailing list
deskbar-applet-listgnome.org
http://mail.gnome.org/mailman/listinfo/deskbar-applet-
list

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

In the long term, supporting two different APIs is
undesirable.
However, going from working to broken, without a
working-but-deprecated step in between, from one stable
release to the
next, is too severe.

Can you document the old and new handler APIs, and whether
it's
possible to write an adapter class to convert from old to
new?  It
should be straightforward to detect if a Handler class is
old or new,
e.g. if it does not implement some methods that are
mandatory in the
new API, then we can presume that it is an old-style
Handler.
_______________________________________________
deskbar-applet-list mailing list
deskbar-applet-listgnome.org
http://mail.gnome.org/mailman/listinfo/deskbar-applet-
list

On 12/08/07, Nigel Tao <nigel.tao.gnomegmail.com> wrote:
> Can you document the old and new handler APIs, and
whether it's

Ah, I see that there's documentation on the new handler APIs
at
h
ttp://www.k-d-w.org/deskbar/new-style_modules.html


> possible to write an adapter class to convert from old
to new?

Now, are there docs on how to port an old-style handler to a
new one?
(Even if there were, I would still like to see an adapter
class
available.)
_______________________________________________
deskbar-applet-list mailing list
deskbar-applet-listgnome.org
http://mail.gnome.org/mailman/listinfo/deskbar-applet-
list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nigel Tao schrieb:
> On 12/08/07, Nigel Tao <nigel.tao.gnomegmail.com> wrote:
>> possible to write an adapter class to convert from
old to new?
> 
> Now, are there docs on how to port an old-style handler
to a new one?
> (Even if there were, I would still like to see an
adapter class
> available.)
> 
No, I didn't write a guide how to port old-style handlers.
It might be
very useful. I'm not sure about the adapter class. I'm
currently really
busy to get the GUI right. If someone wants to write an
adapter I will
support him, but my priority is GUI right now.

- --
Greetings,
Sebastian Pölsterl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFGvth01ygZeJ3lLIcRAufNAKCJL7PwY5VoIRmNG2g1/WSA+/35wQCf
R5Xd
bBwRdbGwjJNhvPF/DMfseEg=
=xGAq
-----END PGP SIGNATURE-----
_______________________________________________
deskbar-applet-list mailing list
deskbar-applet-listgnome.org
http://mail.gnome.org/mailman/listinfo/deskbar-applet-
list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I worked my butt off today.

The work isn't completely finished. Some minor features are
still
missing (saving window position, hitting down on last item
selects first
item, ...).

You can see the results at htt
p://www.k-d-w.org/clipboard/deskbar_newest.ogg

Hopefully, I make some people happy this way (I already
achieved to make
them angry ;)

I will do the final polish tomorrow to get finshed before UI
freeze.
Wish me luck.

- --
Greetings,
Sebastian Pölsterl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


iD8DBQFGv4XE1ygZeJ3lLIcRAnkeAJ0YNRw70MYJ48pzjEWeIHjFyn925ACe
JFGs
tUILuwaRLWapoHTQ3I/XrgQ=
=5s55
-----END PGP SIGNATURE-----
_______________________________________________
deskbar-applet-list mailing list
deskbar-applet-listgnome.org
http://mail.gnome.org/mailman/listinfo/deskbar-applet-
list

2007/8/11, Sebastian Pölsterl <mardukk-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
ht
tp://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
_______________________________________________
deskbar-applet-list mailing list
deskbar-applet-listgnome.org
http://mail.gnome.org/mailman/listinfo/deskbar-applet-
list

-----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
> ht
tp://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+/2boE4gCg
kkYb
hokFPAGgHZ6xEOgj6R2YWsg=
=jCCA
-----END PGP SIGNATURE-----

_______________________________________________
deskbar-applet-list mailing list
deskbar-applet-listgnome.org
http://mail.gnome.org/mailman/listinfo/deskbar-applet-
list