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

From: Uriel <lost.goblin_AT_gmail.com>
Date: Tue, 13 Jun 2006 21:14:49 +0200

> 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).

For such stuff just use a separated sticky app. I think that trying to
put too much functionality into the bar is a big mistake, it should be
a simple tag bar, and at most have an extra field aligned to the right
which can be used for status scripts or whatever. I see no need for
special formating or whatever for any of this, if you like you can run
clock(1) or stats(1) sticky and put them on a corner or whatever.

And I never said something like winwatch(1) should replace the whole
bar, all I said
that for selecting among views it would work just fine.

> > 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.

What I mean is that they should be on a layer on top of both managed
and unmanaged layers (in the Z axis). they should be free floating and
should be possible to move anywhere, both over the managed area or
anywhere else, I see no point in restricting their possition as they
are basically fixed in place.

I also think that probably (not sure) it is a good idea to make the
geometry of the managed area the same across all views.

uriel
Received on Tue Jun 13 2006 - 21:14:50 UTC

This archive was generated by hypermail 2.2.0 : Sun Jul 13 2008 - 16:09:19 UTC