3000 toggle buttons in a table? (was: Button Vs Toogle Button)
Sailaxmi korada wrote: My application has to display around 3000 toggle buttons, in 178 rows of a table. It is taking almost 12 seconds to do so. Can you help me out in reducing this time. Here are the two steps that are consuming maximum time gtk_button_set_label (GTK_BUTTON(drpentry_binbutton), 1); gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON(drpentry_binbutton),FALSE); I refrain from asking who might be supposed to toggle all 3000 buttons. I rather suggest you to do without standard widgets at all when it comes to such an exorbitant number of toggles. It's right that GTK+ gets rather slow if several hundreds (or more) widgets are to be built and displayed. This is because each widget has quite some overhead, regarding its numerous memory structures, internal procedures and handlers and, last but not least, the layout calculations of the table. I rather suggest you to do some more work on your own for this rather special application. Don't use standard widgets like GtkToggleButtons and a GtkTable. If I had to manage 3000 toggles on screen, I would simply use a GtkDrawingArea and manage the display and input handling of those toggles on my own. Monitor the visible height of the drawing area, divide it by 178, then you have the average height of each button. Do the same with the width. Render the buttons on your own, that is, perhaps draw a frame, draw inside labels (you may use clipping for this), and define two different appearances for the two states of the toggles, i.e. two different background colors or different frame appearances. You wouldn't need to connect thousands of widgets to their appropriate handlers either (which would take quite some processing time and memory as well) but rather simply monitor button press and button release events within the single drawing area and calculate the pressed button number by the given mouse pointer coordinates. Maintain a simple bitmap (or bytemap) of 3000 entries, one for each button, to store and change its current state. If keyboard navigation inside the buttons field is required, you would have to built it as well. However, in such a button matrix you could achieve an even more comfortable focus navigation if you not only support [TAB] and [SHIFT]+[TAB] but also the cursor keys for vertical navigation. The number of rows you mention suggest that this would be appreciated by users. This way your button matrix would of course not be fully GTK+-theme-compliant but I guess this would be much less of a worry for you. This way you can achieve a practically instantaneous buildup (accelerated by factors of 10 to 20 compared to genuine widgets). GDK provides a fine set of drawing primitives for you. In fact, you might also consider to derive a new type of widget from your work, like GtkToggleButtonMatrix (not to be derived from GtkToggleButton), which not only you could benefit from, if it comes to similar projects in the future, but others could as well, if you decide to publish your work. Btw, on this high numbers of widgets you can certainly expect your performance problem to be the same (or even worse) on most other toolkits like QT or (especially) Java Swing. FLTK might handle this significantly faster with its builtin widgets, but doing it the way I suggested would still be the fastest, by far. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: 3000 toggle buttons in a table?
Tristan Van Berkom wrote: Gus Koppel wrote: Sailaxmi korada wrote: My application has to display around 3000 toggle buttons, in 178 rows of a table. It is taking almost 12 seconds to do so. Can you help me out in reducing this time. Here are the two steps that are consuming maximum time gtk_button_set_label (GTK_BUTTON(drpentry_binbutton), 1); gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON(drpentry_binbutton),FALSE); I refrain from asking who might be supposed to toggle all 3000 buttons. I rather suggest you to do without standard widgets at all when it comes to such an exorbitant number of toggles. Sorry if I'm jumping into a thread that I havent read... maybe this comment was already made on this thread... Why not use GtkCellRendererToggle w/ GtkTreeView GtkListStore ? Or use a GtkListStore to select your data item and some togglebuttons and whatever other control widgets below your treeview (i.e. the single toggle button applies only to the selected row) ? (Sure; writing treeview code is a pain, but its perfect for these large dataset situations). I suppose for Sailaxmi's application it is important to have all toggles clearly arranged, likely for some sort of state matrix. Using a treeview with togglebuttons below it for just the currently selected line would be the more conventional approach to avoid huge numbers of widgets but likely doesn't fit the demands. On the other hand, filling the visible area of a treeview with 3000 toggles would still result in suboptimal display performance. For (basically) maintaining the original layout while significantly increasing its build speed, I think doing all the drawing on one's own, without keeping any widget or field structures behind it, is the best way. At least it's the fastest by far. Perhaps it would be beneficial to be able to toggle multiple buttons just as the mouse passes over them while the mouse button is being pressed? This could be accomplished with a custom implementation as well. Think of The Gimp with a 16 * 178 B/W bitmap. There's no way of implementing such behaviour (one button press, multiple state changes) with any standatrd means. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gdk_threads_leave in gtk callback ?
Vladimir wrote: Thanks a lot for comprehensive explanations. There are two uses of GTK+ in non-main threads: 1. error reporting via message boxes and 2. adding text (which comes from network) to GUI windows. I can do both of it in main thread but this involves copying text to dynamically allocated buffers. There shouldn't be any additional buffer copying required just because dealing with it moves from one thread to another. You know, all threads have the same access to all program data. More reasonable would probably be to copy just pointers to the buffers between threads. For instance, provide just two pointers like these: gchar *text_for_msg_box; gchar *text_to_add; Most of the time they'll be NULL. The main thread occasionally checks whether they have become non-NULL, for instance within an idle or timeout handler. If they have, then that handler (in the main thread) either displays a message box or adds the text to your windows. When finished, it clears the pointers again. They would be set by the other thread(s) only, of course. Slightly more sophisticated buffer management might be necessary if you expect new data to come in and be handled by the other thread while for instance a message box is being open. However, necessary measures are the same, no matter whether you display the message box from within the main thread or from any other thread. BTW, can I use g_idle_add in non-main thread without locking ? I am not sure. The documentation is not clear about this and I havn't had the time to examine the sources of that yet. To be safe, you should wrap a simple GStaticMutex lock around the call. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gdk_threads_leave in gtk callback ?
Vladimir wrote: There are two uses of GTK+ in non-main threads: 1. error reporting via message boxes and 2. adding text (which comes from network) to GUI windows. Btw, if you don't use modal message box dialogs then there is absolutely no need to use multiple threads (aka one to receive, the other one to display) at all. One single thread can perfectly handle this chain of actions: - wait for data from network and receive into buffer if there's any - add received buffer data to a text display - open a (non-modal) message box to report errors if there are any The non-modality of the dialog assures that reception anmd display of incoming data would continue at the same time. For instance, if you use select() or poll() to wait for network data in the other thread, better have a look at this: http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#GSource http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#g-source-add-poll This way you can do completely without multiple threads for all sorts of asynchronous I/O regarding network traffic and GTK+ visualization. Doing without threads is always easier to debug and also prevents creating some hard to find bugs while writing the code. Unless your application includes massive computations of data (in which multiple threads can be beneficial on multi-core systems, indeed), single-threaded apps may also save a tiny amount of CPU time and code size, since there is no need for thread switches and mutexes and all that stuff. So, if there are no other reasons for multiple threads than being able to receive and display simultaneously, you should perhaps consider to abandon the multi-threadity of your application at all? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gdk_threads_leave in gtk callback ?
Gus Koppel wrote: Vladimir wrote: There are two uses of GTK+ in non-main threads: 1. error reporting via message boxes and 2. adding text (which comes from network) to GUI windows. Btw, if you don't use modal message box dialogs then there is absolutely no need to use multiple threads (aka one to receive, the other one to display) at all. One single thread can perfectly handle this chain of actions: - wait for data from network and receive into buffer if there's any - add received buffer data to a text display - open a (non-modal) message box to report errors if there are any The non-modality of the dialog assures that reception anmd display of incoming data would continue at the same time. Sorry for talking with myself, but I think that in fact it doesn't matter whether there's a non-modal or modal dialog. Single-threaded, asynchronous data reception and visualization (inside a main window) can still be accomplished, since a modal dialog should not block input sources or idle or timeout handlers of a main loop, if I'm not mistaken. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: run time issue- on gtk_widget_show()- Xlib:unexpected async reply
shibu alampatta wrote: during runtime I'm getting the message Xlib:unexpected async reply (sequence 0xbe8) while trying to show a window. The senario is , In my multi window application,from a thread i'm calling a function, which contains the lines as below GtkWidget *mywindow; . mywindow=create_mywindow();// this line is wrking fine gtk_widget_show(mywindow); .. while executing gtk_widget_show(mywindow) it is showing the above mentione message and not showing the window. Please see the following thread: http://mail.gnome.org/archives/gtk-app-devel-list/2006-March/msg00310.html Optionally also: http://publibn.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixprggd/genprogc/writing_reentrant_thread_safe_code.htm#HDRA5CMFJ3B0MANU http://developer.gnome.org/doc/API/2.0/gdk/gdk-Threads.html http://developer.gnome.org/doc/API/2.0/glib/glib-Threads.html http://developer.gnome.org/doc/API/2.0/glib/glib-Threads.html#GMutex http://developer.gnome.org/doc/API/2.0/glib/glib-Threads.html#GStaticMutex In short: writing multi-threaded programs requires a lot more care and knowledge than just how to start another thread. Without knowing about these concepts: don't do it! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Callbacks and widgets
Gonzalo Aguilar Delgado wrote: 1.- Passing a data structure 2.- Using global variables (not good threading support) 3.- Passing window to gpointer and searching. But the point is. What is the best way? Is there any other way to do that? Because structure option looks more suitable for different data to be passed not just widgets... I tried to set the widgets as user-data of the widget to be triggered. But it seems not to work. I have a 4th way to offer. I also use to access arbitrary widgets from within widget's signal handlers frequently. I don't keep all widgets to be reachable as global variables nor do I define or pass any data structures to the handlers. My way has proven to be quite comfortable at source level, since the only precaution you need to take is to assign names to those widgets you want to refer to, and to provide just one globally accessable variable per window. The tiny performance impact by this function is absolutely negligible at runtime, even if you perform 100 widget searches in a row. http://www.spamkiller.bytechase.cx/democode/widget_find_by_name.c ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gdk_threads_leave in gtk callback ?
Vladimir wrote: I'm writing program with several threads each of which uses gtk. I need to wait for one of the threads in gtk-generated callback. I can't do it directly because of gdk lock. So the question is: can I temporarily release gdk lock in gtk-generated callback ? Will it cause any problems ? You should know that accessing GDK / GTK+ functions from different threads is bad programming practice, because GTK+ is not thread-safe. Trying to compensate this properly on application side (using gdk_threads_enter() + gdk_threads_leave() ) would result in quite some code overhead, likely some performance penalty and is error-prone. Even worse sounds the idea of waiting for something inside a GTK+ callback. They are supposed to finish as quickly as possible. Everything else sounds like great potential for deadlocks. So the answer is: no. Even if your app doesn't crash immediately, it may do so sometime later in arbitrary states, possibly leaving you with no trace where to search for the cause of the crash. Generally, the better way would likely be, to set a global flag when the thread you want to wait for, finishes. A GTK+ handler must not wait for this, but rather be able to deal with both situations appropriately: either the other thread hasn't finished yet, then exit immediately. If the other thread has finished, then do what you originally wanted to. If your handler is not supposed to be executed at all before the other thread has finished, then you should prevent the handler to be called, rather than attempting to wait within the handler until the other thread finishes. You know, there are multiple options for preventing handlers to be executed. You're free to use multiple threads for arbitrary computations within your program. But you really should not access GTK+ / GDK from within each of them. It makes programming more complicated and error-prone and the graphics output a bit slower (due to all the thread locks that need to be provided). Leaving all the GDK / GTK+ stuff to just one thread would definitely be the better idea. Since you started with programming multiple threads you should also know how to signal a central GTK+ / GDK thread what to do from other threads, don't you? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Reducing space between treeview rows
Doug McLain wrote: I am trying to reduce the spacing between rows of text in a single column treeview. Ive been experimenting with both the ypad and height properties. They both work in adding space, but neither will take any space out. Seems like anything less than about ypad=3 doesn't do anything. With a font size of 8, there is almost enough space between rows to fit another row in between them. Even trying a tiny font size for troubleshooting purposes, doesnt bring the rows any closer together. Can someone help, please? If it's not because late GTK+ versions have changed their behaviour here then likely your current GTK+ theme is interfering with your pad setting. Try some other themes. Basically, ypad = 0 should make a difference. I use it, too. Unfortunately, as also the vartype shows, negative ypad values are not supported. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Theme not affecting titlebar on windows xp... help needed
Michael L Torrie wrote: On Sat, 2006-03-18 at 00:38 +0100, Gus Koppel wrote: However, then you would have to manage all tasks the window manager takes care of by yourself, i.e. minimizing and maximizing the window on request and providing correct drag behaviour. For resizability of your windows you would still have to rely on the real window manager, since the resizing borders don't (and can't) belong to the interior of a window. To do resize, you can just detect a mouse drag that starts in, say the lower right-hand corner, and then give the real window manager hints to resize the window. This would work on linux and windows. This is how xmms does it (gtk1 app, though). This is true if mouse move events are reported to the application even when the mouse pointer has left the inner area of the window. A long time ago I was experimenting with this and at that time I didn't succeed. Not sure whether it was with GTK+ at that time, though. So I thought mouse move events wouldn't be reported to a GTK+ application when the pointer is outside its window. But apparently in GTK+ this should happen, indeed? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkProgressBar getting blocked
jim Pharis wrote: I have an external synchronous library call that takes a while to complete. I want to display a progress bar well I'm waiting. The problem is, even when the progress bar is in the thread in a loop calling gtk_progress_bar_pulse, the progress bar still looks like its frozen. Graphical updates (or any other signs of life in a GTK+ application) only occur when the GTK+ main loop gets entered. This is either the case when a handler (your library call) finishes or gtk_main_iteration() gets invoked from within a handler. You will want to use the 2nd method. Basically, after each gtk_progress_bar_pulse() you should do this: while (gtk_events_pending ()) gtk_main_iteration (); See: http://developer.gnome.org/doc/API/2.0/gtk/gtk-General.html#gtk-events-pending Possibly also helpful for your understanding: http://mail.gnome.org/archives/gtk-app-devel-list/2006-February/msg00266.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Handling Unix signals in a GTK+ application
Chris Vine wrote: On Saturday 11 March 2006 22:36, Thomas Okken wrote: [Using a pipe] is generally the best way of dealing with asynchronous (Unix) signals, but for simple cases another approach is just to set a flag of type volatile sig_atomic_t in the Unix signal handler, and then check and act on the status of the flag in the glib event loop with an idle handler set up with g_idle_add(). The downside of that approach is that you have to busy-wait on that flag, while the pipe approach allows the application to be completely idle (and still have fast response to the signal)... I went with the pipe approach; using the sample code referred to by another poster, it turned out to be pretty easy. That's not right. Idle handlers do not busy wait. They do trigger invocations of the event loop at indeterminate intervals. They are also very common (if you don't want to communicate with the glib event loop from other threads with a pipe, you are likely to end up with using a GAsyncQueue object and an idle handler). The main problem I see with idle handlers is that there may be application types on which they rarely or never get triggered, simply because the app doesn't go idle. This is commonly the case for games and multimedia applications, which may consume all CPU power there is, possibly generating their own GTK+ signals for redrawings or other tasks all the time, or other sorts of applications which perform long calculations and may see the main loop only via gtk_main_iteration() if there are events pending. Such applications wouldn't enter idle state (hence not triggering the idle handler) for potentially long periods. On the other hand, news from a pipe could still be received and processed nearly instantaneous, as they have higher priority than idle events. However, if you know your application belongs to the majority of GTK+ applications, that is, it stays in the outermost main loop, spending most of its time actually being idle, then using the idle handler may be appropriate. But as explained, it's not quite as fail-safe as pipes. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Can a treeview do this?
kadil wrote: I may not have explained myself very well in my question to the world. To describe it in words, I want: (1) the first child to be in the column next to the parent. (2) subsequent children to be below the first child (3) parent cells are to vertically span the child rows (4) I need visible borders between the cells (5) Just to be difficult, I want to code in csharp (mono and friends) (6) Accommodate thousands of rows with responsive performance. | Function | Funct Failure| Failure Mode | |to be able |slow leak | worn washer | |control the| |-| |rate of fl-| | damaged seat| |uid passing|--|-| |thru the |unable to control | seized | |device |flow at all |-| | | | frozen | || I think your sketch is quite clear. Your demands 1 to 4 can be fulfilled by using a GtkTable with GtkLabels inside GtkFrames in each cell, as I described. I don't know about late developments in GTK+ bindings for C# but I think there should be support for it. At least this is being worked on, AFAIK. As I prefer easiness over difficulty and native performance over losings related to emulation, I stick with C when programming GTK+. Only weak point in the GtkTable based concept may be your demand of much content in the table. However, I'd say you should give it a try. I think building such a structure of thousands of widgets is the main performance bottleneck. Display and navigation within such a GtkScrolledWindow isn't necessarily that slow since GTK+ 2.x should contain some appropriate optimizations to handle this, I think. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Can a treeview do this?
kadil wrote: I don't think a treeview can render this tree structured data that way I wanted. The way I want it and the type of data is shown below: | Function | Funct Failure| Failure Mode | |to be able |slow leak | worn washer | |control the| |-| |rate of fl-| | damaged seat| |uid passing|--|-| |thru the |unable to control | seized | |device |flow at all |-| | | | frozen | || Any ideas, comments warmly received. No, I don't think a GtkTreeview can display this sort of structure. However, this sort of layout can perfectly be achieved by utilizing a GtkTable (instead of GtkTreeview). The Row Span property of cell widgets in a GtkTable is to be set here. It's the very same as in HTML 4 tables, for instance. By doing this you're also not limited to simple drawn items like texts or bitmaps in the cells but can easily put any widget into them, i.e. buttons. To get closest to the appearance you sketched I suggest to use a GtkLabel in a GtkFrame for each cell. Main drawback is that if you're about to use more than 50 rows like this via a GtkTable, some performance degradation may start to take place. But for structures with limited numbers of cells this is negligible. Btw, GtkTable should be put into a GtkScrolledWindow, to handle the situation when there are more rows (or columns) to be displayed than the window dimensions allow - offer scrollbars in that case. It's the same way original GtkTreeViews work. I already created an example of your desired layout type but I'm afraid its Glade XML or .c code is a bit too long to include here (~10 KB). ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Syd Logan source code
Nimmo, William K @ TITAN wrote: I apologize if this has been addressed previously. I have bought Syd Logan's book GTK+ Programming in C. The link referenced in the book to obtain sample code is a dead link. Does anybody know where I can get the sample code? You should either 1. ask the author or publisher of the book this question, 2. provide us the URL of the dead link, possibly with a short description what it is supposed to contain (according to the book), so that someone could possibly name a suitable substitute, even if noone else owns or knows this book, 3. utilize any of the countless other source code examples, references, fragments and programs or GTK+ tutorials that can be found at various places in the internet. Google or yahoo (or whatever) for them. If the book gives some keywords for the source samples you may even be able to locate them via search engines. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: displaying continuosly in entry widget
shibu alampatta wrote: On pressing a button i wanted a list of text to be displayed on entry widget, on after the other ( in a for loop), with some delay, say sleep(3). but the problem is the last text only getting visible. if i increase the sleep argument then also the same. any help.? In short: - NEVER use sleep() or similar in GTK+ apps - make all your handlers return as quickly as possible to GTK+ - use a timeout handler for periodic events, such as text changes In long: sleep() (or nanosleep() or similar) MUST NOT be used in any GUI program! They are of use for old style console or daemon programs only. There, your application usually is in full control of execution, scheduling of events, delays and even the entire (text) screen. GUI programs work fundamentally different. In a GUI application (a GTK+ application in our case) it is GTK+ that has full control over your application. You hand control over to GTK+ when entering gtk_main() loop. From that point on, execution of your application is basically limited to particular functions (handlers), which are called by GTK+. It's basically up to GTK+ when and in what order they are called. Your handlers may be arbitrarily complex. They my call numerous other functions, your own ones or GTK+ ones. Handlers for buttons or menu entries may even open new windows or dialogs. However, all handlers have one thing in common: they are supposed to return control to GTK+ as quickly as possible. Especially without artificial delays (like sleep () or similar)! Returning control to GTK+ means either finishing a handler function that has been called as quickly as possible, or for instance calling the GTK+ function to open modal dialogs. Graphical updates, i.e. of your text, can take place only while GTK+ is in control of program execution. The standard widgets get updated / redrawn automatically when your handler function returns to GTK+. While sleep()ing, there is no return to GTK+, but the whole process is put asleep instead. Since it's the process itself who is responsible for redrawing the widgets, there will be no redraws (and no other sign of life either) while being asleep. If you want to let your application carry out tasks on a periodic basis, i.e. changing text of a GtkEntry, you have to do it another way. You have to inform GTK+ that you want to do something every i.e. 3 seconds. You do this by calling gtk_timeout_add() or g_timeout_add(). It gets a function you provide as an argument. It informs GTK+ that this function wants to be called every 3 seconds. Then, if GTK+ is in control of program execution as it is supposed to be, it will call this function every 3 seconds, indeed. This function of yours should do nothing more than changing the text of the GtkEntry in the desired way (probably just one call to gtk_entry_set_text() ) and return to GTK+. As soon as control is returned to GTK+, the widget will be redrawn. When you don't need the periodic update any more, you just destroy your timeout handler by one of the described means. See: http://developer.gnome.org/doc/API/2.0/gtk/gtk-General.html#gtk-timeout-add http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#g-timeout-add ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to identify the idle state of the GTK+ application?
Daniel Atallah wrote: On 2/15/06, Matt Hull wrote: that like what gaim does ? Yes, gaim does essentially the same thing. http://cvs.sourceforge.net/viewcvs.py/gaim/gaim/src/gtkidle.c?rev=1.12view=markup On Wed, 15 Feb 2006, Martyn Russell wrote: Gossip needs to know how long the user has been idle (with no mouse movement or key presses) for setting users to an away state, this might be useful: http://cvs.gnome.org/viewcvs/gossip/src/gossip-idle.c?rev=1.8view=markup A small addendum to the way I suggested (installing an own GPollFunc to keep track of whenever a main loop iteration occurs, see http://mail.gnome.org/archives/gtk-app-devel-list/2006-February/msg00164.html ) Possibly gtk_get_current_event() could help to determine whether the main loop iteration was triggered by any mouse or keyboard event or by something else, within a custom GPollFunc. This way would have two different features, compared two either writing a genuine screensaver module or the way Gaim Co determine this: 1. it would work in a unique, platform-independent way, i.e. no need for any sort of #ifndef _WIN32 at all (even if the Win32 branch is very small, indeed) 2. it would determine the idle state of the GTK+ application only, not of the entire desktop (including events of / for other running apps). I understood the question as this could be the actual goal. However, for performance reasons, gtk_get_current_event_time() or gtk_get_event_widget() may be even better suited for this purpose, as they do without object allocation (and your requirement to deallocate it) within each main loop iteration. I think all main loop events that should reset your idle timer would be bound to any widgets of your application. So if the iteration has an associated widget (as keyboard and mouse events should do) you would likely reset the idle timer. If there's no widget you would increase or check your idle timer since probably other internal events trihggered the main loop iteration. See: http://developer.gnome.org/doc/API/2.0/gtk/gtk-General.html#gtk-get-current-event ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to identify the idle state of the GTK+ application?
sadhees kumar wrote: In my GTK application, If no action(event) is taken place in the screen, I need to turn OFF the backlight of an TFT monitor. If any key pressed, or mouse movement occured, I need to turn ON the backlight. I have the API for toggling the backlight. My problem is , how to identify the idle state of the screen? First, I hope you know that your GTK+ application usually doesn't represent (or own) the screen. It's just one application of possibly many, which have windows opened and wait for any user actions or system events to take place in order to process them. Via GTK+ you can control and monitor only your own application, not other ones. While your application could think it's idleing, other applications (or applets) could feel quite busy at the same time. So intending to turn on / off the screen based on whether your application feels idle or not sounds inherently unsuitable, if not dangerous. However, there are two exceptions when you can assume that your application has full control over the entire screen. I don't suppose any of them apply to you. They are 1. GTK+ on framebuffer and 2. GTK+ Cursed. Apparently both of them are not well (or not at all) maintained lately. Back to your actual question: what you want are two things: 1. determine whenever the main loop executes an iteration 2. get informed when there are no main loop iterations for some time. I have no detailed solution for your question at this time, but I can point you at some areas which you should examine. I think you should use g_main_context_set_poll_func() for your program to be informed about every main loop iteration that takes place. Your own function should do three things: 1. determine whether the iteration was caused by a timeout event 2. set a global timestamp flag if not caused by timeout 3. call original poll() function to maintain operational reliability Use g_timeout_add() to install a function to be called periodically to check how old the last main loop iteration timestamp is. If now() - timestamp backlight_turn_off_wait_time then you turn off the backlight using your own API. The main problem of this strategy is to determine within your own GPollFunc whether the main loop iteration was triggered by the timeout function or by anything else. The timestamp must be updated only if not your timeout function was triggering the iteration. There's no easy way to determine the sort of event that triggered the main loop iteration within your GPollFunc. You will have to study GLib sources to check whether there's a somewhat clean way to determine the type of event from within it. It's not going to be easy stuff. Creating an ordinary screensaver-like process would be easier, indeed. See: http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#g-main-context-default http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#g-main-context-set-poll-func http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#g-timeout-add ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: About layouts
Fernando Apesteguía wrote: I'm developing an app with gtk. I use glade for GUI development. My question is about the different kinds of layouts. I would like my app resizes by itself when a label text is really long. I've noticed I can do this by placing a table layout (I think vbox and hbox work well too). In fact, this behaves well even when changing fonts dpi (This is the answer to my question that you can see at http://mail.gnome.org/archives/gtk-app-devel-list/2006-January/msg00064.html ) But my app has a lot of labels and buttons so I estimated I need a lot of layouts creating a complex hierarchy (vbox inside a table layout, inside a hbox, inside a table layout again...) Did I forget a simply way to make this?? Your question is not quite clear to me. It seems to be about two issues: 1. auto-resizing of labels, 2, what containers to use for your layout. Regarding GtkLabels: automatic resizing is their default behaviour, regardless of which sort of container (Gtktable, GtkVBox, etc.) it is being put into. Example: when working with Glade, just create an empty dialog window. Drop a new GtkLabel into it (directly into the window, without additional layout containers). Make the window as small as possible (not via the minimizie button). You will see that you can't make the window smaller than the dimensions needed by the GtkLabel to have its text (should be label1 or similar) fully visible. In Glade's properties window, when you type in additional text into the Label property of the GtkLabel, you can see the window grow as you type. Again, this is the default behaviour of GtkLabel (and most other types of widgets as well) and is not bound to particular containers like GtkTables or Boxes. However, if your texts may get really long, this behaviour shouldn't actually be what you want. Especially if the label has disabled its wrapping property, restricting the label text to just one line, the horizontal size requirement by the label may easily exceed the screen's dimensions, making the window wider than the screen as well. This would make your application basically useless. There are three common strategies to consider if you're planning to deal with display of really long texts. They aim at avoiding unrestricted size requests by the GtkLabel: 1. enable the wrap text property of the GtkLabel 2. put the GtkLabel into a GtkScrolledWindow 3. use GtkTextView instead of GtkLabel, with editable property unset. Regarding the other aspect of your question: what layout containers to use and the extent of complexity is determined solely by what layout you actually want to achieve. For instance, having 20 rows with each one consisting of a GtkButton and a GtkLabel next to it, and all widgets aligned vertically, is quite a simple layout. You would only need one GtkTable with 2 columns and 20 rows for it. You could also easily use 10 rows with 4 columns (button, label, button, label) each with the same single table. More complex layouts require additional layout containers, of course. You didn't provide any idea what sort of complex layout hierarchy you want to achieve so I can't give more detailed recommendations. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: About layouts
Fernando Apesteguía wrote: First of all, thanks for your suggestions. Actually my app. uses a static layout and the GtkLabels inside this, don't grown when the text becomes longer. The same GtkLabel behaves ok if it is inside a GtkTable. So I think I will change the static container. By static container you probably refer to a GtkFixed container? Yes, you should change that. GtkFixed (for static layout) should be considered pretty deprecated. Obviously a static layout container contradicts the concept of dynamic (re)layout. And the native concept of GTK+ GUI design and layout is highly dynamic. GtkFixed is mostly a courtesy for programmers from other GUIs, like the MS-Windows or QT ones, where static layout is the default and has a long history. Some of them tend to have problems getting used to more modern GUI layout and keep asking how do I specify X and Y coordinates of my buttons? To modern GUI layout processes, this question simply doesn't apply any more. Dynamic GUI design by using dynamic GTK+ containers is the modern way of flexible GUI design. This way, widgets don't have any sort of absolute X or Y coordinates nor static widths or heights. Instead, only the basic layout (their positions, sizes and optionally gaps relative to each other) are specified using layout containers. At runtime GTK+ then dynamically calculates the absolute positions and sizes of widgets within windows. This way also honors themability better than static layouts, since different themes may use different font sizes and hence require different dimensions for all sorts of texts. I think except when you're dealing with many bitmaps in a dialog and their pixel-wise layout is really important (which it usually isn't): don't use GtkFixed at all! My app uses a menu bar and a GtkNotebook. In every tab, I have several GtkLabels and ProgressBars. So if I choose to use non-static containers I think I'll need two or three GtkTables for each tab.I have three tabs now but it is expected to have at least five. If their layout is supposed to be aligned (as sketched in my previous posting) then you would need just one GtkTable for each tab. For more sophisticated layouts, more layout containers would be needed, indeed. If I change the static layout + label for a deeper containers hierarchy (three levels for example)... will I have a lack of performance when loading the UI? Basically: no. Generally, the number of widgets (including containers) is more important in terms of decreasing the performance than their layout and nesting is. On sub-GHz machines you should be on the safe side for numbers of up to about 200 widgets per dialog. However, yet there are two methods of loading the UI supported by Glade: 1. the UI definition is stored in an XML file and being loaded and parsed by libglade on each start of the application. 2. the UI definition is stored hardcoded, in binary form within the executable. There are a number of benefits and drawbacks of both of these ways. They have been subject of intense discussions already, and I don't want to repeat them here. Just this much: the libglade way is slower than the hardcoded way at execution time. On the other hand, at compilation time, the libglade way has no additional performance drawbacks, while especially for very complex UIs the hardcoded way may consume several extra minutes for every compiler run. The actual display speed is the same on both methods, just load times may vary. I should also note that the code output of Glade is planned to be removed in future versions, which some people (including me) regret. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Font antialiasing on X (was: Re: Font Contrast)
MEA-Mike.Friedrichs wrote: This may be the wrong place, but since I have a question about Gnome, which is built with GTK+, I may be in the right place. I have installed Novell's Suse 10.0 and having problems getting the font to show their true colors and sharpness on the edges. When I pick the font color to be black on a white back ground, the black always shows some gray tones, and ragged on the edges. I've tried as black as I am allowed but always ends up with gray tones. There must be some setting that allows me to get good clean black characters. By, the way I'm using *.ttf fonts. I've also imported the fonts from my XP machine, this was an recommendation, but not the solution. This question is related to rather generic X-Windows behaviour and neither to Gnome nor GTK+ nor application programming, indeed. For instance, the same applies to QT-based applications (KDE). Anyway: The font rendering effect you're referring to is called antialiasing. It's meant to make fonts appear smoother on screen, especially at small sizes or low screen resolutions, by using intermediate colours at the edges. The same effect basically takes place on MS-Windows font rendering and in nearly all modern 3D games, btw. While this effect is considered an improvement of display quality by the majority of users, some users may not like it or there may be some situations (certain fonts at certain sizes) when antialiasing seems not appropriate and may rather worsen the appearance. Hence, the effect can be turned off. In X-Windows it's nowadays controlled by the Xft + Fontconfig library. Unfortunately AFAIK there is no way to thoroughly configure use of antialiasing via Gnome, so you will likely have to edit the config file manually. The advantage of doing so is, that you can not only turn on or off antialiasing entirely, but also enable or disable it for particular fonts at particular sizes and such stuff. The file to edit should be /etc/fonts/font.conf. It's an XML file, so you may need some basic knowledge about XML to understand it. Unfortunately it has a rather complex (I'd say: bloated) structure, so it may not be easy to understand. Anyway, you can turn off antialiasing entirely by inserting a statement like this: match target=font edit name=antialias mode=assignboolfalse/bool/edit /match For further information see also: http://en.wikipedia.org/wiki/Font_rasterization http://en.wikipedia.org/wiki/Antialias http://www.fontconfig.org/fontconfig-user.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/x-fonts.html http://keithp.com/~keithp/talks/xtc2001/paper/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Threads/IPC/???
Ed Kutrzyba wrote: I am developing an application that controls a Data Collection System. I used glade and anjuta for my GUI and C backend control coding. My program works great, but I need to add some extra backround tasks: 1) I need to run a script (perl or bash) on demand without interfering with my program. i.e. the script runs in the background so GTK is still responsive. http://developer.gnome.org/doc/API/2.0/glib/glib-Spawning-Processes.html#g-spawn-async 2) I need to spawn a task to perform some background operations. i.e. get time from an add in board, arm and disarm an interrupt routine that time tags an external signal -- need to start and stop this on demand. What is the best way to do this? http://developer.gnome.org/doc/API/2.0/glib/glib-Spawning-Processes.html#g-spawn-async-with-pipes In general, see: http://developer.gnome.org/doc/API/2.0/glib/glib-Spawning-Processes.html I have some code from the vendor to control the add in board, I just need to massage it to fit into my app, my way. See also: http://mail.gnome.org/archives/gtk-app-devel-list/2004-April/msg00171.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Refreshing gtk window without any mouse/keyboard intervention
Nisha P Kurur wrote: We are trying to create a gtk application which should run without much of manual intervention. Few buttons are placed in a row and each button has an image at the top which changes to red on selection. This image changes to green when the button goes out of selection. So the whole process has to be done in a scan mode without any manual intervention. The problem with our code (attached with this mail) is that the events are generated and the callback functions are called. But the window is not refreshed properly. The window gets updated only when there is any mouse/keyboard movement. 1. using the sleep() function in a GUI application is very bad programming style by all means, even if taking place in a custom thread. It's a relict of shell programming. You should rather use gtk_timeout_add() or g_timeout_add(). Probably you can even do without multiple threads then, which may avoid some hard to find bugs in the future and makes debugging much easier. See: http://developer.gnome.org/doc/API/2.0/gtk/gtk-General.html#gtk-timeout-add http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#g-timeout-add 2. you have to make sure that GTK+ can pass through its main loop for changes to be drawn. In a single-threaded application this would have to happen after your g_signal_emit_by_name() calls. See: http://developer.gnome.org/doc/API/2.0/gtk/gtk-General.html#gtk-main-iteration-do 3. you probably know that the switch-case tree of your example is bloated, i.e. contains much redundancy which could (and probably should) be avoided. Of 7 statements, 3 are completely identical and the other ones could be unified by simply using your index variable instead of distinct constants to pass to the respective functions. Add a little list of const strings for the xpm_label_box() call and you can do completely without a switch-case, that is, with only 1 instead of 9 blocks of that code. Golden rule of programming: _never_ use the copy paste feature of your text editor for more than three or four lines of code, especially not multiple times! Write sub functions (or in this case: just restructure a code block) instead. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How To Draw a window without an option to Maximize it
Amitesh Singh [EMAIL PROTECTED] wrote: How to Draw a Window without an option to Maximize it ? i have also tried to do the same using gdk_window_set_decorations (); but its not working !! :( gdk_window_set_decorations() is basically the right function call to achieve what you intend, indeed. However, decorations (buttons) like maximize, minimize and such are maintained and controlled by the window manager, not by GDK nor GTK. All this function can do is to ask the window manager to set or unset desired window style properties. It really can't control or enforce the window manager to honor this request. It's up to the window manager to pay attention and to style window borders appropriately. It's important to understand that the window manager is a piece of software which is completely independent from GTK+ / GDK. The same window manager may also control Motif or QT based software which may be running concurrently. As you probably know, there are dozenillions of different window managers around (in the Unix world). The way and extent to which they honor decoration requests varies greatly, from complete ignorance (non-support) to full compliance of all feature combinations. The window managers of various MS-Windows versions (there's only the default one for each version of Windows) are known not to fully honor all combinations of decoration requests, either. They support some combinations of window features but don't support others. So if a function call like the above one doesn't produce the correct result on your machine, then it's a matter of your window manager (perhaps of the window manager theme you use). It will look correct on some other machines with other window managers, but there's nothing you can do to enforce the correct look on all machines. Some window managers may even offer a user option to never suppress buttons like maximize or minimize, as some users may prefer to have *all* their windows resizable and maximizable, whether the application properly supports it or not. In general, there should be very few situations when it makes sense to suppress the maximize button (or resizability) of windows. This is true for both toplevel and dialog windows. While in the MS Windows world this artificial restriction of user's freedom has a long tradition, in the Unix world the opposite is the case, hence the varying support of it. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Experience with libgnomeprint/libgnomeprintui?
Bartek Kostrzewa wrote: Also, since my goal is but the printing of an image I was wondering whether you knew of some simple way of passing the image to something else and having it print it. Any help is greatly appreciated. Perhaps a look at the printing code of The Gimp could provide you with useful insights here? Although reportedly not really being a clean reference implementation for printing output, it should do basically what you want: processing and passing image data to something else, suitable for printing. Other than libgnomeprint, The Gimp is not limited to Unix but also runs (and presumably prints) on Windows. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Howto make GtkRadiobutton text flicker (was: Re: I have a problem with GtkRadioButton)
yeajchao wrote: However, the need for some applications to use fixed colours like green, yellow and red to indicate things like error-free results, warnings, error messages or critical choices / operations is recognized. That's why you can rather easily change colours and appearances of texts on screen. See the following URL for an overview of how to change text appearances of markup-enabled widgets even easier than tweaking themes: First,thank you very much for your advice As you say, I want to use the radio button as a alarm, Usually,alarm's color is red My application controls some peripheral instrument, when my application detected some one broken down the alarm will be flicker with red color I am a beginer of gtk, also beginer of program,so I have no other idea toresolve the problem Will you be so kind as to give some advice ? First: you really should forget about manually recolouring the knobs of radiobuttons, checkboxes and other controls. Recolouring just texts is sufficient for this purpose and can be accomplished almost easily. To make text(s) in dialogs flicker there are about four steps to be taken. I assume you have your standard GtkRadiobutton* (the one to be recoloured) within reach. In this example I will call it rb_flicker: 1. learn about Pango's simple markup to apply custom colours (and other styles) to labels. See: http://developer.gnome.org/doc/API/2.0/pango/PangoMarkupFormat.html 2. obtain the GtkLabel that is (usually) associated with a GtkRadiobutton. The simpliest way to get it is about this: label_flicker = gtk_bin_get_child (GTK_BIN (rb_flicker)); See: http://developer.gnome.org/doc/API/2.0/gtk/GtkBin.html#gtk-bin-get-child 3. use gtk_label_set_markup() to change the appearance of the label once, something like this: gtk_label_set_markup (label_flicker, span foreground=\red\This is critical/span); See: http://developer.gnome.org/doc/API/2.0/gtk/GtkLabel.html#gtk-label-set-markup 4. to actually achieve a flicker effect (periodically changing appearance) you manually have to change the markup text of the label periodically. There are no automatic means to achieve any sort of animation in GTK+. Use one of gtk_timeout_add() or g_timeout_add() to register a simple function which periodically switches between two (or more) states of the label, like 1. span foreground=\red\This is critical/span and 2. This is critical. This switches between red and default colour of the text. Upon registration, this simple markup changer function should receive the GtkLabel of the GtkRadiobutton as its data, like this: gtk_timeout_add (500, func_flicker, label_flicker); See: http://developer.gnome.org/doc/API/2.0/gtk/gtk-General.html#gtk-timeout-add http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#g-timeout-add Notes: Step 2, as described here, assumes you are using a simple radiobutton, that is, a GtkRadiobutton with exactly one GtkLabel attached to it. GTK+ also supports more complex radiobuttons which have containers and multiple children, i.e. images, attached to them, instead of just a simple GtkLabel. In that case locating the GtkLabel would require some more efforts. Step 4: it is up to you to take care to stop the periodically called timeout function. For instance, when the dialog that contains the flickering radiobutton gets destroyed, the flicker function MUST NOT continue to try changing the appearance of the radiobutton's label any more. Removal of your timeout fucntion does not happen automatically! After all I'd like to repeat: you shouldn't play with the appearance of GTK+ widgets in a custom, non-themable way unless absolutely required! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: question about combo box
yeajchao wrote: I have a question about GtkcomboBox You know,every combobox have a GList which stores some optional item. My problem is about the GList. When I click the triangle to pull down the list, and move my mouse to select item, the highlight item didn't change from one item to another when my mouse moves from one item to another. The thing I want is that: when my mouse is on item A,the highlight item is item A; when my mouse is on item B,the highlight itme is item B. How can i do that ? Simple answer: don't just single-click the triangle but keep the mouse button pressed while moving down over the popup list. Complex answer: you are referring to some very fundamental GTK+ behaviour. To my knowledge, this behaviour can't be changed easily, not even by themes. I think there should be a chance to manually highlight list items when the mouse moves over them (without any mouse button being pressed) by intercepting certain signals. I haven't tried this and it's generally not advisable to attempt this, for about 4 reasons: 1. you would need to program this non-standard behaviour for every single combobox of your application, 2. the behaviour of other GTK+ applications wouldn't change by this, 3. this different behaviour between your and other GTK+ applications would most certainly irritate users, 4. the change in behaviour appears to be so fractional that apparently noone else considered a change of the standard behaviour (or even complained about it) as yet. An always open alternative for you would be to (re)write your own CustomCombobox widget. Then you can implement exactly the behaviour (and look) you intend. But again, this would most certainly irritate more people than being regarded a benefit. Not to mention the amount of time you would have to spend for this. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: question about combo box
Georg Fritzsche wrote: I have a question about GtkcomboBox You know,every combobox have a GList which stores some optional item. My problem is about the GList. When I click the triangle to pull down the list, and move my mouse to select item, the highlight item didn't change from one item to another when my mouse moves from one item to another. The thing I want is that: when my mouse is on item A,the highlight item is item A; when my mouse is on item B,the highlight itme is item B. How can i do that ? Simple answer: don't just single-click the triangle but keep the mouse button pressed while moving down over the popup list. funny thing, for me it works both ways... either i misunderstood what exactly the desired behaviour is or the problem is not gtk-, but windowmanager-dependent. I've been verifying the behaviour on both GTK 1.x and GTK+ 2.x applications. With a single click on the dropdown button of a combobox, the list expands but no automatic highlight takes place. With the mouse button kept pressed, automatic highlighting of the item below the mouse pointer takes place. I don't think this behaviour can be controlled by a window manager, except perhaps by a really dirty one. I'd rather consider whether there is a (hidden?) Gnome / GTK+ setting to change the behaviour after all? I'm not aware of any, at least. Btw, menus, both dropdown and popup, fulfill the behaviour Yeajchao was asking for: highlighting the current entry below the mouse pointer without the mouse button being pressed. I think there is a good reason for comboboxes not to to auto-highlight the selected entries without explicit mouse press: highlighting of combobox list entries goes along with changing the contents of the associated text field. Often this may be undesired. Sometimes you only want to study what entries are available in a list, possibly with assistance of the mouse pointer moving over them, but you don't want to change the actual (pre)selection. This would not be possible (selection would always change) if there was mouse-button-independent auto-highlighting in combobox lists. In menus there is no such thing like (pre)selection change, so automatic highlighting of entries even without mouse button presses is acceptable there. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Changing the tab order in a dialog
Suresh Stephen wrote: I have created a GUI using GTK and i have created a dialog box which will contain multiple entries. In the following fashion entry 1entry 5 entry 2entry 6 entry 3entry 7 entry 4ebtry 8 1,2,3 indicate the order in which i have added the text entries into the widget When i press tab to navigate across the text entries the control moves from entry 1 to entry 5 then to entry 2 and then to entry 6 and so on. I want the tab order to move from entry 1 to entry 2 and then to entry 3 and so on. Any one knows how to do it ,any help would be great. You are apparently using a GtkTable with 2 columns and 4 rows. Usually that's fine and the best way to do it. However, to tune the [TAB] jump order in your desired way you should rather use a GtkHBox of size 2 (optionally a GtkHPaned) and two GtkVBoxes of size 4 each. Put the GtkEntries into the GtkVBox cells and there you are. This sort of forcing different [TAB] orders works just a bit like using parentheses in mathematics. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: combo rant
control H wrote: Well, I must admit that I haven't used Windows more than occasionaly for the last three or four years, but the last time I checked, Windows combo box was much _worse_ than GTK+'s, in my opinion. You would often get a five-line combo where you'd have to scroll like hell to skip all those 200 items to get to the one you want. Ok it certainly sucks when you have to scroll those 200 items within a five-line combo. But that's part of the programmers job I think. At least you are able to force a five-line combo on Windows! And that's what I miss. A function where you can scale such things, as I stated in my original email. In other words, you miss function(s) to make the UI suck to users? The problem with such functions is that many programmers are not just happy about their existence but unhesitatingly (mis)use them to create UIs that suck, indeed. The pretty common 500-items-3-lines combobox in Windows is a good example for this. While the programmer may be happy for having achieved exactly what he wanted to, the users of those applications have to suffer from such mislead efforts. I am personally happy that GTK+ tries to make it significantly harder for programmers to reduce usability of applications / GUIs in ways which are rather common on i.e. native Windows applications. Due to its open source nature and extensibility nearly nothing is impossible to achieve in GTK+. However, such sort of restriction functions which give the programmer more control at the expense of usability (user's happiness) require significantly more efforts by programmers. Efforts which most programmers should rather invest in improving or extending their applications rather than restricting the UIs. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Inner window size issue
Nikolaj Kiær Thygesen wrote: How on earth do I open a window containing a couple of widgets, one of which is a ScrolledWindow?? This ScrolledWindow displays an image, and now I'd like to fit the size of the ScrolledWindow to the size of the image in pixels. I have understood it like this: you have a GtkImage inside a GtkScrolledWindow. The GtkScrolledWindow should be just large enough to allow the GtkImage to be entirely visible, i.e. there is no need to scroll the GtkImage (the contents of the GtkScrolledWindow). Pardon me, but why is there a GtkScrolledWindow at all if you apparently intend to avoid the need of scrolling inside the bitmap (because it's entirely visible)? Wouldn't just removing the GtkScrolledWindow and placing the GtkImage directly into the container fulfill your demand? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: SubWindows
Daniel Ferreira Monteiro Alves wrote: Anyone knows if the gtk support sub-windows? Yes I do + no it doesn't. I suppose you're referring to WiW (windows in windows) which are user-arrangeable MDI subwindows as known from MS-Windows and QT applications. They're not supported by GTK+ because too many developers believe they're a bad thing for users. I don't share this opinion. Have a look at the following URLs: http://mail.gnome.org/archives/gtk-app-devel-list/2003-August/msg00396.html http://freshmeat.net/projects/libgtkmdi/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Inner window size issue
Stefan Kost wrote: [...] Therefore the scrollable windows is needed if the height of the window would exceed the screen height. Anyway if it does not, I'd prefer to make the window as tall as possible to show the entries without needing to scroll. I am not be able to achive this yet. I suppose gtk_window_maximize () doesn't match your notion of make the window as tall as possible? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: optimal way to use Memory Chunks
Olivier Sessink wrote: Gus Koppel wrote: What sort of 4 byte information is to be stored, if I may ask? Is it to be referenced mainly by entry numbers (1st, 2nd, 3rd, ... atom) or by contents, i.e. locating atoms that contain particular values? Possibly for your app GMemChunks are not only inefficient but unsuitable at all. so not 4 bytes, but anyway, what they are: they are changes in an editor(Bluefish), to be used by the 'undo' function. Each struct has a pointer with a buffer holding the change, a start and end position, and a state'insert' or 'delete'. As you can imagine, with 20 documents open, and doing heavy editing, the number of instances may go up to 5000. They can be freed whenever some document is closed, so the G_ALLOC_AND_FREE mode may be more appropriate. I could associate a GMemChunk to each document so I can use G_ALLOC_ONLY, but people often open many documents (100+), and edit only a few of them. Having a GMemChunk prepared for each document would then be quite some overload.. If it's not treated in a rather special way I suppose your Undo history to be just a LiFo stack with elements of identical size. For this I would simply use dynamically allocated arrays of your Undo step objects, one array per document, indeed. GLib provides GArrays for this purpose, but I wouldn't use them either. The simpliest way is to define (and unconditionally allocate) a fixed maximum number of elements, i.e. 5000, per document. The smarter way is to provide three functions (due to simplicity could even be macros) like undo_stack_push(), undo_stack_pop() and undo_stack_moveto(). undo_stack_push() would add one element to the stack and resize (enlarge) the stack by a fixed number of elements, i.e. 256, if necessary. undo_stack_moveto() would move the stack pointer to any already allocated element within the stack. undo_stack_pop() would simply invoke undo_stack_moveto() to move the stack pointer one element back. An optional undo_stack_cleanup(), to be invoked occasionally, could shrink or deallocate the stack space if there are far less elements in the stack than it has capacity for. My point is: for a LiFo stack of equally sixed elements GMemChunk isn't an appropriate feature. If at all, then GArray would better serve this purpose. But I would consider even that one overhead. Those simple three or four custom functions described above would do the job better, more efficiently and without any overhead of GMemChunk or GArray. You would always have to invest some extra typing to put a GArray into the context of your program, your objects, etc. This could be saved by a direct, custom implementation. In general, I think GLib features should not be utilized by all means. If a custom implementation is that easy (like this one appears to be) and likely more efficient, then you shouldn't use toolkit functions just because they are there and could solve the problem as well. Too much ardour for that might let some people end up one terrible day by writing x = g_math_add (g_math_sub (a, g_math_mul (b, c)), d); instead of just x = a - b * c + d; ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: optimal way to use Memory Chunks
Olivier Sessink wrote: I was considering to use the GMemChunk infrastructure for some of my code, where often 50 till 5000 structs of 4 bytes are allocated. I will use the G_ALLOC_AND_FREE mode, because many items are not used after a while, but not all. I am, however, wondering if GMemChunk has much overhead. Is there much searching time involved looking for the next free element if the number of items become large? And how large would that be? And if the number of elements is at a time actually very little, is there much overhead using GMemChunk instead of g_malloc() ? Summarizing: the question is when *not* to use GMemChunk, and when *to use* GMemChunk. Using such a feature like GMemChunk makes sense only if the size of the objects (atoms) isn't too small (less than about 16 bytes as a rule of thumb). Your atoms appear to be the smallest ones possible at all. GMemChunks are especially helpful for linked lists of any sort. Your atoms are apparently not big enough to contain such information. In your case, the memory overhead by using GMemChunk would be slightly over 100% on 32 bit machines and slightly over 200% on 64 bit machines, as for every 4-byte struct to be stored there would be a 4 (32 bit) or 8 (64 bit) byte handle / pointer to reference that atom, plus the GMemChunk object itelf. So, by using GMemChunk you might end up with 5000 pointers (4 or 8 byte each) to atoms of 4 bytes each. I suppose you would prepare some sort of static array to store those up to 5000 pointers. Then why not simply create an array to contain those 4 byte informations directly, rather than creating an array to contain pointers to the 4 byte information chunks, to be managed with sure memory and speed penalty? What sort of 4 byte information is to be stored, if I may ask? Is it to be referenced mainly by entry numbers (1st, 2nd, 3rd, ... atom) or by contents, i.e. locating atoms that contain particular values? Possibly for your app GMemChunks are not only inefficient but unsuitable at all. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Programming style
César Leonardo Blum Silveira wrote: Thanks for your answer! So, as my app is a Glade app, I can use that lookup_widget() function you mentioned? Otherwise I would use your function :-) That's correct. For fully Glade-built UIs both functions are usable. Mine is just a more generic version of it as it doesn't require the UI to be built using Glade. lookup_widget () bases on some additional Glade-specific data to be present in the app. My function just doesn't. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: memprof problem
Allin Cottrell wrote: I've successfully used memprof for leak-checking my app in the past, but on trying it recently something odd happens: memprof starts up OK, and it also starts up the target program, but the target program is not visible (doesn't appear on screen) and memprof records no memory usage. I tried this with various standard gnome apps as well as my own program, with the same (non-) result. I then tried rebuilding memprof (0.5.1) with the current Debian patches for compilation against current binutils (GNU binutils 2.16.1). Still nothing. Any ideas what could be happening here? Thanks. (All I see on stderr is memintercept (449): _MEMPROF_SOCKET = /tmp/memprof.uTNjuX memintercept (449): New process, operation = NEW, old_pid = 0 ) Any chance this could be either a) some sort of incompatibility by standard system components, like libc b) a problem of insufficient execution permissions? Try as root. You could also try to utilize strace to get an idea whether any stupid and unreported ENOFILE error (or similar) cumbers memproof execution. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Programming style
Tristan Van Berkom wrote:
Every widget callback comes with a user_data argument,
and you can pass the desired data through that argument
(which is just as fast as using a global variable and is
just as clean as using a lookup_widget type of routine).
Right. However, if you want your signal handler to be able to access
more than one foreign widget, you need to define and instantiate (and
finally possibly cleanup) a struct to be passed to the signal handler
(instead of one widget directly).
If you have many widget signal handlers which need to access many
different sets of widgets you would end up defining a large number of
handler-specific structs. Keeping them apart between different handlers
while managing them properly appears more laborious and error-prone to
me than obtaining references to other widgets just as needed in a
well source-readable way within the handler.
That is
typedef struct {
GtkWidget *b;
GtkWidget *c;
} POINTERS_TO_B_AND_C;
...
/* instantiating it somewehere else, either locally or globally */
POINTERS_TO_B_AND_C pbc;
pbc.b = widget_b;
pbc.c = widget_c;
...
void on_whatever_signal (GtkWidget *a, POINTERS_TO_B_AND_C *pbc) {
do_something_with_b (pbc-b, ...);
do_something_with_c (pbc-c, ...);
}
appears more complicated to me than just something like
void on_whatever_signal (GtkWidget *a, void *not_used_here) {
do_something_with_b (WFBN(b), ...);
do_something_with_c (WFBN(c), ...);
}
without any further handler-specific pre- or postcautions (in case of my
function + macro). Especially, as mentioned, when it comes to larger
numbers of distinct widget sets to be used inside handlers.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Programming style
César Leonardo Blum Silveira wrote:
I have a few doubts about the way I code my GTK applications. One of
them is: Is it ok to use many global variables for the widgets? For
example, in a glade app where callbacks are of the form
void callback(GtkWidget *widget)
I can only have access to the widget that received the signal, but
what if I want to make it change a property of another widget? Should
I use a global variable or should I try getting the toplevel widget
and then decending to the neighbour widget I want to make changes
on?
Opinions about it certainly differ. Some people may prefer global
variables for all important widgets for two reasons: 1. it's the very
fastest way to get pointers to widgets, 2. it's okay for them to deal
with large amounts of global vars (despite known problems that could
result with them on larger scale applications).
However, I think the majority of programmers prefers to avoid global
variables whenever possible. Both for stylistic as well as for
complexity reasons. Having to keep track of global variables for somee
(or many) widgets is more difficult and error-prone than not needing to
do so. With the exception of toplevel (or popup) windows I don't use any
global vars to store pointers to widgets in them.
Instead, during program execution I refer to widgets by name. The name
property of widgets, if being used properly, is a wonderful and well
readable way to refer to widgets. It's a glimpse of high-level (or
scripting) language programming in C(++). This way you don't need to
juggle with numerous global variables and their (possibly frequent)
proper initialization (and deinitialization) at all.
It's certainly a bit slower than directly accessing a global variable of
which the memory address is directly known at execution time and doesn't
need to be determined. However, the speed impact should be neglegible
unless you plan to search for far more than some 1000s different widgets
per second (or signal handler). Performance limitations of GTK+
applications are not caused by this sort of custom functions, anyway.
Since this way of easy programming appears not to be supported
officially by GTK+ I use my own simple function for this purpose:
widget_find_by_name (), retrievable at
http://www.spamkiller.bytechase.cx/democode/widget_find_by_name.c
For instance, if you have a window named W_Main and a text field named
I_Value in it then you can simply refer to the latter from within
any callback by something like this:
{
GtkWidget *i_value = WFBN (I_Value);
gtk_widget_do_this (i_value, ...);
gtk_widget_do_that (i_value, ...);
}
For other windows you may (or may not) simply define similar macros like
WFBN_WIN2 (...) for instance.
BTW, the difference between my function and lookup_widget(), provided by
Glade, is that my function is absolutely independent from Glade and
doesn't need any further precautions like lookup_widget() does. It just
suggests you to set the name property of widgets appropriately.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: how to hide close button in gtk dialog
Yogesh M wrote: found it, sometimes it is neccessary to avoid confusion. for example in a dialog i have a cancel button, now if the window show a close button, it is a confusion that whether the window closes or the cancel activates or both. It's common convention that title bar close buttons of windows do a cancel-close. Especially if inside the window there are both Cancel and OK buttons as well. Hint: only using the OK button should confirm input or changes. Closing the window by any other means (i.e. Cancel-button, title bar close button, hitting the [Esc] key, killing or crashing the application) never does. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Doubt about free or dont free
Arx Henrique wrote: my doubt is g_free or not g_free the text? When in doubt, read API docs: Tks x) next time i'll read api While the case of returned const gchar *s is rather simple, the real problem to me is that the API docs are quite less explicit when it comes to more complex objects than just string constants. For instance, whether and how reference counts of objects related to treeviews are changed by what GTK+ functions dealing with them remains undocumented. For instance: whether gtk_tree_view_set_model() changes the reference counts of either the newly set or the replaced GtkTreeModel remains as unclear as whether gtk_tree_view_get_selection() increases the reference count of the selection object or not. If I remember right the first function changes reference counts while the 2nd one doesn't but I may be wrong on this. Frequent explicit checks on object reference counts after many GTK+ functions are my only way to make sure about this while developping. I wish the API docs would be added a line for _every_ get- or set- function, which explicitly notes whether and how reference counts of associated objects are changed by that function. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK version compatibility
Gowri Kandasamy wrote: Does applications built on GTK 2.2 work with gtk2.6 ? Generally yes. However, there are some incompatibilities in undocumented internals between 2.2 and later versions, which sometimes may affect compatibility of applications to particular GTK+ versions, even if they perfectly adhere to GTK+ APIs and docs. For instance, the orders of at least some signals were changed in 2.4. An application which is API-wise compatible to all GTK+ 2.x versions doesn't necessarily run on all GTK+ 2.x versions if it just relies on handled signal A to be emitted before handled signal B. Application bugs which base on this are difficult to locate, since it's not always obvious that your handler of signal A assumes that it's been called before handler of signal B. You may easily have written a handler without realizing this implicit requirement. Generally, there are chances to run into his sort of trouble if any signal handler of any widget accesses (reads or writes) data or properties from or to other widgets or changes states of other widgets which have custom signal handlers as well. If you're lucky then your application, which runs perfectly on GTK+ 2.2, either crashes rather quickly or obviously operates on wrong data or target widgets on GTK+ = 2.4, if this incompatibility applies to it. If you're unlucky the program may appear to run fine but internally confound data, which may stay undiscovered for quite some time. Workarounds for this sort of problem are new custom variables, possibly global ones, especially flag variables, to be used in handlers. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Child windows with Gtk+-2.6.4
[EMAIL PROTECTED] wrote: i'm new in gtk and i have to develop an application with a lot of windows. I remember that with delphi, it is possible to open a window in the mother window. Is it possible with gtk+ ? See: http://mail.gnome.org/archives/gtk-app-devel-list/2003-August/msg00396.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Compiling gtk apps on MingW
Ricardo Malafaia wrote: well, my Makefile is like this now PREFIX=/mingw PATH=/d/GtkWin/bin:/usr/bin:/bin:/mingw/bin CPPFLAGS=-O2 -I/d/GtkWin/include PKG_CONFIG_PATH=/d/GtkWin/lib/pkgconfig LD_LIBRARY_PATH=/d/GtkWin/bin:/d/GtkWin/lib:/lib:/usr/lib:/mingw/lib GTK_CFLAGS=`pkg-config --cflags gtk+-2.0 | sed -e 's/d:/\/d/'` GTK_LIBS=`pkg-config --libs gtk+-2.0 | sed -e 's/d:/\/d/'` LDFLAGS=-L/d/GtkWin/bin -L/d/GtkWin/lib all: exec/teste.exe exec/teste.exe: teste.c gcc.exe -mwindows -mms-bitfields $(GTK_CFLAGS) $(GTK_LIBS) teste.c -o exec/teste.exe And still doesn't work. The gcc command line shown, shows not the result of the sed processed pkg-config output, but simply `pkg-config --cflags gtk+-2.0 | sed -e 's/d:/\/d/'`. Makefiles are not supposed to contain (or evaluate, rather) `-expressions. 'make' doesn't treat them the same way the shell does, i.e. expanding them. 'make' provides the shell function for shell command expansion instead. Study the 'make' documentation for further information about this. However, if you use autotools on MinGW (like I do and like it is recommended), you don't need that either. If you insist on entering it manually then the GTK+-relevant part of the linker parameters to include libs should look similar to this: -Lpath_to_your_gtk_installation/gtk-2.0/lib -lgtk-win32-2.0 \ -lgdk-win32-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangowin32-1.0 -lgdi32 \ -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 When using autotools, this is what pkg-config adds to the app_LDADD variable automatically (provided GTK+ is installed properly). In configure.in the following two lines add that library stuff the portable way, i.e. without need to change anything between MinGW and Unix. pkg_modules=gtk+-2.0 = 2.0.0 PKG_CHECK_MODULES(PACKAGE, [$pkg_modules]) In makefile.am (in your package src/ directory) there should be the line app_LDADD = @PACKAGE_LIBS@ where app is the name of the target binary, usually your package name. You may also add other required libs there, either directly by name or by other variable names. This way, when you got that whole automake + autoconf stuff set up, a simple 'configure' run (which may take quite some time on MinGW, though) creates (long but often functional) Makefiles. Note that both the bin/ and the lib/ directory of GTK+ should be added to your shell's $PATH before running 'configure'. Otherwise 'configure' will abort, complaining it can't find either pkg-config or the GTK+ libs. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: ComboBox on Windows application
Alf Stockton wrote: I have a screen already built using Glade and a whole bunch of code that now needs maintaining. Is it recommended that I carry on using Glade? There are no alternatives for GTK+, except if you're willing to code either C source or XML by hand to design your GUI. Glade has built an interface.c that I now need to alter to get a combobox to display a number of entries I will retrieve from a SQL database, however a comment at the top of interface.c says DO NOT EDIT THIS FILE - it is generated by Glade. Recommendations please. You don't need to alter interface.c. You NEVER need to! interface.c is just a read-only blueprint of your GUI. It mainly describes what widgets and windows there are and how they are layouted. As a convenience option, Glade allows to populate combo boxes and option menus with some predefined list items. This feature should be used for simple and constant lists of items only, though. Don't use it for combo boxes which are to receive changed content frequently. If you use old compatible GtkCombo, gtk_combo_set_popdown_strings () is what you're looking for. For newer GtkComboBox (since GTK+ 2.4) a bunch of functions starting with gtk_combo_box_append_text () is what you can use. Have a look at the respective class descriptions in the GTK+ API docs. There you'll also find methods to delete contents from combo boxes prior to refilling them again with new database result items. manipulate your GtkCombo(Boxe)s either in any of your callback functions in callback.c or, even better, in any of your own source files. But never edit interface.c, indeed! You never need to. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Glade C code a bad thing? (was: root windows)
Freddie Unpenstein wrote: You're going backwards here... Having the code generation part of Glade limits you to what the Glade developers have done, and how good they are at doing it. Having the code generation seperate, allows someone else to take over that burdon, who could potentially be better at it than they are. Since Glade code generation supports ALL features which are supported by the Glade GUI, I think this is a limit one can live very well with. Even the primary replacement project, libglade, didn't for a long time. I'm not aware of any secondary replacement projects (alternate code generation projects) at all as yet. I don't see how they could support more features in translating Glade XML to C source than Glade GUI supports at all? So where's the loss of freedom of choice? I already see messages from someone planning to pick up the torch. I only saw messages from people claiming that it's (pretty) easy to do. I haven't seen anyone picking it up or actually planning to do so. Reinventing the wheel is sometimes the only way to remove the kinks. If the tyre on my car blows, I don't try to stitch it back together, I get a new one. But more importantly, I do so with the knowledge of how that last one performed, and what to look for in the next one. Reinventing the wheel != replacng a blown wheel with a new one. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Glade C code a bad thing? (was: root windows)
Olexiy Avramchenko wrote: If the idea about general tool for XML - C translation, sounds good for you - start development. I think all interested people will help you. I don't think so. The idea about a general XML -- C translation tool doesn't sound good to me and I won't start development of one. I'm busy enough writing things which havent' been created before. All sane people who don't suffer from the Not-Invented-Here syndrome wouldn't waste their time by trying to replace a complex and (rather) perfect solution (regarding its result, not speaking about its implementation) by something self- written, which would likely take a year or so to get close to the quality of the existing one. I don't plead for someone to write a replacement. I just plead for not abandoning the existing one. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Glade C code a bad thing? (was: root windows)
Olexiy Avramchenko wrote: Freddie Unpenstein wrote: That doesn't mean generated code shouldn't be available for those who consider it the best solution to their particular needs. Write a utility that reads in .glade files and outputs code. Call it from your Makefile to ensure the source files are kept up to date, and everyone's happy. Exactly, it's pretty easy to write a 'glade-XML' - 'C source' translator, if someone needs that. Yes, pretty easy, indeed. Do you think 100 - 200 lines of Perl would suffice or would you need more? I suppose either you have been using rather basic design features of Glade only or haven't had a thorough look at the generated C code with all its complexity, its structural integrity and provision for probably more than hundred different GTK+ features and distinct GTK+ function calls with several attributes. Not to mention the other side, the XML parsing and evaluation. You'd probably be in the game with 1000 - 2000 lines of Perl (10 000 if counting XML parsing stuff). To most people this is likely not pretty easy. For instance, Jan Karrman probably thought similar when he started writing his html2ps Perl translation script. Look at the latest result: 4500 lines of tight Perl code, unmaintainable, and still no support for many HTML features! Regarding text format translations, Perl is considered easier than C by most programmers, btw. Imagine there is an existing Glade-XML -- C source translator. It knows perfectly about all features and widget attributes of Glade. (libglade from less than 12 months ago still missed support for some Glade features!) It is written in C, very fast, stable, fully integrated in the Glade UI and well tested. It produces excellent C code which is easier to use than libglade and due to its knowledge of GTK+ tricks can also serve as programming tutorial reference for GTK+. So what would be the intelligent answer to developers who use it and benefit from it? Let's abandon that existing one and rather write a new one from scratch if you believe you need it. Thhank you, sir. This confirms that reinventing the wheel, even with rough edges, must be more important than i.e. working on end user applications using GTK+ and Glade. Sorry if this thread appears to be in the wrong mailing list again. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Glade C code a bad thing? (was: root windows)
Maciej Katafiasz wrote: Unless by build of glade you mean autogenerated C code, which is bad, bad, bad thing to use. Use libglade, really. why it is bad? I use it and it works just fine and I don't have glade dependiencies. Because it makes it impossible to later rework UI without rewriting the code. In general, mixing autogenerated and hand-written code is always a bad idea, and that's exactly what is being done here. Besides, it hardcodes interface in code, which is also very bad thing. Fortunately, glade-3 won't support generating C, making it painfully obvious that libglade is the right thing. Do all conceptual decisions by all developers make painfully obvious that they are / were doing the right thing? If Glade 4 were to add support for QT or MS-Windows resources or other nonsense, would it still be painfully obviously the right thing? Possibly contrary to you I've been using both ways, libglade and hardcoded C source. After quite some time of performance drawbacks and other quirks I returned to Glade C code and am very happy with it. I'm co-working on a rather large Glade-based project, btw, with the .glade file being 1 MB in size. For performance reasons, such files are inherently unsuitable for being accessed via libglade. In contrast, we have never experienced any impossibilities of reworking UIs. There is no more Glade-related code to rewrite (just custom handler code) when using Glade C code than when using libglade. I also don't see why mixing auto-generated code with hand-written code is always a bad idea or hardcoded interface is also very bad thing? Imagine that a hardcoded interface is actually exactly what some people (developers and users) WANT to have, for several reasons! (Speed, size, GUI can't be altered by unauthorized people, installations, easier to program, etc.) See URL below for an extended discussion of why Glade generated C code is actually preferrable, why its ceasing support is regrettable and will certainly cause quite some professional developers to stick to Glade 2. http://mail.gnome.org/archives/gtk-app-devel-list/2005-January/msg00227.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to search through all entries in a column in GtkList
Vinod Joseph wrote: Sorry for the confusion Yes, I'm afraid your description was confusing to some people. Anyways.the major problem for design is with browsing password entries stored as ASTERISK in GtkList.. The problem is with password entry stored as * I don't understand this. You have a GtkList with a column which only displays **? Does that make sense? And you want to compare the input of a GtkEntry (masked with *s as well I think) against any of those rows? Sorry, at this point I have just two, probably non-helpful hints for you: 1. you should probably use strcmp () instead of memcmp (), as possibly the size argument of your memcomp was incorrect. 2. if you write your loops not like this for ( i = 0; i = my_list_store-len - 1 ; i++ ) but like this for ( i = 0; i my_list_store-len ; i++ ) it's not only slightly shorter to write but also saves one or two machine instructions, hence is (very slightly) faster and shorter. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
