[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Desktops, Components and Roles
From: |
Nicolas Roard |
Subject: |
Desktops, Components and Roles |
Date: |
Thu, 10 Feb 2005 19:00:56 +0000 |
Le 10 févr. 05, à 13:10, Quentin Mathé a écrit :
I must confess that I still don't fully understand the
differences/goals/interaction between the 3 desktop efforts... your
explanation made it somewhat clearer, but only slightly :) . I have
the view that, although GNUstep isn't a dekstop by itself, it should
have a default desktop environment where things like the dock, the
status area, etc are well defined.. Apps shouldn't rely on them and
should run on GNOME/KDE/CDE/whatever, but there should be a way to
have a GNUstep desktop proper, i.e. it should be part of the desired
goal for GNUstep proper.
I agree, my hopes is we can merge somewhat the various desktop
environments later in the year, the name of current desktop
environments (Backbone, Garma and Étoilé) should be probably be
associated with specific loadable set of components (like Workspace,
Dock, or specific framework etc.) and the code would be stored in just
one GNUstep environment repository. Like themable behaviors built on a
common semantic, it looks like a more extended version of the roles
idea discussed by Stefan Urbanek in the past… I think it's not easy to
achieve, but Nicolas yesterday convinced it's probably the way to go
until we choose may be at some point a default set of components as
the default GNUstep environment.
OK, here is my point/rant : at the moment, we have 4 projects related
to a "gnustep dekstop": Garma, Backbone, GAP and Étoilé.
Each one have slightly different goals, so there's a reason they exist.
And it's not _that_ a big deal, because GNUstep provides us the basic
cooperation services (pasteboard, services, nsworkspace..) -- meaning
that Garma can reuse Backbone's apps, Backbone can use GAP
applications, etc. All transparently.
BUT.
It's still a shame to have basically 4 efforts toward a (very) similar
goal, while we are so few gnustep developers.
Having one well-identified project would be much better for the users
AND for the developers. It will help reuse of common frameworks.
The problem, of course, is each project has a slightly different goal,
so it's probably difficult to reach an agreement to join all theses
projects into one (and to be blunt,
there's probably some kind of "I want to do whatever I want in my
corner"-power-thing that plays too). I would be happy if all the people
involved will prove me wrong ;-)
But anyway, even if everybody agrees to work on a single desktop, that
won't solve all the problems -- for example, Étoilé's goal is not
Backbone's goal (and that's why I participate to both of them) --
Étoilé don't want to be a clone of the OPENSTEP desktop, but something
more advanced/different, more experimental. Yet, lots of things in
Étoilé (frameworks like IconKit) should (and probably will, anyway) be
used by Backbone or other projects. How can we reconcile different
goals with the idea and advantage of *one* project ?
Stefan Urbanek proposed a while ago having "roles" in gnustep.
Basically, you'd say, GNUMail has the role "Mail client", Waiho has the
role "FTP client". Applications could call automatically the
applications corresponding to a role they need (say, a webbrowser will
call GNUMail on clicking on an email adress, but instead of calling
gnumail directly, call a "Mail client"). That's something needed if we
want to have a minimum of flexibility for the users; we can have
different applications fulfilling a same role, and the user should be
able to easily specify the one it want by default. It's basically
extending the current mechanism of viewer/editor already in place (as
you can see in GWorkspace if you have different image viewers...), that
does exactly that but just for viewing/editing a file.
Well, my proposition would be to add the roles concept, but to extend
it to have hierarchical "roles". Thus, you would have something like:
Files/RTF/Viewer/Ink.app and Files/RTF/Editor/TextEdit.app ... or
Network/FTP/Client/Waiho.app, Network/Mail/Client/GNUMail.app
But furthermore, you would also have Desktop/Backbone, Desktop/Garma,
Desktop/Étoilé -- so for example Backbone would require a sub-role
"dock" and a sub-role "workspace", while Étoilé won't have a sub-role
"dock" for example. Then, the user will just select the desktop he
wants, the same way he would select his preferred Mail client.
The same way, the services could be handled by this registry, you would
have Services/GNUMail/Open mail with content ...
and you could easily extend that to "programmable" services, ie
"services" directly callable by an application using DO and not the
pasteboard... the same mechanism could be used to handles components as
well..
To sum up, I advocate something not unlike a LDAP directory for having
a lot of flexibility.
In doing so, it will be easy to have a common desktop project, where
the user will have the possibility of choosing its flavor. We use
GNUstep and Objective-C because of the increased flexibility brought by
them -- why should we be happy with a "monolithic" desktop ?
Comments appreciated...
--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke