Desktops, Components and Roles

[Nicolas Roard]

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