Re: Move to LGPL3
On Fri, Mar 28, 2008 at 1:09 PM, Vincent Untz <[EMAIL PROTECTED]> wrote: > (cc'ing Luis) > > Le mercredi 19 mars 2008, à 02:14 +, Alberto Ruiz a écrit : > > But for this kind of issues, I suggest to ask for help to the foundation > for > > legal advisory here, licenses are not that much about personal > > interpretation, but effective transposition into each countries' laws and > > stuff like that. I feel that the only way to make sure we don't mess this > up > > is having proper consultancy about what can be done, and what can't be > done. > > Replying a bit late, but of course, the Foundation would be happy to > help here. Luis can have a phone meeting with a few people to discuss > all this, or we can transmit legal questions to lawyers, etc. > > So basically, if help is needed on this topic, just ask :-) Yup! That's what I'm here for; I'd be happy to try to get answers [IANALY!] to any questions. [Note that I'm not on gtk-devel anymore, so please cc me or write me directly.] Luis ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkPerf [was: gtk performance testing]
Kaj- One feature that would be really nice is to make it possible to run 'hands off'. So... (1) it would need to take the number of repetitions from the command line, and not require clicking 'start' to start the tests. (2) output on the command line, ideally with the output being comma-separated instead of the current format. That would make it possible for me to run the tests in an automated, predictable fashion and record the results. Fix me these things and it is quite possible it wouldbe run nightly on gtk. Oh, also, it would be nice (not really that important) if it output the theme, gtk version, and other relevant library details in the report. That is definitely a would-be-nice, though. thanks for the tool- hope you find more time to work on it- Luis On 7/19/05, Kaj Grönholm <[EMAIL PROTECTED]> wrote: > Hello all, > > I'm the developer of GtkPerf (http://gtkperf.sf.net) and just realized (thanks > Clemens!) that you guys have been talking about GTK+ performance few weeks ago > and used also GtkPerf! > > So, I still understand that benchmarking tools such as this only suit to some > high-level testing and collecting numbers in specific environments. But I > would > like to get some insider information from you how GtkPerf could better test > the > speed user experiences with GTK+ applications? And also offer my > (work-limited) > help on tuning GtkPerf in the direction which could help more the actual GTK+ > development. Any ideas? > > > - Kaitsu - > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTKVTS question
On 8/11/05, Banginwar, Rajesh <[EMAIL PROTECTED]> wrote: > Thanks Luis. > > I am still trying to get answers from GTKVTS maintainers. Hopefully will > get some response soon. > > Another interest I had was to explore the feasibility of VTS usefulness > to GTK community. We are working towards completing it to current GTK > release. Once we do that, will GTK community be interested in using it? I admit to a complete lack of familiarity with gtk-vts and TET, except that it was mentioned several times when I too was contracting with Sun :) What mechanisms does gtkvts work by? I'm interested in LDTP and other test tools that work via the accessibility layer to test whole applications, but I admit to nearly complete lack of knowledge when it comes to testing of GUI *libraries*, and I'm curious to learn what you all have in mind. Luis ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTKVTS question
On 8/11/05, Banginwar, Rajesh <[EMAIL PROTECTED]> wrote: > I am resending part of my earlier question here. I am trying to > assess the usefulness of GTKVTS project to GTK community for regression or > other kind of testing. We are using it for LSB runtime testing when we add > GTK library set to LSB. To the best of my knowledge, gtkvts was never used by anyone outside of Sun [The spb.su authors were Sun contractors, I believe.] And as you can see by the CVS history, it has not been modified in over a year. So it is not likely anyone here has a good answer to your question, unfortunately- I would strongly recommend emailing [EMAIL PROTECTED] (the last committer to the project) to ask if they still use it and what they would recommend. > Also, we will really appreciate any information regarding the licensing of > this project. Are we expected (or required) to check in all our > changes/updates back to the GTK CVS? Option we were considering was to make > a copy of this project in LSB CVS and put our changes there. Any help or > suggestions here will be appreciated. Have you tried emailing the maintainers and asking about the license? http://cvs.gnome.org/viewcvs/*checkout*/gtkvts/MAINTAINERS Hope this helps- sorry that there is not a better answer at this point in time- Luis ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
broken build?
At least here, I can't build gtk ATM- looks like the changes to gdk.symbols creates an invalid gdkalias.h: In file included from gdkasync.c:53: ../../gdk/gdkalias.h:2383:2: error: #endif without #if In file included from gdkasync.c:730: ../../gdk/gdkaliasdef.c:2386:2: error: #endif without #if make[4]: *** [gdkasync.lo] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Luis, your friendly build bitch ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK VTS project update
On 7/31/05, Banginwar, Rajesh <[EMAIL PROTECTED]> wrote: > Hello, > To recap earlier discussion on this topic here, we (LSB WG) have > started looking at GTKVTS project (from GTK CVS) for our runtime > testing. We are currently getting it up to date and will start adding > remaining test cases. Currently the project covers only the libgtk > library partially. We will add coverage for other GTK+ libraries and > complete the libgtk coverage further. > > Does GTK+ community have interest in using this project as their > regression or other type of testing? What other test suites are > available which potentially can be used by LSB? You may wish to look at the 'ldtp' project, based out of the gnome bangalore/novell group: http://gnomebangalore.org/ldtp/ I understand there is also a third group working on a testing suite using the a11y framework, but I have not yet seen public information from them. Luis ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
cairo theme engines?
Hey... as I was putting together the demo livecd for the next release, it struck me that I can't really demo the cairo stuff in gtk much, besides the color picker :) Is there a publicly released cairo-using theme engine somewhere that I could build and ship as something to show off? (Presumably not the default.) Thanks- Luis ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: interpreting make check results?
On 7/14/05, Owen Taylor <[EMAIL PROTECTED]> wrote: > On Thu, 2005-07-14 at 15:24 -0400, Luis Villa wrote: > > So, I turned on make check in tinderbox today, and I'm learning all > > kinds of 'exciting' things. :) gtk+'s excitement today: > > > > make[4]: Entering directory `/home/bb/microtinder/cvs/gtk+/gtk' > > --- expected-abi 2005-07-14 15:19:22.737194592 -0400 > > +++ actual-abi2005-07-14 15:19:26.800576864 -0400 > > @@ -2423,6 +2423,7 @@ > > gtk_tree_row_reference_copy > > gtk_tree_row_reference_deleted > > gtk_tree_row_reference_free > > +gtk_tree_row_reference_get_model > > gtk_tree_row_reference_get_path > > gtk_tree_row_reference_get_type > > gtk_tree_row_reference_inserted > > @@ -2521,6 +2522,7 @@ > > gtk_tree_view_column_new_with_attributes > > gtk_tree_view_column_pack_end > > gtk_tree_view_column_pack_start > > +gtk_tree_view_column_queue_resize > > gtk_tree_view_columns_autosize > > gtk_tree_view_column_set_alignment > > gtk_tree_view_column_set_attributes > > @@ -2573,6 +2575,7 @@ > > gtk_tree_view_get_selection > > gtk_tree_view_get_type > > gtk_tree_view_get_vadjustment > > +gtk_tree_view_get_visible_range > > gtk_tree_view_get_visible_rect > > gtk_tree_view_insert_column > > gtk_tree_view_insert_column_with_attributes > > FAIL: abicheck.sh > > === > > 1 of 1 tests failed > > Please report to http://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B > > === > > > > What does this mean, exactly? Should i|tinderbox be ignoring it? > > reporting it religiously as a bug? Should it be expected to happen on > > a semi-regular basis? > > These indicate that someone added public functions and forgot to update > gtk.symbols. OK, so there is an expectation that this will always work. > These failures tend to get caught when we do 'make distcheck', but > filing them would still be appreciated ... if we regularly thwap people > who don't update gtk.symbols, hopefully we can avoid having problems > like this very often. OK, sounds like a plan. Will do. Is someone fixing this one or should I file now? Luis ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
interpreting make check results?
So, I turned on make check in tinderbox today, and I'm learning all kinds of 'exciting' things. :) gtk+'s excitement today: make[4]: Entering directory `/home/bb/microtinder/cvs/gtk+/gtk' --- expected-abi2005-07-14 15:19:22.737194592 -0400 +++ actual-abi 2005-07-14 15:19:26.800576864 -0400 @@ -2423,6 +2423,7 @@ gtk_tree_row_reference_copy gtk_tree_row_reference_deleted gtk_tree_row_reference_free +gtk_tree_row_reference_get_model gtk_tree_row_reference_get_path gtk_tree_row_reference_get_type gtk_tree_row_reference_inserted @@ -2521,6 +2522,7 @@ gtk_tree_view_column_new_with_attributes gtk_tree_view_column_pack_end gtk_tree_view_column_pack_start +gtk_tree_view_column_queue_resize gtk_tree_view_columns_autosize gtk_tree_view_column_set_alignment gtk_tree_view_column_set_attributes @@ -2573,6 +2575,7 @@ gtk_tree_view_get_selection gtk_tree_view_get_type gtk_tree_view_get_vadjustment +gtk_tree_view_get_visible_range gtk_tree_view_get_visible_rect gtk_tree_view_insert_column gtk_tree_view_insert_column_with_attributes FAIL: abicheck.sh === 1 of 1 tests failed Please report to http://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B === What does this mean, exactly? Should i|tinderbox be ignoring it? reporting it religiously as a bug? Should it be expected to happen on a semi-regular basis? Luis ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On 6/14/05, Vincent Untz <[EMAIL PROTECTED]> wrote: > Le mardi 14 juin 2005 à 11:57 +0200, Sebastien Bacher a écrit : > > Le vendredi 10 juin 2005 à 13:10 -0400, Luis Villa a écrit : > > > > > Each of the major distributors could > > > (should?) package 2.7.0 > > > > I've put .deb packages (i386) of the current pango/gtk CVS for Ubuntu > > here: > > "deb http://people.ubuntu.com/~seb128/gtk ./" > > Fantastic! > Do you think that asking breezy users to try it on the Ubuntu forums > and/or mailing lists is appropriate? Might be worth waiting for http://bugzilla.gnome.org/show_bug.cgi?id=306216 to be fixed before pimping it too widely? Luis (using it now) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
OT historical background [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/12/05, Jeff Waugh <[EMAIL PROTECTED]> wrote: > > > > > For non-local servers without Render, Cairo will allow us to eliminate > > > the round-trips... a huge win. > > > > "Show me the money!" > > Morten, I can understand your frustration, but to abuse some more movie > quotes: Your tone was pretty bogus, and we should all be excellent to each > other, regardless of any day-to-day hacking gripes we may have. Ob. IMDB backgrounder link for those who inexplicably did not grow up in the 80s: http://www.imdb.com/title/tt0096928/quotes Luis ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On 6/10/05, Owen Taylor <[EMAIL PROTECTED]> wrote: > On Fri, 2005-06-10 at 10:21 -0400, Luis Villa wrote: > > > But the last time we rushed out a gtk-gnome paired release, and got > > ourselves locked into the new APIs so that we couldn't back out, the > > result was that any distro actually paying attention would have > > noticed that our 'latest stable set' was *not actually stable* by our > > normal standards. *That* undermined the release process (or should > > have, if people paid attention, which it turns out they don't.) If we > > don't ship 2.8, it should be because our collective experience and our > > testing data is telling the distros this is not yet ready for prime > > time. By not shipping 2.8, we're not asking them to figure out what > > the latest stable set is- we're telling them what the latest stable > > set is, and telling them that gtk 2.8 is not part of that, because it > > is not likely to be stable, given our experience. If distros want to > > overrule that, that's fine, but honestly, aes, elijah, bkor, kmaraas > > and I know a fuck of a lot more about the stability of GNOME than any > > of the distros do*, so if they want to overrule that, that is their > > own problem. > > It's *not up to the GNOME release team* to say > when a GTK+ release is stable. That's up to the GTK+ team. I think > our general take on that is that the day we release 2.8.0 we > are committed to ABI and API stability, As an aside, when I say 'stable', I mean 'reliable for users', not 'API stable for developers', and maybe that is part of the confusion of this thread. I expect GNOME .0s to be both stable (in your sense) and reliable (in mine.) GTK 2.4.0 was stable in your sense, but not reliable in mine, and that is why release team is wary of telling people that a gnome .0 based on gtk 2.8.0 would be reliable. > but our general expectation > from past experience is that we do find and fix significant numbers of > bugs in the first few maintenance releases after that. > > But the GNOME release team has *no* ability to say "don't ship GTK > +-2.8.x until we release GNOME-2.14." I'm not claiming we do or should. You get to release .0 whenever you want, and users get to use it whenever they want. Release-team gets to say when they think it is reliable, and hence worthy of being part of GNOME. Ideally your .0 and our .0 should have the same qualities, but in our past experience they have not. This whole conversation is unfortunately sounding very hostile, which was not my intent. Let me try to back it down a little bit and get it back to the first principles, explain why (IMHO) gtk 2.4.0 was not reliable enough for GNOME 2.6.0, and see if/where/when we can compromise from those. With GTK 2.4.0 and GNOME 2.6.0, 2.4.0 was not stable, and apps all over the desktop crashed, which made GNOME 2.6.0 look bad. This didn't happen with GNOME 2.10, mainly IMHO because 2.6.0 was released a full three months before GNOME 2.10 was, allowing for extensive testing and several GTK point releases. Avoiding a repeat of this very difficult problem is my primary concern. GNOME generally avoids this with three big strategies: * avoid entanglements and only release things that are ready: we look at apps case by case and if necessary reject them if they aren't ready on our timeline[1]. This only works if the apps do not provide API to other parts of GNOME, or if their API has not changed. Unfortunately, this can't be the case for GTK- we must be entangled for good testing to happen, so we can't just get to september and say 'gtk isn't ready, punt it.' This means that if we choose to go with gtk 2.8.x, 2.8.x *must* be rock-solid stable at the GNOME 2.12.0 date, we have to punt apps that have upgraded their deps to 2.8.x, or we have to slip. (Or we can ship a .0 we're not happy with, but I'd like to think that isn't an option.) * aggressive freeze schedules: we freeze early, and ask for early releases. As has been pointed out, this does reduce features in favor of stability. * extensive testing: while we've been doing a poorer job of this than we used to, we still rely heavily on extensive testing of unstable releases to make our .0 releases as stable as possible. Because people are nervous about testing gtk, we know it gets less testing than other parts of the stack, even though it needs it more. So, options as I see them: * don't depend on gtk 2.8. This is suboptimal for all of us, in that gtk gets less testing, is less stable, etc., but goes a long way towards guaranteeing a reliable platform for GNOME 2.12 development and deployment, which is important for everyone. * tentatively depend on 2.8, and if 2.8 is not reliable wh
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On 6/10/05, Mark McLoughlin <[EMAIL PROTECTED]> wrote: > On Thu, 2005-06-09 at 19:00 -0400, Owen Taylor wrote: > > > - To be realistic, if GNOME-2.12 is released after GTK+-2.8, > > most distributors are going to ship using them together. > > > > So, the release team could decide to go with 2.6 even with > > the current GTK+ schedule, but the result then would be less > > testing of what people actually ship. > > Yeah, and that would significantly undermine the whole release process > IMHO. If the value of having GNOME releases is to have the very latest > GNOME technologies released as a stable, coherent and integrated set, > then by creating a situation where distributors go off for themselves > and figure out what *really* is the latest stable set of GNOME > technologies, we really reduce the relevance of GNOME releases. I'm all in favor of getting 2.7 tested and released, and I think we should push hard to test it with 2.11. That'll obviously help it get better, and fast. But the last time we rushed out a gtk-gnome paired release, and got ourselves locked into the new APIs so that we couldn't back out, the result was that any distro actually paying attention would have noticed that our 'latest stable set' was *not actually stable* by our normal standards. *That* undermined the release process (or should have, if people paid attention, which it turns out they don't.) If we don't ship 2.8, it should be because our collective experience and our testing data is telling the distros this is not yet ready for prime time. By not shipping 2.8, we're not asking them to figure out what the latest stable set is- we're telling them what the latest stable set is, and telling them that gtk 2.8 is not part of that, because it is not likely to be stable, given our experience. If distros want to overrule that, that's fine, but honestly, aes, elijah, bkor, kmaraas and I know a fuck of a lot more about the stability of GNOME than any of the distros do*, so if they want to overrule that, that is their own problem. Luis *except JDS ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/10/05, Alexander Larsson <[EMAIL PROTECTED]> wrote: > On Fri, 2005-06-10 at 09:40 -0400, Luis Villa wrote: > > On 6/10/05, Luis Villa <[EMAIL PROTECTED]> wrote: > > > > > I haven't seen this announced on gtk-devel or here, so: > > > > > > > > > > http://gtkperf.sourceforge.net/ > > > > > > > > > > Apparently this is a test tool to test gtk performance. Would be great > > > > > to have someone test 2.7 with it. > > > > > > > > Went ahead and did it myself. TextView is brutally slower (300-400%), > > > > some other things are 25-30% slower, and some things actually get > > > > faster. Disclaimer: I'm pretty sure I did this right and I'm linking > > > > against the right stuff, but these numbers should be confirmed by an > > > > expert, and I can't speak to the validity of the tool's measurements > > > > itself, except to note that scrolling in a textview area is *visibly* > > > > slower. > > > > > > New third column is HEAD + glitz, with an x31's ATI card. > > > > Someone larted me on IRC and informed me that it is likely that glitz > > wasn't actually being used. So take these with an even bigger grain of > > salt than my last set. I would love to know how one can (1) know for > > certain glitz is being used and/or (2) how to force glitz to be used > > so that I can do a quickie hack to automate this. > > > > Total time: 253.31 565.94 647.60 > > The question is: Why did you get different times then? Very good question. I tried to kill anything particularly CPU-consuming, and in all cases stopped using the machine during the test, so I don't *think* that is a factor, but it could have been- it's not like I was running this on a perfectly-controlled test box. (Which I'd like to do, as part of the tinderboxing, whenever someone gets me a box to tinder on :) Luis ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/10/05, Luis Villa <[EMAIL PROTECTED]> wrote: > > > I haven't seen this announced on gtk-devel or here, so: > > > > > > http://gtkperf.sourceforge.net/ > > > > > > Apparently this is a test tool to test gtk performance. Would be great > > > to have someone test 2.7 with it. > > > > Went ahead and did it myself. TextView is brutally slower (300-400%), > > some other things are 25-30% slower, and some things actually get > > faster. Disclaimer: I'm pretty sure I did this right and I'm linking > > against the right stuff, but these numbers should be confirmed by an > > expert, and I can't speak to the validity of the tool's measurements > > itself, except to note that scrolling in a textview area is *visibly* > > slower. > > New third column is HEAD + glitz, with an x31's ATI card. Someone larted me on IRC and informed me that it is likely that glitz wasn't actually being used. So take these with an even bigger grain of salt than my last set. I would love to know how one can (1) know for certain glitz is being used and/or (2) how to force glitz to be used so that I can do a quickie hack to automate this. > Still with > Mist. Performance is slightly slower than HEAD just about everywhere, > actually. I'll probably do an N=100 run with default theme + > 2.6/HEAD/HEAD + glitz sometime later. Have to figure out how to > automate this. :) > > The data: > > GtkEntry - time: 0.43 0.76 0.89 > GtkComboBox - time: 12.61 15.30 15.11 > GtkComboBoxEntry - time: 11.95 13.25 13.36 > GtkSpinButton - time: 0.65 1.09 1.17 > GtkProgressBar - time: 0.53 0.87 0.99 > GtkToggleButton - time: 2.17 4.42 4.47 > GtkCheckButton - time: 3.41 3.27 3.37 > GtkRadioButton - time: 4.29 3.96 4.10 > GtkTextView - Add text - time: 91.88 268.67 311.53 > GtkTextView - Scroll - time: 43.17 190.83 229.29 > GtkDrawingArea - Lines - time: 8.40 8.48 8.39 > GtkDrawingArea - Circles - time: 13.38 13.58 13.42 > GtkDrawingArea - Text - time: 48.70 29.99 30.34 > GtkDrawingArea - Pixbufs - time: 11.71 11.46 11.16 > --- > Total time: 253.31 565.94 647.60 > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/9/05, Luis Villa <[EMAIL PROTECTED]> wrote: > On 6/9/05, Luis Villa <[EMAIL PROTECTED]> wrote: > > On 6/9/05, Jon K Hellan <[EMAIL PROTECTED]> wrote: > > > On Thu, 2005-06-09 at 14:39 +0100, Mark McLoughlin wrote: > > > > If we're talking about performance/stability in the context of > > > > whether > > > > GNOME 2.12 should use GTK+ 2.8, we're effectively saying "I think the > > > > GTK+ team might ship a unstable or unacceptably slow 2.8.0 release; > > > > GNOME shouldn't commit to using GTK+ 2.8 yet". I would hope that we > > > > would have more confidence in the judgement of the GTK+ team than that. > > > > > > Crashes and performance are very different types of problem. Crashes get > > > fixed once they can be reproduced. Fixing bad performance can take a > > > long time. > > > > > > Well, I haven't tested gtk2.7 since just after Cairo got added, so I > > > can't tell whether there is a performance problem. Has anybody got > > > numbers? > > > > I haven't seen this announced on gtk-devel or here, so: > > > > http://gtkperf.sourceforge.net/ > > > > Apparently this is a test tool to test gtk performance. Would be great > > to have someone test 2.7 with it. > > Went ahead and did it myself. TextView is brutally slower (300-400%), > some other things are 25-30% slower, and some things actually get > faster. Disclaimer: I'm pretty sure I did this right and I'm linking > against the right stuff, but these numbers should be confirmed by an > expert, and I can't speak to the validity of the tool's measurements > itself, except to note that scrolling in a textview area is *visibly* > slower. New third column is HEAD + glitz, with an x31's ATI card. Still with Mist. Performance is slightly slower than HEAD just about everywhere, actually. I'll probably do an N=100 run with default theme + 2.6/HEAD/HEAD + glitz sometime later. Have to figure out how to automate this. :) The data: GtkEntry - time: 0.43 0.76 0.89 GtkComboBox - time: 12.61 15.30 15.11 GtkComboBoxEntry - time: 11.95 13.25 13.36 GtkSpinButton - time: 0.65 1.09 1.17 GtkProgressBar - time: 0.53 0.87 0.99 GtkToggleButton - time: 2.17 4.42 4.47 GtkCheckButton - time: 3.41 3.27 3.37 GtkRadioButton - time: 4.29 3.96 4.10 GtkTextView - Add text - time: 91.88 268.67 311.53 GtkTextView - Scroll - time: 43.17 190.83 229.29 GtkDrawingArea - Lines - time: 8.40 8.48 8.39 GtkDrawingArea - Circles - time: 13.38 13.58 13.42 GtkDrawingArea - Text - time: 48.70 29.99 30.34 GtkDrawingArea - Pixbufs - time: 11.71 11.46 11.16 --- Total time: 253.31 565.94 647.60 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/9/05, Jon K Hellan <[EMAIL PROTECTED]> wrote: > On Thu, 2005-06-09 at 10:49 -0400, Luis Villa wrote: > > first 'column' of times is gtk 2.6, second is gtk/cairo HEAD of > > yesterday, both with the Mist theme: > > > > GtkEntry - time: 0.43 0.76 > > GtkComboBox - time: 12.61 15.30 > > GtkComboBoxEntry - time: 11.95 13.25 > > GtkSpinButton - time: 0.65 1.09 > > GtkProgressBar - time: 0.53 0.87 > > GtkToggleButton - time: 2.17 4.42 > > GtkCheckButton - time: 3.41 3.27 > > GtkRadioButton - time: 4.29 3.96 > > GtkTextView - Add text - time: 91.88 268.67 > > GtkTextView - Scroll - time: 43.17 190.83 > > GtkDrawingArea - Lines - time: 8.40 8.48 > > GtkDrawingArea - Circles - time: 13.38 13.58 > > GtkDrawingArea - Text - time: 48.70 29.99 > > GtkDrawingArea - Pixbufs - time: 11.71 11.46 > > --- > > Total time: 253.31 565.94 > > I should have mentioned that this was with N=1000; jkh, I'm assuming you did the default n=100? > Here are my numbers. The tendency is the same. I'm comparing the head of > the 2.6 branch in cvs with HEAD. Both locally compiled with the same > jhbuild setup. Default theme. > > Gtk branch 2.6 HEAD > > time time > GtkEntry 0.04 0.07 > GtkComboBox 1.11 1.51 > GtkComboBoxEntry 0.99 1.17 > GtkSpinButton0.07 0.11 > GtkProgressBar 0.04 0.09 > GtkToggleButton 0.21 0.41 > GtkCheckButton 0.34 0.44 > GtkRadioButton 0.41 0.65 > GtkTextView - Add text 1.62 2.82 > GtkTextView - Scroll 0.34 1.39 > GtkDrawingArea - Lines 0.54 0.49 > GtkDrawingArea - Circles 1.22 1.08 > GtkDrawingArea - Text3.98 5.05 > GtkDrawingArea - Pixbufs 1.23 1.00 > --- --- > Total time: 12.16 16.27 > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/9/05, Luis Villa <[EMAIL PROTECTED]> wrote: > On 6/9/05, Jon K Hellan <[EMAIL PROTECTED]> wrote: > > On Thu, 2005-06-09 at 14:39 +0100, Mark McLoughlin wrote: > > > If we're talking about performance/stability in the context of > > > whether > > > GNOME 2.12 should use GTK+ 2.8, we're effectively saying "I think the > > > GTK+ team might ship a unstable or unacceptably slow 2.8.0 release; > > > GNOME shouldn't commit to using GTK+ 2.8 yet". I would hope that we > > > would have more confidence in the judgement of the GTK+ team than that. > > > > Crashes and performance are very different types of problem. Crashes get > > fixed once they can be reproduced. Fixing bad performance can take a > > long time. > > > > Well, I haven't tested gtk2.7 since just after Cairo got added, so I > > can't tell whether there is a performance problem. Has anybody got > > numbers? > > I haven't seen this announced on gtk-devel or here, so: > > http://gtkperf.sourceforge.net/ > > Apparently this is a test tool to test gtk performance. Would be great > to have someone test 2.7 with it. Went ahead and did it myself. TextView is brutally slower (300-400%), some other things are 25-30% slower, and some things actually get faster. Disclaimer: I'm pretty sure I did this right and I'm linking against the right stuff, but these numbers should be confirmed by an expert, and I can't speak to the validity of the tool's measurements itself, except to note that scrolling in a textview area is *visibly* slower. The data: first 'column' of times is gtk 2.6, second is gtk/cairo HEAD of yesterday, both with the Mist theme: GtkEntry - time: 0.43 0.76 GtkComboBox - time: 12.61 15.30 GtkComboBoxEntry - time: 11.95 13.25 GtkSpinButton - time: 0.65 1.09 GtkProgressBar - time: 0.53 0.87 GtkToggleButton - time: 2.17 4.42 GtkCheckButton - time: 3.41 3.27 GtkRadioButton - time: 4.29 3.96 GtkTextView - Add text - time: 91.88 268.67 GtkTextView - Scroll - time: 43.17 190.83 GtkDrawingArea - Lines - time: 8.40 8.48 GtkDrawingArea - Circles - time: 13.38 13.58 GtkDrawingArea - Text - time: 48.70 29.99 GtkDrawingArea - Pixbufs - time: 11.71 11.46 --- Total time: 253.31 565.94 HTH- Luis ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk performance testing [was Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)]
On 6/9/05, Jon K Hellan <[EMAIL PROTECTED]> wrote: > On Thu, 2005-06-09 at 14:39 +0100, Mark McLoughlin wrote: > > If we're talking about performance/stability in the context of whether > > GNOME 2.12 should use GTK+ 2.8, we're effectively saying "I think the > > GTK+ team might ship a unstable or unacceptably slow 2.8.0 release; > > GNOME shouldn't commit to using GTK+ 2.8 yet". I would hope that we > > would have more confidence in the judgement of the GTK+ team than that. > > Crashes and performance are very different types of problem. Crashes get > fixed once they can be reproduced. Fixing bad performance can take a > long time. > > Well, I haven't tested gtk2.7 since just after Cairo got added, so I > can't tell whether there is a performance problem. Has anybody got > numbers? I haven't seen this announced on gtk-devel or here, so: http://gtkperf.sourceforge.net/ Apparently this is a test tool to test gtk performance. Would be great to have someone test 2.7 with it. Luis ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On 6/8/05, Luis Villa <[EMAIL PROTECTED]> wrote: > On 6/8/05, Mark McLoughlin <[EMAIL PROTECTED]> wrote: > > Hey, > > I guess there's quite a few benefits/risks to be weighed up here: > > > > - The benefit of having cool new rendering stuff in GNOME 2.12 > > > > - The benefit of being able to use all the other new APIs in GTK+ > > 2.8 for GNOME 2.12 > > > > - The benefit of getting all this stuff tested early (i.e. before > > GTK+ 2.8 is released, rather than after) > > I'm all in favor of *testing* gtk 2.8 as much as possible now (so I > think it should be left in jhbuild), but I'm very nervous about > shipping with it at this point- we all know HEAD does not get as much > testing as it should, and gtk 2.8 seems like some very big changes > with potentially huge stability implications. Basically, unless Ubuntu > breezy starts shipping it, For the record, Seb has pointed out that he doesn't want to test it until release-team have committed to it for 2.12, for entirely reasonable reasons on his part. I'm more than happy to work with the gtk folks (and anyone else) to push testing heavily and deal with the results, FWIW, but that's Hard Work and our recent track record in pushing it without builds is poor. Luis ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On 6/8/05, Luis Villa <[EMAIL PROTECTED]> wrote: > On 6/8/05, Mark McLoughlin <[EMAIL PROTECTED]> wrote: > > Hey, > > I guess there's quite a few benefits/risks to be weighed up here: > > > > - The benefit of having cool new rendering stuff in GNOME 2.12 > > > > - The benefit of being able to use all the other new APIs in GTK+ > > 2.8 for GNOME 2.12 > > > > - The benefit of getting all this stuff tested early (i.e. before > > GTK+ 2.8 is released, rather than after) > > I'm all in favor of *testing* gtk 2.8 as much as possible now (so I > think it should be left in jhbuild), but I'm very nervous about > shipping with it at this point- we all know HEAD does not get as much > testing as it should, and gtk 2.8 seems like some very big changes > with potentially huge stability implications. Basically, unless Ubuntu > breezy starts shipping it, or Fedora makes a very active push to get > people to use it in Rawhide, I'm very nervous about shipping anything > we'd call a .0 linking against gtk 2.8. Oh, and after the last time we did this, the release team swore mighty oaths to never depend on a released-close-to-gnome-schedule GTK again, since it jeopardizes our release schedule for something that is less tested than the rest of the stack and which in many cases isn't widely used because developers haven't had time to integrate it. I suppose we could reconsider that, but we did it the last time for the same reasons Mark listed, more or less. As a result we had to delay our release and (speaking with my QA hat on) after .0 we still had to track down several issues in gtk that were caused by rushing out a component low-in-the-stack with insufficient real-world testing. So, yeah, I'm pretty strongly against this, though I'm open to persuasion. Luis ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GNOME 2.11/2.12 targeting GTK+ 2.8 (ie cairo based)
On 6/8/05, Mark McLoughlin <[EMAIL PROTECTED]> wrote: > Hey, > I guess there's quite a few benefits/risks to be weighed up here: > > - The benefit of having cool new rendering stuff in GNOME 2.12 > > - The benefit of being able to use all the other new APIs in GTK+ > 2.8 for GNOME 2.12 > > - The benefit of getting all this stuff tested early (i.e. before > GTK+ 2.8 is released, rather than after) I'm all in favor of *testing* gtk 2.8 as much as possible now (so I think it should be left in jhbuild), but I'm very nervous about shipping with it at this point- we all know HEAD does not get as much testing as it should, and gtk 2.8 seems like some very big changes with potentially huge stability implications. Basically, unless Ubuntu breezy starts shipping it, or Fedora makes a very active push to get people to use it in Rawhide, I'm very nervous about shipping anything we'd call a .0 linking against gtk 2.8. Luis > - The extra incentive for people to help with getting the rendering > stuff optimized > > vs. > > - The risk of the GTK+ 2.8 schedule slipping, causing a slip in the > GNOME 2.12 schedule > > - The risk that performance problems with the rendering stuff might > put some people off using GNOME 2.12 > > > Although I was pretty nervous about this too at first, the benefits > certainly seem to outweigh the risks when you spell them out like that. > > Cheers, > Mark. > > ___ > desktop-devel-list mailing list > desktop-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/desktop-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Recently Used Files Proposal
On 6/4/05, Emmanuele Bassi <[EMAIL PROTECTED]> wrote: > I was just saying that a menu, even if commonly used, might not be the > best way to convey the needed informations. That's fair. Like you say, things are often poorly named, etc., and we should certainly try to think outside the box to solve these problems. But you absolutely shouldn't dismiss the simple, common case and overcomplicate it just because sometimes there are other problems. Those problems are not as common as the core problem, and as others have pointed out, there are much simpler ways to disambiguate. [By the way, please don't let me discourage you- despite my disagreements with the proposed UI design we *must* have the infrastructure before any solution goes forward, and a good infrastructure that covers your use cases will let us do a variety of possible solutions and see what fits best.] Luis ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Recently Used Files Proposal
On 6/3/05, Emmanuele Bassi <[EMAIL PROTECTED]> wrote: > Hi, > > On Fri, 2005-06-03 at 03:46 +0400, Nickolay V. Shmyrev wrote: > > > > A menu would never give enough informations on the recently used > > > items: apart from an icon associated to the mime type, we won't know > > > their location, or when they were accessed; so, given that we should > > > provide a tooltip for each item (with an API for adding custom text, > > > maybe), a menu could be also implemented. > > > > > > > Emmanuele, really the best way to provide access to recent items in > > application is menu. > > Even if I could agree, I'm still skeptical about this. A menu is what > it is used on some platforms, but I don't know if it's indeed the best > way to provide all the data we need to know about a recently used > resource. You're thinking this way, I'd suggest, because your use cases are overly complicated. Consider this ridiculously common use case: * I want to open a file that I know I saved in the recent past. That's it. Very simple, very common. Currently, I can open one menu (Places->Recent Documents) and 'solve' that user problem. Covering that use case is the whole point of every recent file menu on every OS. People don't care what month it was opened, or what day it was opened, they just know that they opened it in the recent past, and they want to open it again without digging into crappy FS heirarchies. Covering the more complex user problems is nice, but if you make it too hard to solve this very basic need, you've defeated the point for most users. Luis > Consider web browsing; Firefox, Epiphany, Internet Explorer - all show > the history as a side pane containing a treeview, with each page that > has been visited put it into a treeview. > > What I am suggesting basically is creating the concept of a "resource > history", showing what resources the user has recently openend; and if > the panel registered the menu items it launches, we could also have the > recently used applications, for instance. > > > The main idea of recent file is to allow open new > > file without dialog, while you suggestion is to replace one complex > > dialog (FileChooser) with another one (RecentChooser). > > The idea is to offer a set of widgets - a dialog, a button, whatever - > in order to access this data. > > The GtkFileChooser could register an item in save mode, and show the > recently used items in open mode, so we could scrap the entire "Open > recent..." menu item altogether, and just use the "Open..." menuitem; it > could be a viable solution. But this does not mean that we should not > provide some other way to access this data. > > Kind regards, > Emmanuele. > > > > -- > Emmanuele Bassi <[EMAIL PROTECTED]> > Web site: http://log.emmanuelebassi.net > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
