Re: Supporting Gtk+ Maintenance
On 3/23/07, Behdad Esfahbod <[EMAIL PROTECTED]> wrote: > Setting bugs with outdated patches to needinfo may be a bit problematic > as the bugsquad team has a tendency to close needinfo bugs after some > time... Also they won't show in some default search queries.. Just > removing the patch keyword, or marking the patch as needs-work may be > better, but that's just my idea. Obviously the objective it to get this anomoly to the patch submitter's attention. But as Behdad you just said.. then whats the best way to go about it? One option I see is to re-assign the bug to this patch submitter & once he resubmits a working patch, re-assign it to the gtk-bugs list. Would that be good enough? :) Makuchaku ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Supporting Gtk+ Maintenance
On Fri, 2007-03-23 at 15:42 +0530, मयंक जैन (makuchaku) wrote: > On 3/23/07, Behdad Esfahbod <[EMAIL PROTECTED]> wrote: > > Setting bugs with outdated patches to needinfo may be a bit problematic > > as the bugsquad team has a tendency to close needinfo bugs after some > > time... Also they won't show in some default search queries.. Just > > removing the patch keyword, or marking the patch as needs-work may be > > better, but that's just my idea. > > Obviously the objective it to get this anomoly to the patch > submitter's attention. But as Behdad you just said.. then whats the > best way to go about it? > > One option I see is to re-assign the bug to this patch submitter & > once he resubmits a working patch, re-assign it to the gtk-bugs list. > > Would that be good enough? The submitters gets mail about all changes to the bug (by default). So no real need to do anything specific. Just marking as needs-work and a two line comment about the patch status should be enough. Assigning to him may work better as he will see it in his bug page, but note that other people can update an outdated patch too, and many times do. > :) > Makuchaku -- behdad http://behdad.org/ "Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin, 1759 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK+ 2.12 schedule?
Could we agree on a schedule for GTK+ 2.12, please? I'd really like to know for sure that it will be ready for GNOME 2.20. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: ideas on improving the performance of gtk_tree_view
On Thu, Mar 22, 2007 at 08:18:14PM +0200, Tommi Komulainen wrote: > On 3/22/07, Kalle Vahlman <[EMAIL PROTECTED]> wrote: > > 2007/3/22, Yevgen Muntyan <[EMAIL PROTECTED]>: > > > > > > IIRC reusing single cell renderer in multiple columns was declared > > > broken and unsupported (because it was broken). Is this correct? Yes, a single cell renderer is not supposed to be used in multiple columns. Of couse you might get lucky and it works more or less. > > Maybe there are specific cell renderers that are broken? > > As I understood it, it is "broken" if you do not set the same set of > attributes on each column. Try mapping text and font weight on one > column, and just text on another column and see what happens ;-) That's one really good example of how things will break. And you also already provided a way to work around it :) For the record I am not planning on fixing any new bugs which show up because of using a single cell renderer in multiple columns. Maybe we should guard for reusing a cell renderer multiple times in a later version of GTK+. regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: ideas on improving the performance of gtk_tree_view
2007/3/23, Kristian Rietveld <[EMAIL PROTECTED]>: > On Thu, Mar 22, 2007 at 08:18:14PM +0200, Tommi Komulainen wrote: > > On 3/22/07, Kalle Vahlman <[EMAIL PROTECTED]> wrote: > > > 2007/3/22, Yevgen Muntyan <[EMAIL PROTECTED]>: > > > > > > > > IIRC reusing single cell renderer in multiple columns was declared > > > > broken and unsupported (because it was broken). Is this correct? > > Yes, a single cell renderer is not supposed to be used in multiple > columns. Of couse you might get lucky and it works more or less. > > > > Maybe there are specific cell renderers that are broken? > > > > As I understood it, it is "broken" if you do not set the same set of > > attributes on each column. Try mapping text and font weight on one > > column, and just text on another column and see what happens ;-) > > That's one really good example of how things will break. And you also > already provided a way to work around it :) For the record I am not > planning on fixing any new bugs which show up because of using a single cell > renderer in multiple columns. Maybe we should guard for reusing a cell > renderer multiple times in a later version of GTK+. And at minimum update the docs ASAP to note this. The paragraph I pasted had me at least thinking it doesn't matter at all where the renderer is used... -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: ideas on improving the performance of gtk_tree_view
On Thu, Mar 22, 2007 at 07:44:57PM +0100, Nicolas Setton wrote: > I'm not sure I understand this part: should I use a gtk_table to > display this kind of data? What is the preferred way to display this > kind of information (5000 columns x 50 rows) in Gtk+? The GtkTreeView > seemed the best approach to me. You want to use a sheet widget, which is unfortunately not in GTK+ at the moment (we should really have one at some point...). There are some "third-party" sheet widgets around, for example GtkExtra has one (http://gtkextra.sourceforge.net/). > Moreover, the GtkTreeView 'almost' supports this, so I think it would > be a shame to simply throw down our weapons so soon! See below for > suggestions. It would almost support displaying the data, but getting the behavior of a proper sheet widget right in GtkTreeView is a lot of work and would make the GtkTreeView even more complex, which is something I am not looking forward too. Then you also want to have a two dimensional data model instead of tree view's row-based one, etc. I think this really belongs in a separate widget. > This gives me an idea. > > Proposal (1): we give the user the possibility (through a property, > for instance) to deactivate keyboard navigation, in exchange for an > enormous gain of performance for big trees. I don't think introducing a property to deactivate keyboard navigation is a good idea; I absolutely do not want to go there. > Proposal (2): we give the user the possibility to tell the tree view > that the only way the data will change is through the model. When the > tree view is guaranteed this, it executes the loop on > gtk_tree_view_column_cell_set_cell_data only once in each model > change, and not once in every expose. You need to run gtk_tree_view_column_cell_set_cell_data() in every expose for every row to be rendered. Cell renderers can only hold the data for a single row. (And note that it is being called twice for each row in every expose right now because of the reused cell renderer/key navigation issue raised elsewhere in this thread). I appreciate the time you took to do some profiling and think about this; but unfortunately both ideas will not work. regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.12 schedule?
On Fri, Mar 23, 2007 at 01:45:11PM +0100, Murray Cumming wrote: > Could we agree on a schedule for GTK+ 2.12, please? I'd really like to Since nobody complained about the schedule we devised at FOSDEM and I mailed to the list in my minutes a few weeks ago, I guess that will be our current working schedule. > know for sure that it will be ready for GNOME 2.20. I personally object to guaranteeing that GTK+ 2.12 will be ready in time for GNOME 2.20. Yes, we should try to stick to a schedule everybody agrees with, but I don't want to rush out a release to be ready in time for GNOME 2.20, regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.12 schedule?
On Fri, 2007-03-23 at 15:01 +0100, Kristian Rietveld wrote: > On Fri, Mar 23, 2007 at 01:45:11PM +0100, Murray Cumming wrote: > > Could we agree on a schedule for GTK+ 2.12, please? I'd really like to > > Since nobody complained about the schedule we devised at FOSDEM and I mailed > to the list in my minutes a few weeks ago, I guess that will be our > current working schedule. > > > know for sure that it will be ready for GNOME 2.20. > > I personally object to guaranteeing that GTK+ 2.12 will be ready in time > for GNOME 2.20. Yes, we should try to stick to a schedule everybody > agrees with, but I don't want to rush out a release to be ready in time > for GNOME 2.20, Please let's try. It would be shame to have two GNOME releases with no new GTK+ features. My own eccentric reason for really wanting this is that I can't add API to gtkmm without a new 2.12 release, and I can't do that without a GTK+ 2.12 release, or things will get confusingly out-of-sync. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.12 schedule?
On Fri, 2007-03-23 at 15:25 +0100, Michael Natterer wrote: > On Fri, 2007-03-23 at 15:17 +0100, Murray Cumming wrote: > > On Fri, 2007-03-23 at 15:01 +0100, Kristian Rietveld wrote: > > > On Fri, Mar 23, 2007 at 01:45:11PM +0100, Murray Cumming wrote: > > > > Could we agree on a schedule for GTK+ 2.12, please? I'd really like to > > > > > > Since nobody complained about the schedule we devised at FOSDEM and I > > > mailed > > > to the list in my minutes a few weeks ago, I guess that will be our > > > current working schedule. > > > > > > > know for sure that it will be ready for GNOME 2.20. > > > > > > I personally object to guaranteeing that GTK+ 2.12 will be ready in time > > > for GNOME 2.20. Yes, we should try to stick to a schedule everybody > > > agrees with, but I don't want to rush out a release to be ready in time > > > for GNOME 2.20, > > > > Please let's try. It would be shame to have two GNOME releases with no > > new GTK+ features. > > It would be a shame to ship a broken GTK+ just because GNOME needs it, > just as it happened before. The goal should IMHO be to ship a GTK+ > that is as polished as possible within reasonable time, and *not* > to follow external release cycles that are partly driven by commercial > issues. That seems randomly anti-commerce to me. GNOME's release cycle isn't driven by commercial issues. It's an attempt to ship what is ready if it's ready, and to generally coordinate with other projects. GTK+ could use a similar strategy, I believe, though I agree that GTK+ bugs are far more critical than gnome-games bugs. So trying doesn't mean that we'd have to ship a broken GTK+. But GNOME would decide quite soon whether they think GTK+ is likely to manage it, and I don't think you need to worry about them being too optimistic. > > My own eccentric reason for really wanting this is that I can't add API > > to gtkmm without a new 2.12 release, and I can't do that without a GTK+ > > 2.12 release, or things will get confusingly out-of-sync. > > Where is the difference to GTK+ 2.10 depending on GLIB 2.12 > and Pango 1.14 ? gtkmm 2.x not wrapping stuff from GTK+ 2.x would be confusing. That's not GTK+'s fault. I'm just saying that that's what's important to me. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.12 schedule?
Murray Cumming wrote: > On Fri, 2007-03-23 at 15:25 +0100, Michael Natterer wrote: > >> On Fri, 2007-03-23 at 15:17 +0100, Murray Cumming wrote: >> >>> On Fri, 2007-03-23 at 15:01 +0100, Kristian Rietveld wrote: >>> On Fri, Mar 23, 2007 at 01:45:11PM +0100, Murray Cumming wrote: > Could we agree on a schedule for GTK+ 2.12, please? I'd really like to > Since nobody complained about the schedule we devised at FOSDEM and I mailed to the list in my minutes a few weeks ago, I guess that will be our current working schedule. > know for sure that it will be ready for GNOME 2.20. > I personally object to guaranteeing that GTK+ 2.12 will be ready in time for GNOME 2.20. Yes, we should try to stick to a schedule everybody agrees with, but I don't want to rush out a release to be ready in time for GNOME 2.20, >>> Please let's try. It would be shame to have two GNOME releases with no >>> new GTK+ features. >>> >> It would be a shame to ship a broken GTK+ just because GNOME needs it, >> just as it happened before. The goal should IMHO be to ship a GTK+ >> that is as polished as possible within reasonable time, and *not* >> to follow external release cycles that are partly driven by commercial >> issues. >> > > That seems randomly anti-commerce to me. GNOME's release cycle isn't > driven by commercial issues. It's an attempt to ship what is ready if > it's ready, and to generally coordinate with other projects. GTK+ could > use a similar strategy, I believe, though I agree that GTK+ bugs are far > more critical than gnome-games bugs. > > So trying doesn't mean that we'd have to ship a broken GTK+. But GNOME > would decide quite soon whether they think GTK+ is likely to manage it, > and I don't think you need to worry about them being too optimistic. If you agree to ship what is ready if it's ready, then why not just rely on the GTK+ 2.10 API and maybe release with GTK+ 2.12 (even if not using the new API)? Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ 2.12 schedule?
On Fri, 2007-03-23 at 15:40 +0100, Sven Herzberg wrote: > > So trying doesn't mean that we'd have to ship a broken GTK+. But GNOME > > would decide quite soon whether they think GTK+ is likely to manage it, > > and I don't think you need to worry about them being too optimistic. > If you agree to ship what is ready if it's ready, then why not just rely > on the GTK+ 2.10 API and maybe release with GTK+ 2.12 (even if not using > the new API)? That's effectively what would happen if GNOME said that they don't expect GTK+ 2.12 to be ready and then it suddenly was ready. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: ideas on improving the performance of gtk_tree_view
El jue, 22-03-2007 a las 16:55 +0100, Nicolas Setton escribió: Hi, Nicolas, Thanks for taking the time to profile this! > Consider the subprogram attached. It shows a simple tree_view > displaying a list_store (5000 columns and 50 rows containing > integers). The display performance is very poor: when displaying the > last columns, the vertical scollbar takes between 5 and 10 seconds to > respond. Two things: 1. Yes, we abuse lists here and there. The performance would definitely be better with an array. This is reasonably easy to do, since the changes are internal and self-contained in GtkListStore and GtkTreeDataList. 2. You just created a user interface disaster :) How are your users going to be able to jump to the right column? > So, it seems that we spend most of our time traversing the list of > columns. Note that this explains why a tree of 5000 columns x 50 rows > has such bad performance compared to a tree of 50 columns x 5000 rows. > > First suggestion: we'd be better off in this subprogram if the data > was implemented as an array instead of as a linked list. Exactly. GtkListStore is implemented as a GSequence (a splay tree), where each node is one row in the list. Then, the data for the row's columns is stored in a linked list (GtkTreeDataList). You could reimplement GtkTreeDataList in terms of an array and get a good speedup for *all* uses of GtkListStore (i.e. you'd be replacing a dominant O(n^2) for get/set operations in the list store with a simpler O(log n) for splay tree lookups, plus the constant time to access a column within a node). Using an array instead of a linked list for GtkTreeDataList is a great idea, and we should definitely review a patch for that :) > I'm not familiar with this area yet, so I'm puzzled: is the call to > gtk_tree_view_column_cell_set_cell_data really needed for the > purposes of gtk_tree_view_bin_expose, or is it just needed for the > call to gtk_tree_view_has_special_cell? > > In any case, I suggest we cache this - probably there is no need to > do it in every expose call, only after the model data has changed. It absolutely needs to be called for each row, so that the tree view can know how to display the focus rectangle (a cell-wide rectangle for editable/activatable cells, a row-wide rectangle for "cold" cells). The has_special_cell condition is particular to each row, so the benefits of caching it (say, in the GtkRBTree) would only serve for multiple exposes of the same unchanging data. But since one needs to walk the entire row to paint it, anyway, you'd simply be doing one walk instead of two. But the main problem is getting the cell's data from the model (i.e. walking the GtkTreeDataList) - fix that, and the problem with has_special_cell may simply disappear. Hacking GtkListStore/GtkTreeDataList to use an array for the row data should take one or two afternoons, and it would benefit all trees, not just your huge one. Wanna do it for fame and glory? :) [This would also save memory, since you avoid having GSlice-induced padding in each GtkTreeDataList structure and you also save a pointer per node. I'd love to see actual numbers for this.] Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: ideas on improving the performance of gtk_tree_view
El vie, 23-03-2007 a las 23:19 +0100, Michael Natterer escribió: > I would rather say we absolutely don't abuse lists here. There is no > significant difference between list and array for a couple of items > (say < 50 items). The only abuse I see is creating a treeview with > 5000 columns. The widget is simply not made for that. It would be > the same as optimizing GtkVBox for 5000 children and asking for > the internal list being replaced by an array. So, a few things: * 5000 columns is definitely abusing the *user*. Who cares about the toolkit. * A tree row has an immutable number of columns; their datums are of known sizes. This screams "array". * An array would give you less memory overhead from allocator padding, better cache locality, less pressure on the allocator, and constant-time access to the columns. I bet that it will also require less code than a list :) > What GTK+ needs here is a *sheet* widget, something that is optimized > for organizing two-dimensional data in an efficient way. Hacking up > GtkTreeView for insane use cases does no good whatsoever. Yes, we definitely need a sheet widget. I don't know why people don't just write one, or revive the old one. Maybe they are scared that it doesn't do enough for a spreadsheet --- but people are not building spreadsheets; they just want to display simple tabular data. > P.S.: I do not say that optimizing treeview is a bad idea, I would > just find it very unfortunate to waste developer resources > in order to optimize use cases like this. I'd rather not discourage people who are actually bothering to profile our shitty code --- they don't come along very often. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: ideas on improving the performance of gtk_tree_view
On 3/23/07, Federico Mena Quintero <[EMAIL PROTECTED]> wrote: > * 5000 columns is definitely abusing the *user*. Who cares about the > toolkit. Federico, where you think of "foo", someone else will want to write "Supercalifragilisticexpialidocious". You seem to be making a two-step conclusion: 1. At 5000 columns (or rows for that matter), scrolling with either mouse or keyboard will be an unpleasant way to get to the point you want. 2. Therefore 5000 columns (or rows) cannot work well in a GUI. I agree with 1, but I know that 2 is wrong. I have seen it work with considerably more than 2 rows. I cannot think of a good reason to use that many columns, but I am willing to believe my imagination isn't wild enough. The case I am familiar with is a large, sorted list of names. You get to the initially interesting point by typing the first few letters and then you can scroll to nearby entries. It worked very well, even with people who were completely computer illiterate (and bad spellers at that). Whether that kind of thing works depends a bit on corpus. For example, it wouldn't work with the all-China phone book. That's how many pages of "Li ..."? :-) Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: ideas on improving the performance of gtk_tree_view
On Fri, 2007-03-23 at 17:35 -0600, Federico Mena Quintero wrote: > El vie, 23-03-2007 a las 23:19 +0100, Michael Natterer escribió: > [...] > > What GTK+ needs here is a *sheet* widget, something that is optimized > > for organizing two-dimensional data in an efficient way. Hacking up > > GtkTreeView for insane use cases does no good whatsoever. > > Yes, we definitely need a sheet widget. I don't know why people don't > just write one, or revive the old one. Maybe they are scared that it > doesn't do enough for a spreadsheet --- but people are not building > spreadsheets; they just want to display simple tabular data. Such widget was written a while ago by Lorenzo Gil Sánchez (Gazpacho's author): http://www.sicem.biz/personal/lgs/projects/gtkgrid/view_project But the discussion take here when it was proposed, wasn't very stimulating so far: http://mail.gnome.org/archives/gtk-devel-list/2004-April/msg00137.html -- Germán Poó Caamaño Concepción - Chile ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
