[email protected] wrote:
>> Whether you go that route or with Fl_Tree, in either case
>> you'd want your widgets to be in an Fl_Group that is probably
>> a custom class of your own derived from Fl_Group.
>> This way you can create one instance of this custom group
>> for every 'line' in the browser.
>
> I'd add that you should give some thought early on to how
> many widgets you have to be able to browse through.
True enough.
> The design Greg is describing is great for a few hundred perhaps,
> but won't scale up well.
Oh I dunno about a few hundred.. I tried modifying the
example I posted so that the "Add" button adds 500 items
every time you hit it. I got tired of hitting the button
at around 19,000 items, and still the display was very fast
to scroll around. Tested on a 5 year old 1Ghz linux box.
However, it depends how many widgets you stick into each item;
if each item had a few buttons and an Fl_Input, then it might
be a bit slower, I didn't check.. but I think it would scale
fairly well.
There is some limit imposed by the size of signed shorts
which used to come into play due to pixel sizes wrapping
around at about 32768, but I /think/ in 1.3.x that was
extended to the size of signed ints.
> To handle larger numbers is possible,
> but it's a lot more work... you'll have to take over the
> task of figuring out which widgets should be visible and
> only rendering those to the screen. It would be a shame to
> put in the effort to build something, only to discover that
> you have to start all over at a late date.
If you hit speed walls, there's several optimization tricks
you can do without starting from scratch.
On trick is to make only one instance of the FLTK widgets
of an item, and modify the draw() routine of the browser
to simply draw that one instance in each visible position
in the browser. Then when someone hovers over an item,
you move that instance under their cursor so that if they
click, they hit the widgets. You'd manage the data of the
cells in a separate array.
An example of this is the examples/table-spreadsheet
which simulates a spread sheet with a single instance
of an Fl_Input. All the cells on the spreadsheet are
not separate widgets, but are simply 'drawn' as text..
The single Fl_Input remains hidden most of the time
until someone clicks on a cell; the input widget is then
quickly moved to that location and show()n, then disappears
again when the user hits Enter, and the cell goes back to
being "drawn" with draw().
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
