[openbox] always on top window stays on top of the dock?

Dana Jansens dana at orodu.net
Wed Apr 14 17:14:32 EDT 2010


On 2010-04-14, at 2:54 AM, Anthony Thyssen wrote:

> On Tue, 13 Apr 2010 16:56:14 -0400
> Dana Jansens <dana at orodu.net> wrote:
> 
> | On 12/04/10 03:15 PM, openbox at cstuck.ath.cx wrote:
> | > Hi,
> | > 
> | > I recently answered to one of my threads but forgot to send it to the whole mailing list.
> | > It may cover your concern so I just paste it in here: (Thread: openbox vs. fluxbox)
> | > 
> | > [...]
> | > Layers
> | > 
> | > Fluxbox has more Layers then openbox. I do not remember exactly their names, but basically there is a "normal" one, a "higher" and "lower" and
> | > +additinally to that something like "top" and "bottom"
> | > Which is nice when you want a window to be placed over "everything" at all times, but also want some to be above others without putting them to the
> | > +background...
> | > Hm, might sound a little confusing right now, but it's very useful to me.
> | > 
> | > I had a brief look at layer.c in openbox/actions/ and it seemed to me that the functions sending windows to the layers just set an option to 0/1/-1
> | > I don't know if one could just add 2/-2 to that or even let this the user configure similar to desktops? So far I could find a section in
> | > +openbox/client.c in
> | > static ObAppSettings *client_get_settings_state(ObClient *self)
> | > that just sets self->below and self-above as boolean.
> | > This does not sound like a very flexible solution but to just add two layers as top and bottom should be not too much effort I guess.
> | > 
> | > Well, maybe someone has an idea with that...
> | 
> | It comes, like so many limitations, from here:
> | http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2507241
> | 
> | You could add more states, like _OB_STATE_ABOVE_ABOVE, to make a second
> | above layer.  It'd be nicer if a window's above/below "state" was some
> | kind of integer, with 0 being a default.   But I'm not sure how that
> | would possibly be intuitive in the Openbox GUI, so maybe it would just
> | be ignored there.
> | 
> I don't know seems just as intuitive as having to look up what you are
> allowed to use.  So why not look up that you need an integer some sort.
> 
> Could always have words like 'top' meaning specific integers internally.
> For example  10    with bottom as  -10  Users can then override that
> with a 'higher on top' for some specific cases.

Yes the problem is not keeping the same options, but instead exposing lots of levels to a user in a way that isn't horrid.

> RaiseLower for example could just make the ordering integer
> positive/negative
> 
> What gets me is that some applications force windows to be on top or
> bottom sometimes preventing you getting to the window that currently
> has the 'keyboard'

Currently docks are stuck above other windows, but they should not be constructed to occupy so much screen space that they prevent you from working on other apps, as they are generally omnipresent things.

> 
> Gnome panel for example loves being 'on top' though I would like to be 
> able to say that if 'this window' has a 'top' setting, put it above
> gnome panel.  But still let me put it on bottom on occasion.
> 
If you set a dock such as gnome-panel to be "below", then you will be able to raise other windows above it.  You can put it back to "normal" when you're done to keep it above again, as per default.


Dana


More information about the openbox mailing list