|
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
|