chad,
(couple of responses here)
chris is right in his understanding of the IWMComponent situation as he
describes it below:
-----Original Message-----
From: Chris B. Vetter [mailto:chrisv@...]
However I guess there's a slight misunderstanding in what the components
are supposed to be. As I see it (and granted, I may be terribly wrong)
the components represent a 'hook' into the window manager. They can be
used to either create a bundle that's loaded by iwm directly, or you can
use a (one or more?) protocol(s) to create a seperate app that will be
able to communicate with iwm.
--- snip ---
the protocol issue is somewhat questionable these days - but that was a
plan at one point.
i was working on the IWMComponent code last night & remembered why it was
such a barren landscape: because that's the only way it should be. i'm
still chewing the component cud at the moment, but the whole grounds for
having them was to allow additional utilities to be loadable as some sort of
bundle, whether that component works behind the scenes, or has a graphical
representation that the user interacts with, such as your dock.
please note that the IWMComponents will NOT be subclasses of NSBundle, but
wrappers *around* bundles which will allow dynamic re-loading of the code
(not ready at this very moment in cvs, though). don't want the dock there
anymore? close the thing. just pulled down a newer version of that nifty
email notification component? close it, install the new one, reload it.
sounds elementary, because it is - but it's the little things that matter
the most...and if you're *developing* the component, you'll defintely
appreciate not having to restart the window manager.
>Ok, so we are currently differing on this point:
>I think that it would be best to keep each component (such as the wm and
>the dock) as standalone apps, which do their prescribed function and
>that's it.
but how are you going to access the list of clients that aren't gnustep
apps if you have no open line of communication with the window manager?
this could lead to some ugliness on par with what chris has been talking
about with the GS app icons...
i completely agree with the minimalist/traditional unix-style thinking of
"one tool, one job"...but i've discovered that this is very tough ground in
window manager land. the window manager should be just that: a manager of
windows only. but then you have to deal with the fact that people like the
ability to work without too much effort - this creates the need for things
like a dock, a taskbar, a root window menu, etc.: things that aren't
neccessarily part of the window manager's job, but are related to it in a
fundamental way.
this is where components will (hopefully) come to the rescue. they won't
allow you to muck with the guts of IWM, but they'll let you get access to
the information you need - such as a list of client names for a menu, or a
way to send a move/resize/close request to a particular client.
>However, let me ask you this. How feasible is it to write an X11
>window manager, such as interfacewm, that can do gnustep distributed
>stuff, considering that you would not be running the traditional gnustep
>event loop type setup. If this is not really feasible, then hopes of
>imy dock interacting with an X11 window manager (such as interfacewm)
>are groundless. But if it is possible, are you open to the idea of
>moving away from your ideas of a component based interfacewm to a
>distributed communications/separate apps idea?
i have had a plethora of discussions on the notification vs. DO topic with
people in the gnustep/interfacewm community - and we've all come to the
conclusion that notifications were the way to go, for various reasons.
first of all, it's much more light-weight - not much code is needed at all.
second, i really don't want a distributed object in the code that someone
could take advantage of for whatever purpose (i.e. killing any client with
the name "xterm" or the window manager itself whenever <whatever> happens).
with notifications, you can listen if you want, you can recieve
notifications, and you can ignore the notifications you do recieve if you
want. and if you only need to listen for two notifications, that makes your
life even easier...as opposed to having to set up your component to deal
with DO.
i don't think your hopes of your dock interacting with IWM are groundless at
all - in fact, i *know* they aren't. but, to be brutally honest, i don't
think *anybody* would want to use it if it *only* handles gnustep apps - if
not because of that limitation, then becuase there simply aren't enough
gnustep apps out there to allow you to do everything you need to on a daily
basis (generally speaking).
i know this is kind of a pain in the ass because (a) you've seem to have
already started your dock, (b) the component code isn't complete, (c) the
IWM line of thought is somewhat contradictory to how you've plotted out how
the dock would work, and (d) IWM isn't 100% done yet...but i know that this
stuff will be very feasable, and when everything is worked out, it will make
it significantly easier for you (and anyone else) to hook into IWM for
similar purposes.
- ian
|