Menu
▾
▴
ddccontrol-devel
|
From: Christian S. <csc...@gm...> - 2005-08-23 18:15:28
|
hello, first off, sorry for beeing off the project for so long my spare time was quite limited (a-levels...) i'm currently working on a panel applet for gnome, with allows quick changeing of profiles created with gddccontrol. 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) now i'd suggest to split the project into seperate modules: - libgddcc (or libddcci??) - ddccontrol - gddccontrol - ddcc-applet another benefit of making libddcc a seperate package would be, that fo instance someone could write "kddccontrol", or build the funktionality into applications like video players (automaticly change to "movie" profile, when fullscreen video playback is started)..and so on.. what do you think about this idea? Regards, Christian |
|
From: Nicolas B. <ni...@bo...> - 2005-08-25 13:48:40
|
Hello Christian,
Nice to hear again from you .-)
On Tue, 2005-08-23 at 20:15 +0200, Christian Schilling wrote:
> hello,
>
> first off, sorry for beeing off the project for so long my spare time
> was quite limited (a-levels...)
No problem .-)
> 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?).
> 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??
> 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)
> - ddccontrol
> - gddccontrol
> - ddcc-applet
Maybe should you a a "g" somewhere, because there are also KDE applets I think.
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...).
> another benefit of making libddcc a seperate package would be, that fo
> instance someone could write "kddccontrol",
If someone want to write kddccontrol, it would very probably be
integrated into the project.
> or build the funktionality
> into applications like video players (automaticly change to "movie"
> profile, when fullscreen video playback is started)..and so on..
Yes, that's a good idea.
> what do you think about this idea?
I think you can commit your modifications. Please just add a tag before
doing it ("cvs tag Before_shared_lib" for example).
Thanks for working again on this project.
Best regards,
Nicolas
|
|
From: Roberto C. S. <ro...@fa...> - 2005-08-25 17:35:23
|
On Thu, Aug 25, 2005 at 03:48:26PM +0200, Nicolas Boichat wrote: >=20 > 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...). >=20 I would also like to know about this. I am working on the Debian packaging and should have something ready by this weekend. However, if the project is going to be split into different packages, I think it may be worthwhile to wait. What do you think? -Roberto --=20 Roberto C. Sanchez http://familiasanchez.net/~roberto |
|
From: Nicolas B. <ni...@bo...> - 2005-09-02 09:22:04
|
Hello Roberto, Back at work... (sorry for the delay) On Thu, 2005-08-25 at 13:35 -0400, Roberto C. Sanchez wrote: > On Thu, Aug 25, 2005 at 03:48:26PM +0200, Nicolas Boichat wrote: > > > > 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...). > > > I would also like to know about this. I am working on the Debian > packaging and should have something ready by this weekend. However, if > the project is going to be split into different packages, I think it may > be worthwhile to wait. What do you think? The project will not be splitted in the CVS. But from the packaging point of view, you may want to split the project in different parts, for example: - ddccontrol-base: basic command line ddccontrol tool, and libddccontrol.so - ddccontrol-devel: header files to build apps against libddccontrol.so (for the moment it is not needed as no other app use the library) - ddccontrol-gnome: gddccontrol and gnome-ddcc-applet You may want to create even more packages (Christian presented an alternative), or just create one for the moment. Best regards, Nicolas |
|
From: Roberto C. S. <ro...@fa...> - 2005-09-02 13:34:38
|
On Fri, Sep 02, 2005 at 11:21:53AM +0200, Nicolas Boichat wrote: > Hello Roberto, >=20 > The project will not be splitted in the CVS. >=20 > But from the packaging point of view, you may want to split the project > in different parts, for example: > - ddccontrol-base: basic command line ddccontrol tool, and=20 > libddccontrol.so > - ddccontrol-devel: header files to build apps against libddccontrol.so > (for the moment it is not needed as no other app use the library) > - ddccontrol-gnome: gddccontrol and gnome-ddcc-applet >=20 > You may want to create even more packages (Christian presented an > alternative), or just create one for the moment. >=20 OK. Thanks for the clarification. I have become very busy with my final projects and final exams. I jave part of the packaging work completed already. When I finish exams in the middle of next week, I will return finishing up the packaging and check the files in on teh branch I created in CVS. -Roberto --=20 Roberto C. Sanchez http://familiasanchez.net/~roberto |
|
From: Christian S. <csc...@gm...> - 2005-08-26 10:20:46
|
> > 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?
>
> > 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.
--
Christian Schilling <csc...@gm...>
|
|
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
|
|
From: Christian S. <csc...@gm...> - 2005-09-02 12:46:10
|
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...>
|
|
From: Christian S. <csc...@gm...> - 2005-09-02 12:46:28
|
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... > is it requrired that the whole library is locked, or must just be ensured, that only one library function is executed at a time? i've experienced no problems so far running both apps the same time, exept the information they are showing getting out of sync. what kind of problems do you expect? maybe just adding protection to some critical functions is enough. -- Christian Schilling <csc...@gm...> |
|
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...>
|
|
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
|
|
From: Christian S. <csc...@gm...> - 2005-09-02 12:40:28
|
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... > is it requrired that the whole library is locked, or must just be ensured, that only one library function is executed at a time? i've experienced no problems so far running both apps the same time, exept the information they are showing getting out of sync. what kind of problems do you expect? maybe just adding protection to some critical functions is enough. -- Christian Schilling <csc...@gm...> |
|
From: Nicolas B. <ni...@bo...> - 2005-09-05 13:51:30
|
Hello Christian, On Fri, 2005-09-02 at 14:40 +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... > > > > is it requrired that the whole library is locked, or must just be > ensured, that only one library function is executed at a time? > > i've experienced no problems so far running both apps the same time, > exept the information they are showing getting out of sync. > > what kind of problems do you expect? maybe just adding protection to > some critical functions is enough. Yes, you're right, locking some functions should be enough... I'll also find a way to automatically refresh controls/profile list. Best regards, Nicolas |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X