Re: [g-a-devel] Re: gok broken with new libwnck
- From: Elijah Newren <newren gmail com>
- To: Bill Haneman <Bill Haneman sun com>
- Cc: Fernando Herrera <fernando herrera tecsidel es>, David Bolter <david bolter utoronto ca>, gnome accessibility <gnome-accessibility-devel gnome org>, desktop-devel-list gnome org, Kjartan Maraas <kmaraas broadpark no>
- Subject: Re: [g-a-devel] Re: gok broken with new libwnck
- Date: Tue, 22 Feb 2005 09:22:28 -0700
First, let me apologize for not being the one to notify you. I was
supposed to report this to the gok team when I made the libwnck change
(I did report the gnome-panel one, but was getting overloaded with
other tasks and missed reporting the gok one).
On Tue, 22 Feb 2005 14:54:50 +0000, Bill Haneman <Bill Haneman sun com> wrote:
> Given the fact that it's only 6 days till hard code freeze, might we
> have the old API reinstated, and add
Not an option, sorry:
#ifndef WNCK_I_KNOW_THIS_IS_UNSTABLE
#error "libwnck should only be used if you understand that it's
subject to frequent change, and is not supported as a fixed API/ABI or
as part of the platform"
#endif
Allowing the old API to remain encourages its use but the old API is
inherently problematic and this is not a stable library. Plus, other
solutions exist which are not terribly difficult to implement, and the
only gnome modules that are affected are gnome-panel (which has
already been fixed) and gok (with the only two files affected being
gnome-panel/apllets/wncklet/workspace-switcher.c and
gok/gok/gok-windowlister.c).
> void wnck_workspace_activate_with_time (WnckWorkspace *space,
> guint32 timestamp);
>
> void wnck_window_activate_with_time (WnckWindow *window,
> guint32 timestamp);
>
> The old API could become wrappers around the new API, and supply the current time as timestamp.
The time of the user interaction event that caused the call to
wnck_workspace_activate and wnck_window_activate is what is needed,
and using current time can cause problems.
I'd suggest writing equivalents of _wnck_activate and
_wnck_activate_workspace (which wnck_window_activate and wnck_activate
are wrappers for). gnome-panel has done something similar for a
variety of x messages. If you really need API stability then this is
the way to go because you aren't subject to changes in libwnck but
instead have your own functions that you control. Granted, you'll
need to keep up with the EWMH (though it doesn't change that often...)
at least by taking a periodic look at the relevant libwnck functions.
If you want to go this route, I'll be happy to help.
Elijah
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]