Drawing data from cairo surface to a pixbuf
Hello. I have a problem with loading data that I got from an cairo image surface with cairo_image_surface_get_data(). I got the data with: --- long width, height, len; char *data, *data_tmp; data_tmp = cairo_image_surface_get_data(surface); width = cairo_image_surface_get_width(surface); stride = cairo_format_stride_for_width(CAIRO_FORMAT_RGB24, width); height = cairo_image_surface_get_height(surface); data = g_malloc(stride * height); memcpy(data, data_tmp, stride * height); len = stride * height; --- Then I try to load that data with PixbufLoader: --- ... loader = gdk_pixbuf_loader_new(); gdk_pixbuf_loader_write(loader, data, len, error); ... --- But loading from data failed with error unknown image file format. Is there another way to load that data? Please help. Greets, Luka ___ 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 Dave Dave Foster wrote on 16/06/08 19:49: ... 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) 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 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. So you're thinking of something like this? |: Do Something Involving Themes | || | (*) Create a new theme from scratch| | Named: [] | || | ( ) Create a new theme based on: [Midnight Madness :^] | | Named: [] | || | ( ) Open the last edited theme (Twilight of the Dogs) | || | ( ) Open a different theme: [Midnight Madness :^] | || | ( ) Edit the current theme (Fruity Blues) | || | ( Cancel ) (( OK )) | || 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. The mockup above is a minimal example of how to lay it out, but it's obviously not great, because it's quite repetitive. You could reduce the repetition a bit by grouping the two creation options together: | (*) Create a new theme | | Named: [] | | (*) Start it from scratch | | ( ) Base it on: [Midnight Madness :^] | And you could get rid of Open the last edited theme by just making the last-edited theme the default value for the Open a theme command: | ( ) Open a theme: [Twilight of the Dogs :^]| But that you were using radio buttons for highly disparate immediate actions would still be pretty awkward. (Like the Shut Down dialog in Windows 95/98.) 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. Right. (Like the Shut Down dialog in Windows 2000.) 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. ... I think your basic difficulty is that you're thinking verb - object: presenting a list of actions, and then asking for a choice of theme afterwards. Instead, try thinking object - verb: present the list of themes first, with the actions afterwards. Like this: |(x): Themes :(-)| || | [] Fruity Blues |A| |:[]:Midnight Madness::|:| | [] Twilight of the Dogs |:| | |:| | |:| | |:| |__|V| |(New...) (Duplicate...) (Edit...) ( Open ) | || 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). Here's what would happen to the previous options: * Create a new theme - New..., then type its name into the newly-created table row. *
Re: GTK 3.0: an app developer's view
Allin Cottrell wrote: 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. I did too, I had several applications which had to make the transition and it wasn't a quick job. (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. I just put together quickly a few lists of ALL things marked as deprecated right now. GtkItemFactory is in that list. It will be removed (as I understand it) in 3.0 as will everything else that is marked as deprecated. These lists give you an idea of how much dead code is left in GTK+ right now and why it is so hard to maintain with it lying around. This list is in no way conclusive, it is literally those I looked up in all .h files in the gtk/ directory. There may be others. 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). If you find the loading speed so bad that it is affecting performance of your application, please file a bug. If this is not the case, I think the benefits of a *readable* XML format outweigh the inefficiency you talk about. 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). Glade has been doing this for years. It is much quicker for an application developer to use Glade to define menus, windows, dialogs, etc than it is to code then *statically*. I say statically because you don't need to recompile your program to change some slight detail of the menu layout or labelling. This bears a huge advantage as far as I am concerned. 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. What kind of real application are you talking about? I have written many in my time and I use glade for most of them (which uses an XML format for not only the menus but all window layouts). I don't find it a maintenance nightmare at all, in fact it is quite the opposite. 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: It is a certainty from what I can see. 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. I too have had to move from GtkItemFactory to the new GtkUIManager. It wasn't great, but it is needed. I am not saying GtkItemFactory is evil voodoo either, I am just saying there are some things in GTK+ that just need to be removed and there are some things application developers are *able* to do as a result of not sealing structures with proper APIs. I should add at this point too, that the GtkItemFactory has been marked as deprecated for some time (since GTK+ 2.4) and the documentation has explicitly said so too. So you have had plenty of time to update your application and/or bring your concerns forward about this. Please do not feel like we don't care about application developers here, many of us are application developers and know we too will have transitions to make for our software where we switch from deprecated APIs. -- Regards, Martyn gtk_about_dialog_get_name gtk_about_dialog_set_name gtk_accel_group_ref gtk_accel_group_unref gtk_accel_label_accelerator_width gtk_binding_entry_add gtk_binding_entry_add_signall gtk_binding_entry_clear gtk_binding_parse_binding gtk_button_box_get_child_ipadding gtk_button_box_get_child_size gtk_button_box_get_spacing gtk_button_box_set_child_ipadding gtk_button_box_set_child_size gtk_button_box_set_spacing gtk_calendar_display_options gtk_calendar_freeze gtk_calendar_thaw gtk_cell_renderer_editing_canceled gtk_check_menu_item_set_show_toggle GtkColorSelectionChangePaletteFunc gtk_color_selection_get_color gtk_color_selection_set_color
Re: GTK 3.0: an app developer's view
On Tue, 17 Jun 2008 10:05:28 +0100 Martyn Russell [EMAIL PROTECTED] wrote: Glade has been doing this for years. It is much quicker for an application developer to use Glade to define menus, windows, dialogs, etc than it is to code then *statically*. I say statically because you don't need to recompile your program to change some slight detail of the menu layout or labelling. This bears a huge advantage as far as I am concerned. It's a trend everyone has been making for years, and I very much support it. 20 years ago, everyone was hand-coding assembly routines. 10 years ago, C was king. Today, more and more behaviour is moving into higher level constructs, softcode, bytecode interpreters, etc.. This is a good thing. CPUs get faster all the time. Memory and hard disks get bigger and cheaper all the time. Programmers only ever get more expensive. Engineering is always about tradeoffs between resources. The resources we have are both computer, and programmer. Because the former keeps getting faster and cheaper, it makes sense every so often to have a shift of ideas, a great move where we decide the computer is good enough to take on what we now decide is the boring menial tasks we as programmers can't be bothered to do. 30 years ago, everyone hand-picked their registers for individual assembly statements. Nowadays, I bet most programmers couldn't even identify the register-colouring algorithm in their compiler; it's something that's just done for them. Who's to say what, in 20 or 30 years time, compilers and other programmer tools will be doing for us. I suspect very strongly that building UIs automatically around some description of the task to be solved, will fall under their remit. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
location of gdk-pixbuf.loaders
Hi, I am trying to pack a minimal set of files in one directory right enough to execute my app using gtk/win32. So, I tried to avoid the use of any of gtk's config files in etc/, lib/, share/, ... which can not be put into subdirectories though AFAIK. So, I simply deleted them which seems o.k. for gtk+ and works fine. Similar I replaced gtkrc by using gtk_rc_parse_string() directly from the code. However, I fail to do the same for the image loaders (libpixbufloader-xpm.dll in my case). First, I haven't found any other way to tell gtk+ which loaders to load but by using the in-file solution 'gdk-pixbuf.loaders'. With gtk_rc_parse_string() I can set pixmap_path=., however this does of course not tell what loaders to load. Second, I haven't found any way to tell gtk+ to search the file 'gdk-pixbuf.loaders' in my current directory. Instead, gtk+ wants it in ../etc/gtk-2.0/. Here some options that would solve the problem but which I can't use here: * Since my app shall run without an installer I can't set any env vars first like GDK_PIXBUF_MODULE_FILE. And I would not like to create a shell script/batch file to set the env var since that can be changed and has other unwanted effects. * Writing a small executable to set env vars and then launch the real app is possible but makes it e.g. hard to run the app using a debugger and such. Is there an easier solution to load the pixbuf image loaders? Thank You Felix ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Slow treemodel loading
The solution was to perform the sort myself. The update is now nearly 20x faster. -- Jeffrey Barish ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
