[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Systray Usability
From:       Andras Mantia <amantia () kde ! org>
Date:       2005-02-06 11:50:22
Message-ID: 20050206114551.1E4716BAD4 () smtp ! zappmobile ! ro
[Download RAW message or body]

Aaron J. Seigo wrote:

> On Sunday 06 February 2005 03:57, Andras Mantia wrote:
>> So can I get an example case (aside of which I mentioned and which are
>> fixable in the apps) where this will not work? I'd like to find a real
>> solution for this problem.
> 
> if an app uses an ID of -1 for anything?

That's invalid. From the QMenuData docs:
"The id specifies the identification number associated with the menu item.
Note that only positive values are valid, as a negative value will make Qt
select a unique id for the item."

> if it's on a vertical panel? 

I said that I tested on vertical panel as well. Right now the code checks
for the Y coordinate only. Yet, it can be extended to check for the X
coordinate as well, and reduce the possibilities of putting the title at
the bottom. Even better would be to gather the information from the
systray. If that can give us back it's position, that'd be the best as
there is no need for guessing the position. 

> and putting a title at the bottom of the menu looks pretty sad; it's
> non-standard and totally breaks the natural flow of reading. it's easy to
> click the "don't show this again" checkbox if you don't want to see it
> again.

You have to click it for *every* application that you try exit. Also why
have a dialog when it's really not needed and can be avoided?

I personally don't see a problem with the reading flow. But there are many
other ways to solve the problem without brining up an extra dialog box.
This was a solution. The other solution would be to bring up the box not
near the mouse pointer, but a little further, like it's done for the K menu
icon or the other special buttons. The menu appears above/below/near the
panel, not near the mouse pointer.
Or in case of taskbar buttons. The menu appear above the button (if the
taskbar is at the bottom).

> your whole stated issue with this new functionality is that some apps
> needed to be changed to not confirm with the user. your solution also may
> require apps to be changed, so there's no real win there.

Changing the behavior within .X releases is somewhat different from
requiring a change between  major release versions. 

>> I cannot know how much you or others tried to
>> fix this,
>> but the ksystemtray.cpp/h has very little commit history, only 20
>> version since KDE 1.94, which can mean that there wasn't paid too much
>> attention to it.
> 
> or that there wasn't much to do with it. 

Obviously there would be, as there are problems with it.

> i wouldn't use commit log length 
> as a metric of anything other than the number of commits.

Yes, numbers don't say much by themselves, but if I'd see commit logs
referring to this problem (prior to you recent changes), I'd be much more
sure that there is no easy solution to fix. But in 10 minutes I came up
with a solution which can be a good start to avoid unnecessary dialogs
boxes and still avoid the problem of unwanted exiting of the applications.
Now stating that this problem can't be solved in other ways, just by
providing the confirmation dialog box seems to be a little short sighted
statement.
 
Andras

-- 
Quanta Plus developer - http://quanta.sourceforge.net
K Desktop Environment - http://www.kde.org

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]