bugMyPaint - Bugs: bug #19230, Migrate to GTK3 and/or PyGI /...

Show feedback again

You are not allowed to post comments on this tracker with your current authentification level.

bug #19230: Migrate to GTK3 and/or PyGI / GObject-Introspection

Submitted by:  Andrew Chadwick <achadwick>
Submitted on:  Sun Jan 1 19:16:11 2012  
Severity: 3 - NormalPriority: 7 - High
Status: FixedPrivacy: Public
Assigned to: Andrew Chadwick <achadwick>Open/Closed: Closed
Release: Planned Release: None
Operating System: 

(Jump to the original submission Jump to the original submission)

Mon Jun 23 21:43:37 2014, comment #17:

[This is a canned response, please forgive the broken formatting: it's one of the many things
Gna! unfortunately does not do well.]

This bug tracker will shortly be moving to Github. As part of this process, we are reviewing
old bug reports on gna.org.

This bug was marked as Fixed long ago, but was still classified as Open. Github does not
distinguish between Fixed+Open and Fixed+Closed in the way we once did here, so this bug is
now being marked Closed, and will not be migrated into the github issues tracker.

If you believe that this bug still affects the most recent git master of MyPaint (and thus
the next release), please feel free to open a new issue on Github about it. Our new issue
trackers are:


Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Sat Jun 29 17:37:29 2013, comment #16:

(There are still GTK3 specific porting bugs left, but those should be reported separately now, IMO.)

Martin Renold <martinxyz>
Project Administrator
Sat Jun 29 17:29:55 2013, comment #15:

Master is fully ported to GTK3, we don't even support GTK2 any more for some time now. Time to mark this as fixed.

Martin Renold <martinxyz>
Project Administrator
Fri Mar 22 22:04:00 2013, comment #14:

Docs updated in commit 317709b43c61.

Two fallout bugs so far: bug #20636, bug #20637.

The prefs dialog was getting messy, and I needed to fix the dropdowns anyway, so I've migrated the fiddly bits of the prefs to glade as of commit 764cbc397d. Edit it with:

$ glade/run.sh gui/preferenceswindow.glade

Seems to work so far!

GtkGrid isn't supported in GTK2, so I guess that's it for PyGTK support. I have to admit I'm not particularly fussed about remaining backwards compatible at this point ☺

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Thu Mar 21 06:50:08 2013, comment #13:

Great news, thanks a lot for pushing this forward! I hope I'll find some time to help with testing&debugging.

Martin Renold <martinxyz>
Project Administrator
Thu Mar 21 00:36:54 2013, comment #12:

We are now GTK3 by default https://gitorious.org/mypaint/mypaint/commit/b2b38789b5ab77da77f9a3382e98324f3f4b89ce . Expect bugs!

Support for running in PyGTK mode (see README.gtk3) will be retained for a short while, but expect it to disappear when all of the really annoying bugs have disappeared.

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Fri Jul 20 22:22:08 2012, comment #11:

I've rebased the gtk3 branch against master and merged it back in. It should work correctly in GTK2 mode via our own pygtkcompat.py and lots of local tests, and GTK2 is the default build.

GTK3 mode builds, and you can get some things done. It has quite a few GUI glitches, and will still probably throw exceptions in some of the dustier code paths. However it can be fixed up in master now, and that's where the focus of this work will continue.


Next job is to move towards phase 3: GTK3 by default. The Windows build folks have flagged this as a potential source of problems for that platform,


but hopefully a lengthy (but not too lengthy) transition towards full GTK3 would help.

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Sun Jul 15 20:16:56 2012, comment #10:

You can now save and load files, and press keys to trigger exceptions (mostly). The GUI: still kinda broken. No subwindows yet.

Canvas classes understand pressure and get the transformation matrix right, and device mode setting should happen now for devices which report a pressure axis.

We have cursors, albeit with some wrinkles and assumptions.

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Wed Jul 11 14:43:01 2012, comment #9:

Mailing list planning discussion: https://mail.gna.org/public/mypaint-discuss/2012-07/msg00006.html

README detailing rough plan outline and details of how to get testing and porting https://gitorious.org/mypaint/mypaint/blobs/gtk3/README.gtk3 (evolving)

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Sun Jul 8 22:53:56 2012, comment #8:

I've had time to carry the branch forward a bit, fix a few regressions and do some of the gtk3 work: I think it works fully under gi+gtk2 via pygtkcompat now (all of which is rooting out badly-behving Python code of course: we still have the real work to do).

Curve should be ported. I've added a GUI unit test for it, though it seems to be throwing a few non-GTK-related exceptions when points are dragged to the ends of their range.

gtkexcepthook.py should to the right thing now, and has a new GUI unit test.

TiledDrawWidget is now drawing under gtk3, and you can scribble in it. Resize is broken, and probably lots of other stuff too. Making drawing code portable with a draw_cb() called by expose_cb() and some GTK version tests for binding them seems the obvious approach. Expose/clipping regions seem broken right now, but it's possible to construct workarounds.

I'm liking the opt-in approach: gives us a choice about when to reintegrate the branch.

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Fri Jun 22 21:05:40 2012, comment #7:

I've put up a branch with some GTK+3 migration work now, using pygtkcompat from PyGObject: https://gitorious.org/mypaint/mypaint/commits/gtk3

The work is done such that using it with GTK3 is opt-in, by setting the env var "MYPAINT_ENABLE_GTK3" to 1, and it should still run under GTK2 should without regressions.

We obviously don't want to keep the two in parallel for long, but this approach will allow us to do the work gradually and put ported sub-components into master as they are completed instead of keeping everything in a separate branch for the entire porting period.

Current status is that the main window can be brought up, menu entries work but none of our custom widgets have been ported, nor input device handling.

Jon Nordby <jonnor>
Project Administrator
Thu Jun 14 20:18:03 2012, comment #6:

There is now a PyGTK compatibility module in PyGObject: pygtkcompat

This should make it possible to run MyPaint on top of GTK+ 3 and pyGI without too much initial porting, and then to allow a gradual migration towards the "real" pyGI APIs.

The low hanging fruits are probably still valid.

Jon Nordby <jonnor>
Project Administrator
Wed May 16 14:52:02 2012, comment #5:

Bit too hacky, outdated and incomplete to share, sorry. IMO it's worth hacking on the master branch up front in order to get it into a state that pygi-convert.sh prefers before making the gtk3 branch. Low-hanging fruit:

- Cleaning up import syntax; it's a quick and simple task.

- Redoing any GdkPixmap and GdkBitmap code for cursors using offscreen Cairo stuff as much as possible. Probably the best approach for the long run. Fairly involved, but not too much code.

- Adding unit tests for custom widgets. Might be trickier given how interwired the widgets are, so not essential.

- Taking the opportunity to redo any sizing code that wants use Gtk.Widget.window just for querying the width and height. Quite often it's just the wrong approach anyway, and it's more futureproof to use a .get_allocation() invocation.

Forking a pygi-convert.sh into the MyPaint master and extending it to cope with constants which are now defined in submodules would be a nice hack to have too. It's something that can only be built up with experience though.

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Wed May 16 14:25:01 2012, comment #4:

Andrew, do you have a branch you could share with the porting experiments you have done so far?

Jon Nordby <jonnor>
Project Administrator
Sun Jan 1 21:58:57 2012, comment #3:

Might be good to centralise notes and workaround scraps that we learn as we go too. Perhaps a wiki page?

Agree that we should aim for and gi.require_version() Gtk 3.0. I don't think Gtk 2.0 is functional enough for MyPaint, whereas 3.0 probably is.

Presumably the merge branch would be merged to from master as new fixes and features emerge elsewhere. To ease that, it might be worth porting - to the extent we can - one module at a time in the dirty branch, starting from working test harnesses and combing down only the hair that's necessary for each step. If we do that, fixes should apply quicker than if we try to go everything in one go.

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Sun Jan 1 21:45:07 2012, comment #2:

Isolated problems so far, but I only got as far as having to understand "sparse" and tripping over a Brush::stroke_to() assertion before I gave up. From my notes

- pygi-convert doesn't hit all of our imports, which is annoying.

- Have to be real careful about not mixing old gobject/gtk/glib/pango libs with new gi.repository.* stuff.

- Gdk.Display.get_maximal_cursor_size() isn't wrapped properly for the 2.0 I tried. It works fine in 3.0.

- Drawables; GdkPixmap and GdkBitmap are removed in gtk3. For the custom cursor at least, that means doing it in Cairo and building the cursors from a pixbuf.

- "expose-event" is now named "draw", and the signature has changed: the handler gets passed a Cairo context. Not sure if it's pre-clipped to just what needs drawing; this is sort of where I gave up trying to understand the sparseness optimizations.

- Seemingly no extension events any more. I think everything that used to be enabled via extensions is available through modern XInput stuff.

- No gtk.Widget.window attr any more for any widgets. We'll need to use .get_window() instead, or consider whether we really meant the widget's allocation (.get_allocat{ion,ed_{width,height}}()) when all we're doing with the Gdk.Window is polling its height and width. You should, apparently, use the allocation sizes when drawing.

So an initial plan of action that we can do in master up front might be to a) sort out the pygtk imports so they're all in standard form (one import per line, so that pygi-convert can chew them more easily), b) sort out attribute-based access to gtk.Widget.window and anything else we see, c) rejig the custom cursor making code and any other uses of GdkPixbuf or GdkBitmap completely, d) more per-module test harnesses for important custom widgets, since they'll help us get off the ground faster.

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.
Sun Jan 1 20:10:28 2012, comment #1:

From what I read about the topic, pygi+gtk2 is not recommended, problems specific to the (gtk2+pygi) combination are expected. I think we better go for gtk3 directly. But all I have done with gtk3 is "hello world" so far.

On a related note, I have made the switch from Python2 to Python3 in a toy project of mine (that uses Python extensions). It was straight-forward. No changes in the C code were required, 2to3 did most of the conversion, with some mistakes that were trivial to fix. In MyPaint, we might have to fix some C interfaces, though, because we pass filenames (unicode vs byte strings).

I don't have much general plan for this... except that I think we need a shared "known to be broken" branch for this in the main repository. How bad is the TDW, is it "needs complete rewrite", or just isolated problems?

Martin Renold <martinxyz>
Project Administrator
Sun Jan 1 19:16:11 2012, original submission:

We should migrate to GTK3 in order to keep abreast with emerging technologies. This might be necessary for migration to Python3 as well.

What's the general plan here? It's fairly apparent from mucking around with the code and trying to get the TDW to work that pygi-convert.sh won't do the entire job for us :)

It might be easier to port to pygi+gtk2 at first in order to get the gi part done. Is there any way of forcing which GTK version that gi will load in mixed 2.0/3.0 GIRepository environments?

What general tasks need to be done beforehand to ease the porting?

Andrew Chadwick <achadwick>
Project AdministratorIn charge of this item.


No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by jonnor (Posted a comment)
  • -unavailable- added by unconventionalt
  • -unavailable- added by martinxyz (Posted a comment)
  • -unavailable- added by achadwick (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon Jun 23 21:43:37 2014achadwickOpen/ClosedOpen=>Closed
    Sat Jun 29 17:29:55 2013martinxyzStatusIn Progress=>Fixed
    Thu Mar 21 00:36:54 2013achadwickPriority5 - Normal=>7 - High
    Sun Jul 8 22:54:26 2012achadwickStatusConfirmed=>In Progress
    Sun Jul 8 22:54:03 2012achadwickAssigned toNone=>achadwick
    Sat Jan 28 16:00:39 2012unconventionaltCarbon-Copy-=>Added -unavailable-
    Sun Jan 1 20:10:28 2012martinxyzStatusNone=>Confirmed
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup