From kde-core-devel  Sun Aug 28 19:57:11 2005
From: Simon Hausmann <hausmann () kde ! org>
Date: Sun, 28 Aug 2005 19:57:11 +0000
To: kde-core-devel
Subject: Re: Redefining kdelibs and kdebase
Message-Id: <200508282157.12015.hausmann () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=112525903614351

On Sunday 28 August 2005 10:43, Joseph Wenninger wrote:
> I'm not that sure that restricting apps to use a standard dialog is the way
> to go, which would be the result if you have an out of process generic file
> or print dialog. There are cases where you need to have more control over
> the widgets even in a standard dialog. Eg. it would be very bad if kate 
> runs in in GNOME and you can't choose the encoding of the file to open or
> load. In other applications (ok, it kate too) there is also a need for
> additional settings in the print dialog, it would be very hard to support
> that with a gnome or windows print dialog. Even a lot of native windows
> applications (think about graphic applications) don't use the default
> windows printing dialog but there own specialised one.
>
> The point is, why do we have to limit KDE with generic support for other
> deskops ? Who is maintaining the wrappers around gtk, windows, cocoa ? Do
> we have to do that ourselves ?
>
> Another thing to consider, face  it our main platform is X11 and/or
> embedded. That's about 80% or even more. I don't think we should limit KDE
> to comfort 20% even less. We should try to be consistent within our DESKTOP
> ENVIRONMENT, not consistent with every broken GUI toolkit. I don't say we
> should make it extremly hard for others who really want to use native
> windows or macos ports, but I do think, we should not restrict ourselves
> because of such ports.
> Even if we would use windows dialogs or gtk dialogs or ....., we still
> would not fit in because of the different HIGs.
>
> KDE is a Desktop Environment, not a simple Qt extension. If Trolltech
> really wants to use KDE dialogs they could write their own layer and use
> the static methods we already have for their purposes. The only really
> hindering thing is KApplication, which should be solvable by moving most
> things out of their into a singleton.

Except that Qt would then link against kdelibs, which depends on Qt, which 
depends on kdelibs, which dep...

Qt could try to dlopen kde libraries with a minimum of symbol resolval, 
ideally using a C interface, to avoid crashes due to different C++ ABIs or 
different libstdc++ versions. And when you end up at a C interface where you 
can't even pass through widgets then the question is: What is it worth? At 
that level a remote invocation offers a whole lot more safety. Safety that 
you definitely want if you consider that a file dialog essentially is a 
complete file manager, dragging in a lot of dependencies, connecting to a lot 
of services. All that just for a QString path = FileDialog::getFileOpen(); ?

> If we restrict ourselves to a bare minimum of features, we would remove all
> our distinguishing features. So what's the reason to install KDE at all
> (for a user or distribution) ?

How is a extra custom widget in a file dialog a distinguishing feature?
In fact it's the other way around: By defining interfaces for file/print 
dialogs for example using dbus you get /more/ applications, applications 
beyond KDE using /our/ wonderful file dialog, our kdeprint system.

This is not about restricting our apps, it's about opening up our platform to 
embrace more applications.

Simon