Skip navigation.
KDE Developer's Journals
Home » blogs » daniel molkentin's blog

Basic Desktop API

daniel molkentin's picture
Submitted by daniel molkentin on Thu, 05/19/2005 - 08:32.

Kurt has an interesting point on a common api for basic desktop usage, hidden under some stuff I basically agree with but don't think it's easy to solve: A minimal desktop API for applications that do not use DE libs directly. In fact, Matthias, Scott and me discussed a solution to a similar problem back in Nove Hrady. We were wondering how to enable the use of KDE widgets in Qt applications.

For that we came up with a very thin C API (which is probably still in Scotts drawer) which can be reimplemented by several providers. Handling e.g. file dialogs is trivial, and even printing is sort of easy: the preprocessed printing (read: postscript) data would be pushed into a unix socket provided by the API. Of course it gets trickier when looking at details, but that's a second iteration Smiling

That would give us native dialogs for the most common dialogs:

  • Generic Yes/No/Cancel Dialogs
  • Save (as)...
  • Open...
  • Print...

Of course more are possible. On the technical side, it's an interesting question on wether those providers should be DCOP/DBUS services with the API being an interface definition or if we should go for a plain C interface, which could be wrapped by other languages. The advantage of the latter is flexibility, the problem with the former is that every application would need do use whatever IPC we use. I don't think we should enforce the use of IPC, but I am open for a discussion here.

» daniel molkentin's blog | login or register to post comments | 397 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
beineri's picture

Re: file dialogs is trivial

Submitted by beineri on Thu, 05/19/2005 - 09:14.

It's not as trivial as on first look: This will only work with the pure standard file dialog as long as an application has not the desire to add its own widgets and (remote) KIO slaves don't start to work by magic too (one could implement some "copy to and open temporary local file" hack like latest OOo/KDE builds).

In SUSE 9.3 Novell (afaik Seli) has patched Qt so that pure Qt application will use the KDE file, font and color dialogs and message boxes but it only works if they use the static methods and don't subclass. So it can happen that for some actions Qt applications use the Qt file dialog and for others the KDE file dialog introducing a new kind of inconsistency. :-|

» login or register to post comments
krake's picture

covers most cases

Submitted by krake on Thu, 05/19/2005 - 09:53.

I think the static methods, especially QFileDialog's cover most use cases.

Very seldom do Qt applications use QFileDialog as instances, especially as this would create a totally different file dialog on Windows and OS X, where the static methods invoke the platform's file chooser.

The interesting thing about QFileDialog is that it is capable of handling URLs almost like KFileDialog.

I have a experimental project for a plugin based enhancment system for Qt applications and with that QFileDialog can use KIO slaves without any difficulties.

The limitation are the applications themselves.

» login or register to post comments
lubos lunak's picture

Re: covers most case

Submitted by lubos lunak on Thu, 05/19/2005 - 11:45.

> I think the static methods, especially QFileDialog’s cover most use cases.

Sorry, wrong, unfortunately. Even Qt Designer doesn't use the static methods in one case (in the dialog shown right after startup the file dialog is embedded).

» login or register to post comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.