|
From: Christian S. <csc...@gm...> - 2005-09-02 11:08:52
|
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")
--
Christian Schilling <csc...@gm...>
|