Re: gtk_widget_draw()
- From: Havoc Pennington <hp pobox com>
- To: Ryan Lortie <desrt desrt ca>
- Cc: gtk-devel-list <gtk-devel-list gnome org>, Benjamin Otte <otte gnome org>
- Subject: Re: gtk_widget_draw()
- Date: Mon, 9 Aug 2010 16:17:09 -0400
Hi,
On Mon, Aug 9, 2010 at 3:57 PM, Ryan Lortie <desrt desrt ca> wrote:
> I think we should just fix these.
>
> It seems like the only GtkWidgets that posess GdkWindows ought to be
> toplevels (windows, popups, etc) and GtkPlug/GtkSocket.
Subwindows do have a function though (events, clipping, scrolling). I
think with text view you'd have to sort of replicate that
functionality with a new API to replace
gtk_text_view_get_window(), gtk_text_view_set_border_window_size(),
etc. Right now the API is "get a window to draw to and get events on"
and it would have to become something like a callback where you get a
cairo context to draw to, and I'm not sure about the events.
GtkSourceView would be one heavily-affected codebase if there are
changes here.
gdk_window_scroll() is probably fairly easy to get rid of... _if_ you
don't care about avoiding a full repaint. If you want to only repaint
the "new" area - that seems a bit tricky to me. Maybe client-side
windows already solved it, I don't know.
It's just something that stands out to me from this direction of work
as "I don't know offhand exactly what I'd do about it" that's all, so
I was curious. I'm all in favor of this work.
(One reason is, I'd love to see any downsides to just using GTK
widgets inside Clutter removed; starting over on all the "hard"
widgets, input methods, etc. on top of Clutter loses an awful lot of
effort and functionality imo.)
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]