GNUstep (was: Re: WindowMaker and GNOME)
Michael Hanni
Hello,
If I may...
On Fri, 6 Aug 1999, Alfredo Kengi Kojima wrote:
> On Thu, 5 Aug 1999, Miguel de Icaza wrote:
>
> > The reason why people like the idea of GNUstep so far is because users
> > like the "look and feel" of it, but I do think that a fully working
> > GNUstep system is still far away. Please correct me if I am wrong.
That depends on what you quantify a working "system" to be. You can
already use the gnustep-base library in a production environment. The GNU
AppKit on the other hand is not up to that sort of abuse, err use, yet.
None-the-less, you can already use the GNU AppKit to write wonderfully
intuitive gui applications.
Within the next couple of weeks an RTF implementation will be added to the
NSAttributedString classes. In addition a powerful text system is being
designed and implemented as we speak. This text network will give GNUstep
users the ability to do that famous "Word Processor in 5 Minutes" gimic
that OpenStep users have done for ages. Furthermore, the
InterfaceModeller is under rapid development as is the ProjectCenter
application which provides project management. It is indeed an exciting
time to be working on GNUstep...
> Yes, indeed most users who have some interest in GNUstep are attracted by
> it's "look and feel". But I believe people who are actually involved in
> the project (ie: developing it) like it because of the stable, well
> defined and well designed framework it provides. It's not just a bunch of
> GUI libs with a few neat desktop apps with a nice look.
Well put Alfredo. As GNUstep developers, it is not the look of the button,
or the scrollview which motivates us to hack away at gui classes until all
hours of the night. Rather, we are motivated by the fact that the
framework -- which shows through the visible user interface -- is so
fantastic. I believe in the end that is also what will grab the attention
of many Free Software developers...
GNUstep is not meant as a GNOME-killer, or a KDE-killer. To be honest, I
don't think we have even really talked much about what a future GNUstep
"desktop" would be like. Though, because of the design of the libraries we
have implemented, a desktop environment with wonderful
pasteboard/drag&drop, uniform menus, and the like, comes free of charge.
To be bluntly honest, we *want* Window Maker to be *our* window manager.
That isn't to say we don't want users to be able to use GNOME or KDE in
conjunction with Window Maker, but we want to be able to point to Window
Maker and say, "That is the window manager for GNUstep, everything you
need can be found there." What worries me is that with "forked" versions
of Window Maker, people may run a version which doesn't integrate with the
GNUstep environment and end up getting frustrated. Will it be completly
obvious that the "GNOME Window Maker" is what someone is running, and not
the "GNUstep Window Maker"? If that is the case then perhaps it won't be
such a problem...
Never-the-less, GNUstep is here, we are alive, and before you know it
GNUstep will be ready for real-world software solutions.
Cheers,
Michael
/*
* Michael Hanni <mha...@sprintmail.com>
* GNUstep Developer
* http://gnustep.current.nu/news.html ([GNUstep newsWire];)
*/
Will...@aol.com
Three things.
One, my apologies that I've not learned enough about Obj-C header files to be
able to comment intelligently on a comparison of OpenStep's and GNUstep's
files.
Two, Would anyone be interested in a copy of Garfinkel & Mahoney's book
_NeXTSTEP PROGRAMMING STEP ONE: Object-Oriented Applications_? I may be able
to lay my hands on a second copy and would be delighted to pass it on for
just shipping and handling---contact me off-list.
Three, is it now time to begin a discussion of GNUstep/WindowMaker's User
Interface? If so, what would be an appropriate forum. This is an especial
interest of mine, and an area where I'm actually qualified to help
out/comment intelligently (I hope).
William
David Lázaro
you feel that you are losing your time reading this, you may send it to
/dev/null and send a standard flame to my mail address. If you find it
useful I would like you to discuss on it.]
I don't know for the rest of GNUstep people but I am feeling FUD since
the message from Richard M. Stallman. The whole "We Want a GNOME Window
Maker" thing feels right like a hostile takeover from GNOME. I suppose
Alfredo remembers why he started developing Window Maker instead of keep
helping AfterStep. I think that it was to implement a window manager
with a more NeXT like feel into it. It then followed naturally that
Window Maker was going to be the official GNUstep window manager.
But nobody has keeped with that course of action. I used to think
of WINGS as a temporal hack but then people began using it to develop
full fledged utils and then apps. Now they want to change from WINGS to
gtk+ and I also don't understand why this is necessary.
Some people has talked about the gracious OPENSTEP framework and
they conceptual advantages being wonderful. They say that people is not
in GNUstep only for the looks that they are in it mainly for the
framework. This is true for developers. There is a nice Nirvana like
state when you begin understanding this architecture. But I am also on
it for the looks, and what is more I am also on it for its technical
things and for the added simplicity.
For me the looks count, and the original NeXT ones were precious and
no gtkStep package is going to make me believe that I am using a NeXT
system if I don't feel it. There are a lot of things lacking even in
GNUstep. What about the click in scrollbar/dingle in your pointer
behaviour? And that Alt-Click alternate behaviour? The first one is
already implemented in GNUstep and feels nice but then I try to use that
second one... and it doesn't work.
But I don't want to look that negative. That kind of thing is work
to be done that should be nice to work in. I am really interested in
seeing things like DGS working -- I have a real interest in dgs.
Anyway, this discussion is focused on the future of Window Maker and
I will play the fork advocate role. I think that the fork should be a
good idea for GNOME and GNUstep. Why? Because I feel the wrong swing
here. There is some problem with the implementation of both systems --
I don't know this to be certain for GNOME because I am not interested in
it at all but think that this also applies to it. In a OPENSTEP system
the gui wasn't done by the Window Manager this doesn't make a lot of
sense. I'll try to better explain my point of view in the next
paragraps.
The GNU project started as a way to free people from some of their
strains (Here goes a big++ thank you to RMS and the rest of the GNU
commune^Hity: Thank you). Richard M. Stallman explains [in the GNU site
papers] how in the years that followed since it start various decission
had to be made. The principal of this was to start coding an OS. Then
followed the question of which one to code. After some LISP flirtings
in the beginning they decided to do a UNIX-like OS. From this to the
HURD. I think the HURD is a good decission: technically and
phylosophically. The user space servers give real power to users
without taking anything from them. There are many more advantages but
I'll refer you to the gnu website at http://www.gnu.org/ in order to
learn more about this. And please, think and annalize, as Alfredo said
this is an important discussion.
Many years have passed since the GNU project began and nowadays
computers run with GUIs. Almost all of us relay on GUIs to do our job
even if its only for the posibility of having various xterms open at the
same time. But the GNU project haven't positioned itself in this
respect. It's only statements have been adopting several projects that
use GUIs (primarily X) in the GNU software list. X is also distributed
in the GNU CDs so we have some kind of GNU standard for the window
server. This is only a minimal part, though.
As the election to UNIX as something to develop from nothing has
been said about the GUI part we only have one of the parts of a full OS
GUI. As I said this part is the window server and all the extras that
come with X (Athena included :). The GNU project should stablish some
kind of goal and I don't think that such a big hack as GNOME is up to
the task. Why don't look at NEXTSTEP for an example of how an elegant
GUI over UNIX is done?
>>>>[The following is taken from the book "Objective-C: Object Oriented Programming Techniques" written by Lewis J. Pinson and Richard S. Wiener published by Addison-Wesley in 1991, pages 183-185. It has been slightly modified to help me explain myself.]<<<<
NEXTSTEP was an operating system that provided several layers of
support for the development of software systems. These layers bridge
the gap from user apps to the hardware. NEXTSTEP, consisting of four
software components (the Window Server, the Workspace Manager, the
Application Kit, and the Interface Builder), in conjunction with the
Mach operating system and the underlying hardware, provided the
following support layers fir the development of software systems.
* Top layer: Application
These are the classes and software components generated by a
software developer.
Each application must have an instance of a class Application if it
is to use
the windowing environment of the Workspace Manager. The Workspace
Manager is
automatically launched when the system is booted.
* Second layer: Interface Builder
The Interface Builder is itself an application that is a tool for
the
development of user-interfaces for any other application. It
bridges the gap
between applications and the underlying kit classes that support
user-interface
operations. Although applications can directly access the kit
classes, using
the Interface Builder is a time saver. Many complicated and tedious
operations
are implemented visually from the Interface Builder.
* Third layer: Kit classes
There are three categories of kit classes: Application Kit, Music
Kit, and
sound Kit. Together they provide over seventy predefined classes.
These
classes are accessible either directly or from the Interface
Builder.
* Fourth layer: Window Server and supporting C libraries
Between the Objective-C classes or the user-defined classes and the
operating
system are the Window Server and the supporting C libraries. The
Window Server
is a low-level background process that is launched with the
Workspace Manager
when the system is booted. The Window Server is used by the
Application Kit
to manage windows and to send user events such as mouse and keyboard
actions,
back to an application. Included in the Window Server is a Display
PostScript
interpreter that's used for all drawing of text and graphics on the
screen or
printed page. The Window Server manages all windows and
applications that use
them. It receives and carries out instructions from an application
for drawing
windows and their contents.
* Fifth layer: Mach operating system
The Mach operating system is a multitasking system that provides
complete
compatibility with UNIX 4.3 BSD. Enhancements added in Mach
include:
1. a faster and more consistent system of interprocess
communication,
2. larger virtual memory space,
3. memory mapped files,
4. and multiple threads of execution within a single address
space.
* Bottom layer: Hardware
Microprocessors, controllers and such.
>>>>[End of Quote]<<<<
GNUstep implements the third layer. The X Window System is used by
GNUstep as if it were the Fourth. The X window server is more or less
the same thing, almost exactly the same when you add a DPS extension to
it like Display Ghostscript aims to be. The Second layer is work in
progress and will be part of the GNUstep distribution in the future.
The fifth layer can be substituted in a GNU system either by GNU Mach
with the HURD on top or by Linux [there is also the *BSD systems but
they are not part of the GNU project]. The first layer is provided by
the app developers out there. So, where does WindowMaker fits in all
this? I think that it is now to big to fit in GNUstep and that it needs
to be streamlined. The GNUstep project should implement the Workspace
Manager and I think that it should provide that strange services as the
App icons, the menus, the dock and the File Viewer with a standard way
of extending it through bundles as in NEXTSTEP.
The result here is that I think that WindowMaker does more than it
should do in a finished GNUstep system. It's very nice to use as it is
because I can't have a real NEXTSTEP system [and I won't take any non
free software solution so MacOS X doesn't count] and it does a good
simulation. That was one of the reasons Alfredo said made him decide to
stop coding for AfterStep.
The decission to make it the standard GNOME window manager may be
good because GNUstep needs another thing more than a window manager: the
Workspace Manager. And in complete GNU system GNUstep should be able to
run without pain. Even Mach would be available if using GNU Mach with
the HURD!
I would like to say something in order to finish. Maybe the GNU
project doesn't need GNOME, it is not as elegant or extensible as
GNUstep will be [its much more tweekable but this doesn't count in the
name of consistency]. And maybe the GNU project should take NEXTSTEP
the same as they once take UNIX in order to have something from where to
build, only this time the target will be the GUI of the computer. Take
the NEXTSTEP system outline and think about the mapping of the GNU
project with X and you will find that you will have a complete system
with a nice an Powerful GUI and a great deal of extensibility,
portability and technical excelance.
I don't know where does GNOME fits and why it is important at all,
maybe Richard M. Stallman should explain it to the rest of us. I don't
have a utility for GNOME in my ideal system and think that many of the
GNUstep developers will agree with me that the advantages of having a
complete GNOME system aren't comparable as the ones from having a
complete GNUstep system: technically and phylosophically.
Thank you for reading this real big text and, please quote
selectively,
David Lázaro Saz.
Richard Frith-Macdonald
> For me the looks count, and the original NeXT ones were precious and
> no gtkStep package is going to make me believe that I am using a NeXT
> system if I don't feel it. There are a lot of things lacking even in
> GNUstep. What about the click in scrollbar/dingle in your pointer
> behaviour? And that Alt-Click alternate behaviour? The first one is
> already implemented in GNUstep and feels nice but then I try to use that
> second one... and it doesn't work.
The second one does work - but you need to have your X keyboard mappings
correct - if you go back through the weekly updates on the web site, you will
find some notes about it (several months back). Basically, the problem is
that the X window managers tend to grab the alt keys for their own use, so
you need to get them back by re-mapping the so that GNUstep can use them.
There is probably some way in X to deal with the window manager in order to
do this cleanly, but I don't know it.
Miguel de Icaza Amozurrutia
> I would like to say something in order to finish. Maybe the GNU
> project doesn't need GNOME, it is not as elegant or extensible as
> GNUstep will be [its much more tweekable but this doesn't count in the
> name of consistency].
Do you have any *data* to back this statement or this is based solely
on a magic ball?
Miguel.
Philippe C.D. Robert
> > I would like to say something in order to finish. Maybe the GNU
> > project doesn't need GNOME, it is not as elegant or extensible as
> > GNUstep will be [its much more tweekable but this doesn't count in the
> > name of consistency].
>
> on a magic ball?
I think both 'desktops' have their pros and cons, but it is a fact (proven i.e. by the Enterprise
500 Business), that the OpenStep API is one of the most elegant and most productive API. It's
something that has been used for a decade now, and it is still *the* OO API of choice (don't
mention Java now, this is pure marketing...). There are several papers proving this (measuring the
productivity etc.).
Once GNUstep will be as matured as OPENSTEP or Mac OS X Server are now, it will be *very*
powerfull and perhaps by then the world will recognise what a jewel we have in our bag. You can
see this very easily *right now* once you have written some code for OpenStep and once you
understand the concepts behind it.
GNOME won't ever replace GNUstep and vice versa, but please don't assume that GNUstep is not
worth anything because it is not 'there' yet.
sweet dreams, Phil
---
Philippe C.D. Robert - Software Engineer
########################################
# http://www.nice.ch/~phip #
# http://www.projectcenter.ch #
########################################
slo...@admin.rose-hulman.edu
On Sat, 7 Aug 1999, David [iso-8859-1] Lázaro wrote:
> [Advertency: This is a big post and you may found it utterly wrong if
> you feel that you are losing your time reading this, you may send it to
> /dev/null and send a standard flame to my mail address. If you find it
> useful I would like you to discuss on it.]
David,
This is the first I've heard of the 'RMS post' about a
'GNOME Windowmaker'. I found most of your post to be
very confusing and wonder how much you thought about it
before you posted. Considering that this was cross-posted
to GNOME development lists and contained allusions to the
effect that GNU should ditch GNOME, one also wonders if
this was meant as flame bait. I'll extend the benefit of
a doubt on that for now.
Whether GNU 'needs' GNOME is not material, GNOME exists,
has hundreds of people working on it, has mindshare, is
technically viable, etc., etc., etc. This is all good for
GNU and for Free software in general. I gave up on GNOME
after about a year of following it, when it became clear
to me that it was solidifying technically in ways that
I wasn't confortable with...I was happy early on with
things like GUILE interfaces and ObjC interfaces that later
didn't seem to keep pace. And I hate the panel. And I hate
having icons scattered across the background. And I hate
the Windows-style file explorer. So I quit following it and
now pay more attention to GNUstep. Other people, principally
those working on GNOME or use to Windows will think very
differently about this. So will programmers who are more
comfortable with callbacks/signal/slot/plug/whatever than
a messaging API.
Some things about GNOME are technically wonderful. The
use of CORBA is great, indeed GNOME could easily become the
best example of effective CORBA use. The GNOME canvas is
wonderful, as is libart. Even though I hate the GUI, the
virtual-file-system viewing in GMC is wonderful (I use the
text-based MC in an xterm...Miguel, at some point I'll
submit some patches to make FTP browsing work with VMS hosts)
It has been my hope for a while that some of the non-GUI
'plumbing' of GNOME could be shared/reused by GNUstep. This
would just add more eyeballs to the code. I've several
times suggested for people to look at libart for some of
the backend gui classes. Raph knows what he is doing.
After all of that has been said, I find myself wondering
if this means that GNOME is abandoning the windowmanager
agnostic stance? I really thought the GNOME windowmanager
standards documents were a wonderful contribution...I was
also hoping that some of GNUstep's needs could be audited
against the GNOME standards...use the GNOME standard where
possible and ask for extensions where needed. Maybe a GNU
Window Manager Caucus?
This is starting to ramble, so I'll summarize. GNOME and
GNUstep are *not* mutually exclusive. GNOME is important to
a large pool of developers and a growing pool of users.
GNUstep is important to a different set of developers and
to perhaps a different set of users...time shall tell. If
Richard believes that WindowMaker needs to become more
tightly integrated with GNOME, I don't see the harm. Just
as long as GNUstep isn't compromised. This is ultimately
Alfredo's decision. I think a fork is best avoided if at
all possible...maximize eyeballs, consolidate effort, and
confuse fewer users.
--Robert
--
Robert J. Slover
Administrative Systems Manager/DBA
Rose-Hulman Institute of Technology
Philippe C.D. Robert
> Two, Would anyone be interested in a copy of Garfinkel & Mahoney's book
> _NeXTSTEP PROGRAMMING STEP ONE: Object-Oriented Applications_? I may be able
> to lay my hands on a second copy and would be delighted to pass it on for
> just shipping and handling---contact me off-list.
NEXTSTEP is not OpenStep, so not GNUstep. It has slightly different programming paradigmas and
the APIs are different. So I don't thnk this would help.
Christopher B. Browne
posted:
>the message from Richard M. Stallman. The whole "We Want a GNOME Window
>Maker" thing feels right like a hostile takeover from GNOME. I suppose
>Alfredo remembers why he started developing Window Maker instead of keep
>helping AfterStep. I think that it was to implement a window manager
>with a more NeXT like feel into it. It then followed naturally that
>Window Maker was going to be the official GNUstep window manager.
I too was quite surprised when GNOME was declared to be "so
important," when, for several years, GNUstep had been presented as the
"upcoming GNU GUI system."
If GNUstep had progressed more quickly, then perhaps there wouldn't
have been the incentive for GNOME to be "founded."
That's not the case, so GNOME and GNUstep co-exist, and, at this
point, GNOME has a lot more applications for it than does GNUstep.
> I don't know where does GNOME fits and why it is important at all,
>maybe Richard M. Stallman should explain it to the rest of us. I don't
>have a utility for GNOME in my ideal system and think that many of the
>GNUstep developers will agree with me that the advantages of having a
>complete GNOME system aren't comparable as the ones from having a
>complete GNUstep system: technically and phylosophically.
GNOME is important in that people needed/wanted something *now,* and
not a year later.
It largely uses C, which is more widely understood than Objective C,
but is also fairly language-neutral, with some software written in
C++, Scheme, and, in fact, Objective C (gfax).
Its architecture is fairly different from GNUstep, particularly in
using CORBA, that postdates OPENSTEP, and XML, that also postdates
OPENSTEP.
It seems to me that the parallels are more evident than the
differences, and that the somewhat "ecumenical" approach of GNOME
provides at least two points of contact that can help GNUstep:
a) As GNOME has Objective C as one of its languages, this can
represent an opportunity for the community of people that know
Objective C to grow. That can't but be helpful for GNUstep.
b) GNOME has the notion of a "canvas" that consciously parallels DPS,
and some attempts have been made to use DGS with GNOME, albeit with
limited success due to it not being complete yet.
If GNUstep is an unambiguously better plan than GNOME, then these
things provide routes both towards interoperability and towards
allowing people to *grasp* that they should consider GNUstep.
--
[Message From The Dover at MIT-AI 10:55:60]
HELP ME! HELP ME! MY PAPER FEED IS JAMMED! DO YOU KNOW WHAT IT'S LIKE TO
HAVE YOUR PAPER FEED JAMMED?
cbbr...@ntlug.org- <http://www.hex.net/~cbbrowne/lsf.html>
Dan Pascu
> To be bluntly honest, we *want* Window Maker to be *our* window manager.
> That isn't to say we don't want users to be able to use GNOME or KDE in
> conjunction with Window Maker, but we want to be able to point to Window
> Maker and say, "That is the window manager for GNUstep, everything you
> need can be found there." What worries me is that with "forked" versions
> of Window Maker, people may run a version which doesn't integrate with the
> GNUstep environment and end up getting frustrated. Will it be completly
> obvious that the "GNOME Window Maker" is what someone is running, and not
> the "GNUstep Window Maker"? If that is the case then perhaps it won't be
> such a problem...
Reading this I just realized that we cannot make gnome support compile
time, unless we fork the source tree and the gnome window manager
(derived from wmaker) will become a stand alone entity, used only by
gnome. Else someone running a wmaker binary compiled for gnustep on
gnome (or vice versa) will be very confused by the behavior.
One better idea that came across my mind, is that we can have a single
wmaker binary, designed as a stand alone window manager for X, and the
ability to dynamically load modules at run time, specifically for each
desktop. So, if when starting wmaker finds gnome it will link in the
gnome module, for gnustep the gnustep module, and if none present will
load its own module for X and WINGs
This will lead to a small binary, that will load the required support
for the available desktop at run time, making it small, fast, not
bloated and making anyone happy. Any other desktop can be added as a
module later.
This way we only need to manage our part (based on X and WINGs), and
people developing some desktop can provide the module they need based
on an API we need to specify.
What do you think?
--
Dan
Hadess
fork, more customization for the user that wants it (like me =), but would
require a great deal of work (how to do it The Right Way (tm) ?)
/me still hates having a desktop, prefers happy shelf
/Hadess
--
Themes, Dockapps and links to eye-candy
http://idoru.on.openprojects.net
Richard Stallman
'plumbing' of GNOME could be shared/reused by GNUstep. This
would just add more eyeballs to the code.
I hope so, too--commonality like this is a good thing, when there is a
convenient opportunity. I don't know whether or where this is
practical, but I hope all of you will keep your eyes open for
opportunities of this kind.
Richard Stallman
maybe Richard M. Stallman should explain it to the rest of us.
GNOME is what we're doing to make the GNU system as easy to use for
non-hackers as Windows. That goal is very high priority for the GNU
Project, and therefore GNOME is a very important part of the GNU
Project. It now seems that having a window manager that is good for
GNOME is also very important in order to achieve the goal. So we need
to make one.
In my first message, I took for granted that this should be Window
Maker. I thought so because Window Maker was proposed for the job,
and because it is the only window manager that is GNU software. But I
may have made a mistaken assumption there.
Now it seems people consider several approaches as candidates for the
best method: modify Window Maker, fork Window Maker, or start from
scratch. Which approach to use is a technical decision, and I am not
an expert on it. So I won't try to make the decision; the experts who
are reading this message will decide. I can point out some general
principles--such as, that forking a program is unfortunate, so it
should be the last resort.
But I want to ask everyone reading this message to give high priority
to helping GNOME make the GNU system appealing and easy for
non-hackers to use. Whichever method seems to be best, please help it
succeed. A good GUI will make a great difference for the success of
the GNU Project in its main goal: giving freedom to a wide range of
computer users.
George Farris
d...@services.iiruc.ro (Dan Pascu) writes:
>
> One better idea that came across my mind, is that we can have a single
> wmaker binary, designed as a stand alone window manager for X, and the
> ability to dynamically load modules at run time, specifically for each
> desktop. So, if when starting wmaker finds gnome it will link in the
> gnome module, for gnustep the gnustep module, and if none present will
> load its own module for X and WINGs
What happens when one is running both GNOME and GNUstep? Would it work
properly or would things get confusing?
Michael Hanni
Hello Dan,
On Sat, 7 Aug 1999, Dan Pascu wrote:
> Reading this I just realized that we cannot make gnome support compile
> time, unless we fork the source tree and the gnome window manager
> (derived from wmaker) will become a stand alone entity, used only by
> gnome. Else someone running a wmaker binary compiled for gnustep on
> gnome (or vice versa) will be very confused by the behavior.
That is what I was afraid of...
> One better idea that came across my mind, is that we can have a single
> wmaker binary, designed as a stand alone window manager for X, and the
> ability to dynamically load modules at run time, specifically for each
> desktop. So, if when starting wmaker finds gnome it will link in the
> gnome module, for gnustep the gnustep module, and if none present will
> load its own module for X and WINGs
> This will lead to a small binary, that will load the required support
> for the available desktop at run time, making it small, fast, not
> bloated and making anyone happy. Any other desktop can be added as a
> module later.
Not bad... Though I have one question. Would this solution allow for a
user to use both GNOME and GNUstep at the same time? My beef is this: I
like the ideas and people behind GNONE, hell I've even contributed code,
but I don't want future GNUstep users to have to choose between the two.
That will not be an acceptable situation. Never-the-less, regardless of
what happens users can still use both types of applications, but just not
with all the support we would like.
I wonder if there is a middle ground that we can reach with the GNOME
people on window manager compliance? It seems to me that the needs of both
parties are not necessarily mutually exclusive. For window level,
workspace, and what not, the requirements are the same. I'd be willing to
wager that we would even use the GNOME window manager spec if we had to.
It seems a shame to me that the forces of the free software elite are so
willing to side-swipe the GNUstep project (not to mention the Window Maker
project) after so much time and effort has been invested in it --
especially since we are getting so close to being ready for widespread
use...
Martin Baehr
> Now it seems people consider several approaches as candidates for the
> best method:
> modify Window Maker,
> fork Window Maker,
> or start from scratch.
two more options have been (or should be) mentioned:
modify a different windowmanager (icewm, lwm, wm2, ...)
fork a different windowmanager...
greetings, martin.
--
Life is not fair. But the root password helps.
--
unix systemadministrator iaeste.or.at iaeste.tuwien.ac.at mb.iaeste.or.at.
institut hochbau II an der tu wien.
email.archlab.tuwien.ac.at.
black.linux-m68k.org.
stuts.org.
mud.at.
Martin B"ahr
mba...@iaeste.or.at
Dan Pascu
> This idea of "loadable modules" is very interesting. It would avoid tree
> fork, more customization for the user that wants it (like me =), but would
I don't see any user level customization here. Just that wmaker will
check when starts which desktop is already running, and load a module
to support that. If none found it loads its own default module for X.
Nothing to customize really from the user point of view.
Unless the user writes a module for its own taste.
> require a great deal of work (how to do it The Right Way (tm) ?)
I don't think so. On the contrary it will spread the work. We will only
need to implement the part that deals with checking for the
desktop running, loading the module for that desktop, and using the
available functions in that module to do its job. The people at gnome
can implement their module as they like, people at gnustep do the same.
Even modules for kde can be created.
This way is quite easy to provide some functions for some module while
not for other.
For example there should be a function in the API for setting the
background. In the gnome module that function should do nothing, and
immediately return, because the background is managed by gnome. (or it
will only notify gnome of the call to background change).
On the contrary in the default module for X, that function should do
all the things it does now.
All we need is to design this API, specify some way for wmaker to
detect what desktop is available (maybe an X property, but this should
be also handled by GNUstep when not having a backend based on X).
Then we will move our functions in a module and wait for people at
gnome and anyone else who is interested to implement their own module.
--
Dan
Dan Pascu
> In article <1999080713...@dawn.iiruc.ro>,
> d...@services.iiruc.ro (Dan Pascu) writes:
>>
>> wmaker binary, designed as a stand alone window manager for X, and the
>> ability to dynamically load modules at run time, specifically for each
>> desktop. So, if when starting wmaker finds gnome it will link in the
>> gnome module, for gnustep the gnustep module, and if none present will
>> load its own module for X and WINGs
>
> properly or would things get confusing?
>
How did you think you can run both gnome and gnustep (I mean the
desktops, not apps from each of them).
I think when there is the gnome desktop running, you will not be able
to run the Workspace manager, and viceversa, since they want to control
the same resources.
--
Dan
Alfredo Kengi Kojima
> Not bad... Though I have one question. Would this solution allow for a
> user to use both GNOME and GNUstep at the same time? My beef is this: I
> like the ideas and people behind GNONE, hell I've even contributed code,
> but I don't want future GNUstep users to have to choose between the two.
> That will not be an acceptable situation. Never-the-less, regardless of
> what happens users can still use both types of applications, but just not
> with all the support we would like.
The idea (at least what I have in mind) is to make only the desktop
related portions of wmaker as modules. The things that are necessary for
supporting ICCCM, GNUstep, GNOME or anything else would be kept in the
core.
--
Alfredo
Dan Pascu
> Not bad... Though I have one question. Would this solution allow for a
> user to use both GNOME and GNUstep at the same time? My beef is this: I
Can you run at the same time the gnustep Workspace manager, and the
gnome equivalent of it?
I was not thinking of apps from the two, but from the main part (the
core) of them which should be detected, and I think you cannot run the
core of gnome and the core of gnustep at the same time.
Each desktop environment have a sort of Workspace app that controls
background, workspaces, ..., and you cannot run two of them at the same
time. The one that runs give the tone of the desktop.
And you can run any app you like.
--
Dan
Michael Hanni
Hi,
On Sat, 7 Aug 1999, Alfredo Kengi Kojima wrote:
> On Sat, 7 Aug 1999, Michael Hanni wrote:
>
> > Not bad... Though I have one question. Would this solution allow for a
> > user to use both GNOME and GNUstep at the same time? My beef is this: I
> > like the ideas and people behind GNONE, hell I've even contributed code,
> > but I don't want future GNUstep users to have to choose between the two.
> > That will not be an acceptable situation. Never-the-less, regardless of
> > what happens users can still use both types of applications, but just not
> > with all the support we would like.
Sorry, I should first enumerate a little. What I meant is this: for
GNUstep we will need special services and protocols so that the window
manager will know what to do with app-icons and cursor wait&spin, etc. I'm
not sure if GNOME will require anything like this... Without these things
using GNUstep will seem awkward -- and I had assumed GNOME as well (can
someone comment on this? Or am I trying to fight a change in the name of
the window level hints? :)) I just wanted to know if it would be possible
to support both the GNUstep needs and whatever GNOME needs at the same
time so that atleast we can use application written for both at the same
time.
(Dan: I don't mean running both workspace-type applications at the same
time... I just want to make sure that regardless of what happens I can
still use InterfaceModeller.app, ProjectCenter.app, and gnumeric at the
same time.)
> The idea (at least what I have in mind) is to make only the desktop
> related portions of wmaker as modules. The things that are necessary for
> supporting ICCCM, GNUstep, GNOME or anything else would be kept in the
> core.
I guess thats fair, atleast we won't be left without a window manager that
supports GNUstep.
Regardless, whatever you choose Alfredo will be wonderful, and I -- and
I'm sure the rest of the GNUstep community -- will support you.
Now if you'll excuse me, I have to go make a handful of MacOS-X/GNUstep
developers happy by fixing libgmodel. :-)
Cheers,
Michael
/*
* Michael Hanni <mha...@sprintmail.com>
* GNUstep Developer/Hacker
Pascal J. Bourguignon
> [...]
> One better idea that came across my mind, is that we can have a single
> wmaker binary, designed as a stand alone window manager for X, and the
> ability to dynamically load modules at run time, specifically for each
> desktop. So, if when starting wmaker finds gnome it will link in the
> gnome module, for gnustep the gnustep module, and if none present will
> load its own module for X and WINGs
> for the available desktop at run time, making it small, fast, not
> bloated and making anyone happy. Any other desktop can be added as a
> module later.
> people developing some desktop can provide the module they need based
> on an API we need to specify.
>
> What do you think?
>
> Dan
Yes, good idea! And more: make it so that several different modules can
be loaded at the same time. I would not mind having a GNUstep
application shown in NeXTSTEP windows, a GNOME application shown in
GNOME windows, and a Motif application shown in Motif windows. If I'd
want to have a common user interface, I would use only applications made
for the same user interface. In KDE, they "port" to their UI all kind of
X-windows applications.
It's important because what kind of common look-and-feel is to have
emacs with emacs menus, X-like, in a window of NeXTSTEP look? Where is
the NeXTSTEP menu of emacs when I put it in a NeXTSTEP window? See? It
would be better for the user to see that its applications don't have the
same kind of user interface, by keeping the native look and feel of each
one.
__Pascal Bourguignon__
--
mailto:p...@imaginet.fr http://www.imaginet.fr/~pjb/
SMS=mailto:6490...@activajoven.tsm.es phoneto:+34649040387
+--- C: a bool is a bool ; a pointer is a pointer!----------------+
void PleaseWrite(bool isBetter,void* pointer,int value)
{if((!isBetter)&&(pointer!=NULL)||(value==0)){ print("Right!\n"); }}
void DontBeSilly(bool isSilly,void* pointer,int value)
{if((isSilly!=true)&&(pointer)||(!value)){ print("Wrong!!\n"); }}
+------- Hi! I'm a signature virus. Copy me into your sign -------+
Pascal J. Bourguignon
>
[...]
> Sorry, I should first enumerate a little. What I meant is this: for
> GNUstep we will need special services and protocols so that the window
> manager will know what to do with app-icons and cursor wait&spin, etc. I'm
> not sure if GNOME will require anything like this... Without these things
> using GNUstep will seem awkward -- and I had assumed GNOME as well (can
> someone comment on this? Or am I trying to fight a change in the name of
> the window level hints? :)) I just wanted to know if it would be possible
> to support both the GNUstep needs and whatever GNOME needs at the same
> time so that atleast we can use application written for both at the same
> time.
May I remind everybody some points regarding NeXT's implementations of
the user interface:
- The app-icon window is entirely created and managed by the
NSApplication object, code running in the application processus,
this is evidenced by the fact that:
- When you run an application with no Workspace Manager (launching the
application at login-time, instead of the Workspace Manager, I've
done it for users that did not want to access to anything else than
their application):
the app-icon window still shows on the screen
- The Workspace Manager is an application that is exactly like the
others
it has no special priviledge, and do not manage, or expect exclusive
access to, any resource. You could very well launch several
instances,
and this could very well be very usefull to do (remotely, for
example).
(Well, it's possible that NeXT's Workspace Manager had some little
glitches when running serveral instances, but I considered them a
bug).
- All the user interface aspects, look and feel were implemented in the
appkit objects, that is, in code running in each application
processes.
(With very little support code sent and executed in the DPS server).
There were zero byte of code in the window server drawing a window
frame.
That means that the look and the feel of all the application elements
depend only on the application, not on where it is shown.
Obviously, doing it in an other way poses numerous problems, witnessed
by the proliferation of specific additions and protocols that must be
implemented by X-Window window managers to stay compatibles with the
X-Window applications.
If we recognize that the features of a X-Window server alone are not
"equivalent" architecturally to those of a DPS server, and that a
X-Window server needs a window manager to attain this equivalence, on
the other hand we must not overdo it. I would propose a window manager
extremely minimal that would only behave like a DPS server with the
appkit support code, that is, it would do no decoration, no dock, no
"apps menu", nothing but serve blank windows and send back events.
Up to the appkits, that of GNUstep, or that of GNOME and others KDE to
do what they want, and to display and behave windows, menues and so on,
which much less problems, in a cleaner architecture.
arik devens
> On 6 Aug, Michael Hanni wrote:
> > To be bluntly honest, we *want* Window Maker to be *our* window manager.
> > That isn't to say we don't want users to be able to use GNOME or KDE in
> > conjunction with Window Maker, but we want to be able to point to Window
> > Maker and say, "That is the window manager for GNUstep, everything you
> > need can be found there." What worries me is that with "forked" versions
> > of Window Maker, people may run a version which doesn't integrate with the
> > GNUstep environment and end up getting frustrated. Will it be completly
> > obvious that the "GNOME Window Maker" is what someone is running, and not
> > the "GNUstep Window Maker"? If that is the case then perhaps it won't be
> > such a problem...
>
> time, unless we fork the source tree and the gnome window manager
> (derived from wmaker) will become a stand alone entity, used only by
> gnome. Else someone running a wmaker binary compiled for gnustep on
> gnome (or vice versa) will be very confused by the behavior.
>
> wmaker binary, designed as a stand alone window manager for X, and the
> ability to dynamically load modules at run time, specifically for each
> desktop. So, if when starting wmaker finds gnome it will link in the
> gnome module, for gnustep the gnustep module, and if none present will
> load its own module for X and WINGs
> This will lead to a small binary, that will load the required support
> for the available desktop at run time, making it small, fast, not
> bloated and making anyone happy. Any other desktop can be added as a
> module later.
> This way we only need to manage our part (based on X and WINGs), and
> people developing some desktop can provide the module they need based
> on an API we need to specify.
>
> What do you think?
>
> --
> Dan
i would just like to mention that i am in the process of writing a gnome window
manager. hopefully it will fly and then this whole window maker thing will go
away.
arik
--
Jen fa Ti: Ti fa T'sien: T'sien fa Tao. Tao fa tzu-jan.
-- lao tsu from the tao te ching
David Lázaro
>
> If we recognize that the features of a X-Window server alone are not
> "equivalent" architecturally to those of a DPS server, and that a
> X-Window server needs a window manager to attain this equivalence, on
> the other hand we must not overdo it. I would propose a window manager
> extremely minimal that would only behave like a DPS server with the
> appkit support code, that is, it would do no decoration, no dock, no
> "apps menu", nothing but serve blank windows and send back events.
>
> Up to the appkits, that of GNUstep, or that of GNOME and others KDE to
> do what they want, and to display and behave windows, menues and so on,
> which much less problems, in a cleaner architecture.
I find this comment very wise. IMHO that will be something worth
trying.
--
David Lázaro Saz
E-mail: khel...@encomix.es
GSM messaging mailbox: 6968...@correo.movistar.net
Christopher B. Browne
> I don't know where does GNOME fits and why it is important at all,
> maybe Richard M. Stallman should explain it to the rest of us.
>
>non-hackers as Windows. That goal is very high priority for the GNU
>Project, and therefore GNOME is a very important part of the GNU
>Project. It now seems that having a window manager that is good for
>GNOME is also very important in order to achieve the goal. So we need
>to make one.
The thing that is a bit confusing is the comparative standing, in the
FSF context, of GNOME and GNUstep. The question may be getting raised
due to issues surrounding WindowMaker; if you think this is merely a
question of how a window manager develops, I think you're not seeing
the real conflict, to which the question
"where does GNOME fits and why it is important at all"
is decidedly directed.
GNUstep was being treated in the past as the "GNU Project's GUI." In
favor of this interpretation, the only project that I am aware of where
the FSF solicited directed contributions was towards the development of
Display Ghostscript, a conspicuously GNUstep-related project.
Looking back at GNUS Bulletins, that venue has not been terribly specific;
GNUStep is "merely" presented as a "GNU implementation" of OpenStep.
In GNUS Bulletin #24, GTK is presented as "the GNU GUI toolkit," which
is a conspicuous change in direction.
The critical question is, is GNUstep the GNU GUI? Or GTK/GNOME? The word
"the" is singular, thus implying that they both can't be at once.
I speculate that what has happened here is that GNUstep has been quite
slow to get to the point of having *useful* results, whilst GNOME has
perhaps been something of a "hack," but nonetheless quicker to provide
things that are easily deployed.
That's not to say that nobody has used GNUstep to do anything useful, but
rather, consider that there are only a very few deployed applications
that are not by any means *widely* deployed. In comparison, there
are probably 30-40 GNOME applications, many of which are included with
commercial "Linux distributions."
From a completely practical perspective, GNUstep is looking pretty lame
in that it has been under way for 4 years, and is still not being used
for any widely used applications running on "GNU systems."
That's a bit of a blast against GNUstep, and could be implied to suggest
that GNUstep should be "dropped." I think things should really be a
lot more cooperative than that, to be sure...
GNOME largely consists of libraries that are intended to assist in
creating applications. Most of the libraries *aren't* GUI facilities;
they include things like an XML parser, an ORB, a config library,
a virtual filesystem scheme, sound support, ...
Interoperability can be a valuable two-way street, from various
perspectives:
- Given decent Objective-C bindings to some of the GNOME facilities,
this can help grow the population of people that know Objective-C,
a prerequisite to the growth of developers for GNUstep.
- There are things that may be contributed back and forth. GNOME has
XML, CORBA, and VFS facilities that should be useful to GNUstep.
GNUstep has a pretty neat configuration scheme, available in C as
libPropList, that might represent a decent alternative to GNOME's
"gnome-config" that is apparently considered inadequate. Both
projects have had interest in DPS, albeit with GNUstep considering
it *CRITICAL.*
These are all ways that GNUstep and GNOME can benefit from coexistance.
But it is important that these systems are seen as "coexisting,"
otherwise it looks a lot more like the FSF used to care about GNUstep,
and now cares about GNOME instead.
--
"The main reason for open-source gets developed is need. If the need
is there, then the software will get written. If it isn't really
needed, then the lack of software is hardly a problem, right?"
-- Almost Brian Hurt's Words <bh...@visi.com>
cbbr...@hex.net- <http://www.ntlug.org/~cbbrowne/xgnustep.html>
Philippe C.D. Robert
<snip>
> GNUstep was being treated in the past as the "GNU Project's GUI." In
> favor of this interpretation, the only project that I am aware of where
> the FSF solicited directed contributions was towards the development of
> Display Ghostscript, a conspicuously GNUstep-related project.
>
> Looking back at GNUS Bulletins, that venue has not been terribly specific;
> GNUStep is "merely" presented as a "GNU implementation" of OpenStep.
>
> In GNUS Bulletin #24, GTK is presented as "the GNU GUI toolkit," which
> is a conspicuous change in direction.
>
> The critical question is, is GNUstep the GNU GUI? Or GTK/GNOME? The word
> "the" is singular, thus implying that they both can't be at once.
The cool thing about Open Source is that everyone can do what he/she wants to do. So assuming
there are 2 GNU UIs, then this is great since the user can choose which one to use! You see, it's
like KDE 'vs' GNOME: I bet, if there had been only one of them, the speed of development would
have been much much slower! So what's the point of an 'official UI', IMHO it just doesn't matter
(please correct me, if I am wrong). What *does* matter is the quality and the progress of any Open
Source solutions, not if they are official are not - what this word means or doesn't...
And of both solutions work together then it's even better, so we should perhaps discuss this
point more than whether GNOME or GNUstep is the 'official' GNU UI...
Just my $0.02...
Marko Macek
>
> "Pascal J. Bourguignon" wrote:
> >
> > If we recognize that the features of a X-Window server alone are not
> > "equivalent" architecturally to those of a DPS server, and that a
> > X-Window server needs a window manager to attain this equivalence, on
> > the other hand we must not overdo it. I would propose a window manager
> > extremely minimal that would only behave like a DPS server with the
> > appkit support code, that is, it would do no decoration, no dock, no
> > "apps menu", nothing but serve blank windows and send back events.
> >
> > Up to the appkits, that of GNUstep, or that of GNOME and others KDE to
> > do what they want, and to display and behave windows, menues and so on,
> > which much less problems, in a cleaner architecture.
>
> I find this comment very wise. IMHO that will be something worth
> trying.
This can almost be done with the current GNOME WM specification (+ Motif
hints to get nondecorated window). The only thing missing is a message
to do window resizing/moving which has been proposed for the next WM
specification.
The problem with this is that applications HAVE to be threaded (or multi
process) to respond to user messages immediatelly. The major advantage
of X window manager model is that the WM is asynchronous from the
applications and you can always minimize some window that is in the way
for example. With windows and OS/2 that implement a window manager as a
DLL you can't do this and it very annoying. Windows is slightly better
than OS/2 because it allows async focus switches, but it is not nearly
enough.
Mark
--
.. GUI: WPS.
------------------------------------------------------------------------
Marko...@gmx.net http://www.kiss.uni-lj.si/~k4fr0235/
Hadess
> > This idea of "loadable modules" is very interesting. It would avoid tree
> > fork, more customization for the user that wants it (like me =), but
would
>
> I don't see any user level customization here. Just that wmaker will
> check when starts which desktop is already running, and load a module
> to support that. If none found it loads its own default module for X.
> Nothing to customize really from the user point of view.
> Unless the user writes a module for its own taste.
I was meaning that if (for example) I want to use GTK dialogs and the
Dock/Clip. Maybe I missed the point.
> All we need is to design this API, specify some way for wmaker to
Design the API _is_ the hard work. I'm sure your programming skills are good
enough for this (last year, when Alfredo was away, you released the Clip 2
days too late, for me to impress over 800 persons =)
> detect what desktop is available (maybe an X property, but this should
> be also handled by GNUstep when not having a backend based on X).
slo...@admin.rose-hulman.edu
I believe that there are practical opportunities for this
wherever GNUstep and GNOME have to solve the same problems.
This is fairly common. GNOME has some ancillary libraries
that abstract differences between unices, for instance.
GNUstep has to do the same thing.
One good example is libgtop, which gathers process information
for the GNOME version of the 'top' utility, as well as several
panel applets (I think). Last I checked it supported sundry
BSD's, GNU/Linux, Solaris, DEC OSF1/Digital Unix/Tru64/?!foo?!
and maybe Irix. Some unices let you get this info by walking
structures in /dev/kmem, others by something like /proc. Then
there is HP/UX which does a wierd thing of its own. Some of
these require the user to be in special groups to get at the
info at all. GNOME has solved this problem with libgtop and
a companion daemon where necessary.
Just this week, a fellow announced to the GNUstep list a
really *nice* process browser, which currently works only
with GNU/Linux because it reads /proc for info. Here is a
perfect opportunity to factor some code from GNOME for the
good of GNU as a whole!
-----
Back to the question at hand, I'm curious about what needs to
be added to WM to make GNOME integrate well. What is missing?
Here's my own list for what is missing for GNUstep.
1. A way for the focused App to set the cursor, and I'm not
talking about the usual X behaviour. If the focused app
is busy and has requested a wait cursor, I'd like to see
it even if the pointer migrates outside of the X client
boundry. I'd think this requires the window manager to
handle it. GNOME probably needs some variation of this
too.
2. A protocol for finding out where to draw the App tile,
and notification when it needs to be moved (for instance,
when another App quits).
3. Notification when the screen resolution changes (XFree
allows this) so that apps can redraw. One inch should
be one inch no matter the screen resolution, as should
12 points be 12 points. NeXT, GEM, and the Mac all
seemed to have little problem getting this right. Why
does nothing else? As a former professional typesetter,
this drives me nuts. GNOME should expect to get this
right too if the GIMP and the like ever intend to
satisfy professionals.
4. Notifications to GNUstep apps when WindowMaker actions
like 'Hide Others' are initiated. An app should know
when it is asked to be hidden, and hide itself (or not).
That's a short list. Alfredo has done an incredible job,
and if GNOME *must* pick a window manager, I can't think
of a better one. What is missing for GNOME?
--Robert