mypaint / mypaint

MyPaint is a simple drawing and painting program that works well with Wacom-style graphics tablets.

MyPaint

A fast and dead-simple painting app for artists

Features

• Infinite canvas
• Extremely configurable brushes
• Distraction-free fullscreen mode
• Extensive graphic tablet support
• Speed, simplicity, and expressiveness
• Realistic paint-like pigment model
• 15 bit Rec 709 linear RGB colorspace
• Brush settings stored with each stroke on the canvas
• Layers, various modes, and layer groups

Download

Latest stable release.

Releases and prereleases contain links to standalone packages (and installers for full releases) for Windows, and AppImage files for Linux.

Nightly releases

Using alpha releases comes with its own risks. Sometimes bugs can sneak in that causes crashes, so don't be too surprised by that. If you come across any, please do report those bugs so they can be dealt with.

Linux

If you don't want to build from source, the latest AppImage files can be found in a rolling release. Just download the .AppImage file and make it executable.

Windows

The nightly installers and standalone archives can be downloaded from the AppVeyor CI

Click on the link matching your architecture (32 or 64), then the tab named "Artifacts" to get the file list. Only one of the files ending in .exe or .7z are needed. Using the standalone archive (7z) is recommended.

Windows Package Manager (winget)

The latest stable release is available to install via winget, the Windows Package Manager. To search for the package, run:

winget search MyPaint

and to install, run:

winget install --id MyPaint.MyPaint

The winget package is not maintained by the dev team.

Chocolatey (windows)

If you prefer to use the Chocolatey repository, both stable releases and pre-releases can be found there.

Build/Test/Install

MyPaint depends on its brushstroke rendering library, libmypaint, as well as its brush library mypaint-brushes. If you have those installed, plus MyPaint's third party dependencies, you can try it out without installing:

git clone https://github.com/mypaint/mypaint.git
cd mypaint
python setup.py demo

If the demo works, you can install

python setup.py managed_install
python setup.py managed_uninstall

For more details, see the Setup Instructions.

Contributing

The MyPaint project welcomes and encourages participation by everyone. We want our community to be skilled and diverse, and we want it to be a community that anybody can feel good about joining. No matter who you are or what your background is, we welcome you.

Please see the Contributing Guide for full details of how you can begin contributing. All contributors to the MyPaint project must abide by a Code of Conduct.

Links

• mypaint.app
  • Community Forums
• Twitter
• Discord
• Github
  • Wiki
  • Issue tracker
  • Introductory docs for developers

Legal info

MyPaint is Free/Libre/Open Source software. See Licenses and Copyrights for a summary of its licensing. A list of contributors can be found in the about dialog.

Contributors

Code Contributors

This project exists thanks to all the people who contribute.

Financial Contributors

Become a financial contributor and help us sustain our community. [Contribute]

Individuals

Organizations

Support this project with your organization. Your logo will show up here with a link to your website. [Contribute]

mypaint's Issues

Frame re-enabling at load time: buggy and inconsistent

Migrated from Gna! bug 20926 because the underlying issue is not really fixed, to my eyes. The original report was basically just a request for the frame to be enabled at load time, which is done but is somewhat inconsistent.

• Loading an ORA file updates the frame to the dimensions in the element, but supposedly only enables the frame if its dimensions are something other than the data bounding box's.

  The goal of this silly criterion is that if the user turned off the frame to get an "infinite canvas", that choice should be preserved. However all OpenRaster files must have a top level pixel width and height, and for MyPaint "infinite canvas"es, this width and height are that of the data bounding box. Trying to infer it is fairly nasty and magical. Really the XML should use a mypaint_frame="enabled" field somewhere (or better still its namespaced equivalent).

  • In practice though, the frame is never enabled though on a command line load regardless of its enabled state and size before saving. Oops.
  • Immediately pressing F5 (File → Revert) to reload the same file results in the frame being shown IF the silly criteria above apply.
  • Loading MyPaint without a command-line file then loading an OpenRaster file (for which the silly criteria apply) results in the frame being enabled.

• Loading a PNG or a JPEG file always updates the frame to the correct dimensions (those of the loaded file), but always disables the frame. To be honest, I'm not sure whether this is the right behaviour or not.

Assertion error when merging locked layers

Migrated from Gna! bug 22295:

In MyPaint version "1.1.1-alpha.20140703+git.308c416" on Manjaro (Arch) Linux I have the following issue: when I merge an upper unlocked layer with a locked layer below, MyPaint crashes. This is the error log:
-- Alex

Verified infd586150b03aece619a218cb0bcf4d2e1ff93749. Here's the relevant terminal output from mine, with formatting preserved (gah, Gna.):

Traceback (most recent call last):
  File "/home/andrewc/Development/MyPaint/gui/document.py", line 854, in merge_layer_down_cb
    if self.model.merge_current_layer_down():
  File "/home/andrewc/Development/MyPaint/lib/document.py", line 655, in merge_current_layer_down
    self.do(command.MergeLayerDown(self))
  File "/home/andrewc/Development/MyPaint/lib/document.py", line 557, in do
    self.command_stack.do(cmd)
  File "/home/andrewc/Development/MyPaint/lib/command.py", line 63, in do
    command.redo()
  File "/home/andrewc/Development/MyPaint/lib/command.py", line 562, in redo
    merged = rootstack.layer_new_merge_down(self._upper_path)
  File "/home/andrewc/Development/MyPaint/lib/layer.py", line 2934, in layer_new_merge_down
    assert isinstance(layer, PaintingLayer) and not layer.locked
AssertionError

How we deal with the visibility of Merge Down is also covered in #1. Ideally, let's fix both at the same time.

Typos in header image on development page of web site

On the development page of your web site there is an image at the top with superimposed text reading:

MyPaint uses git for it's developement branches

"Development" is misspelled and there should not be an apostrophe in "its".

scons --help doesn't work

Hello, I was told in #52 that scons --help should produce helpful output, but with the latest commit 92112f7 on OS X 10.9.4 this is what I get:

$ scons --help
scons: Reading SConscript files ...
building for 'python2.7' (use scons python_binary=xxx to change)
using 'python2.7-config' (use scons python_config=xxx to change)
rm -f libmypaint-tests.so libmypaint.so libmypaintlib.so
rm -f libmypaint.a libmypaint-tests.a
Enabling i18n for brushlib in full application build
swig -Wall -o mypaintlib_wrap.cpp -noproxydel -python -c++ mypaintlib.i
Unable to open file mypaintlib_wrap.cpp: Permission denied
scons: *** Error 1

$ sudo scons --help
scons: Reading SConscript files ...
building for 'python2.7' (use scons python_binary=xxx to change)
using 'python2.7-config' (use scons python_config=xxx to change)
rm -f libmypaint-tests.so libmypaint.so libmypaintlib.so
rm -f libmypaint.a libmypaint-tests.a
Enabling i18n for brushlib in full application build
swig -Wall -o mypaintlib_wrap.cpp -noproxydel -python -c++ mypaintlib.i
rm -f _mypaintlib.so
Package pygobject-3.0 was not found in the pkg-config search path.
Perhaps you should add the directory containing `pygobject-3.0.pc'
to the PKG_CONFIG_PATH environment variable
No package 'pygobject-3.0' found
OSError: 'pkg-config --cflags --libs pygobject-3.0' exited 1:
  File "/opt/local/var/macports/build/_Users_rschmidt_macports_dports_graphics_MyPaint-devel/MyPaint-devel/work/mypaint-92112f737e3bc0172ab825566ff4d181d2c3070c/SConstruct", line 202:
    application = SConscript('./SConscript')
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/scons-2.3.0/SCons/Script/SConscript.py", line 609:
    return method(*args, **kw)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/scons-2.3.0/SCons/Script/SConscript.py", line 546:
    return _SConscript(self.fs, *files, **subst_kw)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/scons-2.3.0/SCons/Script/SConscript.py", line 260:
    exec _file_ in call_stack[-1].globals
  File "/opt/local/var/macports/build/_Users_rschmidt_macports_dports_graphics_MyPaint-devel/MyPaint-devel/work/mypaint-92112f737e3bc0172ab825566ff4d181d2c3070c/SConscript", line 26:
    mypaintlib = SConscript('lib/SConscript')
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/scons-2.3.0/SCons/Script/SConscript.py", line 609:
    return method(*args, **kw)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/scons-2.3.0/SCons/Script/SConscript.py", line 546:
    return _SConscript(self.fs, *files, **subst_kw)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/scons-2.3.0/SCons/Script/SConscript.py", line 260:
    exec _file_ in call_stack[-1].globals
  File "/opt/local/var/macports/build/_Users_rschmidt_macports_dports_graphics_MyPaint-devel/MyPaint-devel/work/mypaint-92112f737e3bc0172ab825566ff4d181d2c3070c/lib/SConscript", line 58:
    env.ParseConfig('pkg-config --cflags --libs ' + pygobject)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/scons-2.3.0/SCons/Environment.py", line 1554:
    return function(self, self.backtick(command))
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/scons-2.3.0/SCons/Environment.py", line 596:
    raise OSError("'%s' exited %d" % (command, status))

Write from-source Windows build and install docs

(Fallout from #47, which was in the end more of a request for support)

Windows needs good instructions in the form of a README of some sort in the main repository. It should ideally tell very new starters wishing to test directly from git and get involved in the project how to pull, build from source, and test MyPaint by running it on the command line from within the tree. Optionally instructions on how to install it, or make installer bundles would be very useful to have too.

I'm not a Windows user and can barely get off the ground with this stuff as a result, so I'm going to have to leave this to someone else.

@tumagonx - would you be willing to pick this one up? A pointer to existing docs of this nature would be something we could use too.

[Feature Request] Add Right-Click Menu, and Dragging to Bottom Brush Icon and Popup Menu

Split from Maxy's comment on Gna! bug 20697:

[...] but especially for favourites, right-click might be more efficient anyway.
-- Martin Renold (martinxyz)

Personally I'm thinking in terms of a footer bar button more like the one for colours though: just click it and the current settings are bookmarked (with or without copying the preview)

Panning with a destination-in/out layer visible is extremely performance intensive

With an i7-4770k:

The first huge 90% chunk is from continuously panning in a circle with a destination-in layer visible. The second smaller one was a few seconds of panning with the layer disabled.

The same thing happens with destination-out layers.

Drawing quickly produces very line-y curves

As an example.

For reference, here's some lines drawn very rapidly with Gimp:

They're a lot uglier, because Gimp, but they're a lot smoother than Mypaint's lines.

Background alignment: appears to shift when changed after reloading an OpenRaster file

Migrated here from Gna! bug 16741, where it was originally reported as a transparent PNG issue (sorry, WONTFIX for transparent PNGs: they don't have any background expectations and shouldn't).

However it evolved into a bug which can be provoked when using the layered OpenRaster format, which is intended to alleviate this sort of problem. Steps to reproduce:

1. Pick a "comic panel" type background
2. Paint in a panel, more than 64 pixels from the top and right of the "panel"
3. Save as .ora
4. Load in the same .ora
5. Open the background selection window again, choose another background
6. Choose the "comic panel" type background again
   • background has now shifted irrevocably

There's no need to close the background selection window between steps 5 and 6: the bug presents immediately.

Not sure how much we want to chase this for 1.2 - it's obviously caused by the save code only saving populated tiles (and the background underneath them). The save alignment stuff frankly scares me though, particularly when the frame is factored in; I'd rather have weird behaviour when reassigning backgrounds than subtle alignment bugs emerging between saving and loading.

I'm a newbie. How can I participate?

Hi there,

I'm sorry for this question but I'm new to OpenSource and also inexperienced with gitHub.

What are the steps to participate? I think I'd need to know python first. Then I should download the project. Look through the code and then push if I think the contribution is worth it?

Could anyone give me a step by step instruction on how exactly to participate?

Thanks. And once again, sorry for this newbie question.

[Feature Request] - Add numbers to Tool Options sliders for Freehand Drawing

Hi,

Problem:
The Tool Options in Freehand Drawing mode display a series of sliders ( see the screenshot bellow ):

Those sliders are difficult to use, because they don't display any numbers.
Numbers, can be important while painting and to adjust brush settings. They also provide a feedback.

Proposition:
Using Interface widget with more infos and control ; eg under, the one of Gimp:

After fullscreen, freehand lines look line-y/jagged/geometric/non-smooth until canvas is panned (or similar mode shift)

As of d789f83, entering fullscreen mode when in freehand mode can cause new brushstrokes (blue stroke, on left below) to appear non-smooth. After the canvas is panned, freehand goes back to normal (red/orange stroke, on right).

To reproduce:

• Pick a brush
• Set "Smooth" (Slow Position Tracking) to zero
• Enter Freehand mode
• Press F11 to go fullscreen
• Draw a fast squiggle: line looks like the blue one
• Pan the canvas using the middle button
• Draw another fast squiggle: line looks like the red/orange one now.

Just reporting this one here so people can search for it. It's to do with setting up the workarounds and hacks we use to cope with GDK motion event compression; those for some reason are going away when the main window transitions from regular mode to fullscreen.

Looks like the easiest fix would be to leave and re-enter the current mode when the window is fullscreened, but issuing a checkpoint (and having freehand set the workarounds up again) may be neater.

Freehand mode: "ghost" dabs visible along strokes

As reported by user "kaerhon" in the forums; quoting here:

Hi mypainters.

First, i'm sorry for creating a new thread for something i spoke about some time ago. But it will be clearer, i think

I noticed strokes lacked some dabs. From what i've seen, the curved stroke is broken into small straight lines, drawn with dabs. Maxy, in previous thread, told me about the line interpolated between motion events. Problem is, at junction points of that stroke, a dab is lacking (possibly not drawn?), causing a "hole" in the stroke, at each angle. It is more noticeable with fast strokes (i'm often painting with fast strokes), with low opacity. (see 2/curved on the picture)
At first i thought it had something to do with smudging, but smudging only smoothed opacity, making clearer the hole. Without smudging, high radius, and high hardness, it is very noticeable. (see stroke 1, made with brush 1 of the brush pack i put link below)

I'm no dev, so i can't plunge into source code to search where is the problem (i'm sorry for this). I made a lot of tests, trying to replicate the issue, with success.

Things from me asking people:
-I nearly thought i was alone to have this problem, as noone i asked seemed to have encountered it. i asked on the IRC chan, and someone tried the brushpack i linked in previous thread), so i thought i could ask here again.

-Someone suggested it was about dab amount. i have an old computer so my brushes aren't at full dab amount, and i was reluctant to increase amount (because it makes everything slower). my last tests made evident dab count wasn't in charge

-In the old thread, Maxy asked me about my event timestamp, which was as expected (values maxy told me i should have, i had), and about low direction filter (which was a problem with not round brushes) which isn't the case here. what i understand is stroke is drawn between motion events, but not at motion events.

So, i want to ask you, Devs, if you could fix this, it would be wonderful (for real, i struggle with this for months)

brush pack for test(with 3 brushes made for demonstration purpose)

old thread

Update web pages (wiki, wordpress, forums) to point at github, not gitorious

Mypaint's Development page still says to clone from gitorious, but it looks like development is being done on github first. Slightly confusing situation right now.

With the bugs moving from gna to github, and commits appearing here first, I'm guessing the site just needs to be updated.

Add an inking tool (replace Bézier curves in "Lines and Curves")

I want to add an inking tool beyond 1.2 to replace the Bézier curve drawing aspects of the "Lines and Curves" tool. Code exists in gui/linemode.py for drawing and interpolating arbitrary smooth shapes with Catmull-Rom cubics, so it's just a "small matter" of creating a great UI for it. Rough bullet-point workflow:

• User clicks on an "ink" tool
• User draws a squiggle,
  • while drawing, present the curve differently
  • perhaps drop in the initial control points as we go
  • program captures the shape while rendering it (pressure, tilt, position) as control points
• User stops drawing the squiggle
  • program allows control points to be moved around, curve will update
  • drag far away from the curve to delete a point (= smooth here)
  • click on the curve to add a new point (= new wiggles here)
• UI should allow user to click away from from the curve being edited to start creating a new one

Graphical options for the tool would cover density of initial control points. I envisage no more than one point per 20 to 25 screen pixels while doing the initial capture pass.

Use cases: basically anybody making comics or manga-style images.

Drawbacks: strokes are still strokes, and cannot be edited once a new one is created. Even if the tool does create special "spline edit" actions, users will not be able to save the document, reload it, and edit arbitrary stroke shapes as first-class objects. There may be scope later on for special layer types which revisit this.

Very much post-1.2.

Under rare circumstances, the first stroke is drawn incorrectly

Migrated here from Gna! bug 20405

Under rare circumstances first stroke drawn incorrectly

1. start mypaint
2. Do NOT move mouse.
3. From current position very quickly draw line with mouse
4. Mypaint might add unexpected hook to the beginning of the line. (see screenshot: I've drawn vertical line, diagonal line was added by mypaint)
   AFAICT this happens due mypaint-brush.c\ mypaint_brush_stroke_to due its usage of states at line 790:

x = self->states[MYPAINT_BRUSH_STATE_X] + (x - self->states[MYPAINT_BRUSH_STATE_X]) * fac

fac is calculated from dtime and slow position tracking setting of brush(In my case it is 1.03 of deevad/pen).
Upon initialization states are zeroed, so calculated value is lower than it's supposed to be.
If mouse is moved before drawing, then motion_notify_cb at canvasevent.py:519 will call stroke_to with zero pressure, so coordinate states will be updated. However if stroke_to with pressure is called immediately without moving mouse, then weird thing might happen
-- Libra Rian (zrzz)

It's reproducible as of fc4fafa. Other notes pulled from the original bug:

A good way to reproduce it is to start mypaint using the keyboard only and start the 1st stroke by pressing the mouse button in a way which simultaneously propels the mouse downwards.
-- me

It's got to do with initialization of low-pass filters - they initialize themselves whenever there is motion (and with a tablet, there is always motion).
-- Martin Renold (martinxyz)

Device selector UI needed

With issue #29, and (caveat: own itch only) issues I've been having recently getting Intuos5 wireless to work without the touch area interfering all the time, it's probably time we introduced some code for disabling and enabling devices, or setting the chosen mode for them - kinda what we used to do with heuristics based on names.

A toy branch I have floating around here has something looking like

but perhaps the options should also include ignoring the device, i.e. configuring MyPaint to ignore motion and button events originating from the device. Specifically, the options would be:

• Default behaviour
  • do not attempt to do anything special with the device
• Force Screen mode: immediately, and when
  • starting up
  • device is plugged in
• Force Window mode
  • same transitions as above
  • these need GdkDeviceManager "device-added" magic
• Ignore in MyPaint (canvas ignores any events from this device)

this would scratch my itch - I could set the touchpad device to ignore and be happy. There are reports of differences in Hanvon/Huion tablet behaviour too, which may depend on mode setting. Outside chance that being able to poke the device's GdkInputMode may help. Maybe.

Frame tool: resize when zoomed in or out is unpredictable, often imprecise and nigh-impossible to use

The frame tool shows some very strange behaviour when zoomed in a lot and you try to resize the frame by clicking and dragging on the orange border:

To reproduce:

• Click on the frame tool, make sure the frame is enabled
• Zoom in a lot, say 1100%, so that one of the orange resize edges or corners is visible
• Try to resize the frame by grabbing and moving one of the orange edges or corners

Basically while you're dragging the resize happens, but moves jerkily, in huge multi-pixel steps, or (most of the time) not at all. It's very unpredictable, and looks totally wrong. I expected this to be able to manage pixel precision when it was written, so something's wrong here.

It doesn't matter whether you use the mouse or a tablet, the frame resize is equally broken. It's also independent of canvas rotation. There are also inconsistencies when zoomed out, to 6.2% say. In this casem fast resizes make the frame overshoot where the cursor is rather than undershoot it as in the example above.

Affects git master as of ae3d8b5

Accelerator map (keys) editor is a mess: full of duplicates and out of context strings

The accelerator map editor is a mess right now. I't's derived from lists of registered actions known to the app. So far so good, but

• Loads of seeming duplicates
  • Editing tool modes, for example, have radio actions and actions that serve to flip the radio action on or off depending on its state and the state of the mode stack
  • The separate scratchpad document is another source of duplicates
• Some actions are only there to make the menu structure work!
• Bad, out-of-context strings everywhere

Make selection and use selection data

Migrated here from Gna! bug 19207 because this is such a frequently requested feature.

Okay, this is a slightly obvious, yet slightly important one:
Sometimes, an artist may wish to simply move something they had drawn, either to make room for something else, or to reposition something mispositioned.
This cannot be done unless there are tools to create a selection (either through circles, squares, freeform, etc.), and cut/copy/paste/move/otherwise transform it (or the entire layer's contents)
As long as its not as overly complicated as The GIMP's excuse for this feature (which requires going through 3 different tools to move/resize/etc.), this would be great.
-- .

No time to work on this before 1.2, deferring it again. Some mockups would be nice: it's fairly obvious how selection creation should work, but how to work with selections? What should the user be able to do with them?

• Transform to a layer (& thus to a mask?)
• Accept brushstroke dabs only within the selection
• Cut/copy/paste
• Er, what else?

Accelerator map (keys) editor needs search

Migrated from Gna! bug 22207:

The accelerator map editor needs a search facility to be fully usable: see the feedback on bug #21751.
(Arguably, so does the button binding editor on the neighbouring tab)
-- Andrew Chadwick

The feedback on Gna! bug 21751 originally read:

It still has usability problems, though. No need to keep this bug open because of that, just stating the obvious: The desperate need for a textual filter or search. The action labels which made sense in a certain menu now lack context, e.g. "smaller" and "decrease". Some actions don't seem to be useful when assigned to a key. And a lot of actions in the menu did exist just to assign a key - they can be removed from the menu now... or maybe remain there just to keep existing features and shortcuts discoverable?
-- Martin Renold

@Marand- mentioned making the search a filter, not an uncommon pattern:

1. [...]
2. Is there any way to filter the actions? I know you can type a word and it skips to instances of that, but it's not as clean as having, say, a search field at the top where you type "Undo" and the list propagates with "Undo" and "Undo and Redo" actions.

I only mention #2 because it might make the huge pile of keybinds less daunting. Having some kind of grouping for them might help, too, but I don't know if that's possible, either.
-- Joshua Tyler

'Document' object has no attribute 'layer'

I was messing around with the pressure variation in curves mode and this popped up.

Traceback (most recent call last):
  File "/home/albert/Developer/MyPaint/mypaint-mypaint/mypaint-build@master/share/mypaint/gui/linemode.py", line 704, redraw_line_cb(self=<gui.linemode.StraightMode object>)
            if last_line is not None:
                last_stroke = self.model.layer.get_last_stroke_info()
                if last_line[1] is last_stroke:
  variables: {'last_stroke': (None, [])}
AttributeError: 'Document' object has no attribute 'layer'

Build system: need a more useful message for when the brushlib submodule isn't present

The current error message that people who try to build MyPaint get when the brushlib submodule is missing isn't very helpful:

scons: warning: Ignoring missing SConscript 'brushlib/SConscript'
File "/[...]/src/mypaint/SConstruct", line 199, in <module>
swig -Wall -o mypaintlib_wrap.cpp -noproxydel -python -c++ mypaintlib.i
rm -f _mypaintlib.so
set umask to 0022 (was 0022)
scons: done reading SConscript files.
scons: Building targets ...
g++ -o lib/mypaintlib_wrap.os [...]
In file included from lib/mypaintlib.hpp:13:0,
                 from lib/mypaintlib_wrap.cpp:3071:
lib/mapping.hpp:20:21: fatal error: mapping.h: No such file or directory
 #include "mapping.h"
                     ^
compilation terminated.
scons: *** [lib/mypaintlib_wrap.os] Error 1
scons: building terminated because of errors.

Given that this is a build failure, it would be nice to halt the build and produce a more helpful message explaining about the situation ("have a look in the README" may be enough). We do something similar for missing numpy in the lib/ SCons-stuff.

library not found for -lgomp

Building the latest mypaint commit 92112f7 fails on OS X 10.9.4 with the clang compiler:

clang: warning: argument unused during compilation: '-fopenmp'

ld: library not found for -lgomp
clang: error: linker command failed with exit code 1 (use -v to see invocation)
scons: *** [_mypaintlib.so] Error 1

I understand that mypaint 1.1.0 has openmp support disabled by default but that the current code has it enabled by default.

My understanding is that the clang compiler still doesn't support openmp. I recommend you detect whether the compiler supports openmp and only enable it if it does.

I understand that your SConscript has a BoolVariable called enable_openmp to control whether openmp is enabled or not, but I don't know what I need to do when I invoke scons to affect the value of that variable or what I should set it to if I want to disable openmp.

Triage, then migrate bugs from Gna! to github

Beyond 1.2, we should be using github for bug tracking and as the main development location. We currently maintain a bug tracker on Gna!, but this is no longer a good fit for mypaint and libmypaint after the submodule split - and besides, our users are developing a bit of a loathing for the old Savane-based dinosaur, most apparent when an alternative is offered ☺

Tasks:

• decide and write up triage policy
• aggressively triage bugs on Gna - can be delegated once policy's written
• move bugs over, summaries and links at least
  • might be automatable, but manual may be better
• correct documentation, wiki, forum, and website links to the bug tracker
• announce formally
• close down Gna! for discussion and new bugs

Wheel axis support

Transferred here from Gna! bug 14694:

The current release does not support the wacom artpen rotation (have not tried the airbrush but I think that it uses the same value).
In xidump it is reported as "wheel".
I have searched the code for any use of AXIS_WHEEL but I have not found any so I'll report this to be valid for all versions and all platforms.
-- Emil Assarsson

Looking at this again, this seems to refer to the wheel input on devices like the Wacom airbrush (amazon via ddg). I have an (Intuos 5) artpen EDIT: grip pen myself, but while my tablet presents a wheel axis for the stylus device, the axis value is always the same.

Emil clarifies:

It should act as an input for the brush engine. It is an extra axis for the input device. It could be used to rotate the brush.
Please also note that the same axis is used for the top wheel on the airbrush tool.
-- Emil Assarsson

Maybe it's the Cintiq pen that supplies rotation information? (amazon via ddg). The Amazon blurb says something about rotation being a thing.

Merge Mask Layers

Currently, Merge Down is greyed out if the current layer has its mode set to Destination In or Destination Out. Users sometimes expect Merge Down on such a layer to perform the layer's masking effect onto the layer below: see random's post in the forums.

In terms of MyPaint's design, we take care to ensure that the effects of merge operations are always predictable, i.e. as exactly WYSIWYG as possible. Therefore I suspect the answer is "not always", because "mask" layers potentially mask all the layers underneath them, not just the one that Merge Down would merge them with. Consider that there may be more than one layer in the stack:

├ Group1 [mode=Normal ∴ isolated]
│ ├ Mask1 [mode=Destination In] ← current
│ ├ Painting1 [mode=Normal]
│ └ Painting2 [Mode=Normal]
└ Background

in which case a Merge Down of Mask1 onto Painting1 may reveal part of Painting2 which was previously masked. If Group1 were not isolated – if its mode was Pass-through – then the Background would also become visible where it was not previously.

That said, it's a user expectation to be able to make masks and use them as stencils for trimming. Is there a way users can (sometimes) be given what they expect?

Unit tests:test_performance.py: some tests are inconclusive

The GUI has changed quite a bit since tests/test_performance.py was written:

• failed logging setup clutter (needs a basicConfig() somewhere)
• motion events are now making it through; oops.
• no proper wait-for-fullscreen routine
• are the idle and gui waiting routines still effective in GTK3?

Some tests - specifically the scroll tests scroll_nozoom and scroll_zoomed_out_5x (thinking of issue #21) are inconclusive, returning in under 0.1s no matter what. Lots of scroll() updates seem to be skipped between draws, and that's probably GTK being efficient when it has lots of updates queued. Dropping lots of flush() calls on various things into the mix only gets you so far.

It may be better to replace these with something that exercises gui.tdw.TiledDrawWidget's "draw" handler thorughly.

warning: 'M_PI' macro redefined

Hello, while compiling the latest mypaint code (commit 92112f7) on OS X 10.9.4 the following warning appears:

brushlib/mypaint-brush.c:43:9: warning: 'M_PI' macro redefined
#define M_PI 3.14159265358979323846
        ^
/usr/include/math.h:683:9: note: previous definition is here
#define M_PI        3.14159265358979323846264338327950288   /* pi             */
        ^

Pick Context: for huge strokes, the "blink" overlay doesn't disappear till the next stroke is picked

Migrated here from Gna! bug 18780:

[...] if you make a huge stroke then attempt to pick it with Pick Context, the stroke blink state is entered and you see the stroke highlighted. However sometimes the blink state is never left. Not sure what's going on here, possibly a race condition: it seems to happen more frequently for really huge strokes. To reproduce (on my pretty fast desktop replacement laptop):

1. Pick a nice light colour and background so the blink is more visible.
2. Zoom all the way out. I'm working on master since 6d62404 was merged so this is one level further than 0.9.1, say.
3. Pick a simple, big brush to save time and make processing faster. I used experimental/pixelblocking. Make it huge too, set the radius to max.
4. Make the window big. Doesn't matter if fullscreened or not.
5. Paint a huge stroke across the canvas, then a smaller one. This can be done with either the mouse or a stylus, and can be a straight-line stroke too.
6. Pick the big one with "W", notice how stroke-blink is never left. You can even add and switch layers and it won't go away.
7. Pick the smaller one with "W", and notice how stroke-blink is left quickly.

Confirmed as still happening on the current git master, fc4fafa.

Brush editor exception "GError: Unknown internal child: plus_button" (GTK 3.8)

Isn't possible to use the brush editor on the my last git master.
Ubuntu gnome 13.10.

The GTK version is:

jag@ubuntugnome:~/installs/mypaint-git-master$ dpkg -l libgtk2.0-0 libgtk-3-0
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
ii  libgtk-3-0:amd 3.8.6-0ubunt amd64        GTK+ graphical user interface lib
ii  libgtk2.0-0:am 2.24.20-1ubu amd64        GTK+ graphical user interface lib
ii  libgtk2.0-0:i3 2.24.20-1ubu i386         GTK+ graphical user interface lib

The traceback via terminal is:

Traceback (most recent call last):
  File "/home/jag/installs/mypaint-git-master/gui/drawwindow.py", line 392, in toggle_window_cb
    window = self.app.get_subwindow(action_name)
  File "/home/jag/installs/mypaint-git-master/gui/application.py", line 710, in get_subwindow
    window = window_class()
  File "/home/jag/installs/mypaint-git-master/gui/brusheditor.py", line 74, in __init__
    self._build_ui()
  File "/home/jag/installs/mypaint-git-master/gui/brusheditor.py", line 136, in _build_ui
    self._builder.add_from_string(ui_xml)
  File "/usr/lib/python2.7/dist-packages/gi/overrides/Gtk.py", line 416, in add_from_string
    return Gtk.Builder.add_from_string(self, buffer, length)
GError: Unknown internal child: plus_button

Save in 16bit Color

Migrated from Gna! bug 21650:

MyPaint can load 16 bit per channel OpenRaster files, but can only save 8 bit per channel OpenRaster; inspecting files saved by MyPaint reveals 8-bit PNG inside.
Saving 16-bit files is required for 16-bit workflow across several applications, e.g. with addition of Krita or GIMP 2.10
-- Sergey Davidoff (shnatsel)

OSX build breakage: AttributeError: 'tuple' object has no attribute 'startswith':

I am the maintainer of MyPaint in MacPorts and I'm trying to build the (almost) latest code from this repository (commit e04de3f) without success:

--->  Building MyPaint
DEBUG: Executing org.macports.build (MyPaint)
DEBUG: Environment: 
CC='/usr/bin/clang -arch x86_64 -arch i386'
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_Users_rschmidt_macports_dports_graphics_MyPaint-devel/MyPaint/work/.CC_PRINT_OPTIONS'
CPATH='/opt/local/include'
CXX='/usr/bin/clang++ -arch x86_64 -arch i386'
LIBRARY_PATH='/opt/local/lib'
MACOSX_DEPLOYMENT_TARGET='10.9'
PKG_CONFIG_PATH='/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/pkgconfig'
DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/_Users_rschmidt_macports_dports_graphics_MyPaint-devel/MyPaint/work/mypaint-e04de3f223f21443c5c715b2f8c9c2c7cc657ffb" && /opt/local/bin/scons python_binary=/opt/local/bin/python2.7 python_config=/opt/local/bin/python2.7-config prefix=/opt/local/var/macports/build/_Users_rschmidt_macports_dports_graphics_MyPaint-devel/MyPaint/work/nonexistent'
DEBUG: Executing command line:  cd "/opt/local/var/macports/build/_Users_rschmidt_macports_dports_graphics_MyPaint-devel/MyPaint/work/mypaint-e04de3f223f21443c5c715b2f8c9c2c7cc657ffb" && /opt/local/bin/scons python_binary=/opt/local/bin/python2.7 python_config=/opt/local/bin/python2.7-config prefix=/opt/local/var/macports/build/_Users_rschmidt_macports_dports_graphics_MyPaint-devel/MyPaint/work/nonexistent 
scons: Reading SConscript files ...
building for '/opt/local/bin/python2.7' (use scons python_binary=xxx to change)
using '/opt/local/bin/python2.7-config' (use scons python_config=xxx to change)
rm -f libmypaint-tests.so libmypaint.so libmypaintlib.so
rm -f libmypaint.a libmypaint-tests.a
Enabling i18n for brushlib in full application build
swig -Wall -o mypaintlib_wrap.cpp -noproxydel -python -c++ mypaintlib.i
rm -f _mypaintlib.so
AttributeError: 'tuple' object has no attribute 'startswith':
  File "/opt/local/var/macports/build/_Users_rschmidt_macports_dports_graphics_MyPaint-devel/MyPaint/work/mypaint-e04de3f223f21443c5c715b2f8c9c2c7cc657ffb/SConstruct", line 204:
    application = SConscript('./SConscript')
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/scons-2.3.0/SCons/Script/SConscript.py", line 609:
    return method(*args, **kw)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/scons-2.3.0/SCons/Script/SConscript.py", line 546:
    return _SConscript(self.fs, *files, **subst_kw)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/scons-2.3.0/SCons/Script/SConscript.py", line 260:
    exec _file_ in call_stack[-1].globals
  File "/opt/local/var/macports/build/_Users_rschmidt_macports_dports_graphics_MyPaint-devel/MyPaint/work/mypaint-e04de3f223f21443c5c715b2f8c9c2c7cc657ffb/SConscript", line 26:
    mypaintlib = SConscript('lib/SConscript')
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/scons-2.3.0/SCons/Script/SConscript.py", line 609:
    return method(*args, **kw)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/scons-2.3.0/SCons/Script/SConscript.py", line 546:
    return _SConscript(self.fs, *files, **subst_kw)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/scons-2.3.0/SCons/Script/SConscript.py", line 260:
    exec _file_ in call_stack[-1].globals
  File "/opt/local/var/macports/build/_Users_rschmidt_macports_dports_graphics_MyPaint-devel/MyPaint/work/mypaint-e04de3f223f21443c5c715b2f8c9c2c7cc657ffb/lib/SConscript", line 108:
    if flag in non_python_optimization_flags or not flag.startswith('-O')

1.2 release: decide GTK3 version range to support, & document

We need to decide which versions of GTK should be supported for the upcoming release. I've been testing in 3.10 recently, and now 3.12 on Debian testing/unstable.

Ramon Miranda reports successes with the layers panel (notably new and potentially fragile) under Linux Mint Petra's GTK 3.8.7, but crashes when the brush editor tries to start up:

[during BrushEditorWindow's "self._builder.add_from_string(ui_xml)" call]
[... Builder XML in dump omitted...]
GError: Unknown internal child: plus_button
-- http://www.pasteall.org/52412

to give us an idea of the sorts of fun things we can expect.

Flagging as "docs+artwork" because our choice will need documenting.

Scratchpad→New command turns off the main document's frame

To reproduce:

• Make sure the frame is enabled
• Issue Scratchpad→New
  • this disables the frame; it should not

It's not the least of the WTFery surrounding the scratchpad, however.

Navigation issue with Ctrl+Space(zoom) and Shift+Space(rotate)

Hi,

Problem:
Over the canvas, if you hold together Ctrl+Space or Shift+Space you probably notice the action doesn't Zoom or Rotate the canvas anymore. ( doesn't affect Shift+MiddleMouse button, and Ctrl+MiddleMouse button , they both still work ).

Expected result:
Ctrl+Space --> Zoom to cursor
Shift+Space --> Rotate canvas

Reproductible: always.

Workspace tab options and close buttons: should use symbolic icons

The icons for close-tab and tab-options buttons sometimes lose their lustre with dark theme variants, and become difficult to make out:

These should be converted to symbolic SVG icons for consistency with the rest of the UI. Note that we need to be sure that the icon displayed when a tab has no options looks greyed out in some way.

Pick layer and brush (W key) occasionally doesn't work

At first I thought there was a bug where the W key wouldn't get the correct colour seemingly randomly, but while I was trying to reliably replicate it, I stumbled across a lot more bugs with the W key:

From what I can tell, there seems to be two points of failure. The first is where a stroke is drawn, as sometimes it doesn't save the data needed to recreate layer and brush information. Here's a link to an .ora where this happens.

The circled strokes won't work when you press W on them, while the rest of them will (except for a few of the annotation strokes, ironically).

The second point of failure is when it's trying to get the stroke information, as it seems the W key randomly fails around 0.5% of the time. Trying again will usually work. This doesn't seem to be caused by anything in particular.

Broken lines with devices that use the evdev driver (UC-Logic-based, Monoprice, Genius... and Wacom!)

(Migration of gna bug 20883)

MyPaint is currently unusable when using the evdev xorg driver due to the strokes breaking up frequently. Known to affect multiple UC-Logic devices from multiple vendors, including Monoprice, Huion, and whatever device this forum user was using. (Probably a Genius-branded one, according to digimend.) May affect other evdev-using devices, but uc-logic devices are more common than others.

Non-wacom devices are becoming more prevalent, especially with the recent proliferation of affordable Cintiq alternatives, and everyone but wacom seems to be standardised on using evdev, so this is a fairly nasty issue. Gtk2 apps such as Gimp, Inkscape, and older builds of MyPaint work with the evdev driver. Krita 2.8 and newer works as well.

Some devices can use the xorg wacom driver as a workaround, but this isn't a proper fix. Doing so means access to some xinput settings are lost, such as calibration ("evdev axis calibration"), which is useful for tablet display devices such as the ones by Monoprice and Huion.

The poster of the original port provided a couple sample videos and log information:

Video of the behaviour in MyPaint: https://www.youtube.com/watch?v=MnNbCo2dWlk
Video of testinput + console output: https://www.youtube.com/watch?v=L_Iqs-bGWaI
Log of "xinput test" and screenshot of image made during test: log, image

My device (Monoprice 19" pen display) has the same input problem and "xinput test" produces the same gaps, though in my case the gaps are more frequent and more pronounced.

He also opened a bug report against gtk3 to get help, but nothing was resolved there. Someone indicated that a difference in evdev and wacom driver's behaviour regarding coordinate reporting may be at fault, but that the behaviour difference itself isn't a bug. ref.: https://bugzilla.gnome.org/show_bug.cgi?id=703610

Affects all version of gtk3 + git-mypaint tested so far. He tested gtk 3.6.2, 3.6.4, 3.8.2; I tested 3.10.7, 3.12.0, 3.12.2.

Store mask layers as single channel.

Masks are stored very inefficiently: they're RGBA internally, but only their alpha matters. Let's investigate reducing their impact:

• Represent as a distinct layer class internally.
  • only permit Destination-In and Destination-Out modes
• May need a special surface type too.
• They need to still be visibly paintable, but in white (or black) (or a user-chosen colour) only
• Save as 8bpp indexed PNGs, all 256 colours in the palette white but with 256 varying alphas
  • seems to be the most efficient allowable format
  • are 256 colours alpha levels going to be enough for 16bpp images? (#4)
• How to detect mask layers when loading? Name magic or look at the PNG?

Post 1.2 investigation, definitely.

Write from-source OSX build and install docs

(Fallout from #47, which was in the end more of a request for support)

OSX needs good instructions in the form of a README of some sort in the main repository. It should ideally tell very new starters wishing to test directly from git and get involved in the project how to pull, build from source, and test MyPaint by running it on the command line from within the tree. Optionally instructions on how to install it, or make installer images would be very useful to have too.

I'm not an OSX user and can barely get off the ground with this stuff as a result, so I'm going to have to leave this to someone else.

Outdated bugtracker link on development page of web site

On the development page of your web site the "Bugtracker" section reads:

Please use the new Github Bugtracker to make sure your bug does not get forgotten.

However, the "Bugtracker" header image still links to the old bugtracker at GNA. In the "Submitting Patches" section there's also a "bugtracker" link which you may want to change to the new issue tracker here on github.

[Feature Request] - Support embedded image profiles

Migrated from Gna bug 19537. Long story short, MyPaint should write colour profiles other than an assumed sRGB via embedded ICC profles when saving PNG or JPEG data, or PNG data inside OpenRaster containers.

Still need to determine quite what that means: there are related bugs about gleaning the display colour space via XICC that need migrating here and addressing at roughly the same time as this. There may also be a need for hardware availability to test this.

Colord, display colour profiles

Migrated from Gna bug 20131. Short form: we need support in MyPaint for reading the display colour profile if we're to progress #5 and probably #4 too. I note that there are nice gobjectish wrappers available for colord's stuff now, though I've not played with them.

Current status: MyPaint currently converts everything to an internal sRGB working profile when loading using the embedded profile if it exists, and writes PNGs with explicit sRGB chunks.

Ideal state (I think): MyPaint should convert to the display space, perform linear compositing when working with layers, and should embed the display colour space when saving data.

Color picker icon doesn't appear when holding Ctrl key

Hi,

Problem:
If you hold Ctrl on keyboard over the canvas , it's currently hard to see your tool changed for a color-picker. Only the caption on the footer-bar change. You need to click on canvas to make the color preview and color-picker icon appearing.

Expected behavior:
As soon as Ctrl is pressed, the brush outliner change to a color-picker.

Reproducible: always

Make Symmetry toolbar icon an editing mode for the symmetry centre

Migrated here from Gna! bug 19645
Paraphrasing the original report, the "butterfly" symmetry icon should enter a mode/tool for setting the symmetry axis, rather like we do with the "picture frame" icon and the frame editing tool.

A lot of the legwork has already been done here, in the frame edit tool, so hopefully implementing this should be easy. Tentatively assigning this one to 1.2.

Make "Normal" mode the default for groups, not "Pass-through"

As mentioned in #1, pass-through mode can be confusing when masks are involved. "Backdrop" can be a difficult abstract concept even if users work very fluently with layers on a practical basis, and it's made more difficult by pass-through mode changing the definition of what the backdrop is!

"Pass-through" is a bad default for new groups. It's

• more limiting to the user because its opacity cannot be changed.
• not called "Normal", which users might justifiably expect! ☺
• not like what GIMP and Krita do

The initial mode of a new group should be changed to "Normal". This doesn't affect loading and saving OpenRaster, because those are always inferred directly from the XML, or saved explicitly into the XML with the special logic we need for distinguishing Pass-through from other flavours of svg:src-over ("Normal") in that format.

Tiny papercut that we need to get right for 1.2.

[Feature Request] - Line Pressure Presets

Migrated here from Gna! bug 19906, a wish for 'Line Pressure Preset' to ease setting of the auto-pressure applied when drawing lines, curves, polygons, ellipses and circles.

On my previous proposition mockup, I was still assuming the final user knew how to use a graph/curve to set pressure but then 2 year has passed and I realised "our userbase consists mostly of artists, not sandal-wearing UNIX mystics" .

So, here is an updated mockup where the 'graph/curve' could be fold/unfold for custom fine tuning, and line pressure presets show large thumbnails/buttons with a limited set of 4 presets:

Eraser mode's radius changing is incredibly counter-intuitive.

From gui/brushmodifier.py:

This manages the size difference between the eraser-mode version of a normal brush and its normal state. Initially the eraser-mode version is three steps bigger, but that's configurable by the user through simply changing the brush radius as normal while in eraser mode.

The process of the eraser's radius changing also being affected by your changes is EXTREMELY obtuse and user-hostile. There are many situations where you'd want to go into eraser mode and then change the brush size, and with this system, any changes you make while in that mode remain the next time you go into it.

The amount by which the brush size changes when going in/out of eraser mode (document.eraser_mode_radius_change) should be configurable only in the user preferences.

I have personally opted to just ripping out the code that changes the brush size in the first place, as I have no use for it, but a proper setting for it would be a lot more convenient.

Error opening .ora file

I am using MyPaint 1.0.0 for Windows 64bit on a Windows 7 64bit pc.

Everythinks worked fine since weeks. Than today suddenly I can't open the .ora file I am working on.

I am getting following error message:

Traceback (most recent call last):
File "C:\Program Files\MyPaint\library.zip\gui\filehandling.py", line 388, open_cb(self=<gui.filehandling.FileHandler object>, action=<gtk.Action object at 0x37d33a8 (GtkAction at 0x58ee5a0)>)
dialog.hide()
self.open_file(dialog.get_filename().decode('utf-8'))
finally:
File "C:\Program Files\MyPaint\library.zip\gui\drawwindow.py", line 46, wrapper(self=<gui.filehandling.FileHandler object>, _args=(u'D:\Eigene Bilder\Kunst\Digital Art 2014\haesslich.ora',), *_kwargs={})
try:
func(self, _args, *_kwargs)
# gtk main loop may be called in here...
File "C:\Program Files\MyPaint\library.zip\gui\filehandling.py", line 249, open_file(self=<gui.filehandling.FileHandler object>, filename=u'D:\Eigene Bilder\Kunst\Digital Art 2014\haesslich.ora')
try:
self.doc.model.load(filename, feedback_cb=self.gtk_main_tick)
except document.SaveLoadError, e:
File "C:\Program Files\MyPaint\library.zip\lib\document.py", line 389, load(self=<lib.document.Document instance>, filename=u'D:\Eigene Bilder\Kunst\Digital Art 2014\haesslich.ora', *_kwargs={'feedback_cb': })
try:
load(filename, *_kwargs)
except gobject.GError, e:
File "C:\Program Files\MyPaint\library.zip\lib\document.py", line 590, load_ora(self=<lib.document.Document instance>, filename=u'D:\Eigene Bilder\Kunst\Digital Art 2014\haesslich.ora', feedback_cb=)
tempdir = tempfile.mkdtemp(u'mypaint')
z = zipfile.ZipFile(filename)
print 'mimetype:', z.read('mimetype').strip()
File "zipfile.pyo", line 696, init(self=<zipfile.ZipFile instance>, file=u'D:\Eigene Bilder\Kunst\Digital Art 2014\haesslich.ora', mode='r', compression=0, allowZip64=False)

File "zipfile.pyo", line 716, _GetContents(self=<zipfile.ZipFile instance>)

File "zipfile.pyo", line 728, _RealGetContents(self=<zipfile.ZipFile instance>)

BadZipfile: File is not a zip file