From: Nicolas B. <ni...@bo...> - 2005-09-05 13:26:04
|
Hello Christian, On Fri, 2005-09-02 at 13:08 +0200, Christian Schilling wrote: > Am Freitag, den 02.09.2005, 11:37 +0200 schrieb Nicolas Boichat: > > 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?? > > It should be listed in Gnome's "add to panel" dialog after installation. > Hower if it's not it properbly means the *.server file got in the wrong > location. > On Debian all *.server files are placed in /usr/lib/bonobo/servers. > in the makefile i secified to install it in $(libdir)/bonobo/server (i > configure with --prefix="/usr") Ok, my prefix was /usr/local... I copied the server file to right location and it works. Thanks. Best regards, Nicolas |