[cldp] Re: libraries wrapping incompatible interfaces

  • From: "Benjamin Rich" <benjamin.rich@xxxxxxxxx>
  • To: cldp@xxxxxxxxxxxxx
  • Date: Sat, 15 Apr 2006 13:52:57 +1000


On 4/15/06, Karol Pietrzak <kap4020@xxxxxxx> wrote:
> On Friday 14 April 2006 18:23, Benjamin Rich wrote:
> > Karol,
> >
> > > One thing I'd like the Linux community to move away from is the strictly
> > > GNOME or strictly KDE applications.
> > >
> > > For example, Gaphor [http://gaphor.sourceforge.net/] is a GNOME UML
> > > application, while Umbrello [http://uml.sourceforge.net] is a KDE UML
> > > application.
> > >
> > > I think it leads to a lot of duplication, just like the current RPM
> > > situation.
> >
> > I definitely agree, but until a universal toolkit is chosen, I think
> > this will continue to happen. I don't think the CLDP can do anything
> > about this - people will continue to cling to their favourites until
> > the two are totally integrated. Or, until GTK wins out, which I can
> > only presume will happen eventually because QT is not completely OSS,
> > and so I think the OS community will eventually dump it.
> I completely agree with you that there will be no "universal toolkit".  Of
> course, we could wrap GTK and Qt.  It would quite the arduous and
> time-consuming task, but it is possible.  After all, IBM wrapped win32,
> Motif, and GTK under the SWT toolkit.
> IMHO, I don't think GTK will win out because of any weaknesses in Qt.  Qt is
> GPL for non-commercial applications for both Win32, Mac OS X, and Linux, and
> works very well on all those platforms.  Since the vast majority of open
> source software is non-commercial, I don't think GTK will win out for that
> reason.
> I think this is a side discussion we needn't concern ourselves with, because,
> like you said, there is no "universal tookit".

Agreed, though I wish there was. The idea of a completely XML-based UI
standard is interesing, but I'm not expecting anything meaningful from
there for about another 400 years.

> > [....]
> > All extremely valid points, except once again we can't really make a
> > universal printing or filesystem access layer. There are no doubt
> > already apps out there trying to achieve this - adding our own would
> > be a duplicate of effort.
> Actually, I looked: I found surprisingly few, and none of them fit my goals
> (please feel free to enlighten me).
> KDE, for example, wraps CUPS, LPRng, etc. in KDEprint
> [http://printing.kde.org/].
> KDE's license policy [http://developer.kde.org/policies/licensepolicy.html]
> states that all libraries must be  under a LGPL compatible license, so we
> could conceivably use their code.
> Actually, on that note, what do you think the CLDP will do about the desktop
> environment?  Will there be a requirement _for_ a desktop environment (e.g.,
> either GNOME or KDE), or no requirement at all?
> Technically speaking, we could easily check at runtime for KDE and use kprint
> to get the list of printers on the system, thereby taking advantage of the
> CUPS, LPRng, etc. wrapping that KDE has already done.
> Politically speaking, the CLDP cannot mandate the existence of the KDE
> libraries.  So should the CLDP libraries check for the KDE libraries, and
> then GNOME libraries, etc., until it finds a valid printing "package"?  And
> then fallback to its own detection mechanisms for CUPS, LPRng, etc.?
> Just food for thought.

For the moment the aims of the CLDP are to make it easy to install
packages across systems, regardless of a) distro or b) filesystem
layout, not how said applications should operate. So, essentially,
we're talking about a way to abstract application development, not
application usage - applications can use whatever method they like to
display themselves (QT, GTK, etc.) or to print something (gnome-cups,
cups, etc.).

But, having thought about it, I have to admit it would be a good idea
to have some common systems for functions like printing or accessing
devices. The problems are, otherwise, that applications will have to
search for whether the system they use is installed (either making it
tedious for developers or meaning we have to make bricklayer more
complex), or will blindly install required components without the
user's consent.

So, I hearby decree that someone can get stuck into writing one of the
following, as long as it's not me, at least for the moment while I try
and get the LDBK right and perhaps publish 1 single line of code =)

Linux Desktop Printing Layer - integrates with CUPS, allows an
application to get a list of installed printers, and the default
printer, and then, uh, print to them. The problem here is - do we make
our own printer detection and support system, or do we just make an
interface to a spooler (in this case cups) so that a program can print
to whatever printer the user has already set up through the
distribution? I strongly favour option 2, since it won't interfere
with the distro specific printing setup, and it also means we won't
have to spend 2 years re-inventing the wheel and developing the mother
of all printing systems

Linux Desktop Volume Layer - integrates with HAL/D-Bus to allow an
application a list of available removable devices, and their status.
As for the 'default' CD or whatever device, I think we should let the
application handle this - after all, few people have more than one CD
drive, and those who do can wait four seconds for an app to scan both
to see which has a disc in it, and/or which has the right disc in it.
Strongly recommend we rip of gnome-volume-manager =P

Niether of the above would have configuration components, or GUI
components whatsoever - like the LDML, they would be pure libraries.
They should be short and simple, and allow access to the minimum of
functionality which would allow an application useful functions, like
listing devices, accessing devices, finding out system info about
devices (eg. hardware info for a CD drive, mount point and device
name, etc.). The LDPL (which we can codename Sally for convenience)
would not allow a user, or an app, to search for printers or match
correct drivers; nor would the LDVL (which we'll call Norwood) ask the
user which was their default CD drive, etc.

I might add these ones to the site soon, you've got me thinking now =)
 Of course, we will need someone to, um, write them - you're more than
welcome =P

> > But we might as well choose and sponsor some worthy projects to be our
> > designated default 'layer' apps for printing etc. - I'll look into
> > this, post suggestions if you have some project in mind.
> Yes, please, if you find something, post back.  One thing I think is extremely
> important is to consider commercial use of everything the CLDP covers.
> Agree?  Disagree?

I agree with the commercial side of things, since this will be a way
ot distribute binary apps only. What sort of thing did you mean,


> Thanks for your time!
> --
> Karl Pietrzak
> kap4020@xxxxxxx

Other related posts: