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

[Bill Haneman <Bill Haneman Sun COM>]

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:
>
> #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
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
>