Redefining kdelibs and kdebase

Christoph Cullmann cullmann at babylon2k.de
Mon Aug 29 12:55:16 BST 2005


On Monday 29 August 2005 10:19, Lubos Lunak wrote:
> > Same possible with my design ;) A wrapper around kdelibs stuff we want to
> > export for the ISV's and others, which needs just to cover this small
> > parts and could be bound to kdelibs stuff via dbus to avoid linking.
>
>  So we're going to expect everybody to make their apps also to use our way,
> but we ourselves won't be willing to do the same in the other direction?
The aim is to get people (ISV's) using our platform, not to integrate our 
stuff into windows/mac/gtk+, or? 

If we want that kde stuff runs on windows/mac, we need to port the at least 
kdelibs stuff, as whole, hidding the kfiledialogs won't help, as without 
ioslaves and more most kde apps won't work nodaways. 

We want to get ISV's using our stuff without having them to really link 
against the whole set of our libs, at this is infeasable for many of them. 
For this, it would be enough to provide such out-of-process dialogs to them, 
not enforce our own apps to use that, how would alone the authentification 
managment/remote access work at all if for example KWrite would use a gtk+ 
filedialog just because we happen to run on GNOME? This dialogs won't know 
kio, nor would use the same way to store the auth stuff, how should that work 
in any senseful fashion, KWrite would be crippled down just because I wanted 
to use GNOME as DE, atm, it works perfect in GNOME, as it is able to use our 
filedialog, it can rely that I only have to auth once for example for fish:// 
access and it can rely that the file dialog actually can handle fish://.... 
urls.

(

to pin it down to an example, use case, if we would just default to filedialog 
of the DE running:

Start KDE
Use KWrite with some fish:// urls, or some smb:// ... whatever stuff
Exit KDE
Start GNOME
Use KWrite, use recent files -> doomed :(

I don't think this will help us if we even can't be sure that all KURL's kio 
can handle can be handled by our own filedialogs, even if out of process, it 
should be always our dialog, no gtk+ or windows one

)


Perhaps I misunderstood this, but that's what I got out of the mails.

cu
Christoph




More information about the kde-core-devel mailing list