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

List:       openbox
Subject:    [openbox] always on top window stays on top of the dock?
From:       dana () orodu ! net (Dana Jansens)
Date:       2010-04-14 21:14:32
Message-ID: 1FB5DCA0-6919-454D-B466-E033259F3317 () orodu ! net
[Download RAW message or body]


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


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