From: Nicolas B. <ni...@bo...> - 2005-09-02 09:37:55
|
Hello Christian, On Fri, 2005-08-26 at 12:20 +0200, Christian Schilling wrote: > > > i'm currently working on a panel applet for gnome, with allows quick > > > changeing of profiles created with gddccontrol. > > > > Nice idea .-) One thing you should take care of is multi-screen (which > > monitor are you controlling?). > yes i am aware of this, the applet is now working with one monitor only > (first one thats found), but i intend to make an config dialog to chose > the monitor. > > > > > while doing this i noticed libddcci is build as a static library. > > > as i needed it's functionality in my applet i changed the makefiles (and > > > headers) to build a shared library and install it in $PREFIX/lib > > > (headers in $prefix/include/ddcci) > > > > There is no problem about it. My only concern is about two applications > > accessing the monitors at the same time. It could create huge problems > > (particularly with ddcpci)... I think we need a mechanism to lock and > > unlock the libraries, but I've no experience on it. Any idea?? > not only the library must be locked, but other applications also need to > get informed of changes. > or do you mean not allowing to run two applications at the same time? An easy way of doing this thing, which doesn't requires the apps to be "informed", would be: - When ddccontrol or gddccontrol run, it locks the library, so no other app can access DDC/CI. (so you can't change profile in ddcc-applet) - When ddcc-applet, it doesn't lock the library, unless when it is changing of profile. But again, I don't know how to do this... I'll try to find informations... > > > now i'd suggest to split the project into seperate modules: > > > - libgddcc (or libddcci??) > > What do you think of libddccontrol ? (the so file would be > > libddccontrol.so, and be linked with -lddccontrol) > > yes this name has the atvantage of being a little more self explaining > > > > - ddccontrol > > > - gddccontrol > > > - ddcc-applet > > Maybe should you a a "g" somewhere, because there are also KDE applets I think. > > maybe gnome-ddcc-applet > > > > > Now, about the idea of splitting the project in modules, I'm not sure of > > what you mean... Do you suggest to split the project in different > > tarballs?? If so, I disagree. I think two tarballs (ddccontrol and > > ddcontrol-db) are already enough to download, and as their size is > > relatively limited I don't see any problem (if you only want some parts > > of ddccontrol, you can enable them with configure flags). > > Of course, if a packager want to split the project, there is no problem > > (you often see this with RPMs: ddccontrol-lib, ddccontrol, > > ddccontrol-devel...). > > yes, i meant different tarballs, but mainly because i think it should be > packaged this way in debs and rpms. > > > > I think you can commit your modifications. Please just add a tag before > > doing it ("cvs tag Before_shared_lib" for example). > > ok, ill do this. > i think if the headers are "pubilc" and maybe used in different > applications, not only functions but also types should be prefixed > ("DdcciProfile" instead of "struct profile") to avoid naming conflicts > with other headers/libs. ddcci_profile is better (more GNU-styled .-)). I'll work on this. Concerning ddcc-applet, I first had some problems to build it (libtool was missing, you added it, then the wrong version was installed), but now it builds and gets installed... Could you just explain me how to add it in gnome panels?? Best regards, Nicolas |