Re: simple example of using gdk_pixbuf_new_from_file
On 5/31/05, Freddie Unpenstein <[EMAIL PROTECTED]> wrote: > > You mean all overlapping each other? You can only display a single "flat" > image (animations not counted). So if they're one ontop of another, you need > to composit them together into a single image. > > > > The preferred monster, is; > > > > void gdk_draw_pixbuf (GdkDrawable *drawable, GdkGC *gc, GdkPixbuf *pixbuf, > gint src_x, gint src_y, gint dest_x, gint dest_y, gint width, gint height, > GdkRgbDither dither, gint x_dither, gint y_dither); > > > > ... or, if you don't mind using depreciated functions ... > > > > void gdk_pixbuf_render_to_drawable_alpha (GdkPixbuf *pixbuf, GdkDrawable > *drawable, int src_x, int src_y, int dest_x, int dest_y, int width, int > height, GdkPixbufAlphaMode alpha_mode, int alpha_threshold, GdkRgbDither > dither, int x_dither, int y_dither); > > > > (I didn't actually know the latter had been depreciated... Seems they've > ditched the alpha_mode and alpha_threshold, and added a gc instead.) > > > > That's basically your main tool. Composit them all together, probably into > a new image of the appropriate size (unless you don't mind trashing the one > at the bottom of the heap) and stick the result into a GtkImage or > equivelant. > > > > > > Fredderic > > > Can you do me favour ? Please mail me a complete code for composting images. Thanks in Advance ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: PyGTK and libglade
On Wed, Jun 01, 2005 at 03:31:44AM +0300, Panos Laganakos wrote: > I'd like to know if those two libraries already have a formal > distribution (with installer) or someone has to include their binaries > with a potential program. For libglade, you want the gladewin runtime. http://gladewin32.sourceforge.net/ Dave Cook ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: PyGTK and libglade
Panos Laganakos wrote: Hello, I am considering of writing an app based on PyGTK and libglade. The thing is though, that the OS it will be used is win32. I'd like to know if those two libraries already have a formal distribution (with installer) or someone has to include their binaries with a potential program. Seems i rushed and didn't check out properly. The site with everything a win32 user(/dev) needs is here: http://www.pcpm.ucl.ac.be/~gustin/win32_ports/ Didn't know such a page existed :) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
PyGTK and libglade
Hello, I am considering of writing an app based on PyGTK and libglade. The thing is though, that the OS it will be used is win32. I'd like to know if those two libraries already have a formal distribution (with installer) or someone has to include their binaries with a potential program. ___ 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?
Hi, I make a converter to make (theoretically) any code from a .glade xml code. The converter read a XML file to "know" what do with each entry on .glade xml file. I didn't document it, but I can make this if somebody will have interest. The basic work is make six files (in my case is C++ and GTKmm): 1. The general header file (.h) within one class (the window, just one), visual object declarations and the necessary includes plus one include before the class declaration (.hh) e an other before closing the class (.members); 2. The code (.cc) within the visual objects' configuration; 3. The extra include .hh empty; 4. The extra include .members empty; 5. The user code (.cpp) file, within necessary includes and functions parseds. The functions don't are deleted when its owner (visual object) is and new funcions are created and don't supporte rename functions (not yet). 6. A simple make file. This converter compares an XML entry (node) from .glade with each one in .ctgtkmm (convert to GTKmm - C++). These comparisons are very complex and I made to solve my necessities, when I can, for exemple, identify a "Entry" with name started with "Custom__EntryName" and result on a declaration "MyEntry EntryName;" instead "Entry Custom__EntryName;" and include `#include "../Custom/MyEntry.h"´ instead `#include ´, so I can personalize the generated code to any language (theoretically). Somebody does have interest? -- []'s Claudio Polegato Junior Um peregrino de Problemas; Um pergaminho de Soluções. ___ 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)
Hello everyone, I strongly agree with the opinion that source-code generation should be removed from glade itself. OTOH I very strongly advice the glade developers to write a nice command-line utility to convert a glade file to it's equivalent source code in C/C++, before they drop this support. Since the glade file is XML, I think the tranformation to source-code could also be better done using XSL, right? If someone wan't to write it as a script without using any XML libs. i'll advice him/her to use scheme/lisp instead of perl/python as lisp is AFAIK the best language to deal with XML. Another option would be to write such a utility in C, which shouldn't be that hard if we borrow the same code from Glade that is to be removed. :) BTW, i think this seperation of glade into two utilities would result in much greater freedom than now (quite contrary to the fear of some people on this list) since it open's up a new possiblity: you'll then be able to write your GUI in XML and getting it transformed into the source-code without using any GUI utility. :) -- Regards, Zeeshan Ali ___ 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)
Gus Koppel wrote: 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. This is the main reason glade-2 has suffered IMO, glade-3 tries to address this problem by reducing special-case code to a strict minimum, in glade-2; every single widget had special case code installed for writing source code, glade file output etc... To generate code based on a glade file shouldnt be too difficult at all, but yes; there would be alot of code to write; thousands of lines of no-brainer stuff that just seems like a nightmare to maintain (actually; this could be alot easier for C source assuming that you generated code that makes extensive use of GObject introspection; you might not get away with that when generating perl or python code, I really dont know). 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+. Generated C source is definitly not easier to use than libglade; libglade may have a hard time keeping up with gtk+ widget development, but really; the way libglade is written today adding support for a widget is litteraly one line of code (glade_xml_register_widget ()), you can add it to your code or just bug James to get it in cvs. 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." I'm not saying that generated source code doesn't have its place; but as you said yourself, it involves mountains of unmaintainable monotonous code, so glade-3/libglade is a more generic & maintainable approach than integrating code generation in the tool (as was the case with glade-2). I'm not going to dig up the links, but this definitly has been discussed before, and as was mentioned earlier in this thread; people are welcome to write a utility to convert glade files to source code, we can even discuss making this utility usable as a plugin to anjuta or directly to glade-3. Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: 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: gtk entry
On Tue, 31 May 2005 11:18:40 +0200 Giovanni Manenti <[EMAIL PROTECTED]> wrote: > How can I align the text of a gtkentry on the left or on the right? > Check this: http://mail.gnome.org/archives/gtk-list/2002-July/msg00331.html John ___ 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)
On Tue, 31 May 2005 10:30:37 +0200 (CEST) "Hubert Sokolowski" <[EMAIL PROTECTED]> wrote: > > > I request that code generation not be removed from > > Glade project. > > Me too!!! Me too... I was convinced that Linux was about freedom of choice? If code designers start limiting the choice of users, next we'll have to throw peripherals away because someone decides it's time... (sounds familiar?) I did read somewhere that it would be simple to write a code converter to re-generate the missing C-code. OTOH, maybe this list is not the right (or most effective) forum to discuss this. John ___ 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. Have you written it? If not, please write it for people happiness. Preferably of the same quality as if it was written by glade guys. Maybe it's pretty easy for you, but writing an xml parser and dealing with all those internal-child things and i don't know what else is not easy for many people. Especially when they are busy with writing their application or living and want a tool, not an extra exercise in programming. Yevgen ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk_widget_modify_text on comboBox
Hi, when i set the combobox to insensitive via gtk_widget_set_insentive(comboBox, TRUE) I cant seem to get the gtk_widget_modify_text(comboBox, GTK_STATE_INSENSITIVE, black) to work. the result I am aiming for is that instead of grayed out text, it has black text. the above code seem to work for gtkentry and gtktextview widgets. any ideas how to fix it will be much appreciated thanks ___ 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: 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. Olexiy ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: State changing of Toggle Buttons
Michal Porzuczek wrote: >Hi, > >I was wondering if it is possible to set a Toggle Button's state to >something else when you are inside another Toogle Button's callback. I >know there is the gtk_toggle_button_set_active method but that >requires you to have the GtkToggleButton. Is there another method that >only uses the Widget to change its state? Or is there an easy way of >accessing the GtkToggleButton from the Widget? > > > You can pass the other toggle button as the user_data argument to the callback: g_signal_connect(G_OBJECT(toggle1), "toggled", G_CALLBACK(my_func), toggle2); You can use g_object_set_data to store a pointer to the other toggle in the first toggle object, and the retrieve the pointer with g_object_get_data. If you use glade, you can use its widget looking functions. -- Yes, America is a country based on how pissed-off a group of taxed people can get. We exist as a country because we're cheap. Eduardo M KALINOWSKI [EMAIL PROTECTED] http://move.to/hpkb ___ 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)
> I would support the inclusion of Code generation > in GLADE UI Editor. It is a welcome feature, for those > who would like it. If its not to be in the main tree > atleast put the code into a plugin thats enabled > at default, and users can turn it off, if they prefer. Personally, I don't think code generation belongs in the Glade UI editor at all. If I modify the .glade file by hand, I'd rather not have to run the entire Glade software just to update the source files. 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. ___ Join Excite! - http://www.excite.com The most personalized portal on the Web! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk entry
How can I align the text of a gtkentry on the left or on the right? I'm using gtk 1.2 thanks Giovanni ___ 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)
Hi! > Hello Everyone! > G'day all. > > I would support the inclusion of Code generation > in GLADE UI Editor. It is a welcome feature, for those > who would like it. If its not to be in the main tree > atleast put the code into a plugin thats enabled > at default, and users can turn it off, if they prefer. > > I request that code generation not be removed from > Glade project. Me too!!! ___ 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)
Hello Everyone! G'day all. I would support the inclusion of Code generation in GLADE UI Editor. It is a welcome feature, for those who would like it. If its not to be in the main tree atleast put the code into a plugin thats enabled at default, and users can turn it off, if they prefer. I request that code generation not be removed from Glade project. -Thanks Muthu > 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 > __ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
