Re: [platform-swt-dev] Re: (GTK2) EclipseFixed problem

[Mike_Wilson@xxxxxxx]

Ask the original Mac developers how painful it is to require widgets to clip against their parents. Seeing this reaffirms my belief that lightweight widgets will always cause you grief. Oh well. You definately better make sure that no widget ever attempts to draw outside of its paint.

McQ.

Havoc Pennington <hp@xxxxxxxxxx> Sent by: platform-swt-dev-admin@xxxxxxxxxxx 03/08/2002 06:05 PM Please respond to platform-swt-dev

To:        Boris_Shingarov@xxxxxxx         cc:        platform-swt-dev@xxxxxxxxxxx, otaylor@xxxxxxxxxx         Subject:        [platform-swt-dev] Re: (GTK2) EclipseFixed problem

Hi,

To follow up on that a bit more after talking to Owen about it:

 - Clipping of child widgets to the parent allocation isn't genuinely
   guaranteed by GTK, and the reason is (as usual) the evil of widgets
   with a GdkWindow; e.g. GtkEntry, GtkSpinButton. To clip child
   widgets with a window you would need EclipseFixed to have a
   window - which would result in a world of ugliness.

   A third route is to have EclipseFixed optionally have a window or
   not, depending on whether SWT knows that it will be placing child
   widgets outside the extents of the EclipseFixed. I don't know 
   if this information is available.

 - If you have child GTK_NO_WINDOW widgets that do not clip to
   event->area correctly, you can hack around this by overriding
   expose_event again in EclipseFixed, and calling
   gdk_window_begin_paint_rect() with the intersection of the expose 
   area and the EclipseFixed allocation. (gtk_widget_intersect() can
   be used to compute this I believe.) This has some efficiency cost.

   However GTK widgets generally do clip to expose_event->area.

Havoc

_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev