Re: GtkCanvas requirements?
- From: Carlos Garnacho <carlos imendio com>
- To: Havoc Pennington <hp redhat com>
- Cc: Sven Herzberg <herzi gnome-de org>, gtk-devel-list gnome org
- Subject: Re: GtkCanvas requirements?
- Date: Tue, 24 Apr 2007 02:44:13 +0200
Hi!,
On Mon, 2007-04-23 at 14:03 -0400, Havoc Pennington wrote:
> I certainly have not sat down and exhaustively tried to figure this out.
Oh, nice list below, I was somehow thinking a shorter in scope, less
tangential, set of changes.
>
> There is a fair bit of cruft in the core; if you were starting over, I'm
> sure you'd want to just kill GdkWindow for example, and many other "Xlib
> leakages" such as how some of the events work. You'd want to be
> Cairo-only, use interfaces instead of objects for the core APIs (widget,
> container), rethink GtkContainer and its common subclasses (as
> HippoCanvas does), fix the theme system, blah blah. The list could get
> pretty long.
>
> The question is which of these are cosmetic cleanups that aren't really
> worth it and which add new capabilities, and how long is the new
> capabilities list. Probably not nearly as long as the cosmetic list.
>
> Replacing the core with a more canvas-ish solution would not have to be
> done all in one shot, though; the WidgetCanvasItem and CanvasWidget
> provide a lot of interoperability. You could also have some of the
> existing widgets implement the CanvasItem interface directly, for
> example GtkEntry could be both a GtkWidget and a CanvasItem.
>
> There's no real disruption to the current core while building a new
> canvas-style core either, in fact I'd suggest evolving the canvas stuff
> outside of GTK+ for at least a couple of years. It is probably also true
> that certain "heavy" widgets such as TextView and TreeView never benefit
> from conversion to a canvas-like model.
I agree this is a great idea for a testbed independent to GTK+, but even
in this case you could only test a subset of the things mentioned here,
other ones could prove to be hardly interoperable with the current
GtkWidget/GdkEvent functional details (Events handling, GdkWindow
revamp, ...).
IMVHO, such testbed should become directly a gdk/gtkwidget proof of
concept experiment, with two or three widget implementations to play
with, and such codebase could be reused later when it proves to be a
substantial improvement.
But, even being the canvas a great excuse to begin this effort, I don't
think it's going to offer enough improvements to the canvas itself to
deserve such a long wait, I think leaving potential API users with the
current canvas buffet for (say) these two years would harm us in the
medium/long term.
Regards,
Carlos
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]