[cldp] Re: libraries wrapping incompatible interfaces
- From: "Benjamin Rich" <benjamin.rich@xxxxxxxxx>
- To: cldp@xxxxxxxxxxxxx
- Date: Fri, 14 Apr 2006 10:19:15 +1000
Karol,
On 4/14/06, Karol Pietrzak <kap4020@xxxxxxx> wrote:
> Hello there.
>
> The Common Linux Desktop Platform project struck my eye for two reasons:
> 1. Because Linux needs this
> 2. Because I was working on something vaguely similar
>
> Quick question, though: would this CLDP contain wrappers for items like
> printing, installing menu items, "Autoplay" for CD-ROM/DVD-ROM drives, etc.?
Haven't thought about this aspect yet =P
Things like adding menu items is taken care of by freedesktop.org
standards and a few apps they've recently released as part of the
Portland project, so I think this would be relatively easy to
implement on "all ditros".
As for printing and filesystem access, I imagined this would be done
through the subsystems available in the chosen target desktop manager
- eg. GNOME has it's own interfaces into the file system, into cups,
etc.
The LDBK really applies to desktop apps only, so we'd be dealing with
almost exclusively GUI applications - and every GUI app, as we know,
makes it's own choices about whether it's a GNOME app, a KDE app, or
which toolkit it uses, etc.
With the BrickLayer idea, an application would be able to require GTK,
GNOME, CUPS, Bonobo etc. are present and then implement things it's
own way.
> These are features that exist right now, but the problem is that developers
> can't take advantage of them without selecting a specific software package,
> such as CUPS or KDE.
This is of course the problem, but until we (eg. the whole Linux
community) can universalize all these subsystems, introducing it in
CLDP would be a big duplication of effort, in my opinion. We either
take sides by saying 'use CUPS for everything, that all this platform
supports or recognises' - which in the OSS community, would be
political suicide; or we make our own universal printing subsystem,
and add it to the large and ever-growing pile of such systems, meaning
that it's success in the platform rides on it's success in everyone in
the OSS community liking it and backing it. In short, it's one of
those things like a universal calendar format - it's something in the
process of being decided, and adding our own version would just
confuse things further.
Plus, the majority of applications will center around the 'best',
simplest and most stable interface (which they already do), and let's
face it, that'll probably be CUPS. The platform should simply allow
them to do this, and everything will still work.
-Ben
> Thanks for everyone's time!
>
> --
> Karl Pietrzak
> kap4020@xxxxxxx
>
>
>
Other related posts:
