GTK+ Forums

Discussion forum for GTK+ and Programming. Ask questions, troubleshoot problems, view and post example code, or express your opinions.
It is currently Sun Oct 26, 2014 2:59 am

All times are UTC




Post new topic Reply to topic  [ 7 posts ] 
Author Message
 Post subject: My first adventure into Python and GTK+
PostPosted: Mon Jun 16, 2014 2:37 pm 
Offline

Joined: Mon Jun 16, 2014 5:10 am
Posts: 4
Due to a photo-editing need of mine I was forced to suddenly start considering learning Python and developing a GIMP plugin for my own use.

I am colour-blind (to some degree) and this makes it really hard for me to do certain tasks on colour images that would be much easier on greyscale.

I realized that much of it is related to the fact that colour surfaces in most programs are very very small. Most people have no problem 'perceiving' those colours in a decent degree.

For me it is impossible and I need really big surfaces to properly "feel" a colour. So that I can proceed using intuition to manipulate those pixels.

I wasn't planning to do this at all and it feels like something I don't even want to do, but I must continue with it anyway. There are some things in my life that I cannot get on with unless I do these tasks.

So I went on the GIMP IRC channel and learned that my best bet would be to use GTK+ if I ever wanted it to be a GIMP plugin.

My first exposure to that "PyGObject" thing was very disconcerting. The name, positioning and examples spoke volumes about some bad decisions being made in that area. It seems "PyGnomeObject" was or is intended as a library interconnect layer and not as something that should be directly exposed to the end-user (the library user). And, in PyGTK it is not directly exposed indeed, but merely exists as a back-end to that Python GTK interface.

Then I ventured into the current PyGTK and immediately it was easier to understand, the examples were better, the tutorial snippets were better, etcetera. And I decided then that I would never use GTK+ 3 as long as this was the case.

Besides, GIMP still uses GTK 2 for its current version. They said to migrate to GTK 3 in version 3 of GIMP (now 2.8).

Anyway, I loaded a python 2.7 environment with the complete pygtk package and started using the "gtk" module.

It has been very interesting. GTK looks a lot like the Delphi VCL that I was used to when I was a teenager. It seems to be slightly more flexible while being slightly less elegant. I ran into quite a few problems too.

For example, GC.set_foreground() or whatever it is doesn't do anything. I have to use GC.set_rgb_fg_color(). Not sure if this is related to my OS (Windows 7).

Another thing is that gtk.Window.set_geometry_hint() doesn't honour the max_width and max_height settings, instead doing something very weird: it renders the window unresponsive to programmatical resize() attempts when the current window size is bigger than that max_width and/or max_height (not sure about the combos, but probably the same).

gtk.Window.resize() doesn't do anything anyway unless I set its resize mode to gtk.RESIZE_IMMEDIATE, unless I hide() the window first before callling the resize(), then it always works.

All of that turned into some funky resize-back-to-my-desired-max-dimensions code :D.

I even tried to see if I could use win32gui module to get a custom message loop running etcetera but the documentation for pywin32 is next to nonexistent. The only way to tell Windows your desired max dimensions is to receive a windowproc message that asks for this information. And then respond to it, primarily by setting the pointer-referenced values that you get to something you want. That was a real pain and I didn't achieve anything..

But I know how to create a python Thread now.

Anyway at this point I have some code that creates some precisely calculated clipping regions in a DrawingArea and then I just iterate though all my GCs and draw rectangles of near-infinite size in different colours and everything comes out the way it is supposed to :D :D :D.

I really hope those gtk cq. pygtk devs wisen up and reposition "GObject" in a way that doesn't directly expose it to library users.


Top
 Profile  
 
 Post subject: Re: My first adventure into Python and GTK+
PostPosted: Mon Jun 16, 2014 8:16 pm 
Offline
Familiar Face

Joined: Thu Aug 20, 2009 1:54 pm
Posts: 42
Location: Belgium
I've written recently a small guide to get started with GLib/GTK+ development.

And I recommend the C language, even if the GObject boilerplate is a bit cumbersome (but with tools to generate it it's ok). The advantage with C is that there is no extra layer between GTK+/GLib and your application. GTK+/GLib are themselves written in C, the documentation is primarily written for the C language, so it's easier. If you add an extra layer (GObject introspection or Vala, etc), it adds more potential bugs (in the layer or in the doc), and more potential maintenance work.

Also with the C language you benefit from the static-typed language: the compilation is something really useful to detect e.g. a typo in a variable name. For the maintenance and for code refactoring, a static-typed language is far more better.

And GObject is useful for writing a GTK+ application. If you want to connect to a signal, you use g_signal_connect() for example. If you want to bind two properties, you use g_object_bind_property(), etc. GObject is part of the API.


Top
 Profile  
 
 Post subject: Re: My first adventure into Python and GTK+
PostPosted: Mon Jun 16, 2014 8:36 pm 
Offline

Joined: Mon Jun 16, 2014 5:10 am
Posts: 4
Seriously, this is so poorly implemented.

I'm having to read the full GTK documentation to understand how PyGTK operates.

It's all about the Graphics Context gtk.gdk.GC.

When you use gc.set_foreground(gdk.Color) it will only work for an allocated color, which is a color that has a pixel value set (and registered in the colormap). However, the Color that gets set has its rgb fields garbled (don't ask me why).

So, at all times, the gc.foreground object will have useless rgb fields. You can set them, but it won't do anything and if you read the value back that you just set, it is garbled again.

And the only way to obtain the rgb values (that is, a fully filled-in Color object) is to call gc.get_colormap().query_color(gc.foreground.pixel).

Then, you might as well save the colours you use yourself and not try to depend on the GC for readout or storage. I'm probably best off saving some (gc, color) tuple or even a custom class. It is also not hard to wrap the GC in another class that provides access to its methods.

It is however not possible to subclass gdk.GC properly. You cannot do anything useful with it, the class is written in C and when you try to set a custom attribute for your subclass, the following C code gets executed:

PyErr_SetString(PyExc_AttributeError, "could not write attribute");


edited before I saw there was a new reply:


And this behaviour is not specific to PyGTK.

Here is a mailing list post from 2003:

gtk-app-devel-list: gdk_gc_get_values returns strange things.

So I am sitting here spending hours discovering useless bugs that no one cares about, not even enough to document it. And I'm having to work my way around anomalies that make no sense and that have been left as they are for at least 11 years. And it takes me hours to realize what is going on, when a few lines of documentation would have made it clear to me in minutes.

I get the impression this is not exactly a brilliant way to spend time. Not for me, but also not for the people doing this. Every minute they save in not writing documentation costs other developers many many manhours combined. People are having to reinvent the wheel over and over and over and over again.

The PyGTK docs are just a subset inclusion of the full GTK docs for associated functions. And since it is a subset, important information is left out for you to discover after you access the full C documentation.

Real fun yes, I've already wasting hours trying to do something that should have worked instantly if people had cared enough.

I get the feeling I won't be around here long...


Last edited by dryden on Mon Jun 16, 2014 8:59 pm, edited 2 times in total.

Top
 Profile  
 
 Post subject: Re: My first adventure into Python and GTK+
PostPosted: Mon Jun 16, 2014 8:56 pm 
Offline
Familiar Face

Joined: Thu Aug 20, 2009 1:54 pm
Posts: 42
Location: Belgium
The GGAD book (quite old, but you can download it) has a chapter on GDK, including a section on Graphics Context.
I think GDK didn't change a lot during all these years, so it's maybe still relevant.


Top
 Profile  
 
 Post subject: Re: My first adventure into Python and GTK+
PostPosted: Mon Jun 16, 2014 9:29 pm 
Offline
Never Seen the Sunlight

Joined: Mon Apr 28, 2008 5:52 am
Posts: 764
Location: UK
Hello,

Please do not use the GGAD book as it is too old to be of any use. That book is based on GTK v1.2 which is obsolete. GDK has changed a lot since then even with going to GTK v2.0 and later on in the GTK 2 series with the addition of Cairo.

Also use what ever language is best suited for you and the application you are writing. The official bindings for GTK are well written, fairly bug free and are generally thin wrappers so do not impact on your application in terms of performance. For the OLPC project the preferred programming language is Python.

For a tutorial Zetcode do may good ones and this is theirs on PyGTK at http://zetcode.com/gui/pygtk/

The home page for PyGTK is http://pygtk.org/ and has the documentation and tutorials.

_________________
E.


Top
 Profile  
 
 Post subject: Re: My first adventure into Python and GTK+
PostPosted: Mon Jun 16, 2014 10:11 pm 
Offline

Joined: Mon Jun 16, 2014 5:10 am
Posts: 4
Thanks, that Zetcode tutorial is very readable. It is also the first time that someone explained to me what Glade and Cairo are :P.

And that wxWidgets uses GTK+.

Right now I'm not really working with widgets. I may need to create a few myself though, not sure yet.

I'm just doing everything on a DrawingArea. The next thing I am going to draw is a form of a sliding bar. Except originally (in my old program) it only used keyboard, not mouse. I will probably need to create a widget subclass and handle a few events. Should not be so hard.

It's a lot of fun dealing with a "visual component library" again. Something that's a little better than Java Swing. Although Delphi's VCL was really much more robust than GTK+ 2.


Top
 Profile  
 
 Post subject: Re: My first adventure into Python and GTK+
PostPosted: Tue Jun 17, 2014 6:14 am 
Offline
Never Seen the Sunlight

Joined: Mon Apr 28, 2008 5:52 am
Posts: 764
Location: UK
There is already a widget for doing a sliding bar. It is called GtkScale (Gtk.Scale) with GtkHScale (Gtk.HScale) and GtkVScale (Gtk.VScale) sub-classing it to give you a horizontal or vertical bar.

There are many widgets and by learning how to use them and how to place them will make your application fairly easy to write.

_________________
E.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group