Re: [Ring] ring client
Well, I have figured this out. I should have had a clue as to what was going on when I'd read through the dependencies and made sure they were all met before I ever installed this, but I am thick enough that I had to do a "grep -R dring" from gnome-ring source to find references to how it would start the dring daemon if it was indeed capable of doing so. The problem had to do with dbus. The dbus rules generated at compile time tell the client the path for the executable of the daemon. When installing to a non-standard location, it also installs the dbus rules to that nonstandard location, and those dbus rules never got read. I have now sorted that out and dring works exactly how you described it works for you, which yes, solves the issue. Thank you very much, Baptiste. Your telling me how this *should* work pointed me in the direction to find out why it was not working. From: Baptiste Jonglez To: Chris Curtis Cc: ring@lists.savoirfairelinux.net Sent: Friday, November 27, 2015 1:33 PM Subject: Re: [Ring] ring client Hi again, On Fri, Nov 27, 2015 at 01:17:26PM +, Chris Curtis wrote: > I am not sure what could be different from the client I am using to the one > you are using, as we are both apparently using the gnome client. When I > start the client without having started the daemon first I get a window that > pops up with the message: > > Ring Error > Unable to initializeMake sure the Ring daemon (dring) is running.Error: > If we are both building following the instructions on the website, the > only variable that I would imagine to be different is that I have not > installed ring to the /usr prefix. As I am trying out and testing the > software from source, to more easily track, remove, and rebuild I have > installed ring, libring, and the gnome ring client to its own folder in > /opt/ring. Ah, that's the reason of the difference. I am using the AUR packages: https://aur.archlinux.org/packages/ring-daemon-git/ https://aur.archlinux.org/packages/libringclient-git/ https://aur.archlinux.org/packages/ring-gnome-client-git/ It installs everything in /usr, like any well-behaved package. > So, if it is automatically starting the ring daemon for others, and not > me, is this because it is hardcoded to run "/usr/bin/dring" if it is not > already running rather than simply running "dring" which would pick it > up as long as the dring file is in the user's path? I dunno, just taking > a stab in the dark. Might be. I don't know how the gnome client launches the daemon, but it does not seem hard-coded to /usr/bin (according to a simple grep). > The only reason I would get a second daemon is because of running a self-made > script that launches both, since the client does not launch the daemon, but > rather gives me an error message. I maintain that clicking options and then > quit, rather than clicking the x button, does indeed close the daemon as well > as the client. I am not a programmer, but I find it surprising that this > behaviour could happen for one person and not another. Perhaps I am just > unlucky. > From: Baptiste Jonglez > To: ring@lists.savoirfairelinux.net > Sent: Friday, November 27, 2015 12:26 PM > Subject: Re: [Ring] ring client > > Hi, > > On Fri, Nov 27, 2015 at 12:16:59PM +, Chris Curtis wrote: > > I am on Arch Linux using Gnome 3, so I am using the Gnome-based Ring > > client. The following appears to be true with regard to how the client and > > daemon interact when starting them up and shutting them down: > > 1 - The client does not start the daemon, the daemon must be started > > first. > > This is strange. I am also using the gnome client on Archlinux (version > 20151109-1), and it starts the daemon automatically if needed. > > Additionally, quitting the Gnome client does not kill the daemon, and > launching the Gnome client again just picks up the existing daemon, it > does not start a new one. > > > > > 2 - Closing the client, if you close it by clicking "options --> quit", > > closes not just the client, but will also shut down the daemon as well.3 - > > If I click the "x" in the window title bar of the client it does not close > > the daemon. It also does not appear to properly close the client because, > > while the window does dissapear, I am not returned to the prompt in the > > terminal where I launched it from. > > So my issue is that I cannot find a decent way to start and shut down the > > software. If I use a script that launches the daemon first, and then the > > client, that works so long as I always remember to click options --> quit. > > But I have a really hard time remember
Re: [Ring] ring client
Hi again, On Fri, Nov 27, 2015 at 01:17:26PM +, Chris Curtis wrote: > I am not sure what could be different from the client I am using to the one > you are using, as we are both apparently using the gnome client. When I > start the client without having started the daemon first I get a window that > pops up with the message: > > Ring Error > Unable to initializeMake sure the Ring daemon (dring) is running.Error: > If we are both building following the instructions on the website, the > only variable that I would imagine to be different is that I have not > installed ring to the /usr prefix. As I am trying out and testing the > software from source, to more easily track, remove, and rebuild I have > installed ring, libring, and the gnome ring client to its own folder in > /opt/ring. Ah, that's the reason of the difference. I am using the AUR packages: https://aur.archlinux.org/packages/ring-daemon-git/ https://aur.archlinux.org/packages/libringclient-git/ https://aur.archlinux.org/packages/ring-gnome-client-git/ It installs everything in /usr, like any well-behaved package. > So, if it is automatically starting the ring daemon for others, and not > me, is this because it is hardcoded to run "/usr/bin/dring" if it is not > already running rather than simply running "dring" which would pick it > up as long as the dring file is in the user's path? I dunno, just taking > a stab in the dark. Might be. I don't know how the gnome client launches the daemon, but it does not seem hard-coded to /usr/bin (according to a simple grep). > The only reason I would get a second daemon is because of running a self-made > script that launches both, since the client does not launch the daemon, but > rather gives me an error message. I maintain that clicking options and then > quit, rather than clicking the x button, does indeed close the daemon as well > as the client. I am not a programmer, but I find it surprising that this > behaviour could happen for one person and not another. Perhaps I am just > unlucky. > From: Baptiste Jonglez > To: ring@lists.savoirfairelinux.net > Sent: Friday, November 27, 2015 12:26 PM > Subject: Re: [Ring] ring client > > Hi, > > On Fri, Nov 27, 2015 at 12:16:59PM +, Chris Curtis wrote: > > I am on Arch Linux using Gnome 3, so I am using the Gnome-based Ring > > client. The following appears to be true with regard to how the client and > > daemon interact when starting them up and shutting them down: > > 1 - The client does not start the daemon, the daemon must be started > > first. > > This is strange. I am also using the gnome client on Archlinux (version > 20151109-1), and it starts the daemon automatically if needed. > > Additionally, quitting the Gnome client does not kill the daemon, and > launching the Gnome client again just picks up the existing daemon, it > does not start a new one. > > > > > 2 - Closing the client, if you close it by clicking "options --> quit", > > closes not just the client, but will also shut down the daemon as well.3 - > > If I click the "x" in the window title bar of the client it does not close > > the daemon. It also does not appear to properly close the client because, > > while the window does dissapear, I am not returned to the prompt in the > > terminal where I launched it from. > > So my issue is that I cannot find a decent way to start and shut down the > > software. If I use a script that launches the daemon first, and then the > > client, that works so long as I always remember to click options --> quit. > > But I have a really hard time remembering to do that and often hit "x" > > instead. If hitting "x" minimizes the client somewhere, I cannot find > > it--it is not in the notification area or elsewhere. I then have the > > problem that if I run the same script to start it up I will regain the > > client but have two instances of dring running because the "x" does not > > close down the daemon. Having to use two different ways to start the client > > based on whether or not I've already launched the daemon seems a bit > > unnecessarily complicated. > > If I add the daemon to my startup applications for my desktop, then I don't > > need to make provisions for it to be started with the client. But, then, if > > I happen to close the client with options --> quit, the next time I launch > > the client it will not work because the client had closed the daemon the > > last time I used it. > > To have a manageable way to start and stop the client, I think one of three &
Re: [Ring] ring client
Hi, On Fri, Nov 27, 2015 at 12:16:59PM +, Chris Curtis wrote: > I am on Arch Linux using Gnome 3, so I am using the Gnome-based Ring client. > The following appears to be true with regard to how the client and daemon > interact when starting them up and shutting them down: > 1 - The client does not start the daemon, the daemon must be started > first. This is strange. I am also using the gnome client on Archlinux (version 20151109-1), and it starts the daemon automatically if needed. Additionally, quitting the Gnome client does not kill the daemon, and launching the Gnome client again just picks up the existing daemon, it does not start a new one. > 2 - Closing the client, if you close it by clicking "options --> quit", > closes not just the client, but will also shut down the daemon as well.3 - If > I click the "x" in the window title bar of the client it does not close the > daemon. It also does not appear to properly close the client because, while > the window does dissapear, I am not returned to the prompt in the terminal > where I launched it from. > So my issue is that I cannot find a decent way to start and shut down the > software. If I use a script that launches the daemon first, and then the > client, that works so long as I always remember to click options --> quit. > But I have a really hard time remembering to do that and often hit "x" > instead. If hitting "x" minimizes the client somewhere, I cannot find it--it > is not in the notification area or elsewhere. I then have the problem that if > I run the same script to start it up I will regain the client but have two > instances of dring running because the "x" does not close down the daemon. > Having to use two different ways to start the client based on whether or not > I've already launched the daemon seems a bit unnecessarily complicated. > If I add the daemon to my startup applications for my desktop, then I don't > need to make provisions for it to be started with the client. But, then, if I > happen to close the client with options --> quit, the next time I launch the > client it will not work because the client had closed the daemon the last > time I used it. > To have a manageable way to start and stop the client, I think one of three > things needs to happen, and I don't really care which. A)The client needs to > close the daemon when clicking "x" in the window title bar just like it does > when going through the options --> quit menu.or B)The client needs to not > close the daemon when clicking "options --> quit" just like it doesn't close > it when clicking "x". > Or, C)clicking the "x" button should remove the application's desktop window > and send the application into the notification area/system tray or whatever > people are trying to call it these days. I suspect that this is the intended > behaviour, but if it is supposed to do that it is not working while other > applications--transmission, google hangouts, etc--do this just fine. In this > scenerio I can always make the daemon start with the client because the > client will never be truly closed without also closing the daemon. > Chris > ___ > Ring mailing list > Ring@lists.savoirfairelinux.net > https://lists.savoirfairelinux.net/mailman/listinfo/ring pgp1HWH6r3Bud.pgp Description: PGP signature ___ Ring mailing list Ring@lists.savoirfairelinux.net https://lists.savoirfairelinux.net/mailman/listinfo/ring
[Ring] ring client
A few days ago I tried Ring and ran into a couple issues. One looks like it is already being sorted out. Here is the other. I am on Arch Linux using Gnome 3, so I am using the Gnome-based Ring client. The following appears to be true with regard to how the client and daemon interact when starting them up and shutting them down: 1 - The client does not start the daemon, the daemon must be started first.2 - Closing the client, if you close it by clicking "options --> quit", closes not just the client, but will also shut down the daemon as well.3 - If I click the "x" in the window title bar of the client it does not close the daemon. It also does not appear to properly close the client because, while the window does dissapear, I am not returned to the prompt in the terminal where I launched it from. So my issue is that I cannot find a decent way to start and shut down the software. If I use a script that launches the daemon first, and then the client, that works so long as I always remember to click options --> quit. But I have a really hard time remembering to do that and often hit "x" instead. If hitting "x" minimizes the client somewhere, I cannot find it--it is not in the notification area or elsewhere. I then have the problem that if I run the same script to start it up I will regain the client but have two instances of dring running because the "x" does not close down the daemon. Having to use two different ways to start the client based on whether or not I've already launched the daemon seems a bit unnecessarily complicated. If I add the daemon to my startup applications for my desktop, then I don't need to make provisions for it to be started with the client. But, then, if I happen to close the client with options --> quit, the next time I launch the client it will not work because the client had closed the daemon the last time I used it. To have a manageable way to start and stop the client, I think one of three things needs to happen, and I don't really care which. A)The client needs to close the daemon when clicking "x" in the window title bar just like it does when going through the options --> quit menu.or B)The client needs to not close the daemon when clicking "options --> quit" just like it doesn't close it when clicking "x". Or, C)clicking the "x" button should remove the application's desktop window and send the application into the notification area/system tray or whatever people are trying to call it these days. I suspect that this is the intended behaviour, but if it is supposed to do that it is not working while other applications--transmission, google hangouts, etc--do this just fine. In this scenerio I can always make the daemon start with the client because the client will never be truly closed without also closing the daemon. Chris___ Ring mailing list Ring@lists.savoirfairelinux.net https://lists.savoirfairelinux.net/mailman/listinfo/ring
[Ring] ring-client-gnome compilation
Just an FYI for anyone compiling the Ring GNOME front end from source, we just merged a patch that removes the video quality control button fromt he UI: https://gerrit-ring.savoirfairelinux.com/#/c/3092/ You may have to delete the contents of your build dir and re-run the cmake command for the project to compile. This is because this patch removes one of the images from the pixmaps dir. Currently all the resources are compiled into the binary with the help of glib-compile-resources. To do this automatically in cmake we use the GResources.cmake module found in the cmake dir of the project. It detects when the *.gresource.xml files change to know that it needs to recompile the resources... however make all the files that are resources into targets and it seems to not detect properly when they're removed and so produces an error whenever one is removed. If any cmake hackers know how to ammend cmake/GResources.cmake to avoid this issue please feel free to let us know / contribute a patch. Thanks, -stepan ___ Ring mailing list Ring@lists.savoirfairelinux.net https://lists.savoirfairelinux.net/mailman/listinfo/ring
