On Thu, 2007-03-29 at 09:24 -0700, David J. Andruczyk wrote: > Though when a widget implementation causes 5-10x more cpu usage due > to a bad design. I think it warrants attention. Of course the speed of it can and should be improved across the board. But to say that it is bad design is not correct. It is no more poor design than any other widget. Except for the corner cases where GtkLabel is not appropriate (such as in your case), the setup time is only incurred once, just like any other widget. To hack in logic to deal with your corner case would likely lead to even poorer design. > > Add one simple function call to assign a label a FIXED size > (similar to the call for GtkEntries) so as to prevent the resize up > the widget tree syndrome. When a label update occurs, either > truncate anything past that limit, or if the ellipses property is > set to use that instead to show the label is larger than it's > allocated area. I don't think it is that simple. First of all, a fixed size that you think is right for your app may or may not even have enough room to display any of the text of the label on other people's systems. They may not be using the same font for the default in GTK, not the same DPI, etc. Thus how would you specify "fixed?" Further a GtkLabel can contain markup and cover multiple lines and have different kinds of alignment and justification. > > It would solve the cpu usage problem from the resize triggers and > not break backwards compat. It's also something that should have > been done 3-5 years ago. It would break binary compatibility. Your best bet is to follow the lead of evolution and other projects that need similar functionality and implement a custom widget, and perhaps submit it to the GTK head developers as an ancillary widget. Michael > gtk-list@xxxxxxxxx _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
