On Mon, Jun 12, 2006 at 03:50:09PM +0200, Uriel wrote: > On 6/12/06, Anselm R. Garbe <[EMAIL PROTECTED]> 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 _______________________________________________ [email protected] mailing list http://wmii.de/cgi-bin/mailman/listinfo/wmii
