From kde-core-devel  Mon May 28 19:52:33 2007
From: Kevin Ottens <ervin () kde ! org>
Date: Mon, 28 May 2007 19:52:33 +0000
To: kde-core-devel
Subject: Re: Forthcoming changes for libsolid
Message-Id: <200705282152.38674.ervin () kde ! org>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=118038470915888
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart1481297.mKs7SCn6O8"

--nextPart1481297.mKs7SCn6O8
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Le dimanche 27 mai 2007, Aaron J. Seigo a =E9crit :
> On Saturday 26 May 2007, Kevin Ottens wrote:
> > 2) (kdelibs|kdebase)_no_Solid_DeviceList.path (monday 28th may)
> > Get ride of the useless DeviceList typedef. It's really unnecessary IMO,
> > I
>
> this should probably be consistent throughout kde's libs... if this goes
> in, i'll probably end up changing libplasma to do similarly.

Yup, should be consistent. Actually I even wonder if Qt has such typedefs..=
=2E=20
AFAIK it doesn't.

> the nice thing about having typedefs such as this is that if the collecti=
on
> class type ever changes, which is pretty much a "can't happen" in a public
> lib, it makes it so much easier to port code =3D)

Indeed, that'd be the best argument for keeping this typedef. KDE5 anyone? =
:-)
That said, if we suppose that for KDE5 we switch from QList<Solid::Device> =
to=20
another type for devices list, a simple sed command we'll do for the port.=
=20
That's not the most critical one. So I'd still be in favor of applying my=20
patch.

> > My current plan is to move the eject() method to the OpticalDrive
> > interface, where it actually makes sense (for instance this interface
>
> of course there are many devices which also do eject that aren't optical:
> tape drives, some floppies (legacy hardware, admitedly) and other magnetic
> media most of which is also legacy (jazz/zip for instance)

Yup, since they're mostly legacy and not used often these days I think that=
=20
duplicating the eject feature in this case is ok.

> > 4) I'd need to rework a bit a few classes, mainly AudioHw, Camera and
> > PortableMediaPlayer (monday 4th june). They need to be consistent in the
>
> as an aside, there have been a few requests made at conferences i've spok=
en
> at this year for both still and video camera detection. solid seems to ha=
ve
> a nice interface for the former (which often can also do video too, as you
> note in the API docu) but i'm not sure how detection of webcams, DV
> sources, etc are handled?

=46or now they're basically ignored. As for webcams, Will told me there was=
 an=20
upcoming effort driven from Kopete. So it might happen in the future.

Regards.
=2D-=20
K=E9vin 'ervin' Ottens, http://ervin.ipsquad.net
"Ni le ma=EEtre sans disciple, Ni le disciple sans ma=EEtre,
Ne font reculer l'ignorance."

--nextPart1481297.mKs7SCn6O8
Content-Type: application/pgp-signature

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

iD8DBQBGWzMGB0u7y43syeIRAmxxAJ4wA9p6N05mF+uNd4wlrWzCvVhQeACcDa7Z
E14p9JhEZYII9uidGxzbW3A=
=epYy
-----END PGP SIGNATURE-----

--nextPart1481297.mKs7SCn6O8--