Re: [GnomeMeeting-devel-list] PVideoInputManager API

[PUYDT Julien <julien puydt laposte net>]

Le ven 01/08/2003 à 12:37, Damien Sandras a écrit :
> Le jeu 31/07/2003 à 12:12, PUYDT Julien a écrit :
> > 
> > Is there some function the manager should provide? Should the
> > GetOpenedDevice function accept more arguments?
> 
> I think having a mapping between the driver name and the device is a
> good idea. That was next on my todo list. That way, GM could display
> "Philips PVC Webcam" instead of "/dev/video0". The ideal would be that
> wen GM tries to open "Philips PVC Webcam", the plugin is able to open
> /dev/video0. That way, if your devices are loaded in a random order, and
> that you select "Philips PVC Webcam" as default device, it is always
> your Philips Webcam that will be used.
> 
> Just a thought, it is great work anyway!! Thanks!

That is not impossible. It is hard, but not impossible; some thoughts on
that:
* I would think GM should rather report "V4L Philips PVC Webcam"; that
way, if you write a better driver, it may show up as "V4L2 Philips PVC
Webcam", and you can choose one or the other, to check for regression;
* the manager would still give the driver to GM as a PVideoInputDevice,
ie: no need to change GM more than it has been now;
* but the driver would really be some PVideoInputBetterDevice inheriting
from PVideoInputDevice, able to give more information to the manager,
like the real name of the devices, for example: would not return a list
for device filenames, but a list of pairs with device filename and name;
the manager would keep that list;
* the manager would take that list, and make a custom PStringList for
GM;
* once GM tells it to open "V4L2 PiCam", the manager would look in
V4L2's list, ask the driver to open /dev/video3.14, and if successful,
return the driver to GM;

Yep, that is all possible, but that makes the manager more complex and
adds yet another PVideoInputDevice childclass: if you want equivalence
to accept that, you'll certainly need to have a very nice API.

The reason why I haven't contacted equivalence yet (besides needing more
successful test reports), is that I would like the PVideoInputManager
API to be really good, to avoid a situation where we would have to patch
it.

Snark

PS1: What I just described would work with the current API for the
manager, and not need more change to GM, for example, but would need to
patch the dlopen implementation I wrote+the drivers I ripped off quite
heavily.

PS2: manager implementation change ==> plugin implementation changes, so
that would be nice to think thoroughly about it _now_! Once/If other
projects begin to make use of that manager, then it will become harder
to modify it.