Re: Why intergrate with WindowMaker's dock?

[Dan Pascu]

On 10 Feb, Gregory Casamento wrote:
> Other than the fact that WindowMaker's Dock is very close to the one under
> OPENSTEP, why should we integrate with it?   It seems as though whenever we

The short answer is that you don't need to use it. rewrite if that is
what you want.

The (slightly =) longer answer is like this:

At this moment the dock in window maker has code to make actual
non-gnustep apps mimic the NeXT look (ie have appicon, be able to hide,
....). This means it can be used to dock both gnustep, and non-gnustep
(X11) apps. All about window maker, except the fact it does what a
window manager is supposed to do, is that it also has code to make the
environment be close to what the NeXT env was, but without applications
specifically written for this (ie with existing X11 apps).
Now at this point I think there are very few (read close to none)
usable pure gnustep apps. Even when gnustep will be officially released
as being able to do real work, I think people will use  >50% (optimistic
view), or >80% (pessimistic view) non-gnustep apps, not only because
there will not be the equivalent gnustep apps available at the
beginning, but also people may have preferences to use whatever
software they are already used to.

Of course you may say that people will be fascinated with this very
nice api and will start developing in a fury for it, but that is to be
seen. Practice shows that people tend to be conservative and use
whatever they know and don't jump very easily to learning new things if
the current ones do their job.

Also even if you say that gnustep will allow very easy software
development, let's be realistic. The "build a text editor in 5 minutes"
example that is out there, is possible because the main widget in a
text editor - NSText - is already in the AppKit. You only need to hook
in some callbacks, and you have a bare-bone editor available.
But don't forget that many apps have the biggest part of their code not
in the graphic interface, but in the underlying code.
How much time do you think it will take to develop the gnustep
counterparts of apps like vmware, gimp, a web browser, acrobat reader,
well pretty anything that is not just a frontend of some kind, and
where most of the code is in the non-gui part?
You may build their graphic interface in a couple of days, but that's
only 5% of the code you need to write.
And to be realistic I don't think that we will ever run a pure gnustep
environment, as long as people will have alternatives. You will need to
integrate alien apps in your environment, and do it nicely.

So this is what widnow maker's dock does now: allows you to make
gnustep and non-gnustep apps behave similarly. At least to some degree.
Not only non-gnustep apps get an appicon with window maker, they also
get functionality like hide/unhide, and they can even get a NeXT like
menu (if you care to edit some files with mappings between keystrokes
and menu entries).

Of course you may chose not to use this already existing code, and write
your own. But you will end up reinventing the wheel, and will find out
later that your dock was required to put the same code we already have
(in case you really want to integrate non-gnustep apps in your
environment). This means X API specific code, that is not in wmaker
(where you don't see it), but in your dock.app (where you should only
use the openstep api to be 'kludge free' as you want it).
The same is true for all existing dockapps, which you may need to
rewrite.

> consider doing this we find it necessary to kludge the code.   Why kludge
> GNUstep, when we can write a Dock application which will act as the GNUstep
> dock?

Welcome to the real world. As long as you want to be able to handle
anything outside of the gnustep env (alien apps) you will need a
kludge of some kind. And the funny part is that now all these required
'kludges' are in wmaker and you can use them. But you seem to want to
port them to gnustep, so that they will belong to the core, just because
this way you feel you are more independent of a window manager.
(Because this is what it will happen if you want to also handle
non-gnustep apps: you will find you need kludges for them, which since
you are window manager independent you will need to put in your libs)
You may be more window manager independent, but your apps will start to
include more non-openstep api code.

> 
> If we are going to intergrate with WindowMaker, it needs to be done in a way
> such that we are not tied to it.  We should never, under any circumstances,
> kludge the API for the sake of interoperating with any window manager.

Well, then don't do this. kludge your gnustep libs to allow
inter-operation with non-gnustep apps if that seems better to you. This
is even better for us, since we don't need to consider any code that
makes the wmaker-gnustep communication better. All you already need is
there. We can add an option that will disable any fancy thing in
wmaker, and will leave it to only manage windows.

Well, the overall point is that to interact with non-gnustep apps you
will need kludges. Where you put them, its not my choice.

> Afterwards, it should still be possible to create a GNUstep dock.
> 
> I just thought I would get this off my chest.   I am ready for any flames you
> feel as though you need to send.

-- 
Dan