1
0
mirror of git://projects.qi-hardware.com/fped.git synced 2024-11-17 21:01:32 +02:00

Canvas tooltips now work. The problem was that expose events set the paint

region to only cover the newly exposed area. This prevented the general 
redrawing from clearing areas that still contained hovering and dragging
items. However,the paint region has no effect on reading from the drawable.
Thus when rebuilding the hover and drag stack, the still tainted image was
stored.

This issue could be solved by either introducing a separate mode where the
stack is redrawn instead of rebuilt, or by turning off double-buffering. 
The former would complicate the already fickle logic of overlays, and not
having double-buffering doesn't seem to cause any ill effects.

- gui_canvas.c (make_canvas): disable double-buffering of canvas so that the
  paint region is not restricted in expose events
- gui_tool.c (tool_tip): enabled canvas tooltips



git-svn-id: http://svn.openmoko.org/trunk/eda/fped@5770 99fdad57-331a-0410-800a-d7fa5415bdb3
This commit is contained in:
werner 2010-01-02 15:47:46 +00:00
parent 14f21c0aee
commit 1cd5e6da94
2 changed files with 2 additions and 8 deletions

View File

@ -522,6 +522,8 @@ GtkWidget *make_canvas(void)
GDK_SCROLL | GDK_SCROLL |
GDK_POINTER_MOTION_MASK); GDK_POINTER_MOTION_MASK);
gtk_widget_set_double_buffered(canvas, FALSE);
draw_ctx.widget = canvas; draw_ctx.widget = canvas;
return canvas; return canvas;

View File

@ -848,14 +848,6 @@ const char *tool_tip(struct coord pos)
if (!inst) if (!inst)
return NULL; return NULL;
/*
* Tooltips don't work properly yet, so we return NULL here. The
* tooltips themselves are fine, but the expose event generated when
* removing the tooltip window upsets the overlay logic for some yet
* unknown reason.
*/
return NULL;
/* /*
* The logic below follows exactly what happens in get_hover_inst. * The logic below follows exactly what happens in get_hover_inst.
*/ */