Layout of gtk client
yangoon
Please give your
feedback, because usability aspects will always be a compromise of the
needs of
many different users and a better compromise can be evaluated ans
achieved by a
numerous input.
1) The current statusbar lacks the old functionality of showing
request states
and access.
Just from my point of view I would restore this to the former
behaviour, too.
My arguments:
a)
In my personal usage of the client I *never* use the icons on the
toolbar,
because for those actions really simple keyboard shortcuts are
existing.
Additionally those items are easily accessible from the menu. As a
consequence
I prefer to disable the toolbar first, if I want to get more space out
of
the client window. But unfortunately it is currently the only resource
to get
information about unread requests. So for me it is better to have this
information in the statusbar, too.
b)
In my personal experience the information about request states is much
more
obvious in the statusbar than by means of the toolbar icon. And
requests
should be easily percepted and accessible.
So I am voting for reenabling request states in the status bar.
2) The current statusbar is not configurable.
As a possibility to get even more place in the client window the
statusbar should be configurable as well, thus providing the facility
of
an almost entire 'data' desktop. It is at the taste of the user to get
the most
suitable interface for his personal way of working and I think we are
far from
offering too many options to users, which was a refutation in the
former
discussion.
I already provided a patch for that and I am willing to do it again.
So I am voting for a configurable (enable|disable) status bar in the
same way
as for the toolbar.
Thanks to all for your feedback!
--
Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg
Tel: +49(761)471023
Fax: +49(761)4770816
http://mbsolutions.selfip.biz
UStIdNr: DE 142009020
Udo Spallek
Am Sonntag, den 16.08.2009, 06:49 -0700 schrieb yangoon:
> 1) The current statusbar lacks the old functionality of showing
> request states
> and access.
> Just from my point of view I would restore this to the former
> behaviour, too.
The place for showing the request state is for me the statusbar, too.
Accessing the Request state is for me like it is, in toolbar and menu.
> 2) The current statusbar is not configurable.
> As a possibility to get even more place in the client window the
> statusbar should be configurable as well, thus providing the facility
> of
> an almost entire 'data' desktop. It is at the taste of the user to get
> the most
> suitable interface for his personal way of working and I think we are
> far from
> offering too many options to users, which was a refutation in the
> former
> discussion.
Yes, for me it should be an option, too.
> I already provided a patch for that and I am willing to do it again.
> So I am voting for a configurable (enable|disable) status bar in the
> same way as for the toolbar.
Yes, I find it would be a good compromise. And as we see in the
discussion[1], pros and cons for a statusbar seems in a way a matter of
taste, that we can not decide for the users.
Cheers Udo
[1] https://bugs.tryton.org/roundup/issue1079
--
____________________________________
virtual things
Preisler & Spallek GbR
Munich - Aix-la-Chapelle
Windeckstr. 77
81375 Munich - Germany
Tel: +49 (89) 710 481 55
Fax: +49 (89) 710 481 56
Mathias Behrle
Hi,
since there are no objections to this proposal, I suppose it is
generally accepted.
> > 1) The current statusbar lacks the old functionality of showing
> > request states
> > and access.
> > Just from my point of view I would restore this to the former
> > behaviour, too.
> The place for showing the request state is for me the statusbar, too.
> Accessing the Request state is for me like it is, in toolbar and menu.
I will provide this patch.
> > 2) The current statusbar is not configurable.
> > As a possibility to get even more place in the client window the
> > statusbar should be configurable as well, thus providing the facility
> > of
> > an almost entire 'data' desktop. It is at the taste of the user to get
> > the most
> > suitable interface for his personal way of working and I think we are
> > far from
> > offering too many options to users, which was a refutation in the
> > former
> > discussion.
> Yes, for me it should be an option, too.
I will provide this patch.
> > I already provided a patch for that and I am willing to do it again.
> > So I am voting for a configurable (enable|disable) status bar in the
> > same way as for the toolbar.
> Yes, I find it would be a good compromise. And as we see in the
> discussion[1], pros and cons for a statusbar seems in a way a matter of
> taste, that we can not decide for the users.
>
> Cheers Udo
>
> [1] https://bugs.tryton.org/roundup/issue1079
Additionally I will provide a patch to restore old pda_mode functionality
(disable status bar in pda mode, show correct menu default). There are several
references to this configuration option, and as long as this option is not
removed completely from the client (which could be discussed), it should
work properly.
--
Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg
Tel: +49(761)471023
Fax: +49(761)4770816
http://mbsolutions.selfip.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x89BCA161
Hartmut Goebel
> Additionally I will provide a patch to restore old pda_mode functionality
> (disable status bar in pda mode, show correct menu default). There are several
> references to this configuration option, and as long as this option is not
> removed completely from the client (which could be discussed), it should
> work properly.
Since some (working) "PDA mode" would be a good selling point, I vote
for keeping it or replace it by some specialized PDA client.
--
Schönen Gruß - Regards
Hartmut Goebel
Dipl.-Informatiker (univ.), CISSP, CSSLP
Goebel Consult
Spezialist für IT-Sicherheit in komplexen Umgebungen
http://www.goebel-consult.de
Monatliche Kolumne: http://www.cissp-gefluester.de/
Goebel Consult mit Mitglied bei http://www.7-it.de