Mostly it boils down to these reasons:
* Implementation can be quite hard to understand.
* Issues with widgets that have built-in layout() implementations
that can't be disabled.
* No stable release yet (still snapshots...).
* No accessibility support.
* Weak i18n/complex script support (esp. when compared to Pango/Gtk+).
* Smaller community than Gtk+ (e.g.: no "real" HTML renderer widget, etc)=
.
Currently in Mission I have a problem where the scroll container needs
to call it's layout method (when it's size changes) in order to
configure and position it's scrollbars. This layout call also moves
the children of the scroll container around (incorrectly), so I have
to get Eve to move them back. Having Eve move the children toggles the
"something is dirty, do a relayout" flag in FLTK and the next time
around the event loop it will do a relayout on everything, including
the scroll container again, which means Eve has to reposition the
widgets inside the scroll container that sets the dirty flag... For
whatever reason I haven't been able to hack the scroll container so
that it can correctly set itself up without touching the children (the
scroll container's layout method works iteratively until there is
nothing left to change, and this adds some complexity).
Of course, all of these problems can be addressed but I don't have
much spare time and it looks like using Gtk+ will get me to where I
want to be faster.
Thanks,
Ralph
On 4/6/06, Niki Spahiev <nik...@gm...> wrote:
> 2006/4/5, Ralph Thomas <ra...@gm...>:
> > I am planning on migrating my Mission project from FLTK2 to Gtk+ 2.
>
> Will you give some reasons for the switch. I am considering FLTK2 as
> GUI toolkit and would like toe hear about any weak points.
>
> regards,
>
> Niki Spahiev
>
|
