On Wed, Apr 30, 2008 at 10:52:37PM +0200, Johannes Hofmann wrote:
This is a first cut at making FltkListResource work properly.
The resource maintains a hash of its items' selected status, the MultiBrowser widget gets a callback that updates the hash and isSelected() looks up the hash for the answer. It's the same technique I used for FltkOptionMenuResource , where the FLTK widgets are linked to their resources by user_data() and callback arguments.
I added equals() and hashValue() methods to Items so they could be hash keys, and implemented an object::Object wrapper class for boolean values to be the hash values. The wrapper class is inside FltkListResource , though it could easily move to lout::object IMHO.
It seems a bit complicated to me. Wouldn't it be easier to just add a member "selected" to Item that stores whether the item is currently selected or not? May well be that I'm missing something though.
It's not so much complicated as cumbersome: the logic is pretty straightforward, but using the Hash requires extra scaffolding. I was reluctant to add stuff to Item because that class serves double duty for both FltkListResource and FltkOptionMenuResource and so it's ugly for Item to contain stuff that is specific to one of the resource classes. Of course the resource classes could derive their own Item classes, but that adds scaffolding too. IIRC I experimented with that when I first did FltkOptionMenuResource (before going for a simpler suggestion of yours, I think) and the templating made it particularly messy. Let me think about it a little while I fix the bugs. I think the bug fixes will be orthogonal to the issue of how we store the selection information so it shouldn't impact implementing your suggestions if that's the way to go. Regards, Jeremy Henty