Hi,
On 06/22/2012 05:41 PM, Marc-André Lureau wrote:
<snip>
Just because many people use hash-tables for something does not make
them the
right choice, I looked at using hash-tables first, before I choose to
use
GData and I found GData to be a better match.
Right, but if nobody does something this way, I am very suspicious :)
GData list seems to be a simple growing array of elements with GQuark key, and the API includes "gchar *key". Not really fond of using something meant for various string representations for windows xid.
I don't see why a GHashTable would be more complicated.
Ok, I'll convert this bit to use GHashTables
<snip>
Could we simplify the API and the logic if we used a hidden window?
have you thought about it? That way, we don't need to pass a
window id around, we don't need to call (un)inhibit many times, we
don't need to maintain int->int mapping, we only keep one cookie
and a refcount.
Erm, no, the whole purpose of the toplevel window id is so that if
the window goes
away gnome-session can automatically uninhibit if the app does not do
so properly,
keeping a hidden window around for this would break this.
By go away, you mean destroyed? I suppose the manager doesn't care if
> the window is shown/visible or not, but that it exists and is destroyed
either intentionally, or unintentionally after abort etc.. I don't see
> the need to pass around each and every toplevel window to the manager
> (visible or not)
Passing, what for all intends and purposes is a *fake* toplevel window id,
is just gaming the system, this is not how the inhibit API is supposed to
be used! The whole toplevel id is there to avoid inhibits sticking around
when they should not. And we should simply not try to game the system!
Regards,
Hans
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel