Re: Pointer/screen problems, part two

[Owen Taylor <otaylor redhat com>]

Tim Janik <timj gtk org> writes:

> On Mon, 30 Sep 2002, Owen Taylor wrote:
> 
> > Turns out there is another problem as well - when a pointer
> > grab is in effect, you can get pointer events where
> > x_root/y_root are relative to a different screen than
> > event->window, but there is no way to detect it.
> 
> whoo, messy.
> 
> > My possibly crazy idea for fixing this:
> > 
> > Add:
> >   
> >  gboolean g_mem_chunk_owns (GMemChunk *mem_chunk,
> >                             gpointer   mem);
> 
> nono, don't rely on mem chunk implementations one way
> or the other. for certain machines/systems they are already
> nothing more than a new/free wrapper (DISABLE_MEM_POOLS),

Ugh, forgot about DISABLE_MEM_POOLS.

> and g_mem_chunk_destroy() is basically broken there.
> mem chunks _have_ to be replaced in a future memory system
> rewrite, ading something like g_mem_chunk_owns() simply
> adds up to the compatibility maintenance nightmare mem chunks
> already introduce.
> gosh, why wasn't the mem chunk API correctly deprecated
> before 2.0? i could swear i sent an email out on this.

You mean why wasn't g_mem_chunk_destroy() deprecated? 
Probably because you didn't file a bug :-)

(I don't think we can honestly deprecate mem chunks in general until
we have a strategy for replacing them -- which could conceivably just
be "use malloc", and we stop using them ourselves all over the place.)
 
> > [ This is cheap to implement currently, could get a little
> >   more expensive if we reimplement GMemChunk not to have an
> >   area tree, but should always be possible ]
> > 
> > Then we can have a:
> > 
> >  void gdk_event_set_screen (GdkEvent *event);
> 
> if this is only going to work on events that are allocated
> via _gdk_event_new() and thusly freed with gdk_event_free(),
> i don't see why you couldn't simply use g_datalist_id_set_data_full().

A pretty big percentage of events will actually have this extra 
information (all motion notifies, and motion notifies are a big
percentage of events).

So, if I need to keep track of "is this an allocated event" using 
a hash table, it probably make sense to just to use a separate
hash table rather than incurring the overhead of separate
blocks to hold the extra information and GData blocks. 

> > That works for events allocated with _gdk_event_new()
> > but not for stack allocated evens.
> 
> not that i particularly like the idea of gdk_event_set_screen() not
> working on stack located events, but then that's due to the
> brokeness of allowing events not allocated through _gdk_event_new()
> in the first place. so if you do implement gdk_event_set_screen()
> based on datasets, you should deprecate event allocations
> other than through _gdk_event_new() on the way, so for 3.0, we
> have at least the ability to put a screen fields into GdkEvent.

First step in doing that would be adding a public gdk_event_new()...

Regards,
                                        Owen