Positionning a widget in Table cells
Hi all, I'm developping an app w/ gtkmm 2.4. I'm using a number of custom widgets, packed into a Table in my main window One of these (W) is attached to 2 cells of the first column, and others (a,b,c,m) fill the other cells, like so: m m m W a b W _ b c c c This Widget is set to shrink vertically, and does exactly so :) However, it sits centered in the two cells it's allocated. I'd like to anchor the widget to the top of the two cells. I found the 'Gtk:AnchorType' enum, but I can't find any function that use it. What is the correct way to acheive this? Thanks a lot, Jonathan -- Morpheus linux, c'est une question de VI ou de MORE ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Positionning a widget in Table cells
On Fri, Mar 23, 2007 at 11:33:31PM +0100, Jonathan Winterflood wrote: I'm using a number of custom widgets, packed into a Table in my main window One of these (W) is attached to 2 cells of the first column, and others (a,b,c,m) fill the other cells, like so: m m m W a b W _ b c c c This Widget is set to shrink vertically, and does exactly so :) However, it sits centered in the two cells it's allocated. I'd like to anchor the widget to the top of the two cells. If the widget is a subclass of GtkMisc, use its methods to set the alignment. Otherwise pack it to a GtkAlignment. In both cases it has to be attached to the table with vertical GTK_FILL flag. Yeti -- http://gwyddion.net/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
can't get enter_notify_event to work
Hi all,
can't get this to work the way I need it to and appreciate all clever
ideas.
I have a very simple test code that works as desired, but it does not
work in another app. I'm doing:
void
on_gtk_frame_right_enter_notify_event (GtkWidget * w, gpointer data) {
printf(entered . \n);
}
gtk_frame_right = gtk_window_new (GTK_WINDOW_TOPLEVEL);
g_assert (gtk_frame_right);
gtk_widget_set_size_request (GTK_WIDGET (gtk_frame_right),
FRAME_WIDTH, pheight);
gtk_widget_set_sensitive (GTK_WIDGET (gtk_frame_right), FALSE);
gtk_window_set_title (GTK_WINDOW (gtk_frame_right),
gtk_frame_right);
//GTK_WINDOW (gtk_frame_right)-type = GTK_WINDOW_POPUP;
gtk_window_set_resizable (GTK_WINDOW (gtk_frame_right), FALSE);
colormap = gtk_widget_get_colormap (gtk_frame_right);
r_eb = gtk_event_box_new ();
gtk_container_add (GTK_CONTAINER (gtk_frame_right), r_eb);
gtk_widget_show(r_eb);
...
g_signal_connect (G_OBJECT(toplevel), configure-event,
G_CALLBACK (on_gtk_frame_configure_event),
NULL);
g_signal_connect (G_OBJECT(r_eb), enter_notify_event,
G_CALLBACK
(on_gtk_frame_right_enter_notify_event), NULL);
the callback is never fired. I've also tried to add
GDK_ENTER_NOTIFY_MASK explicitly to no betterment.
Is there anything special to watch out for here?
TIA,
Karl.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
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: 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: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 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
