[Mypaint-discuss] Fwd: [CREATE] A big LGM 2015 announcement
The program for Libre Graphics Meeting 2015, in Toronto, Canada is now out. I'll be there this year, though not talking about MyPaint, but imgflo and related work. http://www.imgflo.org/ Anyone else from the MyPaint community going? -- Forwarded message -- From: ginger coons gin...@adaptstudio.ca Date: 16 March 2015 at 22:50 Subject: [CREATE] A big LGM 2015 announcement To: CREATE cre...@lists.freedesktop.org Announcing Libre Graphics Meeting 2015 April 29th - May 2nd, University of Toronto, Canada For its 10th edition, Libre Graphics Meeting is looking back at the achievements of Free/Libre and Open Source software for artists and designers. We're also looking forward, at the developments coming in the next decade. Since its first edition, held in Lyon, France, in 2006, Libre Graphics Meeting has been bringing together software developers, artists, designers, users and other contributors to Free/Libre and Open Source graphics software. For its tenth edition, Libre Graphics Meeting heads to Toronto for four days of talks, workshops, hack sessions and meetings. Developers and prominent users of software projects like Inkscape, Gimp, Scribus, Fontforge, My Paint, Blender, and Krita—among many others— come together to show off their projects and discuss them with the larger Libre Graphics community. Not only is Libre Graphics Meeting an exciting and motivating moment for developers and users of all kinds, from typographers to illustrators, designers and video artists, it's is also a unique moment for users and developers of free software to collide and share ideas beyond the confined space of mailing-lists, bug trackers or forums. 2015 is going to be an exciting year for LGM. The program, available online now (http://libregraphicsmeeting.org/2015/program/), is packed full of talks and workshops, from new methods of type design to animation, as well as plenty of time built in for informal collaboration and discussion. As well as the four scheduled days, LGM 2015 will also feature pre-event work sessions and hackathons, including the Inkscape Hackfest, which will allow developers of the popular vector graphics software to get together and do concentrated work. LGM is open to the public, and registration is free (visit to http://libregraphicsmeeting.org/2015/register/ to register). Even if you don't plan to attend LGM, you can always help us fund the costs of bringing contributors to this invaluable meeting. Our annual fundraising campaign ( https://pledgie.com/campaigns/28155) helps support the travel costs of contributors travelling to attend LGM. If you're a user or just a fan of Free and Open Source Software, please consider donating as a way to say Thank You! to the developers of these projects. All contributions will be used to reimburse those who travel to Toronto to make our software better. The tenth edition of Libre Graphics Meeting will offer a unique look at the achievements of the last ten years of the Libre Graphics world, and opens the door for more great things in the years to come. So if you are an artist or developer interested in Free and Open Source tools, don't miss a chance to participate in this unique and itinirary event held this year in the beautiful city of Toronto. You will learn how those tools are reshaping the way artist work and have the opportunity to share your ideas with some of the most interseting people of this community. About Libre Graphics Meeting Libre Graphics Meeting (LGM) is the annual gathering of users and developpers of Free and Open Source software for graphics, design, and visual art. This unique event brings together different groups, usually gathering around specific projects, online, via their mailing-lists or forums. LGM has grown over the years to become an essential moment in the lives of these diverse but interconnected communities. The discussions, presentations and feedback available at LGM have had a positive impact on the developpment of both the tools and their respective communities. The event gives developers, contributors and users a chance to get together, get things done, and come up with new ways forward. http://libregraphicsmeeting.org -- ginger all-lower-case coons adaptstudio.ca Phone: 647.865.7757 Skype: gingercoons XMPP: gin...@adaptstudio.ca ___ CREATE mailing list cre...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] MyPaint Jenkins instance shut down
Hi, just as a heads up. I've stopped the Jenkins instance[1] that used to be running at http://ci.mypaint.org/jenkins It was not very well maintained, and to my knowledge not much used either. We still have CI on Travis, which is a superior service from both usefulness and price perspective (free!): https://travis-ci.org/mypaint/mypaint Regards, Jon 1. https://mail.gna.org/public/mypaint-discuss/2012-12/msg00024.html -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Issue#48 - Write from-source Windows build and install docs
It sounds like it was not extracted into the right directory. What is the
contents of the brushlib directory?
On 9 September 2014 15:17, Victor Westmann victor.westm...@gmail.com
wrote:
Jon,
hi. I downloaded the zip package of libmypaint under mypaint folder
and then, after extract it, ran again the scons command.
I got the following error:
scons: warning: EnsureSConsVersion is ignored for development version
File C:\Users\Victor Westmann\Desktop\mypaint-master\SConstruct, line 6,
in m
odule
building for 'python' (use scons python_binary=xxx to change)
using 'python-config' (use scons python_config=xxx to change)
Delete([libmypaint-tests.so, libmypaint-tests.so, libmypaint.so,
libmypai
ntlib.so, libmypaint.a, libmypaint-tests.a, lib/_mypaintlib.so])
Enabling i18n for brushlib in full application build
scons: warning: Ignoring missing SConscript 'brushlib\SConscript'
File C:\Users\Victor Westmann\Desktop\mypaint-master\SConstruct, line
214, in
module
ImportError: cannot import name check_output:
File C:\Users\Victor Westmann\Desktop\mypaint-master\SConstruct, line
218:
SConscript('./SConscript')
File
C:\Python26\Lib\site-packages\scons-2.3.3\SCons\Script\SConscript.py, l
ine 613:
return method(*args, **kw)
File
C:\Python26\Lib\site-packages\scons-2.3.3\SCons\Script\SConscript.py, l
ine 550:
return _SConscript(self.fs, *files, **subst_kw)
File
C:\Python26\Lib\site-packages\scons-2.3.3\SCons\Script\SConscript.py, l
ine 260:
exec _file_ in call_stack[-1].globals
File C:\Users\Victor Westmann\Desktop\mypaint-master\SConscript, line
4:
from subprocess import check_output
:(
--Victor Westmann
2014-09-08 21:57 GMT-03:00 Jon Nordby jono...@gmail.com:
Ok. You can also download libmypaint repository as a .zip and unpack it
info the brushlib directory.
On Sep 9, 2014 2:31 AM, Victor Westmann victor.westm...@gmail.com
wrote:
Jon,
I didn't. I just downloaded the whole MyPaint project as a ZIP package.
I'll do it and let you guys know how did it go.
Thanks!
--Victor Westmann
2014-09-08 21:27 GMT-03:00 Jon Nordby jono...@gmail.com:
scons: warning: Ignoring missing SConscript 'brushlib\SConscript'
Did you run git submodule update --init to bring in the brushlib?
On 9 September 2014 00:24, Victor Westmann victor.westm...@gmail.com
wrote:
Hi folks,
I really tried to help in this matter but I could not progress much. I
stumbled upon this error here on Windows 32.
scons: Reading SConscript files ...
scons: warning: EnsureSConsVersion is ignored for development version
File C:\Users\Victor Westmann\Desktop\mypaint-master\SConstruct,
line 6, in module
building for 'python' (use scons python_binary=xxx to change)
using 'python-config' (use scons python_config=xxx to change)
Delete([libmypaint-tests.so, libmypaint-tests.so, libmypaint.so,
libmypaintlib.so, libmypaint.a, libmypaint-tests.a,
lib/_mypaintlib.so])
Enabling i18n for brushlib in full application build
scons: warning: Ignoring missing SConscript 'brushlib\SConscript'
File C:\Users\Victor Westmann\Desktop\mypaint-master\SConstruct,
line 214, in
module
ImportError: cannot import name check_output:
File C:\Users\Victor Westmann\Desktop\mypaint-master\SConstruct,
line 218:
SConscript('./SConscript')
File
C:\Python26\Lib\site-packages\scons-2.3.3\SCons\Script\SConscript.py, l
ine 613:
return method(*args, **kw)
File
C:\Python26\Lib\site-packages\scons-2.3.3\SCons\Script\SConscript.py, l
ine 550:
return _SConscript(self.fs, *files, **subst_kw)
File
C:\Python26\Lib\site-packages\scons-2.3.3\SCons\Script\SConscript.py, l
ine 260:
exec _file_ in call_stack[-1].globals
File C:\Users\Victor Westmann\Desktop\mypaint-master\SConscript,
line 4:
from subprocess import check_output
What should I do next? I'm not very skilled in this process but once I
get pass this I'd be able to beautifully document all the steps I did so
we
can put it on the project wiki pages. :)
Cheers.
--Victor Westmann
___
Mypaint-discuss mailing list
Mypaint-discuss@gna.org
https://mail.gna.org/listinfo/mypaint-discuss
--
Jon Nordby - www.jonnor.com
--
Jon Nordby - www.jonnor.com
___
Mypaint-discuss mailing list
Mypaint-discuss@gna.org
https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Issue#48 - Write from-source Windows build and install docs
Ok. You can also download libmypaint repository as a .zip and unpack it
info the brushlib directory.
On Sep 9, 2014 2:31 AM, Victor Westmann victor.westm...@gmail.com wrote:
Jon,
I didn't. I just downloaded the whole MyPaint project as a ZIP package.
I'll do it and let you guys know how did it go.
Thanks!
--Victor Westmann
2014-09-08 21:27 GMT-03:00 Jon Nordby jono...@gmail.com:
scons: warning: Ignoring missing SConscript 'brushlib\SConscript'
Did you run git submodule update --init to bring in the brushlib?
On 9 September 2014 00:24, Victor Westmann victor.westm...@gmail.com
wrote:
Hi folks,
I really tried to help in this matter but I could not progress much. I
stumbled upon this error here on Windows 32.
scons: Reading SConscript files ...
scons: warning: EnsureSConsVersion is ignored for development version
File C:\Users\Victor Westmann\Desktop\mypaint-master\SConstruct, line
6, in module
building for 'python' (use scons python_binary=xxx to change)
using 'python-config' (use scons python_config=xxx to change)
Delete([libmypaint-tests.so, libmypaint-tests.so, libmypaint.so,
libmypaintlib.so, libmypaint.a, libmypaint-tests.a,
lib/_mypaintlib.so])
Enabling i18n for brushlib in full application build
scons: warning: Ignoring missing SConscript 'brushlib\SConscript'
File C:\Users\Victor Westmann\Desktop\mypaint-master\SConstruct, line
214, in
module
ImportError: cannot import name check_output:
File C:\Users\Victor Westmann\Desktop\mypaint-master\SConstruct,
line 218:
SConscript('./SConscript')
File
C:\Python26\Lib\site-packages\scons-2.3.3\SCons\Script\SConscript.py, l
ine 613:
return method(*args, **kw)
File
C:\Python26\Lib\site-packages\scons-2.3.3\SCons\Script\SConscript.py, l
ine 550:
return _SConscript(self.fs, *files, **subst_kw)
File
C:\Python26\Lib\site-packages\scons-2.3.3\SCons\Script\SConscript.py, l
ine 260:
exec _file_ in call_stack[-1].globals
File C:\Users\Victor Westmann\Desktop\mypaint-master\SConscript,
line 4:
from subprocess import check_output
What should I do next? I'm not very skilled in this process but once I
get pass this I'd be able to beautifully document all the steps I did so we
can put it on the project wiki pages. :)
Cheers.
--Victor Westmann
___
Mypaint-discuss mailing list
Mypaint-discuss@gna.org
https://mail.gna.org/listinfo/mypaint-discuss
--
Jon Nordby - www.jonnor.com
___
Mypaint-discuss mailing list
Mypaint-discuss@gna.org
https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Build test No package 'json' found/mypaint: No such file or directory
Are you sure you installed all the dependencies?
In particular, package libjson0-dev or the equivalent on your distro?
On 17 July 2014 08:30, thadeusz l thadeusz...@gmail.com wrote:
Hi there,
I just followed this instruction
https://github.com/mypaint/mypaint#build--install-linux
on how to clone and run the MyPaint project. It works until I got to the
point Build test:. These are the results after I typed in the commands:
pad@ubuntu:~/mypaint$ scons
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
Could not find 'json-c' pkg-config, trying legacy 'json' instead
Package json was not found in the pkg-config search path.
Perhaps you should add the directory containing `json.pc'
to the PKG_CONFIG_PATH environment variable
No package 'json' found
OSError: 'pkg-config --cflags --libs json' exited 1:
File /home/pad/mypaint/SConstruct, line 203:
brushlib = SConscript('./brushlib/SConscript')
File /usr/lib/scons/SCons/Script/SConscript.py, line 614:
return method(*args, **kw)
File /usr/lib/scons/SCons/Script/SConscript.py, line 551:
return _SConscript(self.fs, *files, **subst_kw)
File /usr/lib/scons/SCons/Script/SConscript.py, line 260:
exec _file_ in call_stack[-1].globals
File /home/pad/mypaint/brushlib/SConscript, line 128:
env.ParseConfig('pkg-config --cflags --libs %s' % ' '.join(pkg_deps))
File /usr/lib/scons/SCons/Environment.py, line 1551:
return function(self, self.backtick(command))
File /usr/lib/scons/SCons/Environment.py, line 593:
raise OSError('%s' exited %d % (command, status))
pad@ubuntu:~/mypaint$ ./mypaint -c /tmp/mypaint_cfgtmp_$$
bash: ./mypaint: No such file or directory
---
Does anyone know how to solve this? Thanks in advance.
___
Mypaint-discuss mailing list
Mypaint-discuss@gna.org
https://mail.gna.org/listinfo/mypaint-discuss
--
Jon Nordby - www.jonnor.com
___
Mypaint-discuss mailing list
Mypaint-discuss@gna.org
https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] A few fixes to improve third-party integration of libmypaint
Hi Jehan,
I responded on the pull request.
https://github.com/mypaint/libmypaint/pull/3
On 13 July 2014 15:13, Jehan Pagès jehan.marmott...@gmail.com wrote:
Hi,
I'm a GIMP dev. We may have met in LGM. Anyway I submitted a pull
request on your github instance.
1/ The first commit is a one-liner bug (but still important because it
was breaking compilation of GIMP on linking). I guess there is not
much to discuss about it.
2/ The second commit (I wish github allowed me to make a separate pull
request for it, but apparently it won't) is a request for change.
Right now your CFLAGS is Cflags: -I${includedir}/lib@LIBNAME@
It makes that we have to #include mypaint-brush.h. I believe this
would be cleaner to #include libmypaint/mypaint-brush.h (which may
work by chance if you installed libmypaint in the same prefix as
other libs, but is not guaranteed). This way, we immediately see in a
glimpse where an include comes from. Of course, you could say there is
the mypaint- in the start of the file name, but then what about:
#include glib/mypaint-brush.h
Looks like a glib include!
On the other hand, #include libmypaint/glib/mypaint-brush.h would be
nicer in my opinion.
Of course, that's a matter of choice and preference, not a bug. So
that's up to you to decide whether you agree to this change. And we'll
update GIMP accordingly.
The first commit though, that would be nice if you could merge it. :-)
Thanks!
Jehan
___
Mypaint-discuss mailing list
Mypaint-discuss@gna.org
https://mail.gna.org/listinfo/mypaint-discuss
--
Jon Nordby - www.jonnor.com
___
Mypaint-discuss mailing list
Mypaint-discuss@gna.org
https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Compiling libmypaint/brushlib as a dynamically linked library
How are you trying to build, and how does it not work? You should be building directly in libmypaint repo (same as brushlib dir in MyPaint), and brushlib_only=true is no longer neccesary. I note that the README is a bit outdated on this point though... On 1 July 2014 17:38, Chloride Cull chlor...@devurandom.net wrote: Doesn't create a shared library for me (except for the swig python library, as brushlib_only=true doesn't seem to work). On 2014-07-01 00:38, Jon Nordby wrote: scons use_sharedlib=true ? On 30 June 2014 23:18, Chloride Cull chlor...@devurandom.net wrote: By default, compiling libmypaint creates an .a file for static compilation (AFAIK). Is it possible to directly compile as a .so file, so I can integrate it with a C# application, or do I need to build a shim in C? ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Compiling libmypaint/brushlib as a dynamically linked library
scons use_sharedlib=true ? On 30 June 2014 23:18, Chloride Cull chlor...@devurandom.net wrote: By default, compiling libmypaint creates an .a file for static compilation (AFAIK). Is it possible to directly compile as a .so file, so I can integrate it with a C# application, or do I need to build a shim in C? ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] MyPaint brushlib (libmypaint) moved to separate repository
On 9 April 2014 02:46, Albert Westra odysseywes...@gmail.com wrote: Sorry, I'm referring to the quick setup script on the wiki which allows other users to test out the git version. However every time I run it, I'm getting an error about it missing libraries. As mentioned, you need to run git submodule update --init after you do git pull/rebase/merge. If you get an error about public key when you do this, see https://mail.gna.org/public/mypaint-discuss/2014-04/msg6.html #!/bin/bash # Installs MyPaint's dependencies. echo Enter password to install dependencies... if [ -f /etc/debian_version ]; then sudo apt-get update sudo apt-get install git scons python-numpy swig libglib2.0-dev python-dev python-gtk2-dev python-cairo-dev libpng12-dev g++ gettext liblcms2-dev libjson0-dev else sudo yum install git scons numpy swig glib2-devel python-devel pycairo-devel libpng-devel gcc-c++ gettext liblcms2-devel libjson0-devel fi # Makes two folders, one to store GIT clones, and one in which MyPaint will be installed. mkdir ~/mypaintdev git clone git://gitorious.org/mypaint/mypaint.git ~/mypaint-src cd ~/mypaint-src scons prefix=~/mypaintdev/ install These two lines should not be neccesary. If they are let me know so we can just fix it. ln -s ~/mypaintdev/lib/libmypaint-brushlib.so ~/mypaintdev/lib/mypaint/libmypaint-brushlib.so # see next comment scons prefix=~/mypaintdev/ install # not ideal, but making a symlink for a 'missing' lib, then running scons again # Just lets you know that you've installed MyPaint into this folder. echo MyPaint is now installed in the mypaintdev folder in your home directory. # wait three seconds so the user can see the above message sleep 3 # Launches the MyPaint installation. ~/mypaintdev/bin/mypaint In file included from lib/mypaintlib.hpp:13:0, from lib/mypaintlib_wrap.cpp:3086: 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. So how would I modify the script so it can build the the mypaintlib into MyPaint itself? On Tue, Apr 8, 2014 at 5:34 PM, Jon Nordby jono...@gmail.com wrote: On 9 April 2014 01:10, Albert Westra odysseywes...@gmail.com wrote: So how will this effect the build script provided on the wiki? I tried to build the master, only to get an error. Which build script and what error? I've updated the README with the additional command that needs to be ran, git submodule update --init -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] MyPaint brushlib (libmypaint) moved to separate repository
Hi all, as of yesterday the MyPaint brushlib lives in its own repository: https://gitorious.org/mypaint/libmypaint/ The repository has all the history from the brushlib directory in MyPaint repository. MyPaint then uses this repository as a git submodule, at the same location as before. Until we have this library released and packaged in distributions - that is the recommended method of using the library in other applications. There is currently a very basic build based on scons set up, see the SConstruct file for available options. Install of the library files is right now missing. We also need to decide if the MyPaint brushes should also be distributed by the library. It is possible to just include libmypaint.c into ones own application build instead of linking. For quick experiments this may be the easiest way right now. The minimal example is right now broken, but the GEGL backend has been tested using Gobject introspection from Python (examples/gegl.py). Documentation is still TODO. Just ask for any questions :) -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Last git master - scons error
Hi Jose, that was due to a bug of mine, sorry. The public key is not supposed to be required. Fixed now in master, but you will probably need a quick mod to fix the error locally. See commit message below for how: commit 44551e6cd1dc0322194f4a36825b4e7704595902 Author: Jon Nordby jono...@gmail.com Date: Mon Apr 7 00:56:59 2014 +0200 Use relative path for brushlib git submodule This way the same protocol (git/https/ssh) is used for submodule as the top-level repo, avoiding problems with fetching if you don't have a ssh account on gitorious. If you fetched before, you may need to delete the two lines in .git/config which says: [submodule brushlib] url = g...@gitorious.org:mypaint/libmypaint.git before re-running git submodule update --init On 7 April 2014 00:07, José Américo Gobbo jag.rabi...@gmail.com wrote: well, I'm a common user with some skills but for me is a bit complex the new approach to create the git master on my box... ;-) Now with git submodule update --init is need the public key... in past I've tried to implement this but for me is a bit confuse these tasks, sorry. Normally I've used the git clone in a old style without problems... Now I'm not capable to resolve this step: jag@ubuntugnome:~/installs/mypaint-git-master-new$ git submodule update --initCloning into 'brushlib'... The authenticity of host 'gitorious.org (87.238.52.168)' can't be established. RSA key fingerprint is 7e:af:8d:ec:f0:39:5e:ba:52:16:ce:19:fa:d4:b8:7d. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'gitorious.org,87.238.52.168' (RSA) to the list of known hosts. Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Clone of 'g...@gitorious.org:mypaint/libmypaint.git' into submodule path 'brushlib' failed ... J. Americo Gobbo [Painter and Illustrator] Website | Blog | Flickr | Twitter | Facebook On Sun, Apr 6, 2014 at 6:35 PM, Jon Nordby jono...@gmail.com wrote: Hi Jose, did you do git submodule update --init? This is required as of the latest couple of commits which moved the brushlib into its own subdirectory. Let us know if this fixes the issue or not! On 6 April 2014 22:25, José Américo Gobbo jag.rabi...@gmail.com wrote: Hi all, I've update my git master clone via git pull --rebase and I had this error during scons process: jag@ubuntugnome:~/installs/mypaint-git-master$ scons 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 Enabling i18n for brushlib in full application build scons: warning: Ignoring missing SConscript 'brushlib/SConscript' File /home/jag/installs/mypaint-git-master/SConstruct, line 201, 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 -c -Wall -Wno-sign-compare -Wno-write-strings -fopenmp -O3 -pthread -fno-strict-aliasing -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -g -fwrapv -O2 -Wall -Wstrict-prototypes -Xlinker -export-dynamic -fPIC -DHAVE_GTK3 -D_FORTIFY_SOURCE=2 -Ibrushlib -Ibrushlib/tests -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/libpng12 -I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/pygobject-3.0 -I/usr/lib/python2.7/dist-packages/numpy/core/include -I/usr/include/python2.7 -I/usr/include/x86_64-linux-gnu/python2.7 lib/mypaintlib_wrap.cpp cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++ [enabled by default] In file included from lib/mypaintlib.hpp:13:0, from lib/mypaintlib_wrap.cpp:3086: 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. ... J. Americo Gobbo [Painter and Illustrator] Website | Blog | Flickr | Twitter | Facebook ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss -- Jon Nordby - www.jonnor.com -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo
[Mypaint-discuss] LGM2014 in Leipzig, 2-5 April
Hi everyone, who plans to come to LGM this year? achadwick and Animtim have already confirmed via IRC, and I will be there as well. Anyone else? http://libregraphicsmeeting.org/2014 -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] [PATCH] Improve GEGL example
Hi Manuel, thanks for the patch! Pushed with a tiny modification: def configure_handler(self, widget, event): -self.crop.set_property(x, event.x) -self.crop.set_property(y, event.y) Without it the background was offset by the position of the screen position of the application window. Note that here I am still seeing some missing updates to brush strokes sometimes (line becomes discontinious for a small segment). It was there before also, and I don't know if the issue is in GEGL, GEGL-GTK or libmypaint. It becomes correct if something causes a redraw of the widget/area, which makes me think it is not libmypaint. On 14 January 2014 20:57, Manuel Quiñones ma...@laptop.org wrote: Hi Jon, I managed to remove the glitch while drawing. Patch attached. Cheers, -- .. manuq .. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] Fwd: [CREATE] Only 3 days left to submit your proposal for LGM!
Don't forget, we want you at Libre Graphics Meeting in Leipzig in April! -- Forwarded message -- From: Femke Snelting snelt...@collectifs.net Date: 12 January 2014 20:53 Subject: [CREATE] Only 3 days left to submit your proposal for LGM! To: Create ML cre...@lists.freedesktop.org The deadline for submitting proposals to LGM is Wednesday 15 January. Please don't forget to submit your proposal for a talk, workshop or meeting here: http://libregraphicsmeeting.org/2014/submit/ If you are planning to join us at LGM this year in Leipzig, you are welcome to sign up: http://libregraphicsmeeting.org/2014/register -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] stroke_to() simultaneously
On 27 December 2013 17:16, pured...@11h11.com wrote: hi all, i am controlling mypaint via pure data (pyliblo - osc). would like to make some kind of animation (playing back / looping a freehand drawing) - that part is working (recording the tablet information in pure data and sending back this data via osc to mypaint / stroke_to). is it possible to have multiple stroke_to being use at the same time (with different brush / color)? maybe there's a way when using different layers? In theory, from the brush engine perspective, it should just work. But I am not sure anyone has actually tested it before :) You need to instantiate one lib.brush.Brush per brush you want, and set them up with the different brush settings (for instance using lib.brush.BrushInfo). This is done in lib/document.py for the one main brush MyPaint has now. Once you have that, you should be able to call stroke_to() on each of them. Using the same surface (the surface is the part of the layer one paints to) should be fine, but I would first try to call start/end_atomic() around each stroke_to() call. If that works, try moving all the stroke_to() calls inside a single begin/end_atomic() pair. The current code for this is in lib/layer.py btw, i know that mypaint is not made for this kind of hack, but i like the render of it and the fact that it's coded in python (so at least i was able to add pyliblo to it). Nah, but libmypaint (with or without GEGL) should be able to do it easily. Right now its not nice so because the proper backends we have and renderers for it is a bit of work to set up. I assume you mainly want to use the canvas and drawing aspects of MyPaint? -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] Fwd: [LGRU] LGM 2014 in Leipzig: Submit a presentation!
-- Forwarded message -- From: Femke Snelting snelt...@collectifs.net Date: 27 November 2013 06:51 Subject: [LGRU] LGM 2014 in Leipzig: Submit a presentation! To: l...@lists.constantvzw.org The Libre Graphics Meeting 2014 will take place 2. – 5. April 2014 in Leipzig, Germany. This yearly event is an occasion for projects and individual contributors/artists from all over the world to work together, to share experiences and to hear about new ideas. By Libre Graphics we mean Free, Libre and Open Source tools for design, illustration, photography, typography, art, graphics, page layout, publishing, cartography, animation, video, interactive media, generative graphics and visual live-coding. The Libre Graphics Meeting is not just about software, but extends to standards, file formats and actual use of these in creative work. We are looking for: - In-depth presentations on Libre Graphics technologies - Showcases of excellent work made using Libre Graphics tools - New projects in this area to meet the wider community - Reports, use-cases, best practices - New emerging media; breaking free from analog constraints - Well articulated ideas for future approaches, tools and standards Available formats (including questions): - Lightning talk (10 minutes, selected at the event unconference style) - Presentations (20 minutes extendable to 40 minutes) - Entry for State of the Libre Graphics Union (1-2 slides) - Workshops (2 hours or more) - Birds Of a Feather (BOF), discussion meetings or Hackathons (2 hrs or more) More information: http://libregraphicsmeeting.org/2014/?page_id=165 Submit your proposal here: http://libregraphicsmeeting.org/2014/?page_id=85 ___ LGRU mailing list l...@lists.constantvzw.org https://listes.domainepublic.net/listinfo/lgru -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Howto performance tests
On 17 October 2013 09:59, David Revoy davidre...@gmail.com wrote: On Tue, Oct 15, 2013 at 11:21 PM, Jon Nordby jono...@gmail.com wrote: Hi David, please scream loudly when things change in master that cause problems for your workflow. Quick feedback from artists is critical for us. Hi Jon ! Ok, I'll do it :-) Thanks! To confirm: Between these two screenshots, you only changed MyPaint version right? No changes to GTK+ version or anything else? Yes, I only changed from Mypaint 1.1 package from : - 1st version : installed from pacman arch repo ; version 1.1 - 2nd version : cloned git repo, get the dependencies and built Mypaint Git ( also removed with pacman 1.1, and moved ~/.mypaint to ~/.mypaint-old to avoid conflict ) My system / Gtk version was the same in both test. Other main workstation here got Manjaro default's Xfce desktop. Same results ( and same packages versions ). I completely forgot that 1.1 uses GTK+2, so that of course explains the difference. Could you test a small thing for me on git master? (remember that you don't have to install it, can just run straight from source directory). Sure, I did all the test. I prefered to 'scon clean' and reinstall each time to ensure the change was really done when I ran Mypaint. Here are the results ( screenshoted ) In gui/canvasevent.py change MOTION_QUEUE_PRIORITY = gobject.PRIORITY_DEFAULT_IDLE http://i.imgur.com/efvqJj4.jpg MOTION_QUEUE_PRIORITY = gobject.PRIORITY_HIGH_IDLE + 10 http://i.imgur.com/C0WIhXT.jpg MOTION_QUEUE_PRIORITY = gobject.PRIORITY_HIGH http://i.imgur.com/BDVFUec.jpg Does that make the performance any better? The three experiences , as you see on the screenshot were similar. At least on a 'feeling' point of view. Thanks for testing. Looks like there is not much to gain, at least not when the system is not heavily loaded. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Howto performance tests
On 9 October 2013 11:32, David Revoy davidre...@gmail.com wrote: Hi, I was away Mypaint testing since spring ( few weeks after LGM ) , because I experienced more and more problems with master , keeping around during weeks, and it was too hard to follow in production. I decided to build Git-master this morning, and run new test. ( attracted by emails from mailing-list, and a PM poke from José Américo Gobbo ). Hi David, please scream loudly when things change in master that cause problems for your workflow. Quick feedback from artists is critical for us. Here are my observations, painting on Git-master : http://i.imgur.com/navr8HE.png ... output lines are angular, laggy and not precise. The lines display fast ; but it's like all the coordinate of the stylus were crunched on the way , or were being recorded without sufficient frequencies. So, I uninstalled, cleaned the folders , and put 1.1 back from Arch package ( 1.1 got also an annoying issue for me in cursor size and offset who got solved in master , I think I'll build a git~master a bit post 1.1 soon for my personal use) Same sketch on 1.1 to compare : http://i.imgur.com/wybB5Mi.png Smooth lines are back, and very sync to what gesture I have in mind. No angular breaks observed, even drawing speedly. To confirm: Between these two screenshots, you only changed MyPaint version right? No changes to GTK+ version or anything else? Could you test a small thing for me on git master? (remember that you don't have to install it, can just run straight from source directory). In gui/canvasevent.py change MOTION_QUEUE_PRIORITY = gobject.PRIORITY_DEFAULT_IDLE to MOTION_QUEUE_PRIORITY = gobject.PRIORITY_HIGH_IDLE + 10 or even MOTION_QUEUE_PRIORITY = gobject.PRIORITY_HIGH Does that make the performance any better? Maybe it's a local bug... I hope. Because it makes my local experience made of frustration, and make me sad, because I was used to Mypaint Git-master very stable and usable since 2009. I hope it's only a local observation, and it can be solved ! Everything can be solved :) And from the information you gave it even looks like the problem is in MyPaint itself, so it should not be too hard. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] fresh-instal
On 9 October 2013 16:34, uga...@talktalk.net wrote: Hi I am running MyPaint on a Mac OSX v10.6.8 and I find I am unable to instal a fresh version of MyPaint. I have tried deleting both the application together with the complete opt/mypaint directory. On re-installing, history is retained in new version. Hi, which version of MyPaint is this, and where have you installed it from? -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] brushlib with GPU
On 7 October 2013 00:36, brdavs brd...@yahoo.com wrote: Hi Jon, Thank you very much for your kind reply. You are welcome. I'm keeping the mypaint-discuss mailing list CC'ed so others can follow as well. I have several questions / comments: 1. Why do you think that OpenCL is a better solution than doing it purely in OpenGL? One problem I see is that if you are drawing a lot of small dabs, OpenCL will probably be very inefficient, because you won't be doing much work for each dab. You'll be launching a kernel a lot which is not negligible. OpenCL is a more general programming model, hence it will probably be easier to translate existing code and concepts in a meaningful way. Also, I've programmed GPUs in this manner before (using CUDA) - where as I've never done non-trivial OpenGL. If one can make it work in OpenGL/GLSL, that would probably be ideal. Both from performance and availability perspective. Any ideas how to realize the algorithm there would be very welcomed! In addition to a surface backend, you will likely want a way to display the surface on screen - so that is the other thing that needs implementing. This could/should be OpenGL based, using the OpenCL+OpenGL interoperability if the surf backend is in OpenCL. For making full advantage of such a backend in MyPaint itself, one would also have to implement layers etc. on the GPU side. 2. Even if you can batch a bunch of dabs together, the dabs will overlap and you would have to resort to atomic operations (slower) for proper blending. The CPU backend has an operations queue in which dabs are batched, in a tile-wise manner. See operationsqueue.c and mypaint-tiledsurface.c No concurrency is attempted between individual dabs, ordering is preserved by the queue. Threads work on individual tiles, with no syncronization necessary between them. On the GPU one would ideally like that every (output) pixel is computed concurrently without sync. One could perhaps apply the same queuing principle, but probably use a vector for the depth - and store the queue suitable for consumption by individual thread warps (16/32 on GPUs I am used to). But, starting with the naive one-kernel-per-dab approach is probably the best. Once we have that we can think of smarter ways of doing things. 3. Is there a super simple working example of the brushlib painting a (hardwired) stroke with a configurable brush? I would be interested in trying a few simple things in OpenCL (no tiling, etc.) and would be good to have a simple starting point in C/C++ and a reference implementation. Sadly the minimal.c example is broken right now. The API usage as shown is fine, its just the simple surface that is borked - wrong buffer stride handling in the backend. I will have a look at fixing it up later, but I would not wait for it. For GPU things, you'll need a lot of additional scaffolding (OpenCL setup etc), so maybe copy minimal.c and start adding that. I suggest you put the code in a subdirectory as it will have extra dependencies, for instance brushlib/cl/. BlackInk seems to have a very impressive paint engine inplemented on the GPU: http://www.bleank.com/BlackInk-a115.html Marko -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Howto performance tests
On 6 October 2013 21:09, José Américo Gobbo jag.rabi...@gmail.com wrote: I've did the test on new box with ubuntu gnome 13.10 devel, the git version is 1.1.0+git8cbd0ad I've synchronized yesterday with the MyPaint Git Master. While the test ran on terminal many errors have occurred because didn't find the 'Mypaint_Default.gpl' on /palettes. But the palette name and /palettes folder were OK. Yes, I just ran the test myself and it was broken. Quick hack is to change palettes to ../palettes in gui/colors/adjbases.py I'm interested to do this tests with two releases... the 1.1 Mypaint PPa and the last Git Master. For me seems that the last git master have delays in the brush strokes if I compare with 1.1 Mypaint PPa. The idea is to make tests in different distros with the same Mypaint releases. I've ubuntu gnome 13.10, elementary OS 0.2 and linuxmint 15 kde. Yes, current git master have delays in brush strokes. See discussion https://mail.gna.org/public/mypaint-discuss/2013-08/msg00011.html Unfortunately the GUI perf tests do not pick up this regression. Probably either cause they do not inject the input events high enough in the stack, because they don't measure latency, or another weakness in the test. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Attacking the angular brush strokes bug
On 6 October 2013 22:28, Jon Nordby jono...@gmail.com wrote: Seems that noone did this. However, popolon just recorded a video demonstrating the problem: http://popolon.org/cubieboard/mypaint.git.vs.mypaint.jonnorified.ogv Video moved to http://popolon.org/cubieboard/demos_video.201310/mypaint.git.vs.mypaint.jonnorified.ogv ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] brushlib with GPU
Hi Marko, I do not know if anyone has actually tried to implement a GPU backend - but it is something I've given quite a bit of thought. The idea is briefly documented in brushlib/PERFORMANCE https://gitorious.org/mypaint/mypaint/source/master:brushlib/PERFORMANCE Blending of the dab onto the surface is the responsibility of the MyPaintSurface backend. For the normal CPU tiled version, that code is found in brushlib/mypaint-tiled-surface.c and brushlib/brushmodes.c. Search for draw_dab_pixels_ In addition to a surface backend, you will likely want a way to display the surface on screen - so that is the other thing that needs implementing. This could/should be OpenGL based, using the OpenCL+OpenGL interoperability if the surf backend is in OpenCL. For making full advantage of such a backend in MyPaint itself, one would also have to implement layers etc. on the GPU side. On 4 October 2013 23:30, brdavs brd...@yahoo.com wrote: Hi, I have been browsing through brush engine in mypaint. I am wondering if anybody has tried to implement the backend in OpenGL/OpenCL. If I understand correctly, the only thing that is needed to get brush engine working is to implement GPU-backed MyPaintSurface with appropriate methods. Correct? One thing that is not immediately obvious to me is where does blending occur. Namely, when you draw a dab where does the blending occur? It seems that one would want that to be done on the GPU as well. Is there anything else that would have to be rewritten to take advantage of the GPU? Thanks, Marko -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Attacking the angular brush strokes bug
On 23 August 2013 00:35, Jon Nordby jono...@gmail.com wrote: On 17 August 2013 21:45, Andrew Chadwick a.t.chadw...@gmail.com wrote: I'm trying to address https://bugzilla.gnome.org/show_bug.cgi?id=702392 https://gna.org/bugs/?21003 https://gna.org/bugs/?20822 as much as we can in MyPaint by tweaking the way that we deal with stroke processing. We really need an upstream fix for this problem, but in the meantime there's stuff we can do to make the experience nicer for users of the new Gdk. Current work on it can be found at https://gitorious.org/mypaint/mypaint/commits/gtk3-stroke-queue and testing would be most welcome. Hi, sorry that I did not respond until now, after it has been merged. Also saw that a lot of GUI work went in, cool! Pupuser on #mypaint said that master appears much slower than 7e27a690 on his machine. David Revoy also noted some apparent slowness in rendering with master. I have not tested much yet, both said they would follow up with more detailed info later. Another user on IRC reported this now, see git log underneath. Can we revert the patches? werkbau Hm, hello. I use mypaint regularly, GIT version, but since the latest update it's been behaving odd, to the point of being unusable. It's like if every stroke was done with max slow tracking, even at zero. werkbau Could I at least get a command or something to revert my local repository to a previous version? I need it urgently :( jonnor git checkout 7e27a690 -b nostrokequeue werkbau Oh thank you very much. werkbau let me rebuild and check how it works jonnor yes, please let us know if that fixes the issue werkbau Yes, it does! -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Attacking the angular brush strokes bug
On 23 August 2013 09:25, a.l.e ale.comp...@xox.ch wrote: hi jon On Fri, Aug 23, 2013 at 12:35:56AM +0200, Jon Nordby wrote: I am still recovering from tendonitis in both arms, so I've been keeping computer stuff to a bare minimum the last couple of months. Hey Jon, if it's keyboard related, this helped me a lot: http://maxy.homeip.net/misc/kinesis.jpg Hehe, very cool. I have been using this for years now. Takes about two weeks to get used to. I even started to carry it forth and back from work, so now I have two. ping pum chack point point... Using Python to Code by Voice http://www.youtube.com/watch?v=8SkdfdXWYaI good luck with your recovering! Thanks for the tips Martin and Ale! Will probably get myself a new keyboard. Voice control is too rocket science I think :p But first I should probably just take some weeks holidays with zero keyboard/computer... -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Major-ish UI updates pending: tabbed-workspace branch
On 11 July 2013 22:32, Andrew Chadwick a.t.chadw...@gmail.com wrote: Hi all -- I've been working on some UI stuff recently: just pushed a preview to https://gitorious.org/~achadwick/mypaint/achadwick-mypaint/commits/tabbed-workspace for testing. It's quite involved, so I don't want to merge it just yet if folks are doing performance tweaks in master... Probably there are not much changes in lib/, right? In that case I dont think there is any conflict with the work I have ongoing. But please do check that the changes do not introduce performance regressions (by running tests/test_performance.py -a before and after) * Dockable interface using standard GtkNotebook behaviour. Closer to GIMP's look. * Fullscreen management has changed. Sidebars, top and bottom bars, and floating windows containing dockable panels now auto-hide with a delay, and also auto-reveal when you mouseover or push a screen edge. auto-show and auto-hide is very tricky to get right, are you sure you want this to be default? Also, regarding push on screen edge: wouldnt it be more interesting to use this for moving the canvas? * Tab now toggles auto-hide. It's a little crude, but it works: might need to be more customizable. * Reworks of (some) publish/subscribe interfaces. More syntax sugar, and lets both observed and observer objects die naturally (theoretically at least; PyGI/GObject doesn't in many cases) * Fairly major refits of the way palettes and brush groups work. Big parallels going on here in terms of concept and appearance: something for a future refactor? I think brushes and backgrounds are even more similar, so a future rethinking of the way this works. Also, I am thinking more and more that the generic approach we take to brush group management is not ideal. I suspect we would be better of with just letting users favorite brushes easily, and that this would make them available in a favorites / my brushes tab/whatever in the UI. Should be possible to export/share this group, of course. * Dockable tool widgets/panels/subwindows/bleh are registered the way Martin wanted, via an API call (namely setting __gtype_name__ in some future plugin's class definitions, but hey: it's an API call and it's a start). There's nothing written yet for register a new dockable in such-and-such a category. * Don't load all the backgrounds at startup. Also exists in master since a week or two, be aware when merging. * Generally defer loading of dialog-type subwindows wherever we can. * Quite a few drag/drop fixes and other GTK3 niceties. * Additional sidebar on the left. More potential panels means more space, although tabs make space usage more efficient generally. * Footer bar showing the current mode and what pressing modifiers and pointer buttons will do, like Inkscape. Left+bottom corner gets the common colour controls; might so something similar for brushes in the right+bottom corner. Is the footer on-canvas or a separate widget? (sorry for not just checking myself, no buildenv on this machine) -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] OpenMP support for MyPaint in master, testing wanted
On 7 July 2013 08:55, Martin Renold martin...@gmx.ch wrote: On Sat, Jul 06, 2013 at 07:28:53PM +0200, Jon Nordby wrote: I see that the paint and paint-rotated benchmarks have had a regression since 1.1 (due to GTK+3?). I pushed a commit which should help a bit, by caching the transformation matrix: http://gitorious.org/mypaint/mypaint/commit/4b0cf83174cfe0ef3c796b497df913a8e06560da Thanks a lot! I was getting a bit desperate when fixing the display bugs exposed by gtk3.9, and happy to have found a fix at all. The code before fbec5171 (the benchmarked one) wouldn't have needed this caching, I think. where most things are limited by how fast we can fetch tiles from the tile store, ie: _get_tile_numpy() in lib/tiledsurface.py If this is really the per-tile overhead adding up, we can just increase MYPAINT_TILE_SIZE. But looks like _get_tile_numpy() is doing a lot more than just fetching tiles. Increasing the tile size is on option, but it will limit concurrency more (as multi-threading is done on a tile-by-tile basis). It may also lead to poorer Time spent in (and below) _get_tile_numpy() on my system: layerpaint_zoomed_out_5x: 48% brushengine_paint_hires: 35% paint_zoomed_out_5x: 52% Much more than I expected. I wonder if it could be all due to mip-mapping? But then again, mip-mapping should happen only once per displayed frame, I expected this to disappear in actual hi-res dabbing. Well, because we always paint onto the surface which is mipmap level 0, when we are displaying zoomed out we have to. One way of avoiding this would be to paint at the same mipmap level as we are displaying, but this requires us to be able to re-render past strokes when user zooms in again. Tricky, but not impossible as we can now store paint operations efficiently (in an OperationQueue). I am attaching the callgraps (from tests/test_performance.py -c 1 -s TEST) here. layerpaint_zoomed_out_5x: http://i.imgur.com/OZcBjXG.png brushengine_paint_hires: http://i.imgur.com/qj1o5vO.png paint_zoomed_out_5x: http://i.imgur.com/e13IKV4.png As you can see there are three problem spots: 1. computing dirty mipmaps 2. marking tiles as dirty 3. time spent in get_tile_numpy itself 1) is something that we could improve through multi-threading, like we do with tiles while painting. This requires that we batch up the tiles to be processed and hand it over to C++, as one cannot call into Python from multiple threads concurrently. I attempted to do that, but due to added complexity on Python side, it turned out slower. http://gitorious.org/~jonnor/mypaint/jonnors-clone/commits/mipmap-cpp Alternative approaches to this would be appreciated. 2) Could maybe be improved by changing mark_mipmap_dirty to not be recursive, but instead just iterate over the list of mipmap surfaces and doing surface.tiledict[(tx, ty)] = mipmap_dirty_tile, on each? Hmm, or maybe we can return early in some cases. If a tile is the mipmap_dirty_tile, then sure all of the tiles above it will also be already, so no need to redo it? *goes to tests* 3) Perhaps avoding recursion could help here to? Apart from that I don't have many ideas... I am experiementing with moving all of this code into C/C++, so that no trip into Python is needed per-tile http://gitorious.org/~jonnor/mypaint/jonnors-clone/commits/tilestore-cpp This is also an exploration of how we can back the surface in MyPaint with something else than the current implementation (I am thinking GEGL here), as I am still not certain how to approach that. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] OpenMP support for MyPaint in master, testing wanted
On 7 July 2013 14:31, Jon Nordby jono...@gmail.com wrote: I am attaching the callgraps (from tests/test_performance.py -c 1 -s TEST) here. layerpaint_zoomed_out_5x: http://i.imgur.com/OZcBjXG.png brushengine_paint_hires: http://i.imgur.com/qj1o5vO.png paint_zoomed_out_5x: http://i.imgur.com/e13IKV4.png As you can see there are three problem spots: 1. computing dirty mipmaps 2. marking tiles as dirty 3. time spent in get_tile_numpy itself 1) is something that we could improve through multi-threading, like we do with tiles while painting. This requires that we batch up the tiles to be processed and hand it over to C++, as one cannot call into Python from multiple threads concurrently. I attempted to do that, but due to added complexity on Python side, it turned out slower. http://gitorious.org/~jonnor/mypaint/jonnors-clone/commits/mipmap-cpp Alternative approaches to this would be appreciated. I seem to be close to an algoritm which does this with no temporary datastructure for the mipmap tile graph, so maybe it will work out after all. 2) Could maybe be improved by changing mark_mipmap_dirty to not be recursive, but instead just iterate over the list of mipmap surfaces and doing surface.tiledict[(tx, ty)] = mipmap_dirty_tile, on each? Hmm, or maybe we can return early in some cases. If a tile is the mipmap_dirty_tile, then sure all of the tiles above it will also be already, so no need to redo it? *goes to tests* Yup, helped a bit, up to 10%. http://gitorious.org/mypaint/mypaint/commit/e27c3c01f0967b2708e4994dc9b81c35766f2270 3) Perhaps avoding recursion could help here to? Apart from that I don't have many ideas... I found a place where I could optimize a bit, up to 10% gain. http://gitorious.org/mypaint/mypaint/commit/15d58498a5ee08c8ace6866455c472f5405e1860 -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] OpenMP support for MyPaint in master, testing wanted
Hi all, I've implemented support for OpenMP based multithreading for the current (Python-based) surface backend. Because the backend calls into the Python interpreter to get tile data, this whole section is synchronized using the OpenMP critical directive[1]. On the brushlib benchmarks, this gives excellent speedups on my 2 core Intel Core i5 M520: up to 65% increase for large brushes and less than 10% slowdown for tiny brushes (where performance is not an issue anyway). This is very close to what I get using the GEGL backend, which does not need to do so much synchronization when fetching tiles. However, using the GUI performance tests I get very mixed results. In one set of test runs: scroll_zoomed_out_2x_onelayer: 8.80 (780%) paint_zoomed_out_5x: 1.172571 (17%) layerpaint_zoomed_out_5x: 1.156669 (16%) brushengine_paint_hires: 1.091002 (9%) ... rest unchanged ... scroll_nozoom: 0.972973 (-3%) scroll_zoomed_out_5x: 0.970874 (-3%) layerpaint_nozoom: 0.950122 (-5%) paint: 0.948916 (-5%) paint_rotated: 0.940476 (-6%) scroll_zoomed_out_1x_onelayer: 0.80 (-20%) scroll_nozoom_onelayer: 0.75 (-25%) And in another: scroll_nozoom: 25.67 (2467%) paint_zoomed_out_5x: 1.088084 (9%) layerpaint_zoomed_out_5x: 1.060632 (6%) rest unchanged ... brushengine_paint_hires: 0.933682 (-7%) layerpaint_nozoom: 0.801448 (-20%) paint_rotated: 0.782366 (-22%) paint: 0.780457 (-22%) scroll_nozoom_onelayer: 0.60 (-40%) scroll_zoomed_out_1x_onelayer: 0.50 (-50%) I will investigate these things further, but in the meantime it would be good to see what kind of results others get. # To test scons enable_openmp=true ./mypaint # To run GUI perf tests. Note: takes about 5 minutes, should not be disturbed while running python2 tests/test_performance.py -a Just copy paste the SUMMARY section for each run (with and without enable_openmp=true) into the mail. 1. http://gitorious.org/mypaint/mypaint/blobs/283df90826bcc9d3ed6c32e44e9f8f5ed3ed9de4/lib/pythontiledsurface.c -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] Fwd: scons - can't compile MyPaint, g++ options of unknown origin
Forwarding to list -- Forwarded message -- From: Daniel Ziólkowski ziolko...@gmail.com Date: 10 March 2013 22:58 Subject: Re: [Mypaint-discuss] scons - can't compile MyPaint, g++ options of unknown origin To: Jon Nordby jono...@gmail.com 2013/3/9 Jon Nordby jono...@gmail.com: The MyPaint scons file does neither add -OPT:Olimit=0 nor -march=core2 -O2 -fplugin=/usr/lib64/llvm/dragonegg.so. It will capture CFLAGS/CXXFLAGS from the environment, so please first try to unset CFLAGS and unset CXXFLAGS before trying to build. Furthermore, it will use cflags as specified by its dependencies in their pkg-config files. So try to do pkg-config --cflags json-c python gtk-2.0 lcms-2.0 (note: names of the dependencies are from my head, check with the scons file for the exact names). Could also grep your pkg-config files for this strange -OPT thing. There was nothing wrong with pkg-config nor CFLAGS/CXXFLAGS. Scons ignore all variables from command line by the way. However I did little dirty hack and added env[CC] = os.getenv(CC) or env[CC] env[CXX] = os.getenv(CXX) or env[CXX] env[LINK] = os.getenv(LINK) or env[LINK] env[ENV].update(x for x in os.environ.items() if x[0].startswith(CCC_)) to SConstruct and then compiled with 'CC=clang CXX=clang++ LINK=g++ scons'. It worked, but don't ask me why/how, I have no idea. Probably there is something hardcoded in my scons or something. However the most important thing is that MyPaint have compiled and works. :) -- Daniel Tracerneo Ziółkowski -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] scons - can't compile MyPaint, g++ options of unknown origin
On 9 March 2013 20:07, Daniel Ziólkowski ziolko...@gmail.com wrote:
scons uses weird options causing compilation fail:
-OPT:Olimit=0
and
-march=core2 -O2 -fplugin=/usr/lib64/llvm/dragonegg.so
Second line is probably from /etc/portage/make.conf, but even after
commenting line with variable CFLAGS, these options are added.
The first one causes error:
cc1plus: error: argument to ‘-O’ should be a non-negative integer
And the second:
cc1plus: error: cannot load plugin /usr/lib64/llvm/dragonegg.so
/usr/lib64/llvm/dragonegg.so: undefined symbol: tree_map_base_marked_p
What can be problem and how to fix it?
I'm using Gentoo with clang and
CFLAGS=-march=core2 -O2 -fplugin=/usr/lib64/llvm/dragonegg.so
CXXFLAGS=${CFLAGS}
in /etc/portage/make.conf
The MyPaint scons file does neither add -OPT:Olimit=0 nor
-march=core2 -O2 -fplugin=/usr/lib64/llvm/dragonegg.so.
It will capture CFLAGS/CXXFLAGS from the environment, so please first
try to unset CFLAGS and unset CXXFLAGS before trying to build.
Furthermore, it will use cflags as specified by its dependencies in
their pkg-config files. So try to do pkg-config --cflags json-c
python gtk-2.0 lcms-2.0 (note: names of the dependencies are from my
head, check with the scons file for the exact names). Could also grep
your pkg-config files for this strange -OPT thing.
Hope that helps,
Jon
--
Jon Nordby - www.jonnor.com
___
Mypaint-discuss mailing list
Mypaint-discuss@gna.org
https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Vector Data and GSoC
On 4 March 2013 23:41, Kolja Lubitz pinguin...@gmail.com wrote: Hi Hi Kolja, I'm thinking for a while about adding some kind of vector support to MaPaint. The main idea is a Paint program in which you don't have to care about pixel. The main workflow should be open the program and you start with a white surface and then you can start painting and only in the end if you press save you decide in witch resolution you like to have your pic. On the technical side it is very simple. While painting we need to store all input data and scale and brush. And on save the brushes will be rendering to a png or so. I agree with your vision, users should not have to care about pixels most of the time. MyPaint already stores most of the input data. Check out the classes with names like Stroke in lib/stroke.py etc. At the moment it is used for the change last stroke feature that one can toggle on/off in the brush settings editor, and probably for the bezier curve lines. Previously it was used for undo/redo as well, but that was found to be too slow. That is probably going to be the main challenge: performance. In the traditional raster model, where one destructively update a set of tiled mipmapped raster surfaces as changes are made, rendering the document to screen or to a bitmap export is very fast as it only requires compositing the layers together (at the appropriate mipmap level) and blitting it to the screen/bitmap. I am not sure how to efficiently represent a document of MyPaint brush strokes as vector data that can be rendered as fast. To try out the idea, and as a first useful step, you could try to implement a lossless resize document feature? Use the existing stroke infrastructure to store all input information (probably needs some additions as well), and when invoking this function the user can choose to make the document say 2x bigger or smaller. MyPaint should then replay all the strokes onto different size surfaces, and the result should be as if one had been painting at that resolution all the time. That should give you a feeling for how feasible it would be performance wise, and let you understand how such things can be done inside the MyPaint code. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] libMyPaint demo app : second step
it is cleaner to do all this stuff in one step with preproc. And if you want to put this stuff in a function, you'll still have to use some #ifdef outside to avoid the #include libintl.h (unless you plan to put it inside the function, which is not great either) Have a look to the patch and let we know if you still prefer to move this to a function (so I should replace all _ calls to something like translate() and do the routing stuff in it) but my modification is only 5 lines extra and is not invasive. Also, the gettext support should probably be opt-in, so call the define HAVE_GETTEXT or similar. I previously used a NO_GETTEXT flag so you should not modify anything to your mypaint config file, only to the demo project... But this is your choice to do the reverse ;-) Could you provide a patch that shows the required changes? Which version of MSVC are you using? Please find the patches named 000[1..5]-msvc.patch (the one with HAVE_GETTEXT is 0001-msvc.patch) I use msvc 2005 2010. Note that msvc 2012 for C/C++ can not be downloaded freely so I don't think it is an important target. Older msvc versions will have plenty of trouble to compile Qt4 code... I'd like to keep that style of include. The reason it does not use the json/ directory is to avoid system-installed headers to be picked up automatically, [...] Understood. I hope so too! For committing the demo file to the repository, it should be a single file in the brushlib/examples/ directory. And ideally provided as a git formatted patch Hic !? You mean I should merge all C++ headers and cpp files into one ? And what's about the Qt project file, the json-c library (for windows users), the README...? The goal of this mini-demo project is to provide to anyone familiar with Qt a very simple demonstration of libmypaint. Such self-containing directory where the user just type qmake and make is very usual in all Qt example demo. Merging all files into one may ruin the easy to use understand goal. if you prefer, I could adapt the relative path so the demoQt4 could be inside examples (for now it is at the same level) but I can hardy see merging everything into one file inside examples... The latest version (seems bug free) is attached here in demoQt4.zip. Other point : what's about brushmodes.cpp/.h and mypaint-tiled-surface.cpp/.h ? Martin said that he was ok to turn them ISC (no longer GPL) but they may not be only his work. If all the dev involved in these files are ok, you may change the license header... If you have the time and interest, you should consider coming to Libre Graphics Meeting: I will seriously consider it ! Best regards Sébastien -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] Fwd: Relicensing of MyPaint brush rendering code from GPLv2+ to ISC
Just posting this in public for archiving purposes. -- Forwarded message -- From: Karol Guciek k.guc...@gmail.com Date: 21 January 2013 06:55 Subject: Re: Relicensing of MyPaint brush rendering code from GPLv2+ to ISC To: Jon Nordby jono...@gmail.com Hello, Of course it's OK with me; I have not done anything worthwhile anyway. Thanks for asking and good luck with continuing MyPaint development! Chris On Sun, Jan 20, 2013 at 7:37 PM, Jon Nordby jono...@gmail.com wrote: Hi Karol, I'm writing to you because you have contributed some code to the MyPaint brush engine in git commit dbdaeb1b in the file lib/tiledsurface.hpp As you may know, the MyPaint brush engine is available as a library which other applications can use. In order to make it easy for any application to incorporate this library and use the MyPaint brush engine, it is licensed under the BSD-style license ISC: https://www.isc.org/software/license The file that you have contributed to has now been integrated into this library (as file brushlib/mypaint-tiled-surface.c), but is still marked as GPLv2+ license, so I have to ask you: Are you OK with your code being used under the ISC? We hope that this will allow even more applications to pick up the MyPaint brush engine. Thanks for your contributions! - Jon -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Fwd: My animation app
On 20 January 2013 20:17, Manuel Quiñones ma...@laptop.org wrote: 2013/1/20 Jon Nordby jono...@gmail.com: I intend to address the other comments later today. Great! In partular instancing a MyPaintGegl.TiledSurface will allow to do a simple test app like mypaint-gegl.py but with introspection. Here it throws MemoryError, I think you had a different error. As discussed on IRC, this was fixed in master on Sunday evening. Some API changes were needed to make things work, notably making use of refcounting on MyPaintSurface and MyPaintBrush, so that they can be wrapped without issues with GBoxed types. aalmost there to a 100 line application that can paint with MyPaint brushes on a GEGL backend, including rendering to screen: http://gitorious.org/~jonnor/mypaint/jonnors-clone/commit/402366d9b3e7ad708351c193573a8f4d2850b95b -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] Fwd: My animation app
Used the wrong email address the first time. -- Forwarded message -- From: Jon Nordby nordby@gmail.com Date: 20 January 2013 14:29 Subject: Re: My animation app To: Manuel Quiñones ma...@laptop.org Cc: mypaint-discuss mypaint-discuss@gna.org On 19 January 2013 22:49, Manuel Quiñones ma...@laptop.org wrote: Hey Jon, (sending to mypaint-discuss) Hey Manuel, Yes, lets keep others in the loop too. Thanks for testing and pushing the state of libmypaint further. One thing to note is that the mypaint-gegl.py script does not only use the brushlib, it also uses the MyPaint C++ extensions. So for your application you should try to build the brushlib with introspection (pass enable_introspection=true to scons) and then do from gi.repository import MyPaint, MyPaintGegl instead of the current from lib import mypaintlib, tiledsurface, brush. Good advice, yes that's the way to go for my app. So I installed with introspection but I can't import MyPaint or MyPaintGegl after install. I can see the typelib files in the corresponding path. I might be doing something stupid: Looks like the -$version in .gir and .typelib is mandatory. I think it was optional before, but in any case I've fixed it in master now: http://gitorious.org/mypaint/mypaint/commit/6b374591d203e6cbdecd1dd9fa0f67e2614503b3 Also fixed some other bugs, and added the beginning of an example of how to use the GI bindings from Python, see brushlib/examples/gegl.py As you can see from the comments, things are still a bit rough. Perhaps you know how to address the # TODO: Is there a better way to list all enums with GI? comment? I intend to address the other comments later today. [manuq@manuq-laptop mypaint]$ ls $GI_TYPELIB_PATH Babl-0.1.typelib GeglGtk2-0.1.typelib MyPaintGegl.typelib Gegl-0.2.typelib GeglGtk3-0.1.typelib MyPaint.typelib [manuq@manuq-laptop mypaint]$ python Python 2.7.3 (default, Jul 24 2012, 10:05:38) [GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux2 Type help, copyright, credits or license for more information. from gi.repository import Gegl, GeglGtk3 from gi.repository import MyPaint, MyPaintGegl ERROR:root:Could not find any typelib for MyPaint ERROR:root:Could not find any typelib for MyPaintGegl Traceback (most recent call last): File stdin, line 1, in module ImportError: cannot import name MyPaint My scons commands were: scons enable_introspection=true brushlib_only=true prefix=$PREFIX_GEGL scons prefix=$PREFIX_GEGL install Cheers, -- .. manuq .. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] First attempt of a libMyPaint demo app...
On 19 January 2013 20:50, Sebastien Leon sl...@pointcarre.com wrote: For now, I had to include these 4 GPL files : brushmodes.cpp/.h and mypaint-tiled-surface.cpp/.h. Note for anyone who would like to include this code into a proprietary project : these 2 files are GPL and as long as you keep them in this mini-project, the whole project is GPL and can not be include into a proprietary project. (I should write some replacement for these files as a next step - unless their license is modified) You are absolutely right. It was my intent that this code also would become ISC as the rest when I moved it to brushlib/ (from lib/). 90%+ of the copyright belongs to Martin and me, smaller contributions have come from 4 others. I have now sent an email to all the copyright-holders of these files to check whether such relicensing is OK. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] Fwd: [LGRU] Call for presentations LGM2013: Future Tools
Hi all MyPainters, who is coming to the Libre Graphics Meeting this year? This year it is in early April, 10-13th (not early May like before) in Madrid, and has the theme Future Tools. The call for presentations is open until Feb 15th (see below), and you can register your participation now at http://libregraphicsmeeting.org/2013/registration/ I plan be there for the whole week, so hope to see the rest of you! -- Forwarded message -- From: Femke Snelting snelt...@collectifs.net Date: 19 January 2013 13:14 Subject: [LGRU] Call for presentations LGM2013: Future Tools To: l...@lists.constantvzw.org, Create ML cre...@lists.freedesktop.org *Developers and users meet at the Libre Graphics Meeting in Madrid* Libre Graphics Meeting 2013: Future Tools will take place from Wednesday 10th to Saturday 13th April in Madrid, Spain. The 8th LGM will be held at Medialab Prado's brand new building in the center of Madrid, La Serreria Belga. The event brings together developers and designers from all over the world to work on the many different tools in the Free, Libre and Open Source toolbox. http://libregraphicsmeeting.org *Call for presentations* The Libre Graphics Meeting is looking for in-depth presentations on Libre Graphics technologies, showcases of excellent work made using Libre Graphics tools and new ideas for future approaches, tools and standards. Call for presentations: http://libregraphicsmeeting.org/2013/call-for-presentations Deadline: 15 February 2013 *Sign up for LGM2013* LGM is free to attend and open to all! Registration is not required but it would be nice to know who will be there in Madrid, next spring. Register here: http://libregraphicsmeeting.org/2013/registration Participants so far: http://libregraphicsmeeting.org/2013/participants *Support the Libre Graphics Meeting* Please help us bring developers to Madrid for the Libre Graphics Meeting 2013: Future Tools. We aim to raise 10.000$ to support volunteer developers and presenters that would otherwise be unable to journey to Madrid. Every donation counts! http://pledgie.com/campaigns/19064 ___ LGRU mailing list l...@lists.constantvzw.org https://listes.domainepublic.net/listinfo/lgru -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] First attempt of a libMyPaint demo app...
On 20 January 2013 19:52, Sebastien Leon sl...@pointcarre.com wrote: You can temporarely download the zip file here : http://download.pointcarre.com/mypaint/LibMyPaintDemo.zip Note that this is a very first attempt and I really need a lot of help to provide something useful for anyone who may use libmypaint ! And your advises are very welcome :-) Thanks. Looking though it, it seems that you based this code on an older version of libmypaint, before MyPaint 1.1? The API for fetch/update tile is a bit different now, in order to allow multithreading without locking. Also, you seem to have renamed every .c file to .cpp? Why? Some hints for the issues you have listed in the README and in the code. In order for caching and deferred processing to work correctly, you must call mypaint_surface_begin_atomic() before doing mypaint_brush_stroke_to(), and mypaint_surface_end_atomic() when done. With libmypaint 1.1 and git, nothing will happen if you don't as everything is done on end_atomic() To set color, convert RGB to HSV and do (values are float): mypaint_brush_set_base_value(brush, MYPAINT_BRUSH_SETTING_COLOR_H, h); mypaint_brush_set_base_value(brush, MYPAINT_BRUSH_SETTING_COLOR_S, s); mypaint_brush_set_base_value(brush, MYPAINT_BRUSH_SETTING_COLOR_V, v); All other brush settings, from dab size, hardness, opacity to speed filters and alpha-locking are manipulated the same way. Another thing is that the delta-time calculation should normally be done from the input events you get from your windowing system, to not be dependent on CPU load. But it seems Qt does not expose that!? Also, I _believe_ that the correct thing to do is to new_stroke() on button/tablet down to start a stroke, then reset() on button/tablet up to finish it. Martin, does that sound right? If so, perhaps we should rename reset() to end_stroke()? It was my intent that this code also would become ISC [...] I have now sent an email to all the copyright-holders of these files to check whether such relicensing is OK. This is good news because the 15 bpp format seems quite required to render correctly the dab (8 bits format shows a lot of posterization). So it make sense to provide a basic 15 bpp surface + the draw dab algorithm with the library. I'm quite sure I will rewrite it for my own purpose, but for the demo project it is cool ! Yes, at least one needs more than 8bpc. Floating point would also do fine of course. All in all, the renderer we have in MyPaint is pretty good and I think it would be great if others could just use that instead of having to implement their own. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Anatomy of brushlib/libmypaint for 1.1.0 (for the Debian packages)
On 8 January 2013 13:38, Andrew Chadwick a.t.chadw...@gmail.com wrote: Thanks for that useful braindump, Jon. Gives me a really good idea of intent of the lib. I've been discussing it on IRC - see the attached log. Advice from the Debian folks I've spoken to is to not ship a static binary build on the expectation that other packages will be able to build against it as part of their own binary builds. In summary, that is problematic because changes to the lib made by mypaint may require those other packages to perform additional binary uploads. Runtime support packages for such static blobs only serve to compound the issue. Such additional uploads are organizationally fiddly, and technically unnecessary in comparison to the same lib expressed as a dynamic library package with a declared ABI level reflected in the SONAME. Given the above, I won't be making libmypaint* packages which contain only a static .a and runtime support for it. Given the current ABI instability and lack of docs (and given that I don't want to be overambitious at first with my packaging!), I probably won't be making dynamic libmypaint* packages for the 1.1.x release, and I won't be doing so at first. Ok, sounds fair. Does not surprise me that Debian people would frown at this. :) On a strategy note, would it be possible for a future release to support both of the use-cases you identify by building two dynamic libraries? One for the minimal core, and one depending on it for the glib+GI+GEGL brew. It's certainly a lot nicer for Linux distributions to do it that way, which in turn may help the code gain popularity☺. Apps which require static linkage would still have the option of bundling, if that's a more normal thing to do on certain platforms. That is the rough idea. libmypaint is the minimal thing. libmypaint-gegl contains the GEGL backend. They have separate .so and pkg-config files, and paths for header files. GI adds separate .gir and .typelib for each of these libraries. There is one exception though. libmypaint.so will link against glib when built with GI support (and not when built without). As glib is a very common package, I cannot imagine (binary based) Linux distributions to mind this. To consumers of a pre-built package the dependency is not exposed in any way. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Anatomy of brushlib/libmypaint for 1.1.0 (for the Debian packages)
/glib though. PREFIX/share/mypaint/brushlib/__init__.py PREFIX/share/mypaint/brushlib/brushsettings.json PREFIX/share/mypaint/brushlib/brushsettings.py JSON definitions of the brush settings; a runtime requirement for using libmypaint, and a Python interface to it. Both could be used by apps other than MyPaint. I intend to package these and the .mo files below as libmypaint[-brushlib], describing it as an architecture-specific requirement for programs statically linked with libmypaint. Hope that's right. One does not need these to use libmypaint, the C interface provides information about brush settings (based on data generated from the .json file at build time). See mypaint-brush-settings.h (and -gen.h for the enums). In MyPaint we use brushsettings.py mostly because it gives a more convenient interface for use in Python. And we currently don't have access to the whole libmypaint API on Python level. Its shielded behind the C++ wrappers in lib/ The .json file is the canonical data source for brush settings though, so I think that should be available. Post MyPaint 1.1 we should it to PREFIX/share/libmypaint/ though. brushsettings.py I don't really want to promote as public interface. PREFIX/share/mypaint/brushlib/generate.py This file appears to be here in error, and I'll probably be removing it from the packages. It's used at compile time for constructing the -gen.h files, and that's it. If I understand recent changes in master correctly, it's being replaced by a scons Command. Yes, no need to install this file. The scons change only affects how the file is executed during build, so it will continue to exists and we should exclude it from install. PREFIX/share/locale/fr/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/id/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/ru/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/pt_BR/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/nn_NO/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/ro/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/en_CA/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/pl/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/it/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/cs/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/ja/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/zh_TW/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/zh_CN/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/sl/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/ko/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/uk/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/de/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/hu/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/sv/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/nb/LC_MESSAGES/libmypaint.mo PREFIX/share/locale/es/LC_MESSAGES/libmypaint.mo As described above: runtime requirements, packaged with the JSON stuff. GNU message catalogs appear to be endian-specific, so libmypaint[-brushlib] will be marked as architecture-specific for this reason and in expectation of a .so version, and whatever gir magic is needed. Sounds fair, though I don't know about the endianess issue. Debian people will probably. I believe Debian policy requires .gir files to be packaged separately. PREFIX/lib/pkgconfig/libmypaint.pc PREFIX/lib/libmypaint.a Compile-time requirement for programs statically linked with libmypaint[-brushlib], part of the -dev package. ACK -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] Bugtracker cleanup
Hi all, Andrew started cleaning up the bugtracker today, closing all bugs in 'Fixed' state that has been released with MyPaint 1.1. I then closed the vast majority of bugs in 'Wont Fix', 'Works for Me' and 'Ready for Test' state. I also got rid of several bugs that were in 'Need Info' state that had not been updated for a long time. This means that we are down to a total of 110 bugs. There are still many more bugs that we can, and probably should close. Here is a list of likely candidates, 36 items long right now. Please help go through these bugs. https://gna.org/bugs/index.php?go_report=Applygroup=mypaintfunc=browseset=custommsort=0report_id=101advsrch=1status_id[]=1resolution_id[]=3resolution_id[]=6resolution_id[]=10resolution_id[]=4resolution_id[]=8resolution_id[]=7resolution_id[]=2submitted_by[]=0assigned_to[]=0severity[]=0priority[]=0summary=details=sumORdet=0history_search=0history_field=0history_event=modifiedhistory_date_dayfd=5history_date_monthfd=1history_date_yearfd=2013chunksz=50spamscore=5boxoptionwanted=1#options -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] MyPaint 1.1.0 release candidate
On 23 December 2012 20:47, Martin Renold martin...@gmx.ch wrote: I made a release candidate, please help testing: http://download.gna.org/mypaint/mypaint-1.1.0-rc1.tar.bz2 Arch Linux users can use the mypaint-devel package from AUR to test the release candidate. https://aur.archlinux.org/packages/mypaint-devel/ The current plan is to release this on 28th December. Do we still have any major known bugs? Windows support is still known to be broken: http://opensourcepack.blogspot.ch/2012/12/a-peek-at-mypaint-on-windows.html On OSX as far as I know nobody has tried with the latest GTK2 fixes. I think there has been progress on Quartz tablet support in GTK. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] MyPaint Jenkins server up and running
Hi, we now have a Jenkins server for use by the MyPaint project, available at http://ci.mypaint.org/jenkins/ Right now it runs some basic builds of MyPaint/libmypaint in different configurations, and one job with our (heavy) tests. After some breakage and fixes today, these are now passing. In the future we may use it to do more things, like automatically building documentation from source, or creating binaries and developer environments for Windows and/or OSX. The server is running on Amazon EC2 using the Jenkins by Bitnami AMI, on a micro.t1 instance which I currently use for free. In addition to me, Martin and Andrew have access to the server. If you wish to improve how we test and deliver MyPaint, there is now a common place to work on that. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] MyPaint string freeze, translations for 1.1
Hi Manuel,
Using LANG=C should get you the original strings, as they appear in the
code.
On 8 December 2012 19:10, Manuel Quiñones ma...@laptop.org wrote:
What is the LANG parameter to get the original English strings in the
UI? This doesn't work for me:
LANG=en_US.utf8 ./mypaint
Althougth I see this line in the output:
DEBUG: getlocale(): ('en_US', 'UTF-8')
I'm trying to have two instances of MyPaint with two languages side by
side, to test my translation.
2012/12/8 Martin Renold martin...@gmx.ch:
There was a bug, brushlib translations were not displayed at all. The
problem is fixed now in git.
There was also an additional untranslatable string found (frame window
title). Please re-run scons translate=xx to get those.
Let me know if there still are problems left.
Regards
Martin
On Mon, Dec 03, 2012 at 08:03:12PM +0100, Martin Renold wrote:
hi
You are right, the 3 tooltips where not translatable.
I have pushed your translation to git, I have made the tooltips
translatable, and I have also run scons translate=it for you (runs
without
problem here, and produces slightly different output).
Will look at the brushlib string problem later.
Regards
Martin
On Mon, Dec 03, 2012 at 01:26:42PM +0100, Lamberto Tedaldi wrote:
Hi Martin,
here attached there are po file for Italian language.
There are troubles with various strings that are not translated at
runtime.
In main po file (mypaint/po/it.po) some tooltip strings are not
translated , Lines and Curves or Connected Lines tooltips for
example.
I suspect it depends from the fact they contains some line break
character in source code.
In brushlib po file (mypaint/brushlib/po/it.po) the problem seems
affect all short and long description strings of brush settings.
Is this due to an error when I run the command scons translate=it?
The command returns:
[cut]
cd .. ls *.{h,c} | sort po/POTFILES.in
ls: can't access to *.{h,c}: File or directory does not exist
intltool-update -g libmypaint --pot
intltool-update -g libmypaint it
intltool-update: libmypaint.pot does not exist.
scons: *** Error 2
[cut]
I'm using ubuntu 12.10 32bit python 2.7 and poedit 1.4.6 for working
on po files.
Best regards,
Lamberto Tedaldi
--
---
Officine Pixel S.n.c.
produzioni multimediali
via Ardenne 3 - 47100 Forlì
Tel. +39 (0)543 405035
Fax. +39 (0)543 409315
www.officinepixel.com
www.ffx.it
--
Martin Renold
___
Mypaint-discuss mailing list
Mypaint-discuss@gna.org
https://mail.gna.org/listinfo/mypaint-discuss
--
Martin Renold
___
Mypaint-discuss mailing list
Mypaint-discuss@gna.org
https://mail.gna.org/listinfo/mypaint-discuss
--
.. manuq ..
___
Mypaint-discuss mailing list
Mypaint-discuss@gna.org
https://mail.gna.org/listinfo/mypaint-discuss
--
Jon Nordby - www.jonnor.com
___
Mypaint-discuss mailing list
Mypaint-discuss@gna.org
https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Possible migration to github
On 21 November 2012 12:05, Andrew Chadwick a.t.chadw...@gmail.com wrote: On 21/11/12 02:59, Jon Nordby wrote: A question whether to migrate to github has come up a couple of times on irc now. == Should we migrate == I only have two issues with the current infrastructure we use: - GNA uses certificates which are not considered trusted by many web browsers. This scares off some people wanting to file bugs. That's a good reason to move away from Gna! to something friendlier. Major issue this. It's probably scaring off people trying to search for bugs too. - Gitorious has had fairly frequent outtages where pull/push is unreponsive. Annoying when it happens, but not by itself reason enough to change. What do you think about using github? Note that whatever the decision would be, we won't change anything before MyPaint 1.1 is out. Basically positive. If Martin's OK with it, and the faff is minimal, I'd have no objections. Ok, sounds good. == Managing missing fields in github issues == Github Issues does not have as many fields for a bug/issue as GNA. Instead it offers string-based labels/tags. The fields that we were somewhat using in gna that are missing are: Status, Severity, and Platform. We used status to implement a two-step fixed-closed workflow. Fixed when the fix is in git master, closed when released. In addition it is useful to mark triaged bugs with the outcome of the triage, either confirmed or need-info. Labels: fixed, need-info, confirmed How much of this can be achieved with milestones referring to past and future versions? we never really used the Gna! ones, but Github milestones seem flexible, can be annotated and renamed, have pretty completeness bars, and you can filter for issues which don't have one assigned yet. I've never much liked fixed+open as a concept. IMO a bug is either open or closed; it seems more expressive and documentary to assign open or closed bugs to a milestone reflective of current and past work focus. The meaning closed+future-version seems self-evident, particularly if future-version carries an obvious label. Fair point, milestones is perhaps a better way to deal with this on github. A github milestone is completed when all issues for that milestone is complete. So to prevent this from happening prematurely, we would create a Release MyPaint 1.2 bug which we would close when the release, and thus the milestone, is done. Could be a good place to discuss (and for people to follow) release-level things as well. You never know. We might even be able to drive short release cycles from weight of open bugs :) I would like shorter release cycles. Though I am not sure I know any other way to achieve them than for someone to continuously push for it. Which is always hard in a volunteer driven project as making releases is not the most fun thing there is. How can we make releases more fun? One thing would perhaps be to automate it more, so there is less manual hassle and it can be done quicker. For platform we already used [Windows] and similar tags in bug titles, possibly more so than the platform field. Labels: windows, osx, linux Seems good to me. Absence indicates any OS (as far as we know)? Yep. We have not used severity that much, except for separating out wishes from bugreports and indicate very serious issues. This is still useful I think. Labels: wish, crash, dataloss +annoyance, exception, feature... It's nice to be able to treat these things as freeform tags in a way, provided they can be used for prioritising things for upcoming releases. New labels can be added by anyone who is a collaborator. As far as I know that is the same as those that have commit access. Currently we have more people with bug edit status than people with git access, but we can probably give everyone who now has bug edit status commit access without any issues. == How to migrate == In such a migration all comments would be created with the username of the one running the import script. To work around this a comment could be posted on each comment/report about who originally created it, and link to the original content on gna. Would this be possible with a very clearly distinct github account? Yes, I'd create some user for just this purpose. mypaint-gna or somesuch. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] Fwd: Surface optimizations proposed for merging
Forwarding to list -- Forwarded message -- From: Popolon popo...@popolon.org Date: 21 November 2012 01:55 Subject: Re: [Mypaint-discuss] Surface optimizations proposed for merging To: Jon Nordby jono...@gmail.com I made some test with the last git version versus surface optimization version and here are the results in mycase (core i7 4core + hyperthreading ~8core)@3.7Ghz, no opencl support (no intel openCL driver on linux). I tested mosly the deevad brush : deevad/basic_digital_knife_**smudging). this seem to be the slower brush. In all case i growed at max the size of the brush by pressing several time [f] key. All brush are fluid in surface.optimizations version but the deevad/basic_digital_knife_**smudging. In most case this brush is very slow in standard version (perhaps 0.20 to 0.5 s lag). In surface optimization version, it seems to fluidly drawn, when the whole stroke is included in the portion of the canvas seen at screen, but suffer of big slow down every time the brush stroke go out of this area, perhaps simply because the whole surface stroked is bigger ? I made a video record with this brush, but it seems that's the record is not really in real time, probably a little bit accelerated ??? I used gtk-record-mydestkop for this screencast, if someone know a better option, I could make a newone. http://popolon.org/mypaint/**out_seems_accelerated.ogvhttp://popolon.org/mypaint/out_seems_accelerated.ogv I have some slowdown with deevad/watercolor_glazing, deevad/thin_watercolor and deevad/large_watercolor_fringe brushs too. Popolon Le 19/11/2012 13:11, Jon Nordby a écrit : On 18 November 2012 03:12, Jon Nordby jono...@gmail.com mailto:jono...@gmail.com wrote: I have some more ideas for further improve performance, and am working to document these now. Now documented in the surface-optimizations branch, file brushlib/PERFORMANCE: http://gitorious.org/mypaint/**mypaint/blobs/surface-** optimizations/brushlib/**PERFORMANCEhttp://gitorious.org/mypaint/mypaint/blobs/surface-optimizations/brushlib/PERFORMANCE Here are the main points: === TODO: Improve vectorization === === TODO: More efficient serial code === === TODO: Try different tile sizes === === IDEA: Dab masks cache === === IDEA: Make use of GPU processing: OpenCL and OpenGL === -- Jon Nordby - www.jonnor.com http://www.jonnor.com __**_ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/**mypaint-discusshttps://mail.gna.org/listinfo/mypaint-discuss -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Surface optimizations proposed for merging
If there are no objections I will merge the surface-optizations branch to master tomorrow or Friday. The performance improvements are pretty well documented by now, and it has at least got some testing from other people than me. Till found a minor issue in the brushlib tests, and Martin one when using it a bit differently from how we do in MyPaint. I will fix those. Any other issues will be best tested and ironed out in master I think. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Surface optimizations proposed for merging
On 21 November 2012 20:25, Martin Renold martin...@gmx.ch wrote: No objections from me. Better merge it soon so it gets more testing. There is quite some new C code. If there is a bug hiding we may see a crash while painting, not just an exception dialog. Merged. People: test the hell out of it! -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] Possible migration to github
A question whether to migrate to github has come up a couple of times on irc now. == Should we migrate == I only have two issues with the current infrastructure we use: - GNA uses certificates which are not considered trusted by many web browsers. This scares off some people wanting to file bugs. - Gitorious has had fairly frequent outtages where pull/push is unreponsive. A nice thing in Github is the tighter integration between commits, pull requests and issues. When someone refers to something from a commit, issue or pull request, comments will be automatically posted on the thing referred to - establishing two-way links. Currently we've been trying to do that manually. Other useful projects are also integrating with Github and its APIs. An example here is Travis CI, a free hosted continuous integration service for open source projects. But mostly benefits of may come from non-technical aspects: Github is popular. Many more people have, or are willing to create and use github accounts, compared to gitorious and gna. This _may_ lead to an increase in contributions, both on bug-reporting and code. What do you think about using github? Note that whatever the decision would be, we won't change anything before MyPaint 1.1 is out. == Managing missing fields in github issues == Github Issues does not have as many fields for a bug/issue as GNA. Instead it offers string-based labels/tags. The fields that we were somewhat using in gna that are missing are: Status, Severity, and Platform. We used status to implement a two-step fixed-closed workflow. Fixed when the fix is in git master, closed when released. In addition it is useful to mark triaged bugs with the outcome of the triage, either confirmed or need-info. Labels: fixed, need-info, confirmed For platform we already used [Windows] and similar tags in bug titles, possibly more so than the platform field. Labels: windows, osx, linux We have not used severity that much, except for separating out wishes from bugreports and indicate very serious issues. This is still useful I think. Labels: wish, crash, dataloss == How to migrate == Moving the git repository over is of course no issue. That would just require updating URLs in documentation and configurations. Migrating the bugreports would be a bit more work, but is not at all that difficult. GNA offers an XML export for the database*, and GitHub offers an HTTP API for Issues. Based on this I've hacked up a prototype script for automatic migration. Currently it can extract most of the relevant info, and format this as github API requests (though not actually send them yet). Branch gna2github on my personal repo: http://gitorious.org/~jonnor/mypaint/jonnors-clone/commits/gna2github In such a migration all comments would be created with the username of the one running the import script. To work around this a comment could be posted on each comment/report about who originally created it, and link to the original content on gna. I would suggest that we only migrate open bugs, and do this after we have cleaned up the tracker and closed as much as possible. This should leave us with around 100 bugs (just closing fixed and similar would bring us to 130). After a successful migration we would close the bugs on gna.org with a link to the migrated bug on github.com. * Currently it has some invalid UTF8 characters, but the data is still usable with some massaging. Reported here: http://gna.org/support/?2982 -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Surface optimizations proposed for merging
On 18 November 2012 03:12, Jon Nordby jono...@gmail.com wrote: * After the changes, GEGL-based backend is circa 30% faster than the Python-based backend with 1 thread, and twice as fast with 2 threads. A quad-core CPU with 4 threads will have an even higher speedup. Till tested the code on a 6 core AMD Phenom II. It shows that in these raw performance tests, the GEGL based backend is up to 3-4 times as fast as the Python one with 6 threads. http://www.jonnor.com/files/temp/mypaint-brushengine-opt-gegl-vs-py.png http://www.jonnor.com/files/temp/mypaint-brushengine-opt-gegl-vs-py.txt -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Surface optimizations proposed for merging
On 18 November 2012 03:12, Jon Nordby jono...@gmail.com wrote: I have some more ideas for further improve performance, and am working to document these now. Now documented in the surface-optimizations branch, file brushlib/PERFORMANCE: http://gitorious.org/mypaint/mypaint/blobs/surface-optimizations/brushlib/PERFORMANCE Here are the main points: === TODO: Improve vectorization === === TODO: More efficient serial code === === TODO: Try different tile sizes === === IDEA: Dab masks cache === === IDEA: Make use of GPU processing: OpenCL and OpenGL === -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] Surface optimizations proposed for merging
Hi all, I finished the last missing pieces of the surface optimization I started a while back. The changes are not that invasive but it could use some real-life testing before going into master. If no issues are found I'd like for it to be a part of MyPaint 1.1 release. The code is found in the surface-optimizations on mainline repository: http://gitorious.org/mypaint/mypaint/commits/surface-optimizations Please test! (checkout branch, build and run mypaint as normal) == Changes == The optimizations follow a three-pronged strategy: 1. Reordering of data access to minimize fetching and updating of tiles. 2. Coarse grained parallelism using multithreading via OpenMP directives. 3. Fine grained parallelism using SSE via GCC auto-vectorization. The MyPaint surface API has a concept of an atomic transaction: surface.begin_atomic() and surface.end_atomic(). Inside such a transaction, we call brush.stroke_to(surface, ...) each time there is a motion event on the canvas. Depending on the brush configuration and current state this may result in 0 to N surface.draw_dab() calls. N can be in the order of 10-100. Previously each draw_dab() call would fetch the affected tiles, process the draw_dab operation and update the tiles with the results. When subsequent draw_dab() calls affect the same tiles, fetching and updating of tiles would happen up to N-1 times as often as is needed. Now, each time draw_dab() is called, an operation struct is added to a queue for each of the affected tiles before returning. No processing is done at this point. When end_atomic() is called to complete the transaction, the tiles that have pending operations are distributed evenly among the processing threads. The processing of a tile is completely independent of other tiles, allowing it to be done in a lock-free manner. When a get_color() request is made by the brush engine during a surface transaction, the pending draw_dab operations on the affected tiles must be flushed to return the correct value. Both the flushing and calculation of the color is done multi-threaded in the same way as above. Within each thread, SSE based vectorization is used to process a tile. Currently this is limited to part of the brush mask calculation, as the run-length encoding of the masks makes it difficult to auto-vectorize all of the mask calculation and the blending/compositing. == Results == These results are on from my laptop, running Arch Linux current. CPU: Dual-core Intel i5 M520@2.4 GHz, 6GB RAM Note: this benchmarks the *raw* surface rendering performance. The user *may* experience speed-ups similar to what is shown here, but this is is only if layer compositing and rendering to screen is not a bottleneck. http://jonnor.com/files/temp/mypaint-brushengine-opt.png http://jonnor.com/files/temp/mypaint-brushengine-opt.txt Take-aways: * 20% to 50% performance improvements for larger brushes (16 px+) on the currently used Python-based backend. * Performance does not regress significantly for small brushes, max -4% degradation found. * After the changes, GEGL-based backend is circa 30% faster than the Python-based backend with 1 thread, and twice as fast with 2 threads. A quad-core CPU with 4 threads will have an even higher speedup. To reproduce: scons enable_gegl=true enable_openmp=true # to enable GEGL backend, requires babl+gegl git cd brushlib/tests export PYTHONPATH=../../lib:../.. export LD_LIBRARY_PATH=../.. export GEGL_SWAP=RAM export OMP_NUM_THREADS=2 ../../lib/test-python-surface # current python-based backend ./test-gegl-surface # GEGL backend Look inside mypaint-test-surface.c to see/change the different test cases. == Future == Given that the GEGL backend has a significantly higher raw performance, I hope that after we release MyPaint 1.1 we can start the transition to use it instead of our current backend. I have some more ideas for further improve performance, and am working to document these now. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] planning release 1.1.0
On 25 October 2012 19:55, Martin Renold martin...@gmx.ch wrote: There are 158 bug reports open that aren't marked as fixed. It frustrates me that I didn't contribute more time to fix more of them. But there is no reason to hold back all the good work that has been done. After the release I propose that we close all bugs that are marked fixed, won't fix, works-for-me, ready-for-test. Currently this is a massive 104 bugs: https://gna.org/bugs/index.php?go_report=Applygroup=mypaintfunc=browseset=custommsort=0report_id=101advsrch=1status_id[]=1resolution_id[]=1resolution_id[]=3resolution_id[]=6resolution_id[]=10resolution_id[]=7resolution_id[]=2submitted_by[]=0assigned_to[]=0severity[]=0priority[]=0summary=details=sumORdet=0history_search=0history_field=0history_event=modifiedhistory_date_dayfd=11history_date_monthfd=11history_date_yearfd=2012chunksz=150spamscore=5boxoptionwanted=1#options -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Planning a MyPain bugfix hackathon
On 28 October 2012 01:28, spin s...@hackerspace.pl wrote: On 10/28/2012 00:41, Jon Nordby wrote: One bug-related suggestion. How about doing bug-triaging during the hackathon? This is an activity which in my experience scales very well with more people involved, and is easy to get into also for those that are new to the project and/or technologies (toolkit, programming language etc). It is not exactly the sexiest task, but having a clean bug-tracker really helps with the productivity (and motivation) of developers and new contributors. Hey Jon, This is a great suggestion! I will consider doing bugtracking depending on the amount of people participating and the direction the event will take, as it's still in preparation. I'll consult it around with people in the hackerspace as well. I want to do at least two of these events, and I expect about 60% of participants covering both, so getting them to know their way around the code on the first occasion would be great. On the other side, I want to have a few harder tasks on the ready, because some people may lose motivation over simple bugtrack choring (and their resources would be suboptimally allocated as well). I'll go through my personal TODO and bugtracker to see what I can find. Regarding presence, it should be possible online - we have an IRC channel (irc.freenode.net #hackerspace-pl), and we'll set up an etherpad for the event. Getting a voip with video stream should be possible as well, if needed. If you or any other developer would want to participate online, that would be great, since you know your way around the code, and will be able to answer questions that may otherwise take considerable amounts of time. I will be present online to help you out, if the time fits. I would request that we use #mypaint IRC channel though, as many of the questions/answers/topics will probably be of interest to the people that are already there. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Using brushlib in Blender
The email went off-list, so I am quoting it in full here. On 26 May 2012 01:31, Nicholas Bishop nicholasbis...@gmail.com wrote: The overall goal of this is to make it easy for projects to use the MyPaint brush engine without having to fork the code (copy into project and change). And that when using the brush engine, they can use exactly the same brushes as MyPaint. I don't want a situation where there is Blender MyPaint brushes, GIMP MyPaint brushes and MyPaint MyPaint brushes... In particular, transitioning to the JSON file format and accompanying load/save code? I am busy this weekend, so the target for that is middle to late next week. I think we need to do this in the brushlib to achieve the overall goal. I don't think relying on all consumer of the brushlib to correctly read/write settings files (including handling newer and older versions compared to) is a good idea. The things that are not necessary for compatibility can be handled on a higher level. I will however not implement JSON parsing from scratch, so this means a libjson dependency (or similar). That all sounds good to me. Libjson is probably fine to add as a dependency for Blender. * Will brushlib keep its dependency on glib? The use of glib seems to have spread a bit, it's not just using it for g_rand but also types and macros. For Blender we probably don't want to depend on glib, but for now it shouldn't be too hard to patch it locally to work around that. If brushlib starts using glib more extensively that could be a problem though. Is there any interest in using regular C types rather than glib's (e.g. replacing gboolean with int), or wrapping the glib-specific parts in '#ifdef WITH_GLIB' or equivalent? If you really don't accept glib as a dependency, we would have to solve that of course (and without you having to patch it). I can't state with absolute certainty that we wouldn't ever accept glib as a dep, but it's unlikely if its only usage in Blender would be for the brushlib. These are my worries for removing the use of glib, and my motivation for continuing the use of it: * Unicode/UTF-8 string, file and path handling. Mainly relevant for the brush setting handling. This is yet to be written, so I don't know how difficult/tedious it will be without glib. Perhaps these could be just function pointers and the parent application provides the implementation? Blender has its own internal file and string code, and this could work well for replacing the g_rand() stuff too. -Nicholas The JSON load/save handling is now basically done (see separate mail thread). I decided to punt on the file handling issues. libmypaint will only do serialization/deserialization of JSON, read/write to files is left to the applications. So no problem doing that without glib. I also added the gobject introspection based bindings build. Getting rid of glib while still letting that work looks to be easy as well. We will have to copy the gboolean and guint16 typedefs to keep the interface C89 compatible and for the binding scanner to understand it, but that is no problem. The g_rand usage will be replaced with a suitable PRNG implementation. There looks to be several available under liberal licenses that can be dropped in. One from D.Knuth for instance. So when I have time next week, the library should be able to build without glib. If you have time to test if there are any other issues for you using it in Blender before then, that would be much appreciated. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] RFC: JSON format for MyPaint brushes, handling load/save in libmypaint
attributes: not a good idea IMO. New brushes are usually created by modifying an existing brush and then saving it under a new name, which I assume would copy all unknown attributes. So if you have an application that doesn't know the License attribute your new brush has the same License as the old brush, even if you completely changed all settings. Same problem with metadata like modification date or application name or even parent brush name. IMO better only save attributes when you know what they mean, and drop unknown attributes when loading. (Unless they are somehow marked or known as safe to roundtrip.) The point about preserving unknown attributes is just for libmypaint when using the JSON persistence functionality (from_string/to_string). The important thing is to not enforce policy. When an application using libmypaint does a add as new brush or save as new action it may be reasonable to strip all unknown attributes (as you mention). The application is free to do that. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] RFC: JSON format for MyPaint brushes, handling load/save in libmypaint
Hi all, as has been discussed on and off a bit, it would be nice to move to JSON for storing the MyPaint brushes. This should make easier for alternative brush engine implementations (like the Javascript + HTML5 one) to reuse the brushes. In addition I propose to move load/save into libmypaint (currently called brushlib). This is so that anyone using libmypaint are guaranteed to be able to correctly load and save MyPaint brushes correctly. == Data format == The data format is based on JSON, as defined in RFC4627 (http://tools.ietf.org/html/rfc4627). Files saved to disk shall have the extension .myb, like before. The file contents shall be stored UTF-8 encoded. See the attached example for exact format (pretty printed). An open question is whether to change the individual setting format to be a dict with base_value and inputs instead of the current list. That would be a bit more explicit/readable? == Extensibility == New top-level key, value pairs may be added by applications. Application specific attributes must have the prefix x_$appname_. Standardized attributes, as defined by libmypaint/MyPaint must not use an x_ prefix. The currently standardized attributes are version, comment, settings and parent_brush_name. An open question is whether parent_brush_name is considered MyPaint specific? Metadata that may be interesting to add in the future includes: - Brush preview/icon (as base64 encoded PNG for instance) - Name/email of creator - Description - Creation and modification date == Compatibility == - Brushes with old format will work in MyPaint, and be automatically migrated (backwards compatible) - Older MyPaint versions will not be able to open this new format (not forward compatible) - libmypaint will only be able to open this new format, not older. == libmypaint API == The proposed API for libmypaint is: void mypaint_brush_from_string(const char *); const char * mypaint_brush_to_string(); A roundtrip between these is guaranteed to preserve any non-recognized top-level attributes (application defined). This allows applications making use of libmypaint that wish to add or modify the additional metadata to do this by interpreting the JSON string before passing it on. Storing the brushes to disk is the responsibility of the application using libmypaint. == Implementation plan == 1. Add code to migrate to new format to MyPaint. 2. Migrate all the brushes shipped with MyPaint to new format. 3. Add code to libmypaint to load/save the setting brushes in new format 4. Document the format, as part of libmypaint 5. Use the libmypaint load/save code in MyPaint Any comments welcomed! Unless there are major objections I hope to complete this the next week or so. slow_ink.myb Description: Binary data ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] My Paint, request for an Open Source interview
), but major benefits for a few (which might then go on to praise the decision). Again thank you for your help, and I will make sure to send you the end paper if that is what you wish. Morgan Daley Cool, thanks! -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] My Paint, request for an Open Source interview
for a while: direct and informal interactions between core people in the organization/project and its consumers/users. So maybe we were there already? Thank you for your help with this project. You are welcome. If you write a paper, do a presentation, or blog about it, I'd love to read/see it! -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] DragonSphere a macos lion fork for mypaint (maybe ios too)
2011/11/7 dimitris chloupis theki...@yahoo.co.uk: Απο: Jon Nordby jono...@gmail.com We will port to PyGObject and GTK3. PyGObject + GTK introspection bindings are in many cases very similar to pyGTK, so it will not be a complete rewrite, but small changes will be required all over the code base. This will probably happen after 1.0 is out, which should be pretty soon. Thats a great amazing move and I fully support it but there are 2 things bugging me 1) The soon part. How exactly very similar is the porting really , sure I could help with the port too, but I have my doubts here that will be that easy. Soon referred to how quickly we can start. How quickly we can complete depends mostly on how much people work on it ;) It will definitely be much easier than writing a new UI, or writing the same UI in another toolkit. It is still GTK+, and basically all widgets work in the same way as before. Changes are mostly in syntax, and a script exist to take care of those changes. Of course some things that were deprecated have been removed (but I don't think we are affected by that), and some things are now slightly different. It will not be very hard, but it is of course still a significant amount of work. 2) And this is the MOST important, can we really be sure that GTK3 will work stabily on macos ? GUIs on macos have always being an issue, because Apple has provided such a very good gui that people prefer to use objective c and now with the ability to port easily to iOS , its quite rare to find a mac app that does not use native libraries. So many GUIs on macos are very neglected and that is a big understatement ;) No, we have zero guarantees. But the only way to find out how well it works, and if it is good enough is to try. We would love help with MyPaint, especially on OSX. There is some effort going on on providing a MyPaint.app, and this alone would be a big step forward for MyPaint on this platform. Once we are ready to start GTK3 porting work you can help out a lot there. The build you provide in the website does not even run. It complain , fairly, but missing python. I would love to help but I am clueless of objective C and C in general and compilers of course. Yes, another contributor found the same and seems to be working on fixing it. UnconventionalT_ on irc. Maybe talk to him if you want to help out. Just testing it on a different machine might be useful. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] The Future of MyPaint on Windows
On 10 October 2011 13:11, Mihai Cozma mihai.co...@gmail.com wrote: Also (warning: open source development newbie question): When will your patch and BenJackson's patch (if it is the real answer to the problem) will be committed to the 2.24 branch of gtk+? Do you have to submit them first, or you will wait until the whole bug is fixed, or how does these things work? For Gnome patches can generally be considered to be submitted when they are attached to a bug in bugzilla. The patches getting in requires one of the gtk+ maintainers to have a look at it. This often requires some prodding (maintainers nearly always have too much to do). Typical way to escalate is to bring the issue up on the mailing list, mentioning that the bug has patches solving the problem or parts of it. Having a personal contact or two always helps. Michael Natterer (mitch) in the GIMP project is a gtk+ dev that I know care about this issue, but I'm not sure if he does Windows at all. But if not he would likely know who to poke, so consider talking to him if no-one looks at the patches. For trivial and obvious fixes I can commit it if no-one else responds (I have commit rights, but I'm not a gtk+ dev). -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] The Future of MyPaint on Windows
On 9 October 2011 12:39, Mihai Cozma mihai.co...@gmail.com wrote: Hi, Hi! While I'm quite happy with my linux installation where I can use the latest version of my paint, the wacom support for their tablets in linux is quite poor. Another issue is that I have to reboot my machine from Windows into linux every time I want to paint something, then switch back for other tasks. Yesterday I've tried to use a linux virtual machine on Windows (both with Oracle Virtualbox and vmWare Player), and I had basically no 2D acceleration and when I've tried to enable the tablet device on them, one crashed and the other made no difference between the tablet and a simple mouse. All of this kind of points out that I should stick to Windows where Wacom support is best and where I do all my other stuff (programming, playing games, etc) except painting.However, because of some Gtk issues (which should be a portable library), the latest development version of MyPaint is not available on Windows and hasn't been for quite a while now. I also heard that the build on Mac OS has some issues too. Question is: is there any future for MyPaint on other platforms than linux? The latest stable version of MyPaint works pretty OK on Windows does it not? I don't think it is a requirement that the development version is available for end-users on all platforms. We currently have a problem that we don't release stable versions often enough (in my opinion), but that is not platform specific. The way I see it, there are two solutions to this problem: 1. Switch to other library from GTK, one which works better on all target platforms. 2. Completely separate the GUI layer from the engine (which I think it is already happening) and use/maintain platform specific implementations for the GUI, that would assure maximum compatibility with their specific platform. What do you think about it? You are missing one obvious solution: Fix GTK+, at least the parts that MyPaint cares about. In any case, I think you are missing the point. The problem with non GNU/Linux platforms and MyPaint is not the UI toolkit used. The problem is that there is very little developer activity on getting it to work well on those platforms. Switching to a different toolkit or creating platform specific UIs will not solve that problem (the latter would just make it worse). We simply need more people working on MyPaint+Windows and MyPaint+OSX. You care about MyPaint+Windows and do programming. Are you in? -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] The Future of MyPaint on Windows
On 10 October 2011 00:43, Mihai Cozma mihai.co...@gmail.com wrote: Thanks for the reply, useful links. I also found the next text there: The plan seems to wait GTK 3.x become stable for win32 which takes sometime which ultimately invalidate this instruction as we will go with PyGI instead of PyGTK which is also another problem because GI isn't ported to win32 yet. That's the pity situation for mypaint win32. So based on this information, is there any point in trying to fix bugs and stuff, or we just have to wait until GI gets ported to windows and gtk 3 is stable for windows and so on? I mean, would all the work done trying to fix the problem in 2.24 get obsolete by the time GTK 3.x and this GI gets used? Fixing the critical/blocking issues in GTK 2.x on Windows is very valuable still. Porting MyPaint to PyGI and GTK 3.x will likely not happen for the next release. Meaning that without GTK 2.x fixed it will be some additional months _after_ we get the next release out before Windows will get the new stuff. There are other projects that will benefit from having GTK 2.24 fixed as well. GIMP 2.8 is another release that is also blocking on this/these tablet bugs. And, I would not be totally surprised if fixes are also applicable to GTK 3.x -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] Fwd: MyPaint and GtkBuilder/Glade
Opps, my reponse went off-list. -- Forwarded message -- From: Jon Nordby jono...@gmail.com Date: 18 September 2011 21:18 Subject: Re: [Mypaint-discuss] MyPaint and GtkBuilder/Glade To: Andrew Chadwick a.t.chadw...@gmail.com On 18 September 2011 19:51, Andrew Chadwick a.t.chadw...@gmail.com wrote: With the fact that glade 3.8 is the last stable gtk2-supporting version of glade, and glade 3.10 is the first stable gtk3, we may want to move on gtk3 support sooner rather than later. Maxy, Jon: what do you think? We need to release what we have now before we start on such. But apart from that, sooner is fine by me. -- Jon Nordby - www.jonnor.com -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] This link is new PsdToOra and OraToPsd.
Please use reply-to-all when responding to the email, as I have CC'ed
the mypaint mailinglist. This is so that others can also follow the
conversation.
On 7 March 2011 09:58, point_b hotmail.com poin...@hotmail.com wrote:
To Jon
Hi,and thanks for your mail.
I'm sorry...
I succeeded in operating my program without mbcs.
But I failed to operate a program without UTF-8.
This link is new PsdToOra and OraToPsd.
http://www.hmx-12.net/nazk/hiyuu/hiyuu.zip
OraToPsd.py is in hiyuu/OraToPsd7/dist
PsdToOra.py is in hiyuu/PsdToOra7/dist
- There is no license specified. You need to decide on a license. GPL,
LGPL, BSD?
I think it to be good with a license same as MyPaint
What is the license of MyPaint?
MyPaint is mostly GPLv2+ but the brushlib is LGPLv2.1+.
However, I do not think we should include this in MyPaint itself, so
you are free to chose whatever license you want.
This is for two reasons: 1) I do not see why we should support PSD
format. If we want to fix interoperation with Photoshop, a OpenRaster
handler for Photoshop should be written (I will do that if someone
sponsors me a license). 2) The code quality is not good enough, I am
having huge troubles understanding what the code does in some places
and that is a maintainance burden I do not want.
- OraToPsd seems to work.
But the image is uncompressed? (a 50KB .ora turned into a 5.9MB .psd
file).
Yes, the image is uncompressed.
Because it was the second to make a program, I was not able to do it to RLE
compression.
Also, the temporary file was not deleted.
I'm sorry...
Please tyr new OraToPsd.py in hiyuu/OraToPsd7/dist
No reason to be sorry, bugs happen :)
- PsdToOra for me fails with:
[hiyuu]$ python2 PsdToOra7/source/PsdToOra.py ~jon/MyPaint/scrap001_b.psd
PsdToOra開始
PSDデータ取得開始
Traceback (most recent call last):
File PsdToOra7/source/PsdToOra.py, line 314, in module
image.save(os.path.join(psddir,henkan,data,layername[s] + .png))
File /usr/lib/python2.7/site-packages/PIL/Image.py, line 1433, in save
fp = __builtin__.open(fp, wb)
IOError: [Errno 2] No such file or directory:
'PsdToOra7/source/henkan/data/background.png'
This is because the directory is not created. After creating the
directory, I get:
Please tyr new PsdToOra.py in hiyuu/PsdToOra7/dist
[hiyuu]$ mkdir -p PsdToOra7/source/henkan/data
[hiyuu]$ python2 PsdToOra7/source/PsdToOra.py ~jon/MyPaint/scrap001_b.psd
PsdToOra開始
PSDデータ取得開始
Traceback (most recent call last):
File PsdToOra7/source/PsdToOra.py, line 390, in module
enc_path = zippathfile.encode('mbcs')
LookupError: unknown encoding: mbcs
Here the problem is that mbcs does not exist on non-Windows systems. A
bigger problem is that filenames written to .ora files _must_ be UTF-8
encoded, it cannot depend on the system encoding.
Um...mbcs(Multibyte Character Set) and UTF-8...
Because only Japanese used it, I thought
I succeeded in operating a program without MBCS.
But I failed to operate a program without UTF-8.
***
Tategaki
--
Jon Nordby - www.jonnor.com
___
Mypaint-discuss mailing list
Mypaint-discuss@gna.org
https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Licensing policy: a proposal
On 7 March 2011 14:17, Andrew Chadwick (email lists) andrewc-email-li...@piffle.org wrote: We should write down some simple policy for which licenses we accept into the MyPaint main distribution, primarily to keep things simple for coders and artists. What about the following, expressed in FAQ style? --8 DRAFT NOT OFFICIAL * DRAFT NOT OFFICIAL * DRAFT NOT OFFICIAL Q: What licenses should I use when contributing to MyPaint? A: If you want your contribution to go into the official MyPaint distribution, you need to pick a license: 1. All program code and supplemental data files should be GPLv2[1] or LGPL. This includes program icons and artwork for display within the program. 2. Supplemental artworks and promotional material included in the distribution should be CC-Zero, CC-By, or CC-By-SA, version 3 [2]. 3. Elements which are highly likely to be reused by artists in the creation of new works[3], e.g. bundled brushes[4] or background texture images, should be licensed as CC-Zero or Public Domain. You'll get attribution in the official distribution, of course :) DRAFT NOT OFFICIAL * DRAFT NOT OFFICIAL * DRAFT NOT OFFICIAL ---8--- Please pick apart point by point. The final tone should be friendly and not too lawyery :) I agree. However, point 1. should be GPLv2+ / LGPLv2+ (that is, the license must have the or (at your option) any later version. clause intact). This is the license used for existing code, and allows downstream recipients to chose under which version of license they want to distribute the work, and allow us to move to GPLv3+, if we would like to. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] MyPaint 0.9.1 released
On 5 March 2011 14:58, Popolon popo...@popolon.org wrote: Ho, the french translation I sent to the list on 17/02/2011 was not comitted to the master :(. You are right. Fixed now. :) -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] MyPaint 0.9.1 released
On 5 March 2011 11:22, Martin Renold martin...@gmx.ch wrote: MyPaint 0.9.1 is released. This is a bugfix release without any new features. Several problems with non-ASCII file names, directory names, and layer names have been fixed, as well as a number of other minor issues. Integration with the Windows platform has been improved Good stuff. I believe a number of the open bugs we have in fixed state can be closed now? -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Regarding public IRC logs
On 18 February 2011 18:34, Martin Renold martin...@gmx.ch wrote: The IRC log has been down for several months now. We could ask http://irclogs.jackgrigg.com/ or someone else to add #mypaint. I will miss the robots.txt gently telling search engine not to index the logs. But I think we can live with that. Any objections, or any plans to fix the existing logger? If not I'll do it. Yeah, sorry about that. I'd prefer to just use a service like the one you link to. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Desktop file translations
On 15 February 2011 23:07, Andrew Chadwick (list subscriptions) andrewc-email-li...@piffle.org wrote: The desktop file MyPaint uses for KDE and GNOME desktops needs translating into the various languages we support. I also thought the old from scratch wording sounded a bit awkward and off-putting to new users. I've asked around on IRC about some updated wording, and I think we're good to go with Name=MyPaint Comment=Painting program for digital artists GenericName=Raster Graphics Editor Thanks for fixing this up. I'd give you the Norwegian Bokmål strings, but our faithful Norwegian Nynorsk translator did them before I got to it! -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Norwegian Nynorsk translation updates
On 16 February 2011 20:22, Tor Egil Hoftun Kvæstad toregi...@hotmail.com wrote: Hello I've updated the Norwegian Nynorsk translation, and added Norwegian comments to the desktop file (nn_NO and nb_NO). Committed! Thanks for your continued contributions. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Branch dockable-panels: call for review
On 17 February 2011 23:20, Andrew Chadwick (list subscriptions) andrewc-email-li...@piffle.org wrote: Could I canvass people's opinion and review on the dockable-panels branch in the main git repo? If it's not too broken or weird, I'd like to rebase it into master before the next major release (i.e. after 0.9.1). Probably needs some fixups first though... As I said in the forum and on the mailing list I think this change is really useful. But there are some issues. First of all, the license of gui/layout.py is set to GPLv3. MyPaint, is GPLv2+ (LGPLv2+ for brushlib). While not incompatible, this would require us to distribute MyPaint under GPLv3, effectively a license change for downstream recipients. I would really like to avoid that, so please change the license to GPLv2 (and use the standard MyPaint license header). Also, a big change like this is impossible to review properly when delivered in essentially one huge commit. I'll therefore only comment on superficial things regarding the code. Please split the commit into several smaller pieces so we can review properly, and squash in fixup commits. Code - Several hundred lines of code is duplicated in layerswindow.py. We can't have that. - Moving MainWindow from windowing.py to layout.py looks to be unnecessary, - I do not see the benefit of instantiating the menu-bar, et.c from MainWindow, instead of just letting it happen within DrawingWindow like before - There is no status-bar at the moment, why does the code have logic for it? - There is dead code (commented out) several places that needs to be removed. - I'm fairly certain it was not necessary to instantiate the backgroundWindow or brushSettingsWindow before, please check this Regressions - Main window does not obey window manager, is set to floating, maximized by default - Subwindows defaults to minimum size instead of something sane - Subwindows no longer show up in front of main window Strange behavior - When scaling the sidebar, the canvas follows somewhat, but not completely. Same when toggling the sidebar - Gtk color selector resizing behaves strangely (as you noted). Because of this the default color selector is colorsampler Please fix this so that we can keep the Gtk one as default. -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] MyPaints oldest bug, fixed?
I've updated https://gna.org/bugs/index.php?9099 with a minimally useful, working implementation of a frame. Please review/test. If there are no issues I'll push it to mainline in a couple of days. Open questions about this feature: What should it be called? Document/image/canvas frame/border? Should it be somewhere else in the menues than now? Should we use another way to move the frame than now? -- Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] Got mypaint.org
Got an email notification that mypaint.org was available and registered it right away. For now I will set it up as a redirect to mypaint.info, but as .org is much nicer than .info we should, in my opinion, consider swapping. -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] planning a 0.9.1 release
On 4 February 2011 00:36, Martin Renold martin...@gmx.ch wrote: I'm starting to get somewhat annoyed by reports/requests of stuff that is fixed in git. Let's make a new release! We also have one data loss bug fixed (bug #17536). It happens only together with GIMP; we should really get the fix out. I think git master is in good shape to make a full release, rather than just backporting the critical bugfixes. The behavior changes in device and brush selection handling is fairly big, but if you think it is good then lets go for it. This means we need a short string-freeze, and go through the buglist once again, and test a bit more. Is that okay with everyone? Are we ready for string-freeze now already? Anyone got changes in the making that we should wait for? Nothing from me. Speaking about data loss, this bug would be a nice fix, too: https://gna.org/bugs/?17473 Do we have consensus on how to solve this? I've already stated my opinion in the matter, but do note that resolving it in that matter would be a (again) fairly significant behavior change. -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] current git version stopped working? Issue with try-except-finally in WindowManager class.
On 28 December 2010 15:08, Andrzej Giniewicz ggi...@gmail.com wrote: Hi, I wonder if it's my setup or not, but as of 1704779f6bd2f973b095a5bbdbd7a413f58e8910 (windowing: Move code to new WindowManager class.) MyPaint stopped working on fresh config. It fails like this: Thanks a lot for quick testing and the patch! Since f only needs to be closed if it has succesfully opened and thus did not raise IOError, I pushed a fix which puts f.close() inside the try statement. -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] current git version stopped working? Issue with try-except-finally in WindowManager class.
On 28 December 2010 19:02, Andrzej Giniewicz ggi...@gmail.com wrote: Anyway, I noticed one more issue I had fixed on my copy for some time (it's setup thing again, Python3 is default on my OS), today I found out how to fix it in right way. Thanks, applied unchanged and pushed! I've actually seen this for a while (I'm running Arch as well) but I've been too lazy to fix it. -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] current git version stopped working? Issue with try-except-finally in WindowManager class.
On 28 December 2010 21:28, Andrzej Giniewicz ggi...@gmail.com wrote: On Tue, Dec 28, 2010 at 8:58 PM, Jon Nordby jono...@gmail.com wrote: Thanks, applied unchanged and pushed! I've actually seen this for a while (I'm running Arch as well) but I've been too lazy to fix it. Cool, now it builds, runs and all tests pass on fresh install on Arch, yay! (well, kind of - the test_*.py file have to be changed from python to python2 to run, but it is unrelated to mypaint itself). Anyway, I wondered if/when you will guess that it's on Arch, seems not many distros switched to Py3K yet, heh? No, and I don't expect anyone else will follow anytime soon. Probably not in 2011. Lonely are the brave ;) I believe now you can also remove the python2.patch from the mypaint-git package you maintain there? I'd write it under mypaint-git AUR page, but I'm lazy too, and not logged in there at the moment :P Thanks for the reminder, done now. This also reminds me that there is more stuff that should be fixed in our build system. We are running some stuff directly in the sconscript/sconstruct, instead of creating targets like we should: scons: Reading SConscript files ... Building for python2.7 swig -o mypaintlib_wrap.cpp -noproxydel -python -c++ mypaintlib.i python2.7 generate.py Writing brushsettings.hpp scons: done reading SConscript files. scons: Building targets ... The code that makes that output between the scons: ... lines should actually be executed after building targets. -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] ora2png
On 9 December 2010 01:13, David Gowers (kampu) 00a...@gmail.com wrote: Attached is ora2png, a tool I recently wrote that flattens .ora files and saves them as png. it requires Python and the commandline version of G'MIC (http:/gmic.sf.net) Nice, this will be useful to a lot of users. As a better long term solution, it would be nice to use libora for this. It can already render a document to a pixelbuffer, so the only addition needed is to save that buffer to a PNG (there is some sample code for this in the oratool.c file). Patches would be very welcomed :) -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] Fwd: [CREATE] Pro bono ads in Libre Graphics Magazine
This might be interesting for us. Any designers that want to make an advertisement for MyPaint? ;) -- Forwarded message -- From: ginger coons gin...@adaptstudio.ca Date: 3 November 2010 14:38 Subject: [CREATE] Pro bono ads in Libre Graphics Magazine To: create cre...@lists.freedesktop.org Hello, Create! More chatter from Libre Graphics Magazine. In issue 1.1, we've reserved nine full pages for pro bono ads. These pages are spaces we want to go to the promotion of F/LOSS and Libre Graphics software and projects. So far, only one is spoken for. Which means that we've got eight whole pages left for the promotion of Libre Graphics projects. We're running A4 size pages and if you don't want to design an ad yourself, we'll do it for you. If your project wants one of those spaces, either reply to this thread, to me, or to enquir...@libregraphicsmag.com. -- ginger all-lower-case coons adaptstudio.ca 647.865.7757 (Toronto) 514.213.1318 (Montreal) ___ CREATE mailing list cre...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/create -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] MyPaint 0.9.0 released
On 2 November 2010 21:54, Martin Renold martin...@gmx.ch wrote: MyPaint 0.9.0 has been released. Hurrah, party all night. I'm going to make announcements on Freshmeat and Gnome Files tomorrow. I'm going on a closing-spree for the bugs marked as fixed in the bugtracker now. Temporarily disabling email notifications to keep the noise down. -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Hungarian translation - final
The hungarian translation is finally finished, I hope I'm still on time. (If I knew git better, I'd send a patch only, but for now I'll send the whole .po file again) Committed now. Thanks again! Sending the .po file is just fine. I commit all translation changes with the author of the translations anyways, so there is no benefit to sending patches. -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Hungarian translation
2010/10/20 Aradszki Gergely garp...@gmail.com: Greetings! Here is the Hungarian translation. It is possible that minor stilistical changes will be made later, but it can be considered complete. Committed and pushed. Thanks a lot! Note that 5 strings are marked as fuzzy. Is that intentional? -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] MyPaint Spanish update
2010/10/19 manuel quiñones manuel.por@gmail.com: Spanish translation PO updated. Committed and pushed now. Thanks a lot! -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] MyPaint 0.9 brush collection tilt icon
On 17 October 2010 22:08, David REVOY davidre...@gmail.com wrote: Now, the only thing that needs to be done is to move some brushes over from classic to experimental, to keep classic under 35 brushes (at least 5). Does anyone have suggestions for which ones that should be? Hi, my suggestion is to remove the 5 I underlined ( jpg in attachement ) from the actual 40 to have a set of 35. Ok, done. If anyone else has suggestions or wishes to improve the brushset for 0.9, please raise them now. Stuff like ordering inside the groups, moving brush between groups or perhaps putting some favorites back from the sets that were removed? -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] MyPaint 0.9 brush collection tilt icon
On 11 October 2010 11:20, David REVOY davidre...@gmail.com wrote: - Brushes using tilt must have icons that show this. Hi, A little update of my work on the kit, with the tilt icon as promised on IRC : http://www.davidrevoy.com/XYZ/brushes-mypaint-pack.zip In attachement a preview of screenshots. I tried to kept it simple and subtle. They are in 'classic' folder ; markers + impressionism + puantilism. ++ ;) Merged now, thanks a lot! Now, the only thing that needs to be done is to move some brushes over from classic to experimental, to keep classic under 35 brushes (at least 5). Does anyone have suggestions for which ones that should be? -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Norwegian Nynorsk translation update
On 16 October 2010 19:58, Tor Egil Hoftun Kvæstad toregi...@hotmail.com wrote: Hello I'm not entirely certain whether or not I'll work more on it at this time. If you don't hear anything more from me before you must merge it for 0.9.0, just merge it. If I have any updates before that, I'll post them to the list. Ok. Merged and pushed now. Thanks a lot! -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] MyPaint 0.9 string freeze and beta1
On 17 October 2010 00:33, Griatch Griatch-art gria...@gmail.com wrote: Here's the updated .po file for Swedish. . Griatch Committed and pushed. Takk sä mycket! -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Status of FOSS interface design course
Quoted in full and CC'ed to our mailing list. On 15 October 2010 17:28, Matthew Jadud mja...@allegheny.edu wrote: Hello all, You are receiving this because you indicated that you had a FOSS project that might benefit from a student team contributing usability testing and design. This week, the students completed their sprint through the Fedora Project website, and we will be communicating the results of their testing back to the FP websites team shortly. The students learned a great deal in their sprint, and are ready to move on to the next phase of the course. There are only three student teams. They selected projects, began contacting their communities, and in more than one case found an unresponsive community. This is the nature of real-world FOSS participation, and we knew this was possible from the start -- so we're not worried/complaining. It is *possible* that the students are not contacting the right people, but they started by engaging with one of you and/or by using the communication mechanisms that your project uses most. (For example, a team looking to work with VLC found there is heavy reliance on IRC, and therefore the students are doing their best to do their communication in IRC. This is working well so far, and they're excited.) The other two teams will continue attempting to find projects with responsive communities. Our ask remains simple: give them some direction so that they are working on high-value projects *for you*, and by-and-large they're self-directed and self-sufficient. If you hear from any of them in the next day or two, it's because they're now looking for a new project that wants their contributions. Many thanks to all of you, and keep hacking on the good stuff that you do. Cheers, Matt Thanks for the update. Here is a small update on our side in MyPaint, and some possible directions for your students. We have just released MyPaint 0.9.0 beta1, which means we are in string freeze and will release MyPaint 0.9.0 final in some weeks. And after that, we will be focusing again on new features and improvements. Some interesting tasks (for us, and hopefully for you) 1. Brush selection workflow Today this centers around the brush selector dialog, which can bee seen here: http://mypaint.intilinux.com/wp-content/uploads/2008/04/GUIfull1.png I suspect that several things about this dialog is not very intuitive, and not as good as it could be. 2. Brush editing workflow This is an action that is performed more seldom, but has more complexity associated with it. Current solution is the brush editor, of which an older version is shown here: http://mypaint.intilinux.com/wp-content/uploads/2009/06/snapshot3b.png The current solution exposes all the internal complexity directly to the user, with little to no help offered to understand what is going on. This is, in my opinion, one of the least usable aspects of MyPaint. 3. Usability on tablet PCs Tablet PCs are an important class of devices which have so far been neglected by us. Going forward we want to fix that, and some good interaction design would be a great start! More an idea: 4. A user interface for a MyPaint Mobile application This is much more uncertain if we are able to implement, due to the size of the task and that it is a bit of a sidetrack from our primary focus. But I might be able to convince someone to sponsor me to work 50-150 hours on something like that, so if you are very interested it is a possibility. The target form-factor would be the ones that require a fundamentally different user interface (and targeting slightly different usecases) than the original MyPaint: Smartphones, MIDs, small slates. Small-ish mobile devices with touch/stylus as main input device. If any of these tasks seem interesting, please let us know and we will provide more information. -- Regards Jon Nordby - www.jonnor.com PS: The CC'ed mailinglist and IRC are our main communication tools. ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] Norwegian Nynorsk translation update
On 12 October 2010 19:53, Tor Egil Hoftun Kvæstad toregi...@hotmail.com wrote: Hello I've attached the updated Norwegian Nynorsk translation. There are now 323 translated strings, 33 fuzzy and 34 untranslated. Hey. Do you plan to work more on this before 0.9.0, or do you want me to merge it like this? (either way is fine) -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] MyPaint 0.9 string freeze and beta1
On 14 October 2010 10:03, geun-tak jeong berobe...@gmail.com wrote: Hi Hangul language files were completed. I learned how to create a POT file. The translation will be so fresh. Please contact the new version comes out. Thanks a lot! Updated now. The new version will be announced on the mailing list and on the website. www.mypaint.info -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] MyPaint 0.9 string freeze and beta1
2010/10/12 geun-tak jeong berobe...@gmail.com: Hello. I have Mypaint Korean translation. POEdit uses. However, there is a problem. No POT files. I can not create a new POT file. I'm not a programmer. POT file for translators to make ... We have more translations does not help. I need a new standard POT files. POT file can not be translated without the latest. Instead of creating POT files that can not afford? Thanks for reading. 듣기 소리나는 대로 읽기 ps. using Google Translator You will need to use scons translate=ho to update the po file for Korean. Unless you are starting a new translation, you do not need to care about the pot file. Normally we would update the the po files before/after doing a string freeze release, but this has not been done. However, if you need google translate to be able to communicate in English, please consider if you are the right person to do a translation. -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] MyPaint 0.9 string freeze and beta1
On 12 October 2010 14:24, Julian Aloofi jul...@fedoraproject.org wrote: Hi Jon, good to see you keep the work up on this amazing program! :) I don't think I'll be able to continue working on the german translation for now, especially since I'm lacking much artistic vocabulary and am currently working on other stuff. If I find the time I'll be sure to send you a merge request though. Thanks for letting us know. We have several other people around the project who are native speakers of german, so we should be fine. If anyone else is planning to work on this, please let everyone else know so that there is no duplication of effort. -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] MyPaint 0.9 brush collection
On 2 October 2010 15:12, cont...@turnangel.com cont...@turnangel.com wrote: I think that in the next release my brushes set shouldn't be included because is too specialized and normal users don't need it at all. I myself don't use it anymore and I stay sticked with last Deevad Ramòn pack. :D Imho icons should be draw by the same person for consistency and professional look. (Please, don't look at me I'm very bad to draw icons! :D ) Personally I prefer the Ramòn solution because I can say instantly how the brush works reading the labels below and above the icon image.Deevad icons are beautiful and pleasant to look but sometimes confuse me. These are my two cents... What do you think about? Ok, thanks for your input. Tanda has sent me a updated brush set, which I will commit to master soon. So it looks like we are all set as far as artist brushsets goes! For the non-artist brushsets it would be very nice if they also had a nice, consistent look for the icons. That is one of the reasons why we are interested in having a brushset maintainer. -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] layers re-positioning for adjustment
On 2 October 2010 12:24, Vasilis Platanias azathot...@gmail.com wrote: This could be very useful for exchanging layers between mypaint and gimp too. Currently this exchange works better for flat images rather than layers, because layers might lose their original position when pasted back to mypaint. Using OpenRaster as an exchange format will preserve all layers and their positioning. -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] MyPaint 0.9 planning update
I think we've now taken care of most of the things mentioned in the first MyPaint 0.9 planning thread. TODO: 1. Finishing planned brushset changes (I'm following up on that subject shortly) 2. Brushset import testing 3. bug #16109: [Windows] cannot save/load files with non-ascii characters + other Windows save crashers 4. bug #14875: ORA should not be the default file format Personally I think its fixed/not-a-bug, but I wont try to keep anyone from doing it. Anything else? Anything that is blocking a string freeze? If not, I propose string freeze next Sunday, 10 October. I'm also proposing we do a beta release at the same time we have the string freeze. That way we will get significantly more testing before RC and final release. Hopefully also by Windows users, which is perhaps the most important. Bakhtiar, can you do a Windows build sometime around then? -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] MyPaint 0.9 brush collection
This is a status update on the planned MyPaint 0.9 brushset changes. - We now have two artist brush sets that are ready to ship, Deevad and Ramòn. This is enough, but if you are interested we can accept another one. Tone, Ico-dY, Tanda? It would have to follow the guidelines given in the previous email (especially the number of brushes). - We still need a bit of help in redesigning some icons for the non-artist brush sets The biggest problem is the tilt brushes (currently in the Tilt group). These need better icons, so that is is clear that these use tilt. Simply adding some text saying tilt might be enough. Enrico/Ico-dY; I seem to have missed you in the first email, sorry. The original email is included underneath so you can see what we are planning. If there are any questions or comments, remember to use reply to all. -- Regards Jon Nordby - www.jonnor.com On 12 September 2010 22:07, Jon Nordby jono...@gmail.com wrote: Hi dear MyPaint brush set contributors! We (the developers) are working on finalizing MyPaint 0.9, and we hope to finish that release within a month or two. In addition to the software changes (features, bugfixes, et.c.), we want to make some changes to the brush set to make MyPaint more usable. Here is some of the things we have done so far with respect to brushes: - Implemented brush import/export - Implemented loading of last used brush and brushgroup on startup - Remove the default group - Make David Revoy's brush set (Deevad) the default one for first startup And here is what we want your help to do: - Make each brush group contain 25-35 brushes This is to keep the number of brushes down, and to let the user be able to see and keep track of all brushes in a group easily. We are hoping that the artists that has contributed a brush set (thats you!) can make an updated brush set that contains their 25-35 favorite brushes, and set it to us within the next couple of weeks. If you do not think you have time to do this, please let us know. - Improve the brush icons of the non-artist brush sets Good brush icons communicate to the user what type of brush it represents, how the brush looks and can be used. It is also good if they look nice, of course :) If you want to help us create such icons for the non-artist brush sets, let us know. We are also interested in handing over the maintainer-ship of the default brush collection. That means being responsible for updating the collection when artists update their sets, choosing which new brushes/sets should go in, which ones to remove, adjusting the guidelines for the brush collection, improving brush icons that need it, et.c. If anyone is interested in this, please speak up. Remember to use reply to all when replying to this email. -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
Re: [Mypaint-discuss] [CREATE] ORA fullscreen viewers
On 10 September 2010 08:22, Luka Čehovin luka.ceho...@gmail.com wrote: Hello, 3. Let a common library implement basic ORA support, and provide an interface to get the full image as a pixel buffer. My favorite option is number 3, mainly because: 1. results in redundant information in every new ORA file, as you point out. And it does not work for existing files. 2. results in fairly significant duplicate work for each implementation. Or the current state - no implementations at all. In addition having a library abstract the details away means that newer features could be added in a transparent way as the standard develops. These are exactly the reasons why I have started working on libora. At the moment I still do not have time to continue the development ... but since the code is on gitorious everyone is welcome to join. At the moment I can only participate in some potential brainstormings and help with some minor stuff. Do you have time for a code review? Also, would you please remove libora on gitorious in favour of the openraster/libora repo, like we discussed? -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
[Mypaint-discuss] Fwd: Students exploring user interface design
-- Forwarded message -- From: Matthew Jadud mja...@allegheny.edu Date: 12 September 2010 23:04 Subject: Students exploring user interface design To: Matthew Jadud mja...@allegheny.edu Hello all, I will keep my note brief. I'm writing you because you, or a colleague of yours, responded to my call regarding usability/interaction design[1]. I've tried to capture all of your projects in a list[2], and have done my best to (briefly) write something about your projects. I want to say that I am overwhelmed by the number of responses I received, and from so many projects that I am familiar with in one form or another. I'm very excited about the opportunities your projects represent for the students. The students are currently engaging in their first UI design and testing project, which involves student involvement with the Fedora Design community surrounding their pending website redesign. The students don't *really* know what they're doing yet, and Máirín Duffy and the websites team were kind enough to let the students use this as an opportunity to skin their knees a bit and learn what the whole UI design/test process looks like. As I've heard some FOSS practitioners say, the students are learning to be productively lost. While they're doing that, they're reading Norman, Cooper, Snyder, and other resources, delving more deeply into the cognitive and practical aspects of UI design. They're going to be looking at all of your projects over the coming week, and will likely begin contacting some of you next week to ask questions and express interest in working with you. In short, this note is a heads up as to what we've been up to, and where we're going next. I'm sorry I didn't write sooner, but I've been doing a lot of community interaction/bridging myself these past two weeks. The students are engaged, and the knowledge that they will be working with real projects has, I think, really focused their efforts so far. Please feel free to ask me questions. Mostly, I think you can continue to sit back and wait for students to come your way. So, again: thank you! Cheers, Matt PS. Given that we only have 10 students in the class, the fact is that we won't be able to work with most of the projects that responded. That said, I'm going to push to see if I can get this course cross-listed with our Psychology department, and perhaps get it to run more often. Or, perhaps I'll look at ways I can do something that blends our local instruction with P2PU. Either way, it is clear that there are a lot of great opportunities to introduce students to open communities around the theme of usability. [1] http://www.sububi.org/2010/08/18/free-interaction-design-for-your-open-source-project/ [2] http://rockalypse.org/courses/cmpsc303f10/projects/ [3] http://wiki.rockalypse.org/HCD -- Regards Jon Nordby - www.jonnor.com ___ Mypaint-discuss mailing list Mypaint-discuss@gna.org https://mail.gna.org/listinfo/mypaint-discuss
