Placing Widgets over another on the screen
Hello all, i created two widget classes. The first one (Widget A) draws a simple square with a predefined color in a drawingarea . This widget should have four members of the second widget (Widget B) which has the same architecture and draws a simple self-defined symbol. The placement on the screen should finally look like that the four little symbols are placed (like in a hbox) in the square. The color of the symols has to be changed during runtime by events/callbacks. Everything compiles well, with program start Widget A is created and drawn and also all four Widgets B can be created. When trying to add the Widgets B to A like gtk_container_add(GTK_CONTAINER(Widget_A),Widget_B); the console creates an error that Widget A (of coursce) is no Containter-Class but Widget A-Class... Q1) Is there a way to configure my Widget A to contain others widgets so they can be drawn too like mentioned above or Q2) Is there another principial mechanism to draw widgets over another Best regards Markus - Gersys GmbH, Hans-Urmiller-Ring 46c, D-82515 Wolfratshausen, Germany Geschaeftsfuehrer: Erwin Sterzer, HRB 137 872 Muenchen, Fon: +49(0)8171 9986-6 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK+ 2.12.8 released
GTK+ 2.12.8 is now available for download at: http://ftp.gnome.org/pub/GNOME/sources/gtk+/2.12/ gtk+-2.12.8.tar.bz2 md5sum: 1e0d7db0bfa210881743e1d42ee91a24 gtk+-2.12.8.tar.gzmd5sum: f8ff1c2b418cf7ca80f8b96e31ef12dc This is a bug fix release in the 2.12 series. 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.12.7 to 2.12.8 == * Make the directfb backend build with GLib 2.15 * Improve the handling of modal windows on win32 * GtkFileChooser: - Activate bookmarks on single-click - Improve some focus handling issues - Don't select filename extensions in the save dialog * Bugs fixed: 499835 No "object:state-changed:selected" event when [un]selecti... 516024 filechooser critical warning when loading thumbnail pixbufs 144269 GtkHPaned flickers and leaves widgets in child panels unr... 419737 File save dialog deletes/empties filename when changing d... 148828 Side Pane in File Selector requires double-click 455627 Keyboard input gets confused with modal windows 473786 Needs keyboard navigation for gtkstatusicon 494515 GdkPixbufLoader does not always return an image at the si... 499940 Focus shouldn't go to file list when selecting a bookmark 503569 Leak in GtkTreeViewColumn 505928 Right-clicking taskbar entry for minimized window causes ... 51 [Win32] Modal dialogs should affect the entire applicatio... 511987 filter is not working 514621 Crash when changing model while handling GtkTreeSelection... 514643 Hiding a modal window still causes its parents to be blocked 514789 Clicking a menu in a maximized windowcauses it to restore... 515047 check for all return/space keys consistently 515667 gtk_file_chooser_get_current_folder_uri does not check fo... 362516 File extensions should not be selected by default * Updated translations: Greek (el) Spanish (es) Galician (gl) Hebrew (he) Brazilian Portugese (pt_BR) Slovak (sk) Swedish (sv) A list of all the bugs fixed in this release can be found here: http://bugzilla.gnome.org/buglist.cgi?bug_id=144269,505928,148828,499940,419737,514789,511987,503569,473786,514621,515047,499835,362516,515667,455627,51,514643,514789,494515,516024 Thanks to all contributors: Richard Hult Cody Russell Sven Neumann Federico Mena Quintero Josselin Mouette Sven Herzberg Jonh Wendell Emmanuele Bassi Kristian Rietveld Li Yuan Andreas Koehler Christian Persch Rich Burridge LiYan Zhang Francesco Montorsi Mike Morrison February 12, 2008 Matthias Clasen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE:
On 12-Feb-2008 Markus Müller wrote: . . . > The widgets will be nested: The train-widget provides a array of vehicles > which provides a array of waggons with an array of cameras... > Accessing the object properties can be done with references/pointers to the > data variables (the "normal" access to struct-members e.g.: > train.vehicle[1].waggon[4].camera[3].colour = green) > One of the biggest questions therefore is the structure of the necessary > manipulating functions: How can i best handle e.g. the redrawing of a camera > when its de-/selected (In C++ i would create a member-function to the > camera-object!?). I think to create a function set for every widget which can > always provide the interface for the upper "parent" instance!? Alternative > there could be a set of "top level" functions, but therefore the parameters > are getting kind of nasty !? it would be much the same in the gtk environment. You will associate a callback when the object is deselected. Depending upon the type of object, you will have a callback on, e.g. a "clicked" event. My initial reaction is that you might draw your camera on a button, and associate a clicked event with the button, and the callback would redraw the object w/ the appropriate colour. If you need the redraw to be done when ANOTHER event happens (e.g. some OTHER object is selected/deselected, then obviously you need to store a handle to the camera object somewhere. How this is done is left as an exercise to the reader. Common ways are: g_object_set/get_data(), creating a "class like structure", and passing the handle to that structure (or that structure instance, as the case might be), as the callback arg, global arrays/structures, etc. I find the last to be too dirty for my tastes (I like encapsulation). I find the first to be messy (but quite common, and convenient, in gtk code). At the moment, I'm gravitating towards the 2nd approach, and passing a structure pointer as the callback arg, which allows me to pass as much/little information into the callback as I need to (and it's more "class like" in it's approach). (I should hasten to point out that while I listed only 3 approaches, I'm sure that creativity can come up with others... :) I think, at the end of the day, how you organize your data will be key in how you will be able to access it, and pass it around. That is to say that your data organization will more or less dictate your choice of parameter accessability (or vice versa. if you eant to enforce from the accessability point of view, then that will dictate how the data must be organized). best rgds, -Greg +-+ Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler [EMAIL PROTECTED]| +-+ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Strange warning when adding gtk_status_bar to gtk_hbox
Just for those who are interested: I finally managed to get rid of the warning by issuing gtk_statusbar_set_has_resize_grip(GTK_STATUSBAR(_status_bar), false) before adding the status bar to the hbox. The resize grip did not make any sense anyways (just didn't know this was a property) and apparently it could not find the window it was attached to. Best regards, Torsten On Jan 28, 2008 5:02 PM, Torsten Reuss <[EMAIL PROTECTED]> wrote: > Thanks for the reply, Mikael. > > On Jan 28, 2008 3:13 PM, Mikael Hallendal <[EMAIL PROTECTED]> wrote: > > > > > I'm in the process of porting an application from GTK 1.2 to GTK > > > 2.12. One > > > thing I can't get behind is a warning I am getting concerning a > > > gtk_status_bar widget. The warning: > > > > > > Gdk-CRITICAL **: gdk_window_set_cursor: assertion `GDK_IS_WINDOW > > > (window)' > > > failed > > > > It looks odd that that the code you pasted will give this warning and > > it sounds like it's actually coming from some other part. > > I thought the saem, but I verified by debugging and by printing out > output before and after this line, that it is in fact this line. > > > Just one thing I noticed though (not sure if it is just here or if you > > actually pasted code) is that you leak a GtkStatusBar. > > In the actual code _status_bar is a member variable of the dialog > class, so the status bar is not leaked. I just pasted minimum code > here in hope that this warning rings a bell for someone, as too me it > really makes very little sense. > > Thanks and regards, > Torsten > ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
[no subject]
Hello list, let me just give a short introduction to myself before i get to the point... I´m with Gersys, a small company producing embedded platforms for railway applications ( you may look at www.gersys.de). In generel our products are small embedded pc´s running winXPe or linux in very rough environments. Normally our customers get a device running the OS and are writing their own applications. I´m an developer of Hard- and Software and an electrical engineer. My background regarding software development for now is in first instance uC-Code in C, but i´ve also done some example applications under Windows/.NET/VisualStudio/C# for some graphical UI´s... For our new project we have for the first time the task of programming a application: Our customer installs several networking cameras along some city-trains. Our device has to get up to four video streams an display them (which is not the problem for now, maybe later ;-) ) The train driver has to be given the possibility of choosing which camera(s) he wants to view. Therefore, and now we get to the point, we have to display a symbolical image of the train which represents the number and position of the cameras and realize a navigation by key inputs through them. The predefined picture shows for example a train with three combined vehicles, each consisting of four/six waggons. The waggons have up to four inner cameras and up to two outer cameras, which are reprepesented by some pie-slice-like symbols (gdk_draw_arc()...). The selected camera(s) are highlighted by some color. An event from a navigation key moves the selection to the next set. The composition of the train may vary and has to be loaded at program start, so the displayed selection image has to be created dynamically. Our developing platform is a Suse10.3-machine with Eclipse-Environment. The project is written in C and we use GTK2. Because of the above mentioned structure we have a very object-orientated approach, but due to compatibility/porting-issues we don´t want(ed) to use gtkmm (perhaps to be discused) for now. (The destination target is running eLinOS/Codeo-Environment/X-Server...) I´ve "played" a lot the last week and got some few satisfying results: The drawing of the train using standard widgets and gdk-functions has already the lookalike of the predefined image. Creating a simple widget for drawing a camera symbol and manipulating the color of it was also succesful. The main question for now i´d like to hear your opinion to is about the data structure of the project. My approach in cause of the resent results is following: Creating low level widgets (e.g. the camera symbol, a waggon...) with the necessary data variables (e.g. color, name...), which can be manipulated by the "top level program part" (the one which knows what is selected etc. ...) The widgets will be nested: The train-widget provides a array of vehicles which provides a array of waggons with an array of cameras... Accessing the object properties can be done with references/pointers to the data variables (the "normal" access to struct-members e.g.: train.vehicle[1].waggon[4].camera[3].colour = green) One of the biggest questions therefore is the structure of the necessary manipulating functions: How can i best handle e.g. the redrawing of a camera when its de-/selected (In C++ i would create a member-function to the camera-object!?). I think to create a function set for every widget which can always provide the interface for the upper "parent" instance!? Alternative there could be a set of "top level" functions, but therefore the parameters are getting kind of nasty !? I hope i delivered enough information in this vast of text to provide an overview to my problem(s) and hope i get some opinions to my approaches from you to start a productive discussion about it! Best regards Markus - Gersys GmbH, Hans-Urmiller-Ring 46c, D-82515 Wolfratshausen, Germany Geschaeftsfuehrer: Erwin Sterzer, HRB 137 872 Muenchen, Fon: +49(0)8171 9986-6 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Treeview column width changed signal
Gorshkov wrote: > Lack of patience, and the feeling that I was talking to a brick wall, to > be perfectly honest. I even posted all the code he needed to implement > the solution - and given that it was only about 20 or 30 lines total, I > wouldn't exactly call it overly complicated. The only code I did not > give him was the code to actually save the data to a file - everything > else - the signal handlers, callbacks, etc, is there. I had already implemented the solution you gave me before I resurrected the old thread. It works for restoring the column widths after exiting and restarting the program. My lengthy comments were not criticism of your suggestion but an attempt to explain why its application does not meet all of my needs in a straightforward manner. The remaining problem is that a remote section of code needs to know the column widths while the program is running. It would have been trivial to obtain the information from the file, but the file does not get updated when the column widths change, only when the treeview is destroyed. The solution which you, Dave Howorth, and even I have suggested in this thread is to read the column widths from the treeview. Usually, implementing that solution is also trivial. It is not trivial in my situation because the remote section of code does not know about the treeview. Nevertheless, the solution is practicable. Note that in my original posting I did not ask for a solution, I asked why GTK has this small limitation. I understand that there is a way to implement a solution, but I long for the solution that would have been trivial. The implication that writing the file when the treeview is destroyed is equivalent to writing it when the column widths change is wrong. Although there are cases where the two approaches are equivalent, they are not equivalent in situations that Scott and I have encountered. Moreover, the designers of Qt and wxWidgets evidently don't consider the two approaches to be equivalent because they chose to support both. My objective in posting my message was simply to encourage the designers of GTK also to support both. With that resolution, you would be free to continue to use the destroy signal and I would be free to use the column-width-changed signal, even if we were both doing so out of stubborn adherence to the familiar. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
