Re: 3000 toggle buttons in a table?

[Gus Koppel <gtk spamkiller bytechase cx>]

Tristan Van Berkom wrote:

> Gus Koppel wrote:
> > "Sailaxmi korada " wrote:
> >
> > >  My application has to display around 3000 toggle buttons, in 178 rows of a
> > > table. It is taking almost 12 seconds to do so.
> > >
> > >  Can you help me out in reducing this time.
> > >  Here are the two steps that are consuming maximum time
> > >
> > >  gtk_button_set_label (GTK_BUTTON(drpentry_binbutton), "1");
> > >
> > >   gtk_toggle_button_set_active
> > > (GTK_TOGGLE_BUTTON(drpentry_binbutton),FALSE);
> >
> > I refrain from asking who might be supposed to toggle all 3000 buttons.
> > I rather suggest you to do without standard widgets at all when it comes
> > to such an exorbitant number of toggles.
>
> Sorry if I'm jumping into a thread that I havent read... maybe
> this comment was already made on this thread...
>
> Why not use GtkCellRendererToggle w/ GtkTreeView & GtkListStore ?
>
> Or use a GtkListStore to select your data item and some togglebuttons
> and whatever other control widgets below your treeview (i.e. the single
> toggle button applies only to the selected row) ?
>
> (Sure; writing treeview code is a pain, but its perfect for these
> "large dataset" situations).

I suppose for Sailaxmi's application it is important to have all toggles
clearly arranged, likely for some sort of state matrix. Using a treeview
with togglebuttons below it for just the currently selected line would
be the more conventional approach to avoid huge numbers of widgets but
likely doesn't fit the demands.

On the other hand, filling the visible area of a treeview with 3000
toggles would still result in suboptimal display performance. For
(basically) maintaining the original layout while significantly
increasing its build speed, I think doing all the drawing on one's own,
without keeping any widget or field structures behind it, is the best
way. At least it's the fastest by far.

Perhaps it would be beneficial to be able to toggle multiple "buttons"
just as the mouse passes over them while the mouse button is being
pressed? This could be accomplished with a custom implementation as
well. Think of The Gimp with a 16 * 178 B/W bitmap. There's no way of
implementing such behaviour (one button press, multiple state changes)
with any standatrd means.