New versus old Tree/List store

Dear fellow users,

We’re working on a new release of Gtk2Hs which is certainly overdue, not least due to the release of GHC 6.6. We have re-implemented the clumsy Tree- and ListStore objects in Haskell. These objects store the data of the TreeView, ComboBox, IconView and some other widgets which were previously as difficult to use as in C, i.e. setting up a List- or TreeStore and connecting it to the widgets was a nightmare. Duncan has bitten the bullet and re-implemented the ListStore and all it’s ugly interfacing to Gtk within Haskell, on top of which I’ve written a corresponding TreeStore implementation in Haskell. What gives us a bit of a headache is that the not-so-standard widgets like ComboBox often internally create the C variants and that there seem to be no hooks to drop in our own Haskell replacement. As a result, our Haskell List- and TreeStore is not quite working with all widgets.

Duncan therefore proposed to include both, the C-land List- and TreeStore and our new Haskell List- and TreeStore in the new release. While this seemed to be a good intermediate solution, one of our brave bleeding edge users (who use the darcs repository rather than the last release) rightfully complained that things do not work with the new Haskell models. He’s hardly to blame, as it is far from clear which functions are from the C model and which are from the Haskell model. Mixing them will give a compilable program, but one which complains at runtime about bad iterators, invalid indices and the like. I’m wondering wether we should release just the new model and try to fix as many widgets as possible, even if that means that not all widgets will be fully usable in the next release. Note that we really would like to release before Christmas!

7 Responses to “New versus old Tree/List store”

  1. Joachim Breitner Says:

    Isn’t the new TreeStore and ListStore an alternative to the current one? What if users prefer to use the original, maybe because they are used to that, or want to migrated from a C or python program without changeing too much at first.

    It seems that both are independent implementations of the gtk TreeStore interface, and should be usable intependently. Maybe by renaming them to HTreeStore and HListStore?

  2. Gour Says:

    Hi!

    I’m wondering wether we should release just the new model and try to fix as many widgets as possible, even if that means that not all widgets will be fully usable in the next release.

    I’m for it.

    Gtk2Hs is probably does not have such a big user-base and therefore it is not problem if the APIs are still (not-so-fast) moving targets.

    Therefore, imho, it is better to focus time & energy on providing new & better API than to fix things which will soon become obsolete.

    If the project would have many devs (I’m still not being able to help with those issues being busy with non-Haskell stuff), then it could be reasonable to dedicate someone to maintain backward compatibility.

    Otoh, now it is much more important, considering that Haskell is really becoming more & more popular, to have new release with more Haskell-ish interface.

    Note that we really would like to release before Christmas!

    This would be very nice Christmas gift indeed :-)

    Sincerely,
    Gour

  3. David Waern Says:

    Hi,

    I agree with Gour. I’d much rather have a Gtk2Hs with a non-stable API that is constantly improved, than one containing backwards-compatability stuff.

  4. Axel Says:

    Joachim,

    that’s an interesting view. Duncan and I both assume that the new Haskell model is in every way superior, both in usability and type safety. Maybe we can keep the old interface, however, we really need to make sure that people use the new store when they start from scratch. It is much easier to use. We just need to complete it…

    Axel.

  5. Thorsten Says:

    I would suggest that you drop the old interface and concentrate on the new Haskell model (which sounds very promising — I never liked the old interface).

  6. whoopee Says:

    i presume you already know that the current release of gtk2hs relies on a deprecated Data.FiniteMap library?

    anyway, looking forward to using this with ghc6.6 when it is updated!

  7. Duncan Says:

    “whoopee”, yes we do know and we’re just about to announce the second release candidate for everyone to test. :-)

    (The first release candidate was only announced to the users mailing list, so we don’t use up our potential pool of testers too quickly)