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

List:       kde-usability
Subject:    Re: Systray Usability
From:       Manuel Amador <rudd-o () amautacorp ! com>
Date:       2005-02-10 0:16:38
Message-ID: 1107994599.12930.12.camel () master ! amauta
[Download RAW message or body]

I am sorry for hijacking a thread but this problem is somewhat related.
When using GNOME, KDE apps that use the systray work perfectly, as
advertised.  But once I close and save my session, and reopen it again,
the systray icons for the KDE apps appear "floating" at random places on
the screen, instead of on the systray.  This probably has to do with the
fact that the GNOME session manager is restarting the KDE applications
*before* the systray dock in GNOME has finished starting.

This is also related to another problem.  When kicker dies, systray
icons undock and float in random places, just like in GNOME, and they do
not return to the systray once kicker is restarted.

How can this be fixed?

El dom, 06-02-2005 a las 13:50 +0200, Andras Mantia escribió:
> 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
> 
-- 
Manuel Amador <rudd-o@amautacorp.com>
Amauta
_______________________________________________
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]