[Thread Prev][Thread Next]   >Date Index >Thread Index

Re: [wmx] Slight menu annoyance (and comments on related stuff)

Owen Cameron - Mon Aug 09 04:35:44 1999

On Sun, Aug 08, 1999 at 09:45:55AM -0700, James Ramsey did utter:
> 
> --- Lasse Rasinen <lrasinen@iki.fi> wrote:
> > 
> > On related news, I've seen lots of requests trying
> > to make wmx have
> > everything "civilized"[1] window managers have.
> > 
> > 1) Dock. There already are sticky windows, so do we
> > need two overlapping
> >    mechanisms? Of course, the suggestion mentioned
> > losing the window
> >    decorations etc. Sticky windows as is don't do
> > that.
> 
> I agree with you as far as the dock is concerned. It does seem highly
> unnecessary to me.

While I admit I didn't realise that wmx did sticky windows already when I
proposed the dock before, in my defence I would have proposed it anyways.

While sticky windows are great, that's only part of the functionality of a
dock to me. The rest being the lack of window decorations and automatic flush 
alignment with the next window in the dock.

A mouse-method of enabling sticky window might be nice too, since my 
Xterminal seems to trap the pause key (maybe something like shift-click on teh
close button?

A generic way to disable window decorations (except maybe on one edge on
mouseover for moving and re-enabling the decorations) would  go most of
the rest of the way to doing a dock.

Anyways, who said there would be two overlapping mechanisms with a dock?
Rather, it would be two ways of accessing the same mechanism surely? 
While I haven't coded in years, surely it shouldn't be too hard?
  -Implement a toggle for window decorations
  -the "dock" then simply calls three functions. 
    1. sticky window
    2. window decorations off
    3. alignment to the dockpoint.
    
Can the real programmers now stand up and tell me all about my faulty
assumptions? ;)

> > 2) Lots of configurability. Am I the only one here
> > who finds some perverse
> >    joy in having to recompile after every change?

<snip>
> 
> Frankly, I think a good balance would be to have enough runtime
> configurability to customize what can be customized in wmx with a
> minimum of trouble, while not so much as to siphon too many resources.
> Offhand, I don't think that realistically that really constitutes "lots
> of configurability", but I guess that depends on how you look at it.

I tend to feel that the "look" should be runtime and the "feel" be
compiletime. So fonts, colours, pixmaps, maybe even border width are "look",
while channel-switching-delay, close-button-kill-delay, hotkey setup, etc
are all "feel".

Conceptually at least, that is what seems logical to me. I don't use any
runtime configuration myself, but most of the recompilation I do is to 
change frame colours, text colours, etc.

In the same thread though, I would have to say I prefer Xresources over the
symlink hack though. Just from a "standard method" perspective... :)

cheers...
/Nemo
-- 
 .---------[ Owen Cameron, Wombat, Paddington, nemo, earth native ]---------.
 |   http://www.goldweb.com.au/~nemo/  <nemo@net.house.cx>     UIN:#5408336 |
 `--------------------------------------------------------------------------'
   |    "Are you allowed to take a companion on a personal journey of     |
   |     self-discovery??"                 /-[ Owen Cameron, 1996 ]-/     |
   `----------------------------------------------------------------------'


Next: