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 <[EMAIL PROTECTED]> 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
_______________________________________________
Gnome-accessibility-devel mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
_______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
