Forthcoming changes for libsolid

[Aaron J. Seigo]

On Monday 28 May 2007, Kevin Ottens wrote:
> Le dimanche 27 mai 2007, Aaron J. Seigo a écrit :
> > 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... AFAIK it doesn't.

it doesn't; and yes, my only "insight" was that we should make this an 
informal policy and bring everything into line... ok, i'll go through 
libplasma later and do this..

> > the nice thing about having typedefs such as this is that if the
> > collection 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 =)
>
> 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 another type for devices list, a simple sed command
> we'll do for the port. That's not the most critical one. So I'd still be in
> favor of applying my patch.

agreed.

> > > 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
> duplicating the eject feature in this case is ok.

fair enough...

> > as an aside, there have been a few requests made at conferences i've
> > spoken at this year for both still and video camera detection. solid
> > seems to have 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?
>
> For now they're basically ignored. As for webcams, Will told me there was
> an upcoming effort driven from Kopete. So it might happen in the future.

this should cover video sources in general, not webcams only of course. what 
i'd be looking for personally is the addition of Video or DigitalVideo or 
some such to Solid::DeviceInterface::Type. even if no video cameras are 
currently even seen by Solid, it would at least point to where this support 
will be coming in.

i see that HAL currently doesn't know anything special about video cameras, at 
least according to the spec[1] which is unfortunate.

is the policy in Solid to only expose what HAL can provide?

would it make any sense to have a Solid::Video object before a backend 
provides it?

[1] http://people.freedesktop.org/~david/hal-spec/hal-spec.html

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070528/2e9c7bb0/attachment.sig>