From kde-core-devel  Mon Jun 02 18:09:26 2003
From: Gav Wood <gav () kde ! org>
Date: Mon, 02 Jun 2003 18:09:26 +0000
To: kde-core-devel
Subject: Re: new kde project
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=105457739616179
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--Boundary-02=_aL52+EaPzw99eRR"


--Boundary-02=_aL52+EaPzw99eRR
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Monday 02 June 2003 17:49, Scott Wheeler wrote:
> Would it make sense to merge this into KHotkeys?
> There you have DCOP binding configuration thingies and whatnot.

the dcop ui, and general infrastructure is more developed in kdelirc.

i have developed infrastructure such as application profiles to hide all of=
=20
dcop from the user, and remote control profiles to hide lirc from the user.=
=20
even if they want to use dcop, the argument entry and dcop browsing ui is=20
substantially more advanced.

with this infrastructure, kdelirc is meant to be stable and of good ui for=
=20
novice users pretty much now. looking at its dcop dialog khotkeys is=20
apparently quite "power-user orientated" :-).

> IR control would seem to fit into the same family as hotkeys and mouse
> gestures...=20

dcop and lirc are so powerful in themselves that (currently) any code the t=
wo=20
projects could share would be fairly minimal.

infrastructure code that kdelirc relies upon (e.g. per-remote-control state=
=20
switching), would currently be very hard (read: not worth doing) to fit int=
o=20
khotkey's design, since by design it doesn't appear to have any concept of=
=20
input devices let alone being able to distinguish between input devices or=
=20
even states of input devices.

at this current point in time, it would be a tremendous downgrade to port a=
ll=20
the rc and ui features of kdelirc to khotkeys, and i have neither the time=
=20
nor inclination to do it. it's entirely possible that for some features=20
(parts of) khotkeys would need to completely redesigned.

in the future, should khotkeys become a general plugin-based input device=20
=2D>output action proxy program a remote-control addition may be useful.=20
however i doubt very much that kdelirc would be useful in making such a=20
module --- much of kdelirc's code is infrastructure joining the superb lirc=
=20
interface to the superb dcop interface in the superb kde environment, and=20
likely as not is mutually exclusive with that of khotkeys.

perhaps kdelirc has some potential of being a general plugin-based=20
input-device->output action proxy program; i might even be tempted to add=20
such functionality in due course.... ;-)

gav
=2D-=20
Gav Wood <gav@kde.org>

codito ergo non satis bibivi

--Boundary-02=_aL52+EaPzw99eRR
Content-Type: application/pgp-signature
Content-Description: signature

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

iD8DBQA+25La7nE5x1pIEBQRAmWWAKCEgJpu+ZonUziOp4PSjge4xY0K3wCgo1AA
DuqUzTuvt+apAOUmn/JReSk=
=cy6C
-----END PGP SIGNATURE-----

--Boundary-02=_aL52+EaPzw99eRR--