suspend/hibernation in xfce4-session

[Andre Puschmann]

Brian J. Tarricone wrote:
> Andre Puschmann wrote:
>>> hi folks,
>>> although we already have a thread arguing this topic, i decided to start
>>>  a new one, since this one should be about the following patch, if this
>>> is o.k. to you?
>>>
>>> i wrote a simple patch (still testing!!) which implements the discussed
>>> features. there are still some bugs+workarounds in there and i would
>>> very much appreciate if you guys can drop some hints, since this i my
>>> first xfce patch :-)
>>>
>>> - no dynamic hal+dbus recognition in Makefile.in
> 
> You need to edit Makefile.am.  Makefile.in is regenerated whenver
> autogen.sh is run.  You should use the XDT_CHECK_OPTIONAL_PACKAGE()
> macro in configure.in.in to detect hal and dbus properly.  I believe
> thunar uses both of these, so look there for examples of both
> configure.in.in and Makefile.am.

jep, i'll have a look at thunar's configure scripts ..

>>> - the session settings dialog crashes until dbus+hal-stuff is loaded
>>> (even if i did the error handling, but it seems that there is still
>>> something missing)
> 
> I didn't look too closely to this, but to debug, kill xfce-mcs-manager,
> and then run 'gdb xfce-mcs-manager' from a terminal.  Inside gdb, type
> 'run --no-daemon-debug' at the prompt, and you can get a backtrace when
> it crashes and hopefully figure out what's wrong.

thank you very much .. this was the tip i was looking for!
initialize hal_ctx with NULL fixed the problem ;-)

> 
>>> - if i call suspend, after resuming my xsession is stopped (like on
>>> normal logout). should i handle this with the "accessibility" boolean
>>> and do something like "if ((strcmp(shutdownType,
>>> "SHUTDOWN_HIBERNATE")==0))"?
> 
> Not sure what you mean... though that's probably because I'm not too
> familiar with xfce4-session's codebase.

i think xfce4-session quits the running xsession after a "SUCCESS" from
xfce-shutdown-helper, since this is quite usefull for all other
shutdown-actions like reboot+shutdown.
but we have to interrupt this xsession shutdown in case SUSPEND or
HIBERNATE is called, i guess.

>>> - hibernate+suspend command in xfsm-shutdown-helper are very static, so
>>> they have to be in PATH
> 
> This is definitely a bad idea security-wise; they should be absolute
> paths.  What you should do is make it configurable at compile-time via
> ./configure.  Grep around in one of our configure.in.in files for
> AC_ARG_WITH and AC_DEFINE - that's how you'd make it configurable.
> You'd want a hardcoded default in configure.in.in; use whatever appears
> to be the "normal" location for those commands.  That way, distribution
> packagers can easily set the location for their packages (since they
> know where their HAL installs its binaries), by doing something like:
> 
> ./configure --prefix=/whatever --with-hibernate-command=/sbin/foo

i'll try this. may be it is possible to figure out with which prefix hal
is compiled and thus figure out where those scripts use to be?

> One further comment: I (personally) would prefer the usage of the terms
> "Suspend" for "suspend to RAM" and "Hibernate" for "suspend to disk".
> These seem to be the accepted user-friendly terms for these functions,
> and are consistent across both Windows and MacOS X.  (Well, OS X doesn't
> have suspend-to-disk functionality without some nasty software hacks,
> but otherwise...)

changed! you're right since i am using this naming scheme inside as
well. thanks for that.

> 
> Oh, and just an English-language comment: for the checkbox text, it's
> just "Show XYZ", not "Show up XYZ".

changed as well :-)

> 	-brian

cheers
andre