Re: [g-a-devel] Re: gok broken with new libwnck

We still have the problem that we are 6 days from code freeze with a change in API which we depend on. So the solution proposed below (re-implementing the libwnck calls) is not a runner for us.

I still think that keeping the old API around and marking it deprecated is a reasonable compromise given the timing of the change. I don't even mind if it's removed post-2.10, if your concern is "encouraging its use" for too long.

I also think that re-implementing libwnck functionality in multiple modules is a clear sign that we need stable API in this area.

- Bill

Elijah Newren wrote:

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:

#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"

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

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.

Gnome-accessibility-devel mailing list
Gnome-accessibility-devel gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]