[cldp] Re: libraries wrapping incompatible interfaces

  • From: Karol Pietrzak <kap4020@xxxxxxx>
  • To: cldp@xxxxxxxxxxxxx
  • Date: Sat, 15 Apr 2006 00:42:49 -0400

On Friday 14 April 2006 23:52, Benjamin Rich wrote:

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

Heh, yes, you're so right. ;)  Although the competition isn't such a bad 
thing: even Windows has multiple, competing GUI toolkits.

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

Right.  I'm glad you followed my train of thought.

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

Well, I can be that software guy.  I actually already have some code in place 
for the concepts you mention, like the Linux Desktop Printing Layer.

> 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

I agree with you, and I like the name too. :)   I'm in favor of interfaces to 
as many spoolers as need be.  This will allow preservation of an API while 
still allowing competing spoolers to exist and change (see Mac OS X example).

This is what KPrint does, and technically it shouldn't be that hard.

> 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

Cool... could you elaborate on gnome-volume-manager or send me to some page?  
I'd like to know more about it before I start writing code.

Along with what you mention, one thing I'd like to enable ISVs to allow easy 
multi-CD installs.  The reason this irks me is because even something like 
Unreal Tournament 2004 is not installable by default on most modern Linux 
distributions because it doesn't recognize supermount-type CD/DVD drive 
installations.

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

I think that's very well said.  This library would be "short and sweet" and 
simply stick to the "minimum of functionality" to enable ISVs to do their 
jobs.

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

Sounds good!  We'll also have to avoid trampling on distribution makers toes: 
SuSE has its own dialogs for configuring CD/DVD drives, but the beauty of a 
library is that we can wrap that.

> 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

Gladly. :)  Like I said, I already have some code.  Here's a few more details 
on this library that I've thought up along the way:
1. I also want this library to gain a large user base in both the commercial 
and non-commercial spheres.  So, I would like the license to be something 
along the lines of the zlib license, which basically allows anything.

I think this library would be staticly linked for convenience, at least in the 
beginning.

2. Great names, IMO!  I think aesthetics  is very important, even for a purely 
developer-oriented library like this.  The names you've given also illustrate 
the different components that this library will consist of.

3. Another component will be the Desktop Integration component, or some such.  
It will install menu items, register MIME types, and use handlers.  Like you 
mentioned, the Portland project will do a lot of the work for us, but only 
for modern distributions.  The Autopackage folks have already done a lot of 
this, but even they have expressed interest in extracting the hard work 
they've done in wrapping distributions into an external library for ISVs to 
use.  It's not perfect, and hopefully we can help them out by having a 
complete library.

This library will hopefully support older distributions that are still in 
heavy use, such as older releases Debian and RedHat Enterprise Linux 
releases.

> 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,
> though?

Well, I wanted to see whether we agree on the issue of binary-only, commercial 
applications.  I think we see eye-to-eye that commercial, binary applications 
should be given first-class status in whatever specifications, documents, and 
software we write.

-- 
Karl Pietrzak
kap4020@xxxxxxx

Other related posts: