Gdk-CRITICAL **: gdk_drawable_set_colormap: assertion `cmap == NULL || HOW TO HANDLE: gdk_drawable_set_colormap: assertion `cmap == NULL || gdk_drawable_get_depth (drawable) == cmap-visual-depth' fa
Hi all , I have an application running on DirectFB and I have a function gnome_canvas_new_aa( ) to generate a canvas As an example , a code snippet would be as below GtkWidget *canvas_widget; gdk_rgb_init( ); gtk_widget_push_visual(gdk_rgb_get_visual( )); gtk_widget_push_colormap(gdk_rgb_get_cmap( )); canvas_widget = gnome_canvas_new_aa( ); gtk_widget_pop_visual( ); gtk_widget_pop_colormap( ); But i get the warning Gdk-CRITICAL **: gdk_drawable_set_colormap: assertion `cmap == NULL || gdk_drawable_get_depth (drawable) == cmap-visual-depth' failed And my canvas appears blue / dark blue /balck in color What could be the reason for this? And how u handle this warning? plz help Thanks Regards sv. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Reading jpg data
Hi everybody, I need to read a jpg image out of a buffer, not a file; the caveman way to do this could be: write buffer to file, then use gdk_pixbuf_new_from_file. Is there a more elegant way to do this? I tried with pixbuf_loaders (with no success), but before spending further effort I'd like to have some hints from the list. BTW I'm developing on win32. Thansk, cheers Federico ___ Tiscali.Fax: ricevi gratis sulla tua email e invii a 12 cent per pagina senza scatto alla risposta http://vas.tiscali.it/fax// ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
UI design question
Hi, I'm crossposting to both the usability list and gtk app devel list, i hope this is ok, as I couldn't really see where my question fit in. I am designing a gtk application and I'm trying to follow the HIG, and I wanted to get some opinions on a simple dialog in the application. Here is a description (chopped out of an email i sent to a friend earlier): I've come up with 5 distinct actions this dialog should have. The actions are as follows: - Create a new theme - Create a new theme based on an existing theme - Open an existing theme - Edit current theme - Open last edited theme (the last two items will have text inserted at run time to explain what those theme names are) I thought the best way to do this was a radio button group, as it would show all the available actions neatly on one screen. The problem is, there is additional information that needs to be taken in depending on what is selected. For the top two items (both creates), a theme name must be given in a text box. For the create new based on existing and open existing, a theme needs to be selected from a list of themes. Because of these additional controls, I don't know how to lay this dialog out so that the user can see that the listbox and textbox are dependant on selections in the radio group. Another idea is to use a drop down, which could be put above the textbox/listbox, and have those go sensitive/insensitive as appropriate, but i feel that masks the user from seeing the possibilities of opening/creating themes. Yet one more idea is to use a multiple screen approach, with simple buttons that have nice icons that indiciate which action to take, and have a second dialog then ask for the required information such as a name or existing theme, but i feel multiple screens is a bit wizardy and not needed. Any thoughts? thanks all. dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [Usability] UI design question
Hi Matthew + Jacob - Thanks for the advice, some good stuff in here. On Mon, Jun 16, 2008 at 7:59 PM, Matthew Paul Thomas [EMAIL PROTECTED] wrote: My first thought is: That list of actions doesn't seem to include anything that requires it to be a dialog. Could it be an ordinary window instead? I guess I just didn't get the difference between the two. I thought a dialog was just a window with a pre-defined layout. I'm guessing by your reactions there is a bit more? Instead, try thinking object - verb: present the list of themes first, with the actions afterwards. Like this: This is much calmer, even while it lets you see the complete list of themes at a glance (which the radio-button-based design wouldn't). To be honest, it didn't strike me right away, but this could be a pretty good way of looking at it. I'll fiddle with it a bit and see what looks good. Any other options for laying it out? The buttons at the bottom seem a bit.. eh, i don't know how to describe it. Would it lose anything if they were on the right, arranged vertically? Here's what would happen to the previous options: * Create a new theme - New..., then type its name into the newly-created table row. * Create a new theme based on an existing theme - select theme, then click Duplicate... and type the name into the newly-created table row. * Open an existing theme - select theme, then click Open. * Edit current theme - open window, then click Edit (the current theme being selected by default). * Open last edited theme - select theme, then click Edit I think the edit and open actions are really the same thing here, so they can be combined into a single button. Thinking about the (future) general users of this application, the new from scratch option is going to be not used very often. I think the majority of themers start off by copying something (the duplicate) and then tweaking it until it is unrecognizable, so I think the create based on an existing or edit existing are the two most important items on this menu. With the new theme being so prevalent, I think people will miss the functionality of duplicate on first glance, until they try it a few times and see what happens. I hope I'm being clear above. With this info in mind, does it change anything about what you said? Either way, thanks for this information, it's exactly the kind of stuff I was looking for. Sorry if I am not so that's perfect! out the gate, I'm trying to learn this stuff a bit, not just follow blind advice :) Thanks again, dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK 3.0: an app developer's view
Sorry for cross-posting, but I think this does cross gtk-devel and gtk-app-devel: it's the thoughts of a common-or-garden app developer following the dicussions on gtk-devel about what's coming with GTK 3.0. As a starting point, on June 5, in the thread Steps to get to GTK+ 3.0, Martyn Russell ([EMAIL PROTECTED]) wrote: Many applications didn't make the change [from GTK 1.2 to GTK 2] because it meant rewriting a lot of code. Unless my applications are using some evil voodoo they shouldn't be using, I don't expect the transition from GTK+ 2.x to 3.x to take much time at all. As an app developer who did take the trouble to re-write a lot of code in the transition 1.2 - 2.0, I wonder about this statement. (Note: In my understanding, one key difference between GTK 2.0 and 3.0 is that all the APIs deprecated in 2.0 will be removed in 3.0; If I'm wrong about that, please tell me!) What's the status of the portion of the GTK API that was not deprecated from the get-go with GTK 2.0, but joined the deprecated list later, after 2.4? I'm thinking in particular of GtkItemFactory: if I'm remembering right, that was still kosher when GTK 2.0 appeared. My app has a large number of menus, across several classes of windows, and, after checking my code in the wake of the recent discussion of GTK 3.0, I find I'm very heavily invested in GtkItemFactory. I don't want to be a stick-in-the-mud, and I spent most of today working on a trial port to the GtkUIManager API of some of my GtkItemFactory code, to get a sense of the work that would be involved in eliminating all dependency on the older API. Results so far: On the one hand, I can certainly see the attraction in the newer API. Being able to define an action just once and then have it instantiated in various different UI constructions (regular menus, buttons, popups) is very nice. But from my point of view the attraction is largely counterfactual: _If_ I had originally composed my app's UIs in this way, I could have saved myself some trouble. But I didn't, and now I'd have to go to very considerable trouble to redo them. I considered the possibility of writing some sort of script or program to translate from GtkItemFactory to GtkUIManager, but fairly quickly convinced myself this was not feasible in a reasonable amount of time: the APIs are just too different. One key difference relates to the situation where you have several GUI actions that are basically similar but differ in some detail. In the GtkItemFactory API you can map all such actions to a common callback, but assign different values to the guint parameter to the callback. So far as I can tell, the callback signature for a GtkAction does not support any such (gu)int parameter. So either you have to use different callbacks for each specific action, or you have to construct a mapping from string action names to specific int action values. This is perhaps not terribly onerous if you're starting from scratch, but it's definitely inconvenient, and represents quite a major porting burden: not only would I have to rewrite all the menu code, but I'd also have to rewrite all the top-level callback code other than for simple cases where there's a one-to-one mapping from GUI action to callback function. Moreover, the new code would be less efficient than the old (lots of strcmp as opposed to just looking at integer values from an enumeration). In addition, I'm not 100% convinced of the virtues of defining a UI in XML as opposed to via an array of C structs (having both options would be nice). Gtk-demo has an example where the UI is defined via a chunk of XML inlined as a C string. This really sucks, and would be a maintenence nightmare in any real app. Reading the XML from file is preferable, but even then I'm a bit skeptical about offloading core stuff to separate files to be read at runtime. OK, I don't want to be too negative about GtkUIManager; it surely has its advantages. But I am concerned about the possibility that GtkItemFactory will disappear: this API is not evil voodoo, IMO, and I don't suppose that mine is the only GTK 2 app that uses it rather extensively. -- Allin Cottrell Department of Economics Wake Forest University, NC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk_main_iteration_do() always returns TRUE
Hi , I have an application which does not use any of the UI packages. I had to embed a mozilla browser inside the application which requires a gtk window for it to work. So I tried creating a gtk window inside my application and passing that to mozilla to draw into. Also since I didnt want my application freeze I tried using gtk_main_iteration_do() instead of gtk_main() and whenever the app gets a draw event I would call gtk-main_iteration_do() for it to process all the events it received after the previous call to gtk-main_iteration_do(). My assumption is that when we call gtk_main_iteratio_do() it process all the pending gtk events and then we have a choice of blocking for another gtk event or continuing with execution. Please correct me if I am wrong here. I tried the above said method and the gtk_main_iteratio_do() returns true indicating that gtk_main_quit() has been called , the very first time I call gtk_main_iteration_do(). Please let me know what I am doing wrong?? Thanks Shivaprasad ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
