Tryton - Issues

 

Issue1079

Title i can not directly see in which database I am working
Priority feature Status resolved
Superseder Nosy List ced, udono, yangoon
Type behavior Components
Assigned To ced Keywords
Reviews

Created on 2009-06-09.21:26:36 by udono, last changed by ced.

Files
File name Uploaded Type Edit Remove
db_status_bar.tgz bch, 2009-06-12.17:04:46 application/x-compressed-tar
tryton_configure_statusbar.patch yangoon, 2009-06-19.01:29:10 text/x-patch
tryton_restore_statusbar.patch yangoon, 2009-06-19.01:28:47 text/x-patch
tryton_rietv_108045.patch yangoon, 2009-08-17.17:13:49 text/x-diff
Messages
msg4392 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2009-08-17.17:37:23
Applied
msg4390 (view) Author: [hidden] (yangoon) Date: 2009-08-17.17:13:49
Patch attached for http://codereview.appspot.com/108045, please apply.
msg4375 (view) Author: [hidden] (yangoon) Date: 2009-08-16.15:50:20
Thx for restoring statusbar functionality, IMHO a good and wise decision.

Nevertheless there are left some issues to discuss, that I have put on http://groups.google.com/group/tryton/t/2475d1c358cfc928
, because the mailing list seems better suited for discussions than the tracker.

Additionally I have put a proposal for a minor code cleanup for changeset c22e643a07f9 on  http://codereview.appspot.com/108045, please review.
msg4315 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2009-07-31.13:56:11
Fix with changeset c22e643a07f9
msg4300 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2009-07-28.17:30:59
Here is a patch to restore a status bar with username and connection http://codereview.appspot.com/98054
It looks like this http://nopaste.at/img/200907d15db36f17.png
msg4156 (view) Author: [hidden] (yangoon) Date: 2009-06-19.01:28:47
Two patches attached to restore old functionality of statusbar (tryton_restore_statusbar.patch), but preserving new menu icon for requests and adding configuration option to show/hide status bar (tryton_configure_statusbar.patch).
Applying to changeset  1347:c1e759dca340.
msg4145 (view) Author: [hidden] (yangoon) Date: 2009-06-13.14:36:10
- The module eliminates the display of the actual tab in the title, which was indeed an improvement.

- As long as we cannot uninstall modules we are fixed one time the module is installed.

- I still prefer a (switchable) status bar for the rationales in msg4135.
msg4141 (view) Author: [hidden] (bch) (Tryton committer) Date: 2009-06-12.17:04:46
I have created a module that add the db name to the window title, see attachment. Please comment.
msg4135 (view) Author: [hidden] (yangoon) Date: 2009-06-10.23:20:42
> > > Having configuration option for this kind of thing is always the worst
> > > choice.
> > 
> > Why?
> 
> http://video.google.com/videoplay?docid=6127548813950043200

Interesting video, but I don't see the point. I don't want to have the choice
between small, middle, big, red, blue or green status bars, I just want to keep
the one that you have eliminated.
And if someone doesn't want it, it would be just nice for him if he could
deactivate it by configuration.
 
> > > And as I already said, it is possible to write a module (~10 min.) that
> > > add the database name against the user name company on the windows title.
> > 
> > This would be for me the second best approach. Personally I prefer the
> > status bar, because I am used to get such information from there. Other
> > programs like openoffice, evolution, vim allow to configure the status bar. 
> 
> I'm not against but we will have a status bar with only the database name.

I also miss the state of the waiting/sent requests. The status bar is the ideal
place to show this state. I don't need any actions there, but if there are
messages from the application I will always search in the status bar.
So if it is common sense to remove the state of requests from the status bar,
then I would appreciate a much more eye-catching icon than the current one.
The icon used now for showing waiting requests at least with my
themes (raleigh, qt-curve) looks rather indifferent. The former
info about requests in the status bar for me was much more accurate.
msg4134 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2009-06-10.19:30:42
On 10/06/09 19:17 +0200, Mathias Behrle wrote:
> 
> Mathias Behrle <mathias.behrle@gmx.de> added the comment:
> 
> > Having configuration option for this kind of thing is always the worst choice.
> 
> Why?

http://video.google.com/videoplay?docid=6127548813950043200

> > And as I already said, it is possible to write a module (~10 min.) that add the database name against the user name company on the windows title.
> 
> This would be for me the second best approach. Personally I prefer the status bar, because I am used to get such information from there. Other programs like openoffice, evolution, vim allow to configure the status bar. 

I'm not against but we will have a status bar with only the database name.

> > We don't want to not have dev items on the client but we don't want to waste space on screen with dev items. 
> 
> For me it is not a dev feature to know to which database I am connected. The same way I want to know from a network manager, to which network I am connected (and not: just connected). No, I am not a Windows user, who is just satisfied getting presented something, but I want to know on what I am working.

Generaly network manager show you an icon with the connection state but you
have information with mouse over.

> > The connection parameters are still visible.
> 
> Only after interaction with mouse.
msg4132 (view) Author: [hidden] (yangoon) Date: 2009-06-10.19:17:13
> Having configuration option for this kind of thing is always the worst choice.

Why?

> And as I already said, it is possible to write a module (~10 min.) that add the database name against the user name company on the windows title.

This would be for me the second best approach. Personally I prefer the status bar, because I am used to get such information from there. Other programs like openoffice, evolution, vim allow to configure the status bar. 

> We don't want to not have dev items on the client but we don't want to waste space on screen with dev items. 

For me it is not a dev feature to know to which database I am connected. The same way I want to know from a network manager, to which network I am connected (and not: just connected). No, I am not a Windows user, who is just satisfied getting presented something, but I want to know on what I am working.

> The connection parameters are still visible.

Only after interaction with mouse.
msg4130 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2009-06-10.19:03:14
Having configuration option for this kind of thing is always the worst choice.
And as I already said, it is possible to write a module (~10 min.) that add the database name against the user name company on the windows title.

We don't want to not have dev items on the client but we don't want to waste space on screen with dev items. The connection parameters are still visible.
msg4127 (view) Author: [hidden] (yangoon) Date: 2009-06-10.14:10:46
There can be very well be end-users connected to different databases. Where is the problem to make the display of the statusbar configurable?

And I really don't understand why you don't want to remove first the database options from the menu, if you don't want to have dev items on the client...

http://www.tryton.org/~irclog/2008-07-06.log.html
msg4125 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2009-06-10.13:47:42
On 10/06/09 13:24 +0200, Udono wrote:
> 
> Udono <udono@gmx.net> added the comment:
> 
> >> There should be only one statusbar like now.
> 
> > If people want the connection information always visible on a status bar, it
> > must be on an other status bar then the one of the form.
> Yes, this I mean. To have separate statusbars on different forms is bad design. Better design is to have one real statusbar, which includes all information of displaied forms and the client connection.

No, it doesn't work with things like dashboard.

> And on a dashboard view the real statusbar could change informations on focus of the choosen view.

It is bad if you can see only partial information.

> 
> But for me these topics are details of a new concept we should plan and discuss separate from this issue.

It is not new dashboard already exist.

> 
> For me the main critics is the missing usability and the new icon in the menu bar of the status quo solution as I told below. For me it is better to have the changeset 7f7ea87ab171 reverted and find a solution which fit all needs.
> 

The only information that is no more displayed (but with info box) is the
connection information which is as bechamel said, only useful for devs. End users
do not understand this and do not want to see this because in production
environment there is only one database.
msg4124 (view) Author: [hidden] (udono) Date: 2009-06-10.13:24:44
>> There should be only one statusbar like now.

> If people want the connection information always visible on a status bar, it
> must be on an other status bar then the one of the form.
Yes, this I mean. To have separate statusbars on different forms is bad design. Better design is to have one real statusbar, which includes all information of displaied forms and the client connection.
And on a dashboard view the real statusbar could change informations on focus of the choosen view.

But for me these topics are details of a new concept we should plan and discuss separate from this issue.

For me the main critics is the missing usability and the new icon in the menu bar of the status quo solution as I told below. For me it is better to have the changeset 7f7ea87ab171 reverted and find a solution which fit all needs.
msg4123 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2009-06-10.13:07:00
On 10/06/09 13:03 +0200, Udono wrote:
> 
> Udono <udono@gmx.net> added the comment:
> 
> > It is linked to the view not to the connection.
> But it is build in the client. So we have both links available.
> > And there is no one on tree view.
> I see on menu. A 'statusbar' which act and function like a standard statusbar but which is no real statusbar is bad design in my eyes.

What is bad design is mixing information. Because it will not allow to extend
the client like displaying many forms at once, etc.

> 
> When using a statusbar it should be visible or invisible on any view, like before.
> There should be only one statusbar like now.

If people want the connection information always visible on a status bar, it
must be on an other status bar then the one of the form.
msg4122 (view) Author: [hidden] (udono) Date: 2009-06-10.13:03:31
> It is linked to the view not to the connection.
But it is build in the client. So we have both links available.
> And there is no one on tree view.
I see on menu. A 'statusbar' which act and function like a standard statusbar but which is no real statusbar is bad design in my eyes.

When using a statusbar it should be visible or invisible on any view, like before.
There should be only one statusbar like now.
msg4121 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2009-06-10.12:44:03
On 10/06/09 12:42 +0200, Udono wrote:
> 
> Udono <udono@gmx.net> added the comment:
> 
> There is something which looks like a statusbar and which function like a statusbar.
> Record: 60 / 96 - Editing record (id: 33)
> So I say: It is a statusbar...

It is linked to the view not to the connection.
And there is no one on tree view.
msg4120 (view) Author: [hidden] (udono) Date: 2009-06-10.12:42:15
There is something which looks like a statusbar and which function like a statusbar.
Record: 60 / 96 - Editing record (id: 33)
So I say: It is a statusbar...
msg4119 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2009-06-10.12:26:12
> 1.2. When not checked, leave right side of the statusbar free like it is now. 
There is no more statusbar.
msg4118 (view) Author: [hidden] (udono) Date: 2009-06-10.12:17:58
I don't think it is a developer issue. As I told, new tasks and modules I test in a test database which is a copy of my production system. There I need to decide quickly where I am working. It is like to have a training database for end user.

I don't say it is a bad solution in any case. A good point for me is the removal of the requests to the toolbar. With this the toolbar and the menubar are the places to 'do' something, and the statusbar is a place to 'keep inform' about something.

The computer icon on right side of the menubar is a bad solution for me, because it is unusual and needs a mouse action (moving mouse to icon), it is not usable with the keyboard. So accessability is restricted to mouse only.

What I prefer is 
1. to make the statusbar informations about the connection details configurable like "Options > Statusbar > Show Connection Details"
1.1. When checked, show connection details on the right side of the statusbar
1.2. When not checked, leave right side of the statusbar free like it is now. 
2. remove the computer icon on the right side since it is irregular and breaks clean usability

With this there is no more space needed (Statusbar is there in all cases), but the connection details are shown if someone likes.
msg4117 (view) Author: [hidden] (bch) (Tryton committer) Date: 2009-06-10.11:53:57
Isn't it a developer-only issue ? IMO the end user shouldn't be aware of the concept of database (And I think it should be also hidden on the login screen, but I think I'm the only one with this point of view).
msg4116 (view) Author: [hidden] (yangoon) Date: 2009-06-10.11:10:43
I am always pleased to have a tidy workspace, but knowledge of the database you are working in, is indispensable in many cases. Since many (if not all) programs I am using place such precious information in the status bar, this can not be declared as lost space.
The classic statusbar should indeed be configurable.
msg4115 (view) Author: [hidden] (ced) (Tryton committer) (Tryton translator) Date: 2009-06-09.23:29:22
It is possible to add the database name in the windows title by overriding the function field status_bar on res.user.
The change was to simplify and reduce lost space in the client but there is still some place to win.
msg4113 (view) Author: [hidden] (Timitos) Date: 2009-06-09.21:37:57
you can see it when you point your mouse to the new connection icon on the main window right top.
but i agree it is not very comfortable.
msg4112 (view) Author: [hidden] (udono) Date: 2009-06-09.21:26:36
In the client the status line is removed. For me it is essential to see directly which database and user I am working on. That's because I often use many clients to many databases in parallel for debugging reasons. And new tasks and modules I test in a test database which is a copy of my production system. There I need to decide quickly where I am working.

So it is a good solution to make the classic statusbar configurable or put the database information into the window title.
History
Date User Action Args
2009-08-17 17:37:23cedsetstatus: chatting -> resolved
messages: + msg4392
2009-08-17 17:13:49yangoonsetfiles: + tryton_rietv_108045.patch
messages: + msg4390
2009-08-16 15:50:20yangoonsetstatus: resolved -> chatting
messages: + msg4375
2009-07-31 13:56:11cedsetstatus: chatting -> resolved
assignedto: ced
messages: + msg4315
2009-07-29 13:34:14cedsettitle: i can not directly see in which databae I am working -> i can not directly see in which database I am working
2009-07-28 17:30:59cedsetmessages: + msg4300
2009-06-22 14:30:31cedsetassignedto: ced -> (no value)
2009-06-19 01:29:10yangoonsetfiles: + tryton_configure_statusbar.patch
2009-06-19 01:28:48yangoonsetfiles: + tryton_restore_statusbar.patch
messages: + msg4156
2009-06-13 14:36:10yangoonsetmessages: + msg4145

Showing 10 items. Show all history (warning: this could be VERY long)