GTK+ 2.21.8 released
GTK+ 2.21.8 is now available for download at: ftp://ftp.gtk.org/pub/gtk/2.21/ http://download.gnome.org/sources/gtk+/2.21/ f17ce48b3a896dc35bf70f22a18c868d06fca526f024396473e227ea30c32cc8 gtk +-2.21.8.tar.bz2 4c2acf5798efa9e85efdd785bf73e2d80661bae025a22dfd9c319cd9a4e384b8 gtk +-2.21.8.tar.gz This is the last development release leading toward 2.22. Notes: * GTK+ 2.22 is planned to be the last stable GTK+ 2.x release, to be released in parallel with GTK+ 3. It will not receive major feature work beyond API additions that are required to facilitate porting to GTK+ 3. * Installing this version will overwrite your existing copy of GTK+ 2.20. If you have problems, you'll need to reinstall GTK+ 2.20. * GTK+ 2.22 will be source and binary compatible with the GTK+ 2.20 series. * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Contributing GTK+ is a large project and relies on voluntary contributions. We are actively searching for new contributors in various areas and invite everyone to help project development. If you are willing to participate, please subscribe to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GtkTasks Overview of Changes from GTK+ 2.21.7 to 2.21.8 == * Deprecations: - Various style properties have been deprecated: GtkEntry::state-hint GtkTreeView::row-ending-details GtkRange::trough-side-details GtkRange::stepper-position-details GtkRange::activate-slider - The GtkIconView::orientation property has been deprecated and renamed to item-orientation - Separator-related API in GtkDialog - API related to blinking status icons - The keysym names have been renamed from GDK_... to GDK_KEY_... - The GtkItem class - The gdk_display variable and the GDK_DISPLAY macro * GTK+ now uses standard icon names for stock icons, where applicable * Win32: - Fixes to the MS Windows theme engine * Directfb: - Many fixes * Bugs fixed: 414712 gtk_container_set_focus_child leaks widget 601731 Drag and Drop from Workspace to Activities Overview 628049 Native windows don't work very well 628110 gtranslator inserts unwanted line breaks 628291 Drawing artifacts when used with a cairo 1.9.* 628308 docs referencing non existing icons 628656 _gdk_windowing_get_startup_notify_id memory leak 628932 key typing causes core dump in VNC environment 629093 [patch] prefix GDK key names 629277 Hanging because do_syntheszie_crossing_event... * Updated translations: Arabic Basque British English Estonian French Galician German Hebrew Hungarian Indonesian Italian Japanese Kazakh Korean Norwegian bokmål Polish Portuguese Slovian Spanish Swedish Tradition Chinese Thanks to all contributors: Martin Schlemmer Philip Withnall Fridrich Štrba Lionel Landwerlin Stefan Kost Carl-Anton Ingmarsson Tor Lillqvist Matthew Barnes Hans Breuer Neil Roberts Benjamin Otte Colin Walters Mike Gorse Michael Meeks Adel Gadllah Milan Bouchet-Valat September 14, 2010 Matthias Clasen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK+ vs GTK 2 vs GTKMM
I appeal to experienced programmers. What technology should I use? My requirements: 1. I want (will) create very large applications. At least 50 windows. 2. I want to use the visual editor for creating windows. 3. I want to write code in C++ (compiler g++). 4. I want to write programs only for the system Linux. 5. I want to work with the database and use the Grid in different windows: http://gtkextra.sourceforge.net/ 6. I need the full documentation on the functions of the chosen technology. 7. Technology should not have a lot of mistakes that, in the middle of the project does not change the technology and do not redo the entire project. I will be grateful for any information provided by my question. I totally get lost in the technology. I began to look different instructions. In this instruction: http://www.opennet.ru/docs/RUS/gtk_plus/x178.html Written, I quote: In version 2.0, the system signals moved from GTK to GLib, so the functions and types in this section have the prefix g_ and not gtk_. Why are all using old technology? Why use a function of GTK 1.2? For example: http://tadeboro.blogspot.com/2009/09/glade3-tutorial-6-signals.html or http://www.micahcarrick.com/gtk-glade-tutorial-part-2.html Perhaps creating a new technology GTK 2, the authors tried to improve the library? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ policy (was RE:rendering-cleanup-next)
On Sep 13, 2010, at 10:49 PM, Kristian Rietveld wrote: To add to this, it does not specify how to deal with braces in nested if-statements. When I start to nest if-statements (also with a single-statement body) I typically start adding braces, because it is a bit clearer and avoids the dangling else problem. Aside from the functional reasons to use braces even for single-line statements, using them make review and reading much simpler. If one just can go here is an if statement, oops, the brace is missing reading and reviews fly by. On the other hand, if one has to go hmm... here is an if, let me look for a brace. No, I don't see one. Let me read and consider if this is a situation calling for one or not, then code reviews, reading, maintenance, etc. go significantly slower. Over the years I've consistently found it to be at least an order of magnitude slower, and more error prone. And on the functional side, yes I've fixed many many bugs in many projects that have been caused by or missed due to lack of braces on single-lines. Oh, and nested if statements do get things quite complicated if the rule is to only use braces sometimes, instead of the simpler use braces 100% of the time. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ policy (was RE:rendering-cleanup-next)
On Tue, Sep 14, 2010 at 09:14, Jon Cruz j...@joncruz.org wrote: On Sep 13, 2010, at 10:49 PM, Kristian Rietveld wrote: To add to this, it does not specify how to deal with braces in nested if-statements. When I start to nest if-statements (also with a single-statement body) I typically start adding braces, because it is a bit clearer and avoids the dangling else problem. Aside from the functional reasons to use braces even for single-line statements, using them make review and reading much simpler. If one just can go here is an if statement, oops, the brace is missing reading and reviews fly by. On the other hand, if one has to go hmm... here is an if, let me look for a brace. No, I don't see one. Let me read and consider if this is a situation calling for one or not, then code reviews, reading, maintenance, etc. go significantly slower. Over the years I've consistently found it to be at least an order of magnitude slower, and more error prone. And on the functional side, yes I've fixed many many bugs in many projects that have been caused by or missed due to lack of braces on single-lines. Oh, and nested if statements do get things quite complicated if the rule is to only use braces sometimes, instead of the simpler use braces 100% of the time. One more reason is that if braces are them from the start, they won't need to be added later and git-blame will be more useful. Regards, Tomeu ___ 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: padding cleanup
On 13.09.2010 04:50, Havoc Pennington wrote: Hi, I merged the main patch to master. I wrote docs (see attached) but did not push them yet because I can't figure out how to actually document a non-signal virtual function in a non-interface. Yes, docuemnt is as part of the class structure. What I have here puts the text of the docs in the HTML but it doesn't look nice. Does gtk-doc just not do this? Its a bit uncommon to do it like you did in gtk/gtkwidget.h. Just do: *...@adjust_size_request: Convert·an·initial·size·request·from·a·widget's·#GtkSizeRequest * virtual·method·implementations·into·a·size·request·to·be·used·by ... Stefan Havoc ___ 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: rendering-cleanup Part 2
On Aug 29, 2010, at 9:02 PM, Benjamin Otte wrote: That's about it. Comments? This morning I did an attempt to build rendering-cleanup (so not rendering-cleanup-next yet, I am a bit behind ...). I have pushed fixes that make the thing build to completion. Right now any test/demo crashes on start up, I have a fix for that to avoid the crash, but that results in fully white windows. It looks like the initial expose is missing. (Yes I have upgraded to cairo 1.10 :) ). I will investigate some more later this week. regards, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ policy (was RE:rendering-cleanup-next)
El 14/09/10 09:46, Tomeu Vizoso escribió: On Tue, Sep 14, 2010 at 09:14, Jon Cruz j...@joncruz.org wrote: On Sep 13, 2010, at 10:49 PM, Kristian Rietveld wrote: To add to this, it does not specify how to deal with braces in nested if-statements. When I start to nest if-statements (also with a single-statement body) I typically start adding braces, because it is a bit clearer and avoids the dangling else problem. Aside from the functional reasons to use braces even for single-line statements, using them make review and reading much simpler. If one just can go here is an if statement, oops, the brace is missing reading and reviews fly by. On the other hand, if one has to go hmm... here is an if, let me look for a brace. No, I don't see one. Let me read and consider if this is a situation calling for one or not, then code reviews, reading, maintenance, etc. go significantly slower. Over the years I've consistently found it to be at least an order of magnitude slower, and more error prone. And on the functional side, yes I've fixed many many bugs in many projects that have been caused by or missed due to lack of braces on single-lines. Oh, and nested if statements do get things quite complicated if the rule is to only use braces sometimes, instead of the simpler use braces 100% of the time. One more reason is that if braces are them from the start, they won't need to be added later and git-blame will be more useful. +1 for Paul, Kristian and Tomeu. To Jon's point, I would say it will be good to have this compromise: * Always put braces. * If you find a place where there is no brace, you can: a) Fix it, if and only if your commit is already changing that line. b) If there are lots of places where style rules are violated in the file, and the maintainer agrees, do a pre-commit fixing the style (stating very clearly that it shouldn't be changing behaviour), and then do your commit with the meaniningful changes. Regards, Andres -- ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Private types inside GTK+
Hi, On Sep 9, 2010, at 11:28 AM, Tristan Van Berkom wrote: Hi, With all the GSEAL()ing of the whole GTK+ api we get to privatize alot of things which leaves us alot more leeway in how we can change things under the hood in the future. However, what we have to play with is still a matter of basic C code implementation details and not much in the sense of OOP code... so I wonder if we can make a mechanism at the build level to privatize entire object types to be used solely as delegate objects of widgets that are a part of the API. I see where you are going. I think that often such objects could make sense as public API. But I guess you also want to avoid making these objects public too soon, since that will decrease the amount of leeway again. I had this idea while pondering: https://bugzilla.gnome.org/show_bug.cgi?id=629133 Please allow me to comment in some more detail on this exact issue. b.) Add some magick/logic to GtkCellView where cellviews can be associated with a group of cellviews and then align them with all the cellview's siblings. While this option seems more sound at first sight in terms of code readability and all, it also introduces some iterative overhead as each cell would have to consult the size requests of every cell in each cellview sibling... the the allocation of each cellview in the list. (not to mention it would have to make the assumption that every sibling has the same type of cell renderer packed in the same order... and that each cell view is set to render a row from the same model... a kind of ugly assumption that you really dont want to make). I agree, this will turn out ugly :) c.) What seems to me as the Right Thing to do here is to create a derived GtkMenu; GtkComboBoxMenu that would be responsible for taking into account the width of each cell on each row and then effecting an allocation for every cellview in the menu in a single pass. If possible, I would even get rid of the separate cell views in this case. Could a GtkComboBoxMenu just render itself using a set of cell renderers without needing instances of GtkCellView. Though this might show troublesome in combination with supporting the separate menu items ... Vaguely, for bug 629133 my plan could be: - Privatize GtkCellView unless there are some objections (or at least early deprecation in 3.0 cycle). CellView is really only an implementation detail of GtkComboBox and thus adds some cruft to the api that we really dont need (unless some applications love the cellview and then justify its existence and our maintenance of it). GtkCellView has been around for some time, so it might have seen some usage. We would have to investigate this. At least, I would really deprecate early in 3.0 and not before ... - Create a private type GtkComboBoxMenu which could be responsible for allocating the private cellviews in a combo box's dropdown menu properly and in a single pass. - Work on refactoring GtkTreeViewColumn so that it stands alone and apart from GtkTreeView (somewhere along side working on wordwrapping cell renderers and variable row heights in treeviews). As I also noted in the bug, I would not make GtkTreeViewColumn a stand-alone class, rather, I would work on getting the algorithms that do the cell and column layouting in separate classes and then have GtkTreeView, GtkTreeViewColumn and GtkComboBoxMenu re-use this. Note that even though cell layouting is done in GtkTreeViewColumn, the column layouting is done in GtkTreeView. I think that these layouting algorithms in separate classes might actually be useful public API, to reflect on the comment I made at the start of this e-mail. There might be more components of GtkTreeView that could be useful to refactor into new separate classes, for example the rendering loop, selection handling, input event handling etc. My goal would be to refactor GtkTreeView in such a way so that it (the original functionality) can be composed from these separate classes. And also so that GtkIconView (and new kinds of such views, Windows-style columnary perhaps?) could also be re-written by a composition of these classes. This will reduce the amount of code that is duplicated between GtkTreeView and GtkIconView, and in this case you can also add GtkComboBox and GtkCellView to that list. Furthermore, the road for creating variations of these view widgets with more flexible and special layouting has then been opened. - Integrate GtkTreeViewColumn as a delegate of the private GtkComboBoxMenu which would be used to render rows into the allocated menu item space. So instead of using GtkTreeViewColumn as a delegate, GtkComboBoxMenu would re-use the layouting algorithms and perhaps the rendering loop which are now in shared
GTK+ 2.21.8 released
GTK+ 2.21.8 is now available for download at: ftp://ftp.gtk.org/pub/gtk/2.21/ http://download.gnome.org/sources/gtk+/2.21/ f17ce48b3a896dc35bf70f22a18c868d06fca526f024396473e227ea30c32cc8 gtk +-2.21.8.tar.bz2 4c2acf5798efa9e85efdd785bf73e2d80661bae025a22dfd9c319cd9a4e384b8 gtk +-2.21.8.tar.gz This is the last development release leading toward 2.22. Notes: * GTK+ 2.22 is planned to be the last stable GTK+ 2.x release, to be released in parallel with GTK+ 3. It will not receive major feature work beyond API additions that are required to facilitate porting to GTK+ 3. * Installing this version will overwrite your existing copy of GTK+ 2.20. If you have problems, you'll need to reinstall GTK+ 2.20. * GTK+ 2.22 will be source and binary compatible with the GTK+ 2.20 series. * Bugs should be reported to http://bugzilla.gnome.org. What is GTK+ GTK+ is a multi-platform toolkit for creating graphical user interfaces. Offering a complete set of widgets, GTK+ is suitable for projects ranging from small one-off tools to complete application suites. GTK+ has been designed from the ground up to support a range of languages, not only C/C++. Using GTK+ from languages such as Perl and Python (especially in combination with the Glade GUI builder) provides an effective method of rapid application development. GTK+ is free software and part of the GNU Project. However, the licensing terms for GTK+, the GNU LGPL, allow it to be used by all developers, including those developing proprietary software, without any license fees or royalties. Where to get more information about GTK+ Information about GTK+ including links to documentation can be found at: http://www.gtk.org/ An installation guide for GTK+ 2.x is found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Common questions: http://developer.gnome.org/doc/API/2.0/gtk/gtk-question-index.html http://www.gtk.org/faq/ Contributing GTK+ is a large project and relies on voluntary contributions. We are actively searching for new contributors in various areas and invite everyone to help project development. If you are willing to participate, please subscribe to the project mailing lists to offer your help and read over our list of vacant project tasks: http://live.gnome.org/GtkTasks Overview of Changes from GTK+ 2.21.7 to 2.21.8 == * Deprecations: - Various style properties have been deprecated: GtkEntry::state-hint GtkTreeView::row-ending-details GtkRange::trough-side-details GtkRange::stepper-position-details GtkRange::activate-slider - The GtkIconView::orientation property has been deprecated and renamed to item-orientation - Separator-related API in GtkDialog - API related to blinking status icons - The keysym names have been renamed from GDK_... to GDK_KEY_... - The GtkItem class - The gdk_display variable and the GDK_DISPLAY macro * GTK+ now uses standard icon names for stock icons, where applicable * Win32: - Fixes to the MS Windows theme engine * Directfb: - Many fixes * Bugs fixed: 414712 gtk_container_set_focus_child leaks widget 601731 Drag and Drop from Workspace to Activities Overview 628049 Native windows don't work very well 628110 gtranslator inserts unwanted line breaks 628291 Drawing artifacts when used with a cairo 1.9.* 628308 docs referencing non existing icons 628656 _gdk_windowing_get_startup_notify_id memory leak 628932 key typing causes core dump in VNC environment 629093 [patch] prefix GDK key names 629277 Hanging because do_syntheszie_crossing_event... * Updated translations: Arabic Basque British English Estonian French Galician German Hebrew Hungarian Indonesian Italian Japanese Kazakh Korean Norwegian bokmål Polish Portuguese Slovian Spanish Swedish Tradition Chinese Thanks to all contributors: Martin Schlemmer Philip Withnall Fridrich Štrba Lionel Landwerlin Stefan Kost Carl-Anton Ingmarsson Tor Lillqvist Matthew Barnes Hans Breuer Neil Roberts Benjamin Otte Colin Walters Mike Gorse Michael Meeks Adel Gadllah Milan Bouchet-Valat September 14, 2010 Matthias Clasen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ policy (was RE:rendering-cleanup-next)
On Mon, 2010-09-13 at 21:48 -0400, Paul Davis wrote:
On Mon, Sep 13, 2010 at 6:27 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
2010/9/13 Thomas Wood t...@gnome.org:
Clutter's (very detailed) coding style document may be useful here,
since it has a very similar coding style to GTK+:
http://git.clutter-project.org/clutter/tree/doc/CODING_STYLE
Yes, I think we could basically adopt this word-by-word.
i know that coding styles are, as it says in the clutter guide,
arbitrary, but i would just like to mention one little detail that i
find problematic when working on shared projects (and much less so on
non-shared projects). this rule:
--
Curly braces should not be used for single statement blocks:
if (condition)
single_statement ();
else
another_single_statement (arg1);
---
what's wrong with this?
There are valid arguments the other way, and you make them. But
remember, GTK+ is using GNU style bracing and that pretty much takes the
question out of the matter. Doing:
if (conditition)
{
single_statement ();
}
else
{
another_single_statement ();
}
consistently wouldn't really fly. (Plus, there's the question of all the
existing code...)
- Owen
[ Along with the nested if thing, if you are specifying exactly
the style, the other thing to note is that if one branch of an if gets
braces because it is multiline, the other branch should usually get
them too ]
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
I just pushed an update to rendering-cleanup and rendering-cleanup-next that incorporates the suggestions from this thread. In particular: - I squelched commits The fixes from Kris for OS X should now be in their correct position and allow compiling random checkouts so git bisect works on OS X (hopefully). Also, I squelched the background handling fixes Havoc mentioned in his mail - GtkWidget::draw now doesn't pass width/height You just get the widget and a cairo_t now. To get the values previously passed as width and height, I introduced gtk_widget_get_allocated_width/height(). They return widget-priv-allocation.width/height, but are way nicer to use. - The draw signal handlers are properly guarded by cairo_save/restore() This was only discussed on IRC, but I thought it's worth mentioning here. I consider this API prtty much done at this point. There might be some implementation details that we might want to change later (like background handling), but we can do that after rendering-leanup-next hit master. So I consider it ready to merge. Comments? Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSizeGroup breakage (was Re: questions re: aux info, size request)
This is indeed quite a brain teaser.
I don't think your current approach of incrementally bumping the size
group requisition does even work correctly. How does the size group
requisition ever become smaller again ? The pre-hfw sizegroup code
always looped over all widgets to determine the size group
requisition, which seems to me the only way to make things work.
I'll attach a simple example that shows the problem with incremental
bumping. If you use the hpaned to make the long label unwrap
completely, the height request does not get reduced to a single line
height, as you can see by using the vpaned.
Matthias
#include gtk/gtk.h
int
main (int argc, char *argv[])
{
GtkWidget *window;
GtkWidget *hbox;
GtkWidget *vbox1;
GtkWidget *vbox2;
GtkWidget *c11, *c12, *c21, *c22;
GtkSizeGroup *sg;
GtkWidget *hpaned, *vpaned;
gtk_init (argc, argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_window_set_default_size (GTK_WINDOW (window), 600, 200);
hpaned = gtk_hpaned_new ();
vpaned = gtk_vpaned_new ();
hbox = gtk_hbox_new (FALSE, 5);
vbox1 = gtk_vbox_new (FALSE, 5);
vbox2 = gtk_vbox_new (FALSE, 5);
gtk_container_add (GTK_CONTAINER (window), hpaned);
gtk_paned_add1 (GTK_PANED (hpaned), vpaned);
gtk_paned_add2 (GTK_PANED (hpaned), gtk_label_new ());
gtk_paned_add1 (GTK_PANED (vpaned), hbox);
gtk_paned_add2 (GTK_PANED (vpaned), gtk_label_new ());
gtk_container_add (GTK_CONTAINER (hbox), vbox1);
gtk_container_add (GTK_CONTAINER (hbox), vbox2);
c11 = gtk_label_new (Some text that might wrap);
c12 = gtk_label_new (Ellipsizing text that doesn't wrap);
c21 = gtk_label_new (Short text);
c22 = gtk_label_new (Some longer text that might also wrap over several lines);
gtk_label_set_line_wrap (GTK_LABEL (c11), TRUE);
gtk_label_set_ellipsize (GTK_LABEL (c12), PANGO_ELLIPSIZE_END);
gtk_label_set_ellipsize (GTK_LABEL (c21), PANGO_ELLIPSIZE_END);
gtk_label_set_line_wrap (GTK_LABEL (c22), TRUE);
gtk_container_add (GTK_CONTAINER (vbox1), c11);
gtk_container_add (GTK_CONTAINER (vbox1), c12);
gtk_container_add (GTK_CONTAINER (vbox2), c21);
gtk_container_add (GTK_CONTAINER (vbox2), c22);
sg = gtk_size_group_new (GTK_SIZE_GROUP_BOTH);
gtk_size_group_add_widget (sg, c11);
gtk_size_group_add_widget (sg, c22);
gtk_widget_show_all (window);
gtk_main ();
return 0;
}
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
On Tue, Sep 14, 2010 at 11:46 AM, Benjamin Otte o...@gnome.org wrote: I consider this API prtty much done at this point. There might be some implementation details that we might want to change later (like background handling), but we can do that after rendering-leanup-next hit master. So I consider it ready to merge. Comments? What about the expose_event / gtk_widget_send_expose_event stuff ? Do we want to merge what you have first and figure that out afterwards ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ policy (was RE:rendering-cleanup-next)
On Tue, Sep 14, 2010 at 9:48 AM, Owen Taylor otay...@redhat.com wrote:
But
remember, GTK+ is using GNU style bracing and that pretty much takes the
question out of the matter. Doing:
if (conditition)
{
single_statement ();
}
else
{
another_single_statement ();
}
consistently wouldn't really fly. (Plus, there's the question of all the
existing code...)
why not?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
And did you want to add some of the checks and warnings in gtk_widget_draw_internal that were discussed (eg about not having up-to-date allocation) ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
On Tue, Sep 14, 2010 at 7:46 PM, Matthias Clasen matthias.cla...@gmail.com wrote: What about the expose_event / gtk_widget_send_expose_event stuff ? Do we want to merge what you have first and figure that out afterwards ? I want to figure that out afterwards. It's something I haven't figured out completely yet. I consider it a part of rendering-cleanup part 4: The hackfest menace. And did you want to add some of the checks and warnings in gtk_widget_draw_internal that were discussed (eg about not having up-to-date allocation) ? I'm actually not sure about that. First, we don't have any code that defines if an allocation is valid or even defines what a valid allocation is. Or do we? gtk_widget_get_allocation() at least doesn't do anything there. But I guess we can add more warnings to gtk_widget_draw() while we start using it. (Or better: Fix those problems). Both of these problems at least belong to the implementation details that we might want to change later stage. I suspect we'll find a few useful knobs to tune and APIs to add when we port all those applications to it. So I consider it by no means finished yet. But it's certainly good enough to build a toolkit with. ;) Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
Hi, On Tue, Sep 14, 2010 at 7:42 PM, Benjamin Otte o...@gnome.org wrote: I'm actually not sure about that. First, we don't have any code that defines if an allocation is valid or even defines what a valid allocation is. Or do we? gtk_widget_get_allocation() at least doesn't do anything there. yes, we have GTK_WIDGET_ALLOC_NEEDED(). draw() should whine if an alloc is needed. I don't think there's much question here. Drawing without an updated allocation is just a bug, plain and simple. Widgets need this guarantee. For example if I'm coding GtkLabel, I should be able to create the PangoLayout in size_allocate and assume that I have the right layout in draw(). If you don't require updating the allocation, I might draw() some old text that has been changed. (Not saying GtkLabel works this way, I didn't look, just that if it did work this way it would be correct and would have worked in GTK 2.x. And it's certainly easier to write a correct widget if we keep this invariant.) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
Hi, On Tue, Sep 14, 2010 at 7:42 PM, Benjamin Otte o...@gnome.org wrote: On Tue, Sep 14, 2010 at 7:46 PM, Matthias Clasen matthias.cla...@gmail.com wrote: What about the expose_event / gtk_widget_send_expose_event stuff ? Do we want to merge what you have first and figure that out afterwards ? I want to figure that out afterwards. It's something I haven't figured out completely yet. I consider it a part of rendering-cleanup part 4: The hackfest menace. The thing about this is someone will have to go git-digging to get back the deleted docs and stuff. We end up intermediately deleting expose-event then bringing it back then moving it to WidgetWithWindow thingy. I can do it after you merge if you like rather than trying to explain what I mean in email. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
Fixed in http://git.gnome.org/browse/gtk+/commit/?h=rendering-cleanup-nextid=99f0da58168e3db6cdf8c27c4239afc600bef058 Thanks for pointing out that flag, I never realized it exists. Benjamin On Wed, Sep 15, 2010 at 2:36 AM, Havoc Pennington h...@pobox.com wrote: Hi, On Tue, Sep 14, 2010 at 7:42 PM, Benjamin Otte o...@gnome.org wrote: I'm actually not sure about that. First, we don't have any code that defines if an allocation is valid or even defines what a valid allocation is. Or do we? gtk_widget_get_allocation() at least doesn't do anything there. yes, we have GTK_WIDGET_ALLOC_NEEDED(). draw() should whine if an alloc is needed. I don't think there's much question here. Drawing without an updated allocation is just a bug, plain and simple. Widgets need this guarantee. For example if I'm coding GtkLabel, I should be able to create the PangoLayout in size_allocate and assume that I have the right layout in draw(). If you don't require updating the allocation, I might draw() some old text that has been changed. (Not saying GtkLabel works this way, I didn't look, just that if it did work this way it would be correct and would have worked in GTK 2.x. And it's certainly easier to write a correct widget if we keep this invariant.) Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: rendering-cleanup-next
+ g_return_if_fail (GTK_WIDGET_ALLOC_NEEDED (widget)); g_return_if_fail( ! GTK_WIDGET_ALLOC_NEEDED (widget)); right? Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
