Re: Bar going away? (was: Re: [wmii] Re: wmii-4 fs proposal/discussion)

On Mon, Jun 12, 2006 at 03:50:09PM +0200, Uriel wrote:
> On 6/12/06, Anselm R. Garbe <garbeam_AT_wmii.de> wrote:
> >On Sun, Jun 11, 2006 at 03:26:56AM +0200, Uriel wrote:
> >> An external app could provide pretty much the current bar
> >> functionality if anyone wants it, something like winwatch(1) but for
> >> pages might make sense.
> >
> >The bar should be internal to prevent adding bunch of
> >synchronization complexity to not overlap the bar all the
> >time... Also, I doubt the sense of having a bar with a 9P
> >interface as external app, that would add also much complexity
> >which seems totally unnecessary. The bar-(re)internalization was
> >the correct decision. larswm, ion3, *box and many other WMs
> >using a bar prove that.
>
> Uhu? since when does winwatch(1) need a 9P interface?

For those who dunno what winwatch is in Plan 9:
http://cm.bell-labs.com/magic/man2html/1/winwatch

Anyway, winwatch is rather specialized compared to the bottom
bar of wmii, and it simply accesses /dev/wsys/ namespace. But
an external wmiibar would need a 9P interface to be feed with
input. An external wmiibar also has the disadvantage that this
increases the 'choice' for users to a point, that many questions
will arise ('Why don't you do this in default setup...') what we
should prevent in keeping the bar as simple as possible, but at
least also as usable as possible. Personally I'd be fine with a
single label, but I haven't extended the bar for my personal use
that much. But several things come to my mind what I'd like
todo, esp. dynamic creation of temporary notification labels,
which might have a red background color and a yellow text color
for exceptions in the network infrastructure I maintain at my
University).

> Anyway, obviously the 'master-tagbar' should be builtin.

Sure.

> >> What is needed is a way to 1) resize the managed area(across all
> >> views?) 2) make floating clients 'sticky' (ie., stay in place across
> >> views); neither seems particularly hard once wmii internals are
> >> cleaned up.
> >
> >1) Agreed.
> >2) Is already there through tagging, thus nothing new.
>
> Wrong, that is not what i meant, sticky-floating clients should appear
> in all views always in the same position (and they should show up in
> all views even if the tag for the new view did not exist when the
> client was started). Basically sticky clients are in an extra layer on
> top of views that is always visible.

You mean something like the OSX widgets layer or the ion3
scratchpad layer? That might be worth considering (esp. for
external dockbar apps). We need in any case the possibility to
define the width (at least) of the managed layer relatively that
such an sticky layer would make any sense.

Regards,

-- 
 Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361