discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnustep-ui] Desktops, Components and Roles


From: Jesse Ross
Subject: Re: [Gnustep-ui] Desktops, Components and Roles
Date: Thu, 10 Feb 2005 13:40:59 -0600 (CST)

>
> 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.

Not only that, but having a unified project will making marketing a
gazillion times easier.

Which sounds better?

"What are you using? That doesn't look like Winders XP?" "Well, it's
[insert desktop of choice], which uses the GNUstep frameworks."

-- or --

"What are you using? That doesn't look like Winders XP?" "GNUstep."

By unifying the desktop, the GNUstep name gains more mindshare and could
potentially attract more users and developers.

>
> 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 ;-)

I think this is kind of unavoidable given the nature of open source.

>
> 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..

I think this is an absolutely brilliant idea. It puts the power in the
hands of the users to customize to their individual
workflow/interests/aesthetics, but keeps the identity of the project in
the forefront and keeps the developers working in unison.

>
> 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
>
>
> _______________________________________________
> Gnustep-ui mailing list
> Gnustep-ui@gna.org
> https://mail.gna.org/listinfo/gnustep-ui






reply via email to

[Prev in Thread] Current Thread [Next in Thread]