Re: Save Dialog
On Thu, 2007-03-29 at 13:44 -0600, Michael L Torrie wrote: > On Wed, 2007-03-28 at 13:34 -0400, Docsonic wrote: > > I use Inkscape and posted a request on their list, they referred me to > > your list as the save dialog they use is GTK. So, I wanted to know if it > > was possible to change the save dialog so that, when you create a new > > subfolder, you are automaically entered into that folder. It does that now... Perhaps your version of GTK is out of date? > I wonder if this would lead to user confusion. I don't think so - whenever I do it I go from a folder full of stuff to an display of a folder that is empty, which is predictable and makes sense. I don't see it as jarring. A bit of bling animation would always help reinforce the notion, perhaps, but I don't see that as necessary. AfC Sydney signature.asc Description: This is a digitally signed message part ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On 3/29/07, Robert Pearce <[EMAIL PROTECTED]> wrote: > On Thu, 29 Mar 2007 13:58:51 -0700 (PDT) > "David J. Andruczyk" <[EMAIL PROTECTED]> wrote: > > > > > It does when you're monitoring a realtime datalogging system, and > > don't want to have gaps or slow response in the updates. (there > > are also graphical monitors as well, but the text is there for a > > precise reading) > > > No, it doesn't. No, it absolutely doesn't. Who the £%$% do you think is > watching this? Because you seem to have forgotten (along with your manners) > the FIRST RULE OF GUI DESIGN : > > If it's not USEFUL to the USER it's WRONG. > > I use high speed data loggers. I would not want your "feature". > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > I've been following this thread for a bit and thought I might make a couple points that I haven't really seen yet. First, there's been talk of the efficiency of GtkLabel vs. GtkEntry, but not of the conceptual difference as far as I've read. To me, a GtkLabel is a 'label' (get it?). A label shouldn't change. It tells the user what a given piece of information is. A GtkEntry contains a value. A value is expected to change. As to making an entry look like a label, I don't really understand why thats necessary, but thats a design decision and one I don't quite understand at that. My other point of contention is the discussion on how fast to update these widgets. Some of the posters have immediately said thats too fast. If you find yourself among this group, ask yourself one question, "Would I want to fly in a plane where the instruments were updated any slower?" I sure as hell wouldn't. Granted thats reductio ad absurum, but I think it gets the point across. Anyway, just my thoughts. Paul Davis (don't get confused, there are two of us). ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 2007-03-29 at 22:49 +0100, Robert Pearce wrote: > On Thu, 29 Mar 2007 13:58:51 -0700 (PDT) > "David J. Andruczyk" <[EMAIL PROTECTED]> wrote: > > > > > It does when you're monitoring a realtime datalogging system, and > > don't want to have gaps or slow response in the updates. (there > > are also graphical monitors as well, but the text is there for a > > precise reading) > > > No, it doesn't. No, it absolutely doesn't. Who the £%$% do you think is > watching this? Because you seem to have forgotten (along with your manners) > the FIRST RULE OF GUI DESIGN : > > If it's not USEFUL to the USER it's WRONG. > > I use high speed data loggers. I would not want your "feature". sometimes, the 30Hz "signal" transmitted to the user by the simple fact that the text is rapidly changing is actually very useful. 30fps is roughly the level needed to avoid visual perception of discontinuity - one could argue that 10Hz or 40Hz might be better for a visual "image" that isn't ever going to be continuous anyway. either way, its not clear to me that changing text so fast that it cannot be read is WRONG. there are certainly many cases where its counter productive. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Save Dialog
Michael L Torrie wrote: > Interesting proposition. I wonder if this would lead to user confusion. > Except for the crumb bar, there is little indication that the create > folder operation was successful if a user is automatically moved to the > new folder. My grandmother would likely end up creating dozens of > nested folders without realizing it. Perhaps an animation, involving the folder in question being selected, and then navigated into, would avoid such confusion, not to mention look nice :) Either way, I agree with the OP's suggestion. If you create a folder from a save dialog, chances are you want to save your file in the folder you've just created. -- Daniel Kasak IT Developer NUS Consulting Group Level 5, 77 Pacific Highway North Sydney, NSW, Australia 2060 T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989 email: [EMAIL PROTECTED] website: http://www.nusconsulting.com.au ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 29 Mar 2007 13:58:51 -0700 (PDT) "David J. Andruczyk" <[EMAIL PROTECTED]> wrote: > > It does when you're monitoring a realtime datalogging system, and > don't want to have gaps or slow response in the updates. (there > are also graphical monitors as well, but the text is there for a > precise reading) > No, it doesn't. No, it absolutely doesn't. Who the £%$% do you think is watching this? Because you seem to have forgotten (along with your manners) the FIRST RULE OF GUI DESIGN : If it's not USEFUL to the USER it's WRONG. I use high speed data loggers. I would not want your "feature". ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 2007-03-29 at 13:58 -0700, David J. Andruczyk wrote: > > Updating textual information 30x a second (2007-March/msg00116) > > does not make any sense though. > > > > Yeti > > It does when you're monitoring a realtime datalogging system, and > don't want to have gaps or slow response in the updates. (there > are also graphical monitors as well, but the text is there for a > precise reading) But you can't perceive changes in text 30 times in a second, so there's no point in showing that to a human. If you want to log the details for later (slower) perusal then you can do that, independently of any GtkLabel. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
--- David Neèas (Yeti) <[EMAIL PROTECTED]> wrote: > On Thu, Mar 29, 2007 at 12:43:20PM -0700, David J. Andruczyk > wrote: > > > > since there is NO other wisget that can > > be used to display rapidlychanging text. > > Most widgets can do it. Just do gdk_draw_layout() on > whatever you want. > > > (it's a textual display > > for a realtime datalogger, so fast updating is wanted) > > Updating textual information 30x a second (2007-March/msg00116) > does not make any sense though. > > Yeti It does when you're monitoring a realtime datalogging system, and don't want to have gaps or slow response in the updates. (there are also graphical monitors as well, but the text is there for a precise reading) -- David J. Andruczyk Expecting? Get great news right away with email Auto-Check. Try the Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 2007-03-29 at 22:27 +0200, David Nečas (Yeti) wrote: > On Thu, Mar 29, 2007 at 12:43:20PM -0700, David J. Andruczyk wrote: > > > > since there is NO other wisget that can > > be used to display rapidlychanging text. > > Most widgets can do it. Just do gdk_draw_layout() on > whatever you want. > > > (it's a textual display > > for a realtime datalogger, so fast updating is wanted) > > Updating textual information 30x a second (2007-March/msg00116) > does not make any sense though. it can be more work to make non-textual and textual elements update at a different rate than to just swallow the cost and do them both on the same interval. oh for an X toolkit that was really driven by the vertical retrace interrupt not realistic given network transparency, but a hacker can dream, can't s/he ? --p ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Save Dialog
On Thu, Mar 29, 2007 at 01:44:09PM -0600, Michael L Torrie wrote: > On Wed, 2007-03-28 at 13:34 -0400, Docsonic wrote: > > I use Inkscape and posted a request on their list, they referred me to > > your list as the save dialog they use is GTK. So, I wanted to know if it > > was possible to change the save dialog so that, when you create a new > > subfolder, you are automaically entered into that folder. i.e. If I > > create a subfolder and name it 'New', once I enter to accept the new > > name the directory structure places me into the 'New' folder to name and > > save the document. > > Interesting proposition. I wonder if this would lead to user confusion. > Except for the crumb bar, there is little indication that the create > folder operation was successful if a user is automatically moved to the > new folder. My grandmother would likely end up creating dozens of > nested folders without realizing it. Another thing is that given the > way GTK's save dialog box currently implements the "new folder" > mechanism, the folder goes into the file list immediately but sticks it > in edit mode so the user can give it a name. This behavior is not > possible if the save dialog box works as you suggest. Well, when I press Enter after typing the name of the new folder, the dialog does immediately switch to it (Gtk+ 2.10.x for various x). And it's quite confusing even though it is the thing I want most of the time. Yeti -- http://gwyddion.net/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, Mar 29, 2007 at 12:43:20PM -0700, David J. Andruczyk wrote: > > since there is NO other wisget that can > be used to display rapidlychanging text. Most widgets can do it. Just do gdk_draw_layout() on whatever you want. > (it's a textual display > for a realtime datalogger, so fast updating is wanted) Updating textual information 30x a second (2007-March/msg00116) does not make any sense though. Yeti -- http://gwyddion.net/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Save Dialog
Interesting proposition. I wonder if this would lead to user confusion. Except for the crumb bar, there is little indication that the create folder operation was successful if a user is automatically moved to the new folder. My grandmother would likely end up creating dozens of nested folders without realizing it. Another thing is that given the way GTK's save dialog box currently implements the "new folder" mechanism, the folder goes into the file list immediately but sticks it in edit mode so the user can give it a name. This behavior is not possible if the save dialog box works as you suggest. Just some observations. Michael Actually it could go into the new folder when you hit enter after you rename the folder. I am not saying that it is a good idea but maybe a power user short cut of hitting ctrl-enter or shift enter when you give the folder a name might be an idea. That would reduce the chance of people making too many nested folders by mistake. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 2007-03-29 at 12:43 -0700, David J. Andruczyk wrote: > I do this already ahead of time . I ONLY update the labels when > absolutely necessary.. > > As a workaround I moved t GTKEntries which did NOT have the > performance problem, though I can't quite make them appear like a > GtkLabel in all instances, since there is NO other wisget that can > be used to display rapidlychanging text. (it's a textual display > for a realtime datalogger, so fast updating is wanted) if you were working in C++ and using gtkmm, then its actually very easy to do this with just a drawing area. you just create a derived widget with its own pango layout, and a "set text" method. then in the expose method, just tell the pango layout to draw itself within the drawing area. no resize, no width computation, etc. in C, its quite a bit more complex, but can be done. --p ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 2007-03-29 at 16:22 -0300, Ivan Baldo wrote: > In gtk_label_size_request there is code to get the desired width and > height of the label, that could be called on the set_text and set_label > functions to see if they differ to the current allocated ones by a > threshold, and only then call gtk_widget_queue_resize_no_redraw > (expensive?) and always do a redraw (since the text is different so > something has changed). getting the height+width is not cheap with pango. checking that the text itself has not changed should be the first line of defense. also, on another note. it seems that some people think i am a GTK developer. i am not. i write applications with GTK and because they are extremely demanding and complex, i have been forced to grapple with GTK in a way that hopefully most of you are not. --p ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Save Dialog
On Wed, 2007-03-28 at 13:34 -0400, Docsonic wrote: > I use Inkscape and posted a request on their list, they referred me to > your list as the save dialog they use is GTK. So, I wanted to know if it > was possible to change the save dialog so that, when you create a new > subfolder, you are automaically entered into that folder. i.e. If I > create a subfolder and name it 'New', once I enter to accept the new > name the directory structure places me into the 'New' folder to name and > save the document. Interesting proposition. I wonder if this would lead to user confusion. Except for the crumb bar, there is little indication that the create folder operation was successful if a user is automatically moved to the new folder. My grandmother would likely end up creating dozens of nested folders without realizing it. Another thing is that given the way GTK's save dialog box currently implements the "new folder" mechanism, the folder goes into the file list immediately but sticks it in edit mode so the user can give it a name. This behavior is not possible if the save dialog box works as you suggest. Just some observations. Michael > > Thanks, > > Tony > > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
I do this already ahead of time . I ONLY update the labels when absolutely necessary.. As a workaround I moved t GTKEntries which did NOT have the performance problem, though I can't quite make them appear like a GtkLabel in all instances, since there is NO other wisget that can be used to display rapidlychanging text. (it's a textual display for a realtime datalogger, so fast updating is wanted) I have managed in some themes to get the entry's background color to change to that of it's parent, but in some themes the colors don't match and I end up with a different colored rectangle around the text. (which I can live with for the time being as the cpu usage dropped from 45% (on a 2.1Ghz machine) down to 4% by changing from GtkLabels to GtkEntries.. --- Ivan Baldo <[EMAIL PROTECTED]> wrote: > Hello. > > El 29/03/07 12:26, Paul Davis escribió: > > this is a sort of known "bug". setting the text of a label > causes a > > recompute of the label's size, which can propagate up the > containing > > widget tree. add Pango into the mix, and that resetting is very > costly. > > the same is not true of text entries, because they never resize > based on > > their contents. > > > > evolution, sodipodi (the precursor to inkscape) and a few other > projects > > have implimented their own labels that do not do this, for > precisely the > > reason you are now discovering. > > > I don't know if this applies to the original person with the > problem, > but there is a simple optimization for when an application > repeatedly > sets the same text to the label. > In gtk_label_set_text and gtk_label_set_label a simple strcmp of > the str > argument against the label or text fields of the label structure > can > avoid all re-computations and mallocs and frees when the text > specified > is the same as the previously one. > > In my case, I write applications in a very dumb way, I expect > that GTK > detects such silly things and avoid computations when it can. > For example in a current application that I am working I set > values for > a group of spinbuttons when only one changes, so I set all the > values to > the previously set ones and only change one. > Doing it in a smarter way means I need to put more time on it, > slowing > the true advancement of the application. Luckily it seems that > gtk_spinbutton_set_value checks that the value has really changed > and > avoid expensive operations if it doesn't. > I expect the same behavior in all GTK facilities, helping the > user when > it is reasonable and easy to do. > > In gtk_label_size_request there is code to get the desired width > and > height of the label, that could be called on the set_text and > set_label > functions to see if they differ to the current allocated ones by > a > threshold, and only then call gtk_widget_queue_resize_no_redraw > (expensive?) and always do a redraw (since the text is different > so > something has changed). > > I am not an expert on GTK so I am really shy to try to implement > this, > benchmark it, test it, etc. since I don't understand it fully... > Also because of that, maybe this email is totally wrong, I may be > > misunderstanding everything :). > > Goodbye. > > -- > Ivan Baldo - [EMAIL PROTECTED] - > http://ibaldo.codigolibre.net/ > ICQ 10215364 - Phone/FAX (598) (2) 613 3223. > Caldas 1781, Malvin, Montevideo, Uruguay, South America. > We believe that we are free, but in reality we are not! Are we? > Alternatives: [EMAIL PROTECTED] - http://go.to/ibaldo > > > ___ > gtk-list mailing list > gtk-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-list > -- David J. Andruczyk Don't get soaked. Take a quick peek at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
Hello. El 29/03/07 12:26, Paul Davis escribió: > this is a sort of known "bug". setting the text of a label causes a > recompute of the label's size, which can propagate up the containing > widget tree. add Pango into the mix, and that resetting is very costly. > the same is not true of text entries, because they never resize based on > their contents. > > evolution, sodipodi (the precursor to inkscape) and a few other projects > have implimented their own labels that do not do this, for precisely the > reason you are now discovering. > I don't know if this applies to the original person with the problem, but there is a simple optimization for when an application repeatedly sets the same text to the label. In gtk_label_set_text and gtk_label_set_label a simple strcmp of the str argument against the label or text fields of the label structure can avoid all re-computations and mallocs and frees when the text specified is the same as the previously one. In my case, I write applications in a very dumb way, I expect that GTK detects such silly things and avoid computations when it can. For example in a current application that I am working I set values for a group of spinbuttons when only one changes, so I set all the values to the previously set ones and only change one. Doing it in a smarter way means I need to put more time on it, slowing the true advancement of the application. Luckily it seems that gtk_spinbutton_set_value checks that the value has really changed and avoid expensive operations if it doesn't. I expect the same behavior in all GTK facilities, helping the user when it is reasonable and easy to do. In gtk_label_size_request there is code to get the desired width and height of the label, that could be called on the set_text and set_label functions to see if they differ to the current allocated ones by a threshold, and only then call gtk_widget_queue_resize_no_redraw (expensive?) and always do a redraw (since the text is different so something has changed). I am not an expert on GTK so I am really shy to try to implement this, benchmark it, test it, etc. since I don't understand it fully... Also because of that, maybe this email is totally wrong, I may be misunderstanding everything :). Goodbye. -- Ivan Baldo - [EMAIL PROTECTED] - http://ibaldo.codigolibre.net/ ICQ 10215364 - Phone/FAX (598) (2) 613 3223. Caldas 1781, Malvin, Montevideo, Uruguay, South America. We believe that we are free, but in reality we are not! Are we? Alternatives: [EMAIL PROTECTED] - http://go.to/ibaldo ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 2007-03-29 at 10:48 -0700, David J. Andruczyk wrote: > --- Michael Ekstrand <[EMAIL PROTECTED]> wrote: > > > 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. > > > > > > [suggested fix snipped] > > > > > > 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's open-source software. If this issue is that important to > > you, > > submit a patch. Criticizing the volunteers working on GTK+, who > > evidently haven't found this to be a significant enough issue to > > warrant > > this kind of attention, isn't a constructive way to promote > > change. > > > > I did my part by SUBMITTING BUG REPORTS, several in fact.. > I'm an not a GTK+ wizard, nor do I know all the intricacies about > how it renders. hence I GAVE them the information ,described the > problems, and it was tossed out. I am not a GTK developer; I'm more of a list lurker. But I do use GTK for developing and I am familiar internal GTK code. So I merely give my opinion. The reasons for this being marked as "won't fix" have been, in my opinion, fairly clearly expressed on the list. Unless you can a) argue persuasively why changing this behavior (the so-called bug) is worthwhile to the majority of GTK users, preserves the ABI, does not introduce new behaviors or side effects or b) demonstrate code that does these things, then you need to accept the opinions of the developers and move on with your own work-around code. Complaining here will not bring about any progress on this issue. I believe I can summarize the reasons why GTK developers have dismissed your bug report: - The bad behavior is only apparent in a corner use case of GtkLabel that was never an intended use. GtkLabels were never designed for constant updating. The nominal use case is a on-time setup, incurring no more cost than any other widget setup. Other uses likely need to be fulfilled by another built-in widget or custom widget. - Changing the code to fix this behavioral problem would break the binary compatibility and likely introduce new bugs and side-effects. A new API for GtkLabel should be introduced to the GTK3 work, not GTK2. Despite what you say, your changes would indeed introduce a new API and break GTK2.x compatibility (ABI). - The cost in developer time of changing this behavior is simply too high. Since it does not affect the speed and stability of 99% of GTK apps, developer time should be spent elsewhere. Another minor issue may have been the way you wrote up the bug report. Bug reports that give the impression that the GTK developers owe you something will likely not elicit a favorable response, especially given the points above. If it was similar to your posts on this issue, then I can imagine that the human factor may have played a role. In short, I think GTK developers have agreed with you that this behavior of the GtkLabel during updates can cause issues, but given the points I mentioned, will not fix this corner case for you in the stable GTK2 branches. However they have suggested some very good workarounds, including writing/borrowing your own GtkLabel widget that would work better for your use case. In fact they even told you where to go to see exactly such code. cheers, Michael > > > > -- David J. Andruczyk > > > ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
--- Michael Ekstrand <[EMAIL PROTECTED]> wrote: > 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. > > > > [suggested fix snipped] > > > > 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's open-source software. If this issue is that important to > you, > submit a patch. Criticizing the volunteers working on GTK+, who > evidently haven't found this to be a significant enough issue to > warrant > this kind of attention, isn't a constructive way to promote > change. > I did my part by SUBMITTING BUG REPORTS, several in fact.. I'm an not a GTK+ wizard, nor do I know all the intricacies about how it renders. hence I GAVE them the information ,described the problems, and it was tossed out. -- David J. Andruczyk We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265 ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
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@gnome.org ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
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. > > [suggested fix snipped] > > 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's open-source software. If this issue is that important to you, submit a patch. Criticizing the volunteers working on GTK+, who evidently haven't found this to be a significant enough issue to warrant this kind of attention, isn't a constructive way to promote change. - Michael -- Michael Ekstrand Research Assistant, Scalable Computing Laboratory Goanna, compute cluster and InfiniBand network monitor tool: http://www.scl.ameslab.gov/Projects/Monitor/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
Though when a widget implementation causes 5-10x more cpu usage due to a bad design. I think it warrants attention. 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. 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. --- Paul Davis <[EMAIL PROTECTED]> wrote: > On Thu, 2007-03-29 at 09:04 -0700, David J. Andruczyk wrote: > > And the GTK+ developers haven't fixed this because of what? > pride? > > > > I've seen this issue in GTK+ for YEARS, and filed bug reports > on it > > for several years only to be shot down and turned away by them. > > > That's disappointing. > > its not actually a bug, which is why i wrote "bug". its an issue > with > the semantics of what a "label" is and how it should behave. > > for many applications, the current behaviour of GtkLabel is > correct and > desired. for many others, it isn't, hence the work that > Evolution's team > had to do. > > there are very few people working on the GTK infrastructure. > adding a > whole new semantic for labels (or even an option to disable > resizing, > which has several side effects) is not likely high on the couple > of > personal TODO lists that anyone has. > > --p > > > -- David J. Andruczyk Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Thu, 2007-03-29 at 09:04 -0700, David J. Andruczyk wrote: > And the GTK+ developers haven't fixed this because of what? pride? > > I've seen this issue in GTK+ for YEARS, and filed bug reports on it > for several years only to be shot down and turned away by them. > That's disappointing. its not actually a bug, which is why i wrote "bug". its an issue with the semantics of what a "label" is and how it should behave. for many applications, the current behaviour of GtkLabel is correct and desired. for many others, it isn't, hence the work that Evolution's team had to do. there are very few people working on the GTK infrastructure. adding a whole new semantic for labels (or even an option to disable resizing, which has several side effects) is not likely high on the couple of personal TODO lists that anyone has. --p ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
And the GTK+ developers haven't fixed this because of what? pride? I've seen this issue in GTK+ for YEARS, and filed bug reports on it for several years only to be shot down and turned away by them. That's disappointing. --- Paul Davis <[EMAIL PROTECTED]> wrote: > On Mon, 2007-03-26 at 17:17 -0700, David J. Andruczyk wrote: > > I hadn't tried that as I assumed that it was off by default > unless > > enabled.. > > > > Since a simple test program doesn't show it,. but my app does > and > > the performance hogging goes away when I comment out one line > > (gtk_label_set_text) the problem appears to be internal to GTK> > > > Another fine fellow suggested it may be due to resizing of > widgets > > caused by the label update, and showed me a way to set it to a > > fixed size, but that ahd no effect on cpu usage (still high). > > > > I managed to create a workaround by useing a GtkEntry instead, > and > > working out some trickery to make the entrie's background color > > (normally white) to match it's parent so it blends in and looks > > like a label, and presto, cpu usage went from 40-45% down to 4 > %. > > > > For some reason in my case the label updates seem to be > triggering > > some internal stuff for no good reason. when I get a little > time > > I'll try to extract that section of code int oan isolated test > > case, and if it still shows that I'll file it as a GTK+ bug. > > this is a sort of known "bug". setting the text of a label causes > a > recompute of the label's size, which can propagate up the > containing > widget tree. add Pango into the mix, and that resetting is very > costly. > the same is not true of text entries, because they never resize > based on > their contents. > > evolution, sodipodi (the precursor to inkscape) and a few other > projects > have implimented their own labels that do not do this, for > precisely the > reason you are now discovering. > > (i would have replied sooner, but was away in berlin at the linux > audio > conference with no email access or time) > > --p > > > > -- David J. Andruczyk It's here! Your new message! Get new email alerts with the free Yahoo! Toolbar. http://tools.search.yahoo.com/toolbar/features/mail/ ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: (severe) performance issues
On Mon, 2007-03-26 at 17:17 -0700, David J. Andruczyk wrote: > I hadn't tried that as I assumed that it was off by default unless > enabled.. > > Since a simple test program doesn't show it,. but my app does and > the performance hogging goes away when I comment out one line > (gtk_label_set_text) the problem appears to be internal to GTK> > Another fine fellow suggested it may be due to resizing of widgets > caused by the label update, and showed me a way to set it to a > fixed size, but that ahd no effect on cpu usage (still high). > > I managed to create a workaround by useing a GtkEntry instead, and > working out some trickery to make the entrie's background color > (normally white) to match it's parent so it blends in and looks > like a label, and presto, cpu usage went from 40-45% down to 4 %. > > For some reason in my case the label updates seem to be triggering > some internal stuff for no good reason. when I get a little time > I'll try to extract that section of code int oan isolated test > case, and if it still shows that I'll file it as a GTK+ bug. this is a sort of known "bug". setting the text of a label causes a recompute of the label's size, which can propagate up the containing widget tree. add Pango into the mix, and that resetting is very costly. the same is not true of text entries, because they never resize based on their contents. evolution, sodipodi (the precursor to inkscape) and a few other projects have implimented their own labels that do not do this, for precisely the reason you are now discovering. (i would have replied sooner, but was away in berlin at the linux audio conference with no email access or time) --p ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Save Dialog
I use Inkscape and posted a request on their list, they referred me to your list as the save dialog they use is GTK. So, I wanted to know if it was possible to change the save dialog so that, when you create a new subfolder, you are automaically entered into that folder. i.e. If I create a subfolder and name it 'New', once I enter to accept the new name the directory structure places me into the 'New' folder to name and save the document. Thanks, Tony ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Possible bug when rendering 'r' in DejaVu Sans
I've been seeing this for a while, I'm not sure if it's a bug and if so,
in which component (Pango, FreeType, font maintainers?). The letter
'r', when rendered many times in succession, is placed at irregular
intervals. This seems to occur only when using the "DejaVu Sans" font,
but this font is the default choice for "application font" (used in text
fields and labels) of modern Linux distributions.
You can test this by creating a label containing the string
"rrr...", such as with this one-liner:
python -c 'import
gtk;w=gtk.Window();w.add(gtk.Label("r"*50));w.show_all();gtk.main()'
The attached image shows the problem as seen on my system: every fourth
'r' is placed closer to the preceding letter, as if misplaced by a
rounding error.
It is baffling that this only seems to occur when GTK+ renders text
using the "DejaVu Sans" font. If you choose another font, 'r' gets
rendered correctly. If you use the Qt or Firefox[1] renderer, it also
shows correctly. I was able to repeat this on GTK+ 2.10.6 and on GTK+
2.10.11. Changing antialiasing settings had no effect.
[1]
You can test Firefox's renderer using something like
r
x.png
Description: PNG image
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
