Re: [Rhythmbox-devel] [patch] tray icon rework patch



On Sat, Nov 12, 2005 at 03:03:41PM +1100, James Livingston wrote:
> On Fri, 2005-11-11 at 20:18 +0100, Paul van Tilburg wrote:
> > On Tue, Sep 06, 2005 at 04:21:36PM -0500, James Cotton wrote:
> > > I'm seeing some strange behavior with the icon now. Using the latest gnome 
> > > 2.12 libraries. What happens is that when I click it to show it always comes 
> > > up in the upper left corner. If I move or resize the window then click it 
> > > again first the window just blinks but doesn't minimize. The next time I 
> > > click it, the window minimizes. Finally when I click it again it opens back 
> > > in the upper left corner.
> 
> What version of Rhythmbox are you using, 0.9.0, 0.9.1 or cvs? There were
> some window state (e.g. position and size) issues that have been fixed
> since 0.9.1, and that may be causes by those problems.
> 
> When you click and it doesn't minimise, is there another application
> that you have focused? If so, and you are using cvs, then the
> doesn't-minimise issue is probably caused by the change in window
> visibility policy (described below).

I am not using CVS yet but RB 0.9.1. 

> > I have the same behaviour (with RB 0.9.1), and frankly it drives me nuts
> > but this probably because of how I am used to using Rhythmbox.
> 
> If that the window size and position, or visibility toggling? the former
> should have been fixed since 0.9.1, but the latter may not.

Both the minimizing is strange to me, as also mentioned by ïïïïïï
ïïïïïïïïï . and the fact that if the app window is recalled it
is shown at a random position (probably due to metacity).

> > Normally I put the Rhythmbox with a reasonable size in the middle of my
> > screen, set it to Play and hide it.  Sometimes I recall the window to
> > see what's happening and playing, but this is because of the balloons
> > not necessary anymore.  I also recall it to give new commands, manage
> > what is playing of manage the database.  So I do frequent recalls and
> > hides, which now doesn't work very well because a hide requires two
> > clicks on the trayicon and recalling leads to Rhythmbox appearing on a
> > random position, not the previous.
> 
> If Rhythmbox isn't the focused top-level window, cvs currently requires
> two click because the first will bring it to the front (described
> below). Perhaps we should change this, if it annoying people.

I didn't know yet that this was done on purpose :).

> > I'd like to compare the way this works with Gossip, which I also use a
> > lot and aims to grow into a (IM) service as well.  Gossip is recallable
> > with one click on the tray icon, and I can dismiss it with a single
> > Escape press or click on the tray icon.  The X button is still Close
> > which is fine with me because that always has been Close.  Since there
> > is a keyboard way (Esc) and mouse way (trayicon click) I do not need
> > Close to minimize at all.  I'd prefer the 3 title-bar-buttons to keep
> > doing as they always have done, but still have an easy way to recall and
> > hide RB by keyboard and by mouse.
> 
> A single click on Rhythmbox's tray icon toggles it "visibility", but
> this is made more complex by how we define "visibility". Up to and
> including 0.9.1 the definition was that Rhythmbox was visible when the
> window was shown (in the GTK sense) and invisible when it was hidden.
> 
> This lead to a lot of quirks, and doing things that people didn't
> expect. Take for example a situation where Rhythmbox's window is on
> workspace 1, and you are using workspace 2. Clicking the tray icon would
> cause the window to be hidden, because it is "visible" on workspace 1 -
> which isn't what most people really want.

Yes, indeed.

> The definition was changed so that Rhythmbox is considered visible, when
> a) the window is shown, and b) it is the current top-level window. This
> means that if a window is on another workspace it will be considered as
> not visible.
> 
> That works well, but there are two potential things that may seem odd -
> which we might want to change:
> 1) when on another workspace, clicking the tray icon causes the window
> to be moved to the current workspace, rather than moving the user to
> it's workspace. I'm not sure which people prefer, but moving to the
> window's workspace is how other things like the window list and selector
> work.

Hmm.  Gossip moves itself to the current desktop if it is visible but on
another desktop.  This feels quite natural actually, it is however indeed
different from what the window list and selector do. 
It's more the meaning that is different, with the window list/selector,
I mean: take me there, but with a click on a trayicon of Gossip or Rhythmbox
or whatever application, I mean: you're not visibile, show yourself.

> 2) if the window is shown and on the current workspace, but you have
> another top-level window (e.g. another application) on top of it, it is
> considered not visible.

If you have sloppy focus (which I still prefer using a 3200x1200 desktop
with 12 windows on it), the Rhytmbox window is never focused once I
reach the notification area.  This implies that I always have to do a
double click to hide it when I was expecting a single click, since I was
not intending to focus it at all.
IMO metacity and people handle placing well, so I would consider an
application "visible" if it is on the current desktop and "hidden" if on
another desktop or in the Gtk sense of hidden mode.  This is also AFAIK
equal to the way RB 0.8 worked when using a single desktop.

Just my thouhgs,
Greetings,

Paul

-- 
Student @ Eindhoven                         | email: paul luon net
University of Technology, The Netherlands   | JID: paul luon net
>>> Using the Power of Debian GNU/Linux <<< | GnuPG key ID: 0x50064181

Attachment: signature.asc
Description: Digital signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]