hi lothar, i'm not familiar with the details of your app, but i wonder if looking at this from the user's perspective might lead you to a way out.
first, does your model assume a single list of items? or are there several levels of hierarchy involved? because when it's a single list: if, as a user, i am confronted with a combo box with 10K+ items, how am i expected to use it in a way that translates to user-friendliness? like i said, don't know your app, but a combo box with thousands of items a user is expected to select a single entry from seems, well, a little crazy. i would definitely look to breaking this up into as many levels of hierarchy as possible to make the user not go insane. (on the other hand, this doesn't necessarily solve your problem...) when, on the other hand, your model translates to combo-box lists that define several levels of hierarchy (resulting ultimately in a selection list presented to the user that is a reasonable length), then you might want to think about how to tackle the problem as part of the design. for example: - is the list data static (defined once during the lifetime of the program) or dynamic? - when static, create all the combo boxes you need at program startup and then simply attach them accordingly during the course of program execution, when and where you need them. - when dynamic, what triggers a change? - if triggered externally (i.e., not a result of user interaction), consider handling the change in the background, constructing the new models and then attaching to a new combo box widget that is used as a replacement the next time the combo box is requested. - if triggered by the user, there's not a lot (i think) you can do about GTK+ internals and how this particular processing has been designed and implemented. my app constructs combo-box lists, some quite large, so when the user dis-connects and re-connects from/to different databases, many, many data models and combo-boxes must be destroyed and recreated. for me, this translates to less than a minute of time in my worst-case scenario. and so i've decided to live with this since DB switching does not iccur very frequently. that doesn't mean a different, better solution doesn't exist, i just don't know of it. richard On Wed, Apr 27, 2011 at 10:54 AM, Lothar Scholz <[email protected]> wrote: > Hello, > > i tried to test GtkComboBox with just 10000 items (not that much) and > the app becomes totally unusable. I'm using my own tree model and my > own cell renderer. > > While GtkTreeView works very well with a few ten thousand items, > GtkComboBox runs through all items multiple times when attaching > the model and displaying the list. And setting > "gtk_cell_renderer_set_fixed_size" seems not to work either, cause it > still iterates like crazy. > > Is there anything i can do about it? > > > -- > Best regards, > Lothar mailto:[email protected] > > _______________________________________________ > gtk-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gtk-list >
_______________________________________________ gtk-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-list
