From kde-core-devel  Sun Aug 28 20:31:31 2005
From: Kevin Krammer <kevin.krammer () gmx ! at>
Date: Sun, 28 Aug 2005 20:31:31 +0000
To: kde-core-devel
Subject: Re: Redefining kdelibs and kdebase
Message-Id: <200508282231.36640.kevin.krammer () gmx ! at>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=112526113223894
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart1197985.7JhTCem8YW"

--nextPart1197985.7JhTCem8YW
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Sunday 28 August 2005 21:32, Simon Hausmann wrote:

[snip]

> The customizations I see are mostly simple GUI elements. Check boxes,
> comboboxes, some labels with no interaction between them. We could use a
> simple piece of XML to describe options like these, send them to the other
> process and in the reply get the chosen options.

Sounds doable, but I am not sure how responsive this would be.
Like when doing something like this:
=2D user selects file
=2D information about newly selected file gets transmitted to application
=2D application updates XML description of additional elements
=2D XML description transmitted to dialog
=2D dialog parses XML and updates extra widgets

> It's not as flexible as the current solution where you get access to the
> widget, but on the other hand think of the advantages from a user's
> perspective:
>
> (this is beyond your specific concern, but I'll take the opportunity to u=
se
> this reply to stress the advantage of the approach in general)
>
> *) Imagine kmail on windows, let the user attach a file. You really do wa=
nt
> to see the windows file dialog there. Same for printing.

Well, I see the adantage of KDE as a desktop provider :)
KDE applications on Windows would then be restricted to the possibilities o=
f=20
the Windows file dialog and could offer features like remote file access on=
ly=20
on KDE, thus giving KDE an advantage in competing with other desktop=20
providers.

> *) Mozilla/Firefox, OpenOffice.org, Gtk applications could just fire off
> their request on d-bus and the user would see the nice KDE file dialog wh=
en
> running inside KDE

Would be nice indeed.

> I admit we do loose a little bit of flexibility, but in my opinion we wou=
ld
> gain a lot, without changing the common case where applications just use
> the static functions to get a file path or to fire up a print dialog.

I am a bit afraid we move into a situation wrapper toolkits like wxWidgets =
or=20
SWT are in, i.e. only be able to guarantee least denominator functionality

Cheers,
Kevin

=2D-=20
Kevin Krammer <kevin.krammer@gmx.at>
Qt/KDE Developer, Debian User
Moderator: www.mrunix.de (German), www.qtforum.org

--nextPart1197985.7JhTCem8YW
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQBDEh8onKMhG6pzZJIRAtBeAJ9v2VJ8QAYbhS6gg+zelyI3IdXxzgCeM5MF
OKX1m6pP0ZoxaZweaYhNXHg=
=f9J3
-----END PGP SIGNATURE-----

--nextPart1197985.7JhTCem8YW--