Re: GNOME Summary, June 7-14
- From: Tony Lill ajlc waterloo on ca
- To: gnome-list gnome org
- Subject: Re: GNOME Summary, June 7-14
- Date: Thu, 17 Jun 1999 20:28:07 GMT
Havoc Pennington <rhp@zirx.pair.com> writes:
> Session Management
> ===
>
> Session management is a very powerful thing, when implemented
> thoroughly. Applications should remember details such as the cursor
> location, current open documents, and so on. I recommend reading the
> "SM/SMlib.PS" document that comes with X (on Debian, it's in the
When you are doing this, remenber that people could have the same app
running in multiple sessions, so make sure that you save and restore a
seperate state for each. For example, I have a seperate session for
each client's network that I plug my laptop into.
> Speaking of which, gnome-session needs a lot of work, if someone is so
> inclined. The SMlib.PS document gives you an idea how powerful a
> session manager could really be, in conjunction with SM-compliant
> applications.
Here's a question, how does one go about changeing the SM interface?
The problem that lead me into looking at the session manager is that
the session manager has no idea what host the client is running on.
IMHO, there should be an SM property that tells you the client
host. It would take about 6 lines of code to add it to libXt.a.
Now there is a function call, SMClientHost, that the spec claims will
give you the info. However, as implemented, it just gives you the
thing at the other end of the SM connection, which is always the X
server. The only way I can think of getting the client host is from
the window manager.
Then there's the UserId property. The spec also says "On POSIX-based
systems this will contain the the user's name (the pw_name field of
struct passwd)." In reality, on a local linux box it works, but on a
remote one, you get the uid number, making it useless for doing
something like "rsh -l username host cmd".
> you're using the Gnome or KDE or CDE session manager. Also, most
> window managers don't properly save application window locations, per
> the X specs. Perhaps the new window manager spec will clarify some of
> this mess.
Even more unfortunately, the window manager is the only thing that
could possibly do it properly. Think, for instance, if you login on a
display with a different geometry, or enlightenment, where, near as I
can tell, there is no way to start a client on any desktop but the
root one.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]