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 <bapti...@bitsofnetworks.org>
To: Chris Curtis <hopperc...@yahoo.com>
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 +0000, 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 <bapti...@bitsofnetworks.org>
> 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 +0000, 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
>
> _______________________________________________
> Ring mailing list
> Ring@lists.savoirfairelinux.net
> https://lists.savoirfairelinux.net/mailman/listinfo/ring
>
>
>
_______________________________________________
Ring mailing list
Ring@lists.savoirfairelinux.net
https://lists.savoirfairelinux.net/mailman/listinfo/ring
