Re: "Desktop bundles" and host-platform interfaces

[Sheldon Gill]

Peter Cooper wrote:
> Hi everyone
>
> I was going to update the wiki with some thoughts about desktop bundles
> and host-platform service interfaces, but it's still locked. Instead,
> the dev mailing list will get spammed - it might be useful to discuss
> anyway.
>
> There's been some discussion about the need for "desktop bundles" in
> GNUstep. They are intended to support using GNUstep apps within a native
> desktop environment like GNOME, KDE, Windows and MacOSX. I guess these
> bundles will be tied in to some kind of UI theme, too.

Probably will be tied to a UI theme eventually. Initially much of the work is 
at a lower level.

> I think it's a good idea, it'd be nice to be able to use GNUstep and the
> development tools to create native-like apps for other platforms. Even
> better, doing this might make a GNUstep-native environment richer, by
> creating a GNUstep-native bundle that enables the same kind of
> functionality in a GNUstep desktop kind of way.

This is where things get murky. What's a "GNUstep desktop kind of way"?

I believe that the key initial direction is a set of API/Classes which 
appropriately provide the underlying mechanisms or re-target existing ones so 
that the platform specific approach is well integrated.

My view is that an environment discovery mechanism (ala Gestalt) is the right 
starting point. So applications can ask "hasX" or "supportsX" questions.

> The key areas I can think of that would benefit from a bundle of 
> prebuilt standard dialogs, integrated host-desktop dialogs, controls
> and GNUstep-like APIs are:
>
> * disk and file management
>   - managing volumes - platform/filesystem independent capacity,
>     read-only/read-write status, formatting, inserting, ejecting
>   - utilising local shortcut schemes, special folders, VFS schemes etc
>   - integration into local indexing services

I agree that applications should be able to cleanly access this functionality. 
Not so sure about UI facilities. They'd be per application rather than provided 
by a bundle.

> * misc hardware
>   - power management integration
>   - battery data
>   - screen topology (how many? what layout?), bit-depth and blanking
>   - local printer services
>   - consumer electronics services (cameras, music players, home
>     entertainment devices)
>
> * data, IPC and helper apps
>   - integration into local cut and paste services where not already 
>     operational, or where extra functionality exists
>   - use of local calendar, identity (vCard-like), authenication,
>     privilege-escalation, and mail services
>   - messaging, voice and video services
>   - integration of local IPC types where appropriate into GS mechanisms
>   - use of and registration into local MIME and file type mappings
>   - start and stop local services
>
> * networking
>   - interface configuration
>   - interface authentication
>   - profiles
>   - remote desktop services
>   - web and internet services (proxies, system-wide aggregators)
>
> * internationalisation and localisation
>   - integration into local localisation services for currency symbols,
>     date formats, sort orders, timezone name display-names, well-known
>     filesystem locations...
>   - keyboard layout etc

There is a lot of work in -core still needed in this area.

> * assistive and automation services
>   - local screen readers and assistance services
>   - local alternative data entry systems
>   - proxies for local automation services
>
> The idea would be first to be able to harvest these things from the
> local system, so that our application that wishes to appear native can
> use local services, provide expected functionality, display the
> appropriate local directory names depending on the language settings of
> the user, battery charge status etc.
>
> In some cases, there are new Cocoa classes that would be well-suited to
> deliver this functionality to a GNUstep app, and where a desktop bundle
> could provide UI wrapping for it. In other cases, it'd be necessary to
> create some kind of well-thought-out GS extension classes I guess.

Definitely. There are actually quite a few extension classes required to 
encapsulate all the above. For some of it the design work needed is actually 
quite extensive.

For example, network authentication and authorisation would be a big design 
task unless you go with Open Directory.
Messaging is an extensive field of much interest but also debate. It gets too 
close to Collaboration and GroupWare...

> You'd probably need a backend bundle - GNOME runs on a large number of
> platforms, all of which have different ways of doing power-management,
> for example. KDE and a native GNUstep desktop are in the same boat -
> it seems sensible to create common backends for them for Linux, the
> BSDs, etc.

Some of this is being addressed by the FreeDesktop standards. I personally 
think some of their solutions aren't what they should be but until I put up 
I'll keep quiet.

> Is anyone doing any work on these things at this point? 

Umm... yes. Me. Mostly for Win32 at this point because it's the outlyer but 
also because it has preferred solutions for most of these things. (Even if 
they're not very nice...)

For example, integrating  assistive technology on *nix means decided which of 
several competing standards should be supported. Since it needs -core work 
there is a lot to be done to get the front-end/back-end design into good shape.

I've done some KDE hacking in the past but held off really getting stuck in 
there until workable, reliable ObjC++.


Regards,
Sheldon