Re: Application termination at some point
ds.sun...@gmail.com wrote: I learned to generate the core dump file of the test application when it crashes... and using the gdb debugger i got the following bt... Could you please tell me where might be the problem? I'm afraid no one is going to be able to tell you where the problem might be. All you've given us is a stack trace. To solve the problem we'd have to debug the program for you. Since you've not provided the source code, that's something only you can do. Debugging code on Linux is done in much the same way as on Windows, although there are powerful tools on linux like Valgrind. Core dumps are useful, but it's also helpful to run the program in a debugger from the beginning. On my machine, ddd and kdbg are two debugger interfaces that work well for me. All we can do is give you tips on what we'd do or look at, which has been done. If you can create a small program (say 50 lines or less) that exhibits this problem, we can probably help more directly. The fact that the abort is occurring in a GTK call deep in the system is usually indicative of something not quite being right in your code before you call gtk_main. IE the code where you set up your windows and widgets. Or it could be in a callback for an event. In another e-mail I see evidence that you are using pthreads. Are you following the threading guidelines for GTK? If you are calling gtk calls from other threads are you using the proper locks? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Creating an aggregating GtkContainer
Hi everyone I'm contributing to a project called the Common Printing Dialog which goal is to create the next generation print dialog for Gnome. The dialog allows users to customize different options which depends on the current printer being selected. What I'm struggling to implement is a GtkContainer which sort of aggregates or combines multiple sub-containers. So that when adding new widgets each sub-container is filled until no more space is available then the next sub-container is filled. A picture of how this should look like is available here: http://wiki.openusability.org/printing/index.php/Image:Level3.5_1200.png My question is if someone knows a good way to implement this. I've tested with estimating the widgets size and if the sum of all children is larger then the container the next sub-container is used. One problem is that the widget's size is not known until the widget gets visible so I need to workaround that. Feel free to post suggestions here or have a look at the source code here [1] (e.g. the option_table_append function) and contribute a patch. Thanks Per [1] http://bzr.linuxfoundation.org/loggerhead/openprinting/misc/common-printing-dialog/annotate/head%3A/gtk-dialog/dialog-optiontable.c ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Creating an aggregating GtkContainer
On Wed, Nov 18, 2009 at 10:35, Per Hermansson hermansson@bredband.net wrote: My question is if someone knows a good way to implement this. I've tested with estimating the widgets size and if the sum of all children is larger then the container the next sub-container is used. One problem is that the widget's size is not known until the widget gets visible so I need to workaround that. Without thinking about this too much (so this may not fit your code or use model), you could defer placing widgets in subcontainers until the container is realized. At that point you'll know their sizes. -brian ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Creating an aggregating GtkContainer
Brian J. Tarricone wrote: On Wed, Nov 18, 2009 at 10:35, Per Hermansson hermansson@bredband.net wrote: My question is if someone knows a good way to implement this. I've tested with estimating the widgets size and if the sum of all children is larger then the container the next sub-container is used. One problem is that the widget's size is not known until the widget gets visible so I need to workaround that. Without thinking about this too much (so this may not fit your code or use model), you could defer placing widgets in subcontainers until the container is realized. At that point you'll know their sizes. -brian Thanks, this is actually an requirement for me (which I forgot to mention) the widgets are created at runtime, after containers are realized (when a new printer is selected) but the subcontainers are placed by glade (before the window is realized). Is there a way to after the containers (but before widgets) are realized detect if a widget will overflow a container? /Per ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Creating an aggregating GtkContainer
On Wed, Nov 18, 2009 at 5:40 PM, Per Hermansson hermansson@bredband.net wrote: Brian J. Tarricone wrote: On Wed, Nov 18, 2009 at 10:35, Per Hermansson hermansson@bredband.net wrote: My question is if someone knows a good way to implement this. I've tested with estimating the widgets size and if the sum of all children is larger then the container the next sub-container is used. One problem is that the widget's size is not known until the widget gets visible so I need to workaround that. Without thinking about this too much (so this may not fit your code or use model), you could defer placing widgets in subcontainers until the container is realized. At that point you'll know their sizes. -brian Thanks, this is actually an requirement for me (which I forgot to mention) the widgets are created at runtime, after containers are realized (when a new printer is selected) but the subcontainers are placed by glade (before the window is realized). Is there a way to after the containers (but before widgets) are realized detect if a widget will overflow a container? Maybe a simple answer to your question is, since usually the base size request for your interface is going to depend on system preferences, such as if buttons will display icons, or the fonts used in labels and the default sizes that they are using, it is impossible to guess exactly the size of a widget before actually mapping it and going through the size-request rigamarole. You might consider using a scrolled window that may not appear in most cases, but will allow for some level of overflow tolerance in your dynamic UI. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Creating an aggregating GtkContainer
Tristan Van Berkom wrote: On Wed, Nov 18, 2009 at 5:40 PM, Per Hermansson hermansson@bredband.net wrote: Thanks, this is actually an requirement for me (which I forgot to mention) the widgets are created at runtime, after containers are realized (when a new printer is selected) but the subcontainers are placed by glade (before the window is realized). Is there a way to after the containers (but before widgets) are realized detect if a widget will overflow a container? Maybe a simple answer to your question is, since usually the base size request for your interface is going to depend on system preferences, such as if buttons will display icons, or the fonts used in labels and the default sizes that they are using, it is impossible to guess exactly the size of a widget before actually mapping it and going through the size-request rigamarole. You might consider using a scrolled window that may not appear in most cases, but will allow for some level of overflow tolerance in your dynamic UI. Cheers, -Tristan Thanks, maybe I'm asking for the impossible :) Say I use a scroll window for the different subcontainers to allow some overflow. Would it be possible to listen for signals on the containers and when the widgets have gotten their size allocated move them if the scrollbars became visible as a result of this. The user will then probably experience some flicker as containers are repainted and widgets moved. Would this be reasonable/possible to implement? /Per ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Creating an aggregating GtkContainer
On Wed, Nov 18, 2009 at 7:22 PM, Per Hermansson hermansson@bredband.net wrote: Tristan Van Berkom wrote: On Wed, Nov 18, 2009 at 5:40 PM, Per Hermansson hermansson@bredband.net wrote: Thanks, this is actually an requirement for me (which I forgot to mention) the widgets are created at runtime, after containers are realized (when a new printer is selected) but the subcontainers are placed by glade (before the window is realized). Is there a way to after the containers (but before widgets) are realized detect if a widget will overflow a container? Maybe a simple answer to your question is, since usually the base size request for your interface is going to depend on system preferences, such as if buttons will display icons, or the fonts used in labels and the default sizes that they are using, it is impossible to guess exactly the size of a widget before actually mapping it and going through the size-request rigamarole. You might consider using a scrolled window that may not appear in most cases, but will allow for some level of overflow tolerance in your dynamic UI. Cheers, -Tristan Thanks, maybe I'm asking for the impossible :) Say I use a scroll window for the different subcontainers to allow some overflow. Would it be possible to listen for signals on the containers and when the widgets have gotten their size allocated move them if the scrollbars became visible as a result of this. The user will then probably experience some flicker as containers are repainted and widgets moved. Would this be reasonable/possible to implement? First lets clarify, you are writing a container implementation, technically you allocate space for the children, usually according to the size they requested. So best not hook onto signals before properly implementing -size_allocate() and -size_request() for your composite widget (from there you should be able to manage all the main children - when reparenting a child this should be all automatic, maybe theres a need for gtk_container_check_resize() in some corner cases I couldnt say off hand). Somehow I doubt that you want to move widgets around based on size reallocation, I think that a well designed application layout should just stand alone and widgets jumping around will confuse the user more than anything else. At any rate, there are nice things you can do like making sure an important widget in the undetermined size window gets focus and is visible inside the scrolled window - or remembering scroll positions of various tabs when they get replaced or reloaded or such. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Creating an aggregating GtkContainer
On Wed, 2009-11-18 at 22:22 +0100, Per Hermansson wrote: The user will then probably experience some flicker as containers are repainted and widgets moved. As an aside [and not otherwise commenting on what you're trying to achieve], Evolution's preferences dialog has for years behaved somewhat this way. The resizing flicker is awful. Really jarring. AfC Sydney ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Creating an aggregating GtkContainer
Tristan Van Berkom wrote: On Wed, Nov 18, 2009 at 7:22 PM, Per Hermansson hermansson@bredband.net wrote: Thanks, maybe I'm asking for the impossible :) Say I use a scroll window for the different subcontainers to allow some overflow. Would it be possible to listen for signals on the containers and when the widgets have gotten their size allocated move them if the scrollbars became visible as a result of this. The user will then probably experience some flicker as containers are repainted and widgets moved. Would this be reasonable/possible to implement? First lets clarify, you are writing a container implementation, technically you allocate space for the children, usually according to the size they requested. So best not hook onto signals before properly implementing -size_allocate() and -size_request() for your composite widget (from there you should be able to manage all the main children - when reparenting a child this should be all automatic, maybe theres a need for gtk_container_check_resize() in some corner cases I couldnt say off hand). Somehow I doubt that you want to move widgets around based on size reallocation, I think that a well designed application layout should just stand alone and widgets jumping around will confuse the user more than anything else. At any rate, there are nice things you can do like making sure an important widget in the undetermined size window gets focus and is visible inside the scrolled window - or remembering scroll positions of various tabs when they get replaced or reloaded or such. I agree that this will surely be confusing to anyone watching widgets move around. What I understand from the design makers is that having multiple containers that span different parts of the application is a replacement for having a single scrollable container since scrollbars are not user friendly. Anyway, I'm gonna test your advice and see if I can approximate the widget's size to avoid unnecessary flickering and widgets moving around. Other than that I don't think its possible to do what I want with GTK+. Thanks Per ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Creating an aggregating GtkContainer
Andrew Cowie wrote: On Wed, 2009-11-18 at 22:22 +0100, Per Hermansson wrote: The user will then probably experience some flicker as containers are repainted and widgets moved. As an aside [and not otherwise commenting on what you're trying to achieve], Evolution's preferences dialog has for years behaved somewhat this way. The resizing flicker is awful. Really jarring. AfC Sydney Ok got it, will try to avoid this the longest then since the goal is to make the *Common* Print Dialog widely accepted :) Per ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
