mtpaint-devel — This list is for mtPaint developers to discuss ideas

Re: [Mtpaint-devel] Fix crashes with PAM files

[Dmitry G. <wj...@us...>]

Hello!

On 6/5/16, Martin Širokov <shi...@gm...> wrote:
> mtPaint crashes when loading PAM files with an unknown TUPLTYPE, because
> the 'typenames' array in load_pam_frame (somewhere in png.c) isn't null
> terminated.

Thanks for noticing this. Fix will be in the next version.

P.S.: Sorry for answering so late - I was on vacation in Latvia and
wasn't reading email. :-)


-- 
-= With best regards, Dmitry Groshev, maintainer of mtPaint =-

[Mtpaint-devel] Fix crashes with PAM files

[Martin Š. <shi...@gm...>]

Hello,

mtPaint crashes when loading PAM files with an unknown TUPLTYPE, because
the 'typenames' array in load_pam_frame (somewhere in png.c) isn't null terminated.
A patch (in git format) is attached.

--
Martin Širokov

Re: [Mtpaint-devel] mtPaint Ukrainian Translation

[Dmitry G. <wj...@us...>]

Hello!

You wrote:
> I would like to translate your program into Ukrainian. What do I need?

Not much - a copy of mtPaint, a text editor, and working knowledge of
two languages. :-)
The existing Russian translation (po/ru.po) can serve as template, and
the Ukraiinian translation for GIMP, as a reference with regard to
terminology.
The "./configure newpo" command can generate an empty translation
template file, but this is not really necessary at present; as far as
strings go, the current dev version is not much different from the
last release - nearly all changes are under the hood.

Alternatively, you could use Launchpad:
https://translations.launchpad.net/mtpaint/main/+pots/mtpaint


-- 
-= With best regards, Dmitry Groshev, maintainer of mtPaint =-

[Mtpaint-devel] mtPaint Ukrainian Translation

[Микола К. <myk...@gm...>]

Hello!
I would like to translate your program into Ukrainian. What do I need?

-- 
Sincerely,
Mykola

Re: [Mtpaint-devel] I update Japanese language files

[Dmitry G. <wj...@us...>]

Hello!

On 11/13/14, Fu-sen. / Keiichi SHIGA <bal...@sh...> wrote:
> I was disappointed at this reply very much.
>
> remove does mtPaint from my Linux now.
> I establish Japanese introduction sites of Linux,
> but get rid of a mention of mtPaint entirely.
>
> I lose a support of mtPaint. Thank you very much.

All the trappings of a petulant little boy taking the ball and running
home. Not what I expected from a rational person, at all. :-(

Weirdest things do happen on 13ths, surely. Particularly to the
mtPaint project. :-)

Anyhow, every cloud has its silver lining; the prospect of my having
to dig through the whole load of hieroglyphics felt fairly terrifying.
;-)


-- 
-= With best regards, Dmitry Groshev, maintainer of mtPaint =-

Re: [Mtpaint-devel] I update Japanese language files

[Fu-sen. / K. S. <bal...@sh...>]

I was disappointed at this reply very much.

remove does mtPaint from my Linux now.
I establish Japanese introduction sites of Linux,
but get rid of a mention of mtPaint entirely.

I lose a support of mtPaint. Thank you very much.


2014-11-13 3:50 GMT+09:00 Dmitry Groshev <wj...@us...>:
> Hello!
>
> You wrote:
>> Therefore I succeed work of YoN, and I work on Japanese translation now.
>> A part of translation has already gone Pull Request in GitHub:
>> https://github.com/wjaguar/mtPaint/pulls
>> Please merge it if you notice this.
>
> Thanks for your work. However, I do not do merges blindly; all changes
> need be reviewed by me, even if they are changes in a translation.
> Because all sort of errors, mistakes and misunderstandings can happen,
> and sometimes do.
>
> The changes to existing translation that move the terminology closer
> to the one used in GIMP are appreciated. However, among the ones I had
> time to review, I also noticed a few which I consider misguided.
> See, I have a principled stance that there are no "folders" inside a
> *nix system; these, since their inception, have had _directories_.
> Every message in mtPaint says "directory", never "folder"; and so do
> the translations. So, where a change is done for the sole reason of
> replacing "directory" with a "folder", these I will now need to filter
> out.
> And another thing - what was the reason for reverting the translations
> for builtin help strings like:
> msgid "  1                 10% zoom"
> msgstr "  1              10% ズーム"
> - back to untranslated English?
>
>> I am going to perform this translation a little more.
>
> Thanks in advance.
>
>
> --
> -= With best regards, Dmitry Groshev =-

Re: [Mtpaint-devel] I update Japanese language files

[Dmitry G. <wj...@us...>]

Hello!

You wrote:
> Therefore I succeed work of YoN, and I work on Japanese translation now.
> A part of translation has already gone Pull Request in GitHub:
> https://github.com/wjaguar/mtPaint/pulls
> Please merge it if you notice this.

Thanks for your work. However, I do not do merges blindly; all changes
need be reviewed by me, even if they are changes in a translation.
Because all sort of errors, mistakes and misunderstandings can happen,
and sometimes do.

The changes to existing translation that move the terminology closer
to the one used in GIMP are appreciated. However, among the ones I had
time to review, I also noticed a few which I consider misguided.
See, I have a principled stance that there are no "folders" inside a
*nix system; these, since their inception, have had _directories_.
Every message in mtPaint says "directory", never "folder"; and so do
the translations. So, where a change is done for the sole reason of
replacing "directory" with a "folder", these I will now need to filter
out.
And another thing - what was the reason for reverting the translations
for builtin help strings like:
msgid "  1                 10% zoom"
msgstr "  1              10% ズーム"
- back to untranslated English?

> I am going to perform this translation a little more.

Thanks in advance.


-- 
-= With best regards, Dmitry Groshev =-

[Mtpaint-devel] I update Japanese language files

[Fu-sen. / K. S. <bal...@sh...>]

I am Japanese mtPaint user.
I come across mtPaint in Puppy Linux and use it habitually.
I install mtPaint in Ubuntu, Debian, Fedora and Windows and use it.
(mtPaint is included in Lubuntu...)
Thank you for splendid application!


By the way, the thing that YoN (Norihiro YONEDA)
of the Puppy Linux Japanese Edition member
translated the Japanese translation of mtPaint for a long time is left.
A change is born of contents of translation by evolution of mtPaint.

Therefore I succeed work of YoN, and I work on Japanese translation now.
A part of translation has already gone Pull Request in GitHub:

https://github.com/wjaguar/mtPaint/pulls

Please merge it if you notice this.
I am going to perform this translation a little more.


Thanks development members and supporter of mtPaint.

[Mtpaint-devel] Please install the supplied AppData file

[Richard H. <hug...@gm...>]

Please consider installing this AppData file we wrote:
https://raw.githubusercontent.com/hughsie/fedora-appstream/master/appdata-extra/desktop/mtpaint.appdata.xml

This is used in GNOME and KDE software installers to add the
application description and some screenshots. We'd love to showcase
more applications, but without the extra data file we can't. The
AppData file needs to be installed to /usr/share/appdata/ on Linux and
the basename needs to match the .desktop basename. It would also be
great if you could integrate the file with your translation system
(e.g. intltool) to make the descriptions translated.

See http://people.freedesktop.org/~hughsient/appdata/ for more details; thanks!

Richard

Re: [Mtpaint-devel] mini patch so "fix aspect ratio" is off by default when resizing canvas

[Mark T. <mar...@gm...>]

Thanks for the update Dmitry.  Now I can see how it works in mtPaint, I do
think this is the best solution.

GUI design is always rather tricky because its so subjective and dependent
on the use cases of the people involved.  Thankfully here we were able to
find a solution that satisfied all the contributors to this thread.

Good work everyone!  :-)

-- 
Regards,
Mark.


On 25 July 2014 20:07, Dmitry Groshev <wj...@us...> wrote:

> Hello, Mark.
>
> You wrote:
> >  Specifically I mean a situation where the resize and scale dialog
> windows
> > restore the previously user set state for the aspect ratio toggle
> (getting
> > the state on startup from the inifile, or defaulting to on if unset).
> > I don't think this would involve code complexity or annoying GUI
> behaviour,
> > so I feel the benefits outweigh the costs.
>
> In the matters of interface design, I always relied on your judgement.
> So if you think this is better, then so it is done. Version 3.44.81
> now has the toggle backed by 2 inifile vars, one for scale, another
> for resize.
>
>
> --
> -= With best regards, Dmitry Groshev =-
>


​

Re: [Mtpaint-devel] mini patch so "fix aspect ratio" is off by default when resizing canvas

[Dmitry G. <wj...@us...>]

Hello, Mark.

You wrote:
>  Specifically I mean a situation where the resize and scale dialog windows
> restore the previously user set state for the aspect ratio toggle (getting
> the state on startup from the inifile, or defaulting to on if unset).
> I don't think this would involve code complexity or annoying GUI behaviour,
> so I feel the benefits outweigh the costs.

In the matters of interface design, I always relied on your judgement.
So if you think this is better, then so it is done. Version 3.44.81
now has the toggle backed by 2 inifile vars, one for scale, another
for resize.


-- 
-= With best regards, Dmitry Groshev =-

Re: [Mtpaint-devel] mini patch so "fix aspect ratio" is off by default when resizing canvas

[Javier M. <cou...@gm...>]

In my opinion, preserving the aspect ratio only makes sense if you want 
to preserve the aspect of the image, so I agree with Sam that it should 
only be enabled by default for scaling and not for resizing.

On 25/07/14 05:46, Sam Watkins wrote:
> Scaling and Cropping images to fit a certain
> "wallpaper" or "screen" size is a very common task, one that mtpaint is
> very good at - especially with this change.
In my case, I often use mtpaint for scribbling stuff or drawing quick 
sketches, so I often end up running out of space and have to make the 
image taller (or wider, or sometimes both), so what I need is to enlarge 
it in 1 dimension only.
> If
> different settings suit different people / workflow, it sounds like what
> we should do is make the resize and scale windows remember the setting
> the user chose for that toggle button, rather than setting it back to
> "on" each time.  I'm pretty sure gimp does that.  Does that seem
> reasonable?  I can prepare another hacky patch ;)  (on head this time)
I thought what you described should be default behavior as I don't see 
any situation in which the current behavior makes sense, but after 
seeing Dmitry's reply I see that remembering the choice seems like the 
only good option to satisfy everyone.
In Gimp (or at least in my version, 2.6.something), this setting doesn't 
get saved.  Maybe in 2.8-ish it does.


PS: remember that you can crop an image by selecting a rectangle and 
pressing Delete; maybe this option is better for your particular need.  
(And you can move a rectangular selection with pixel precision using the 
arrows, and resize it using Ctrl-arrows)

Re: [Mtpaint-devel] mini patch so "fix aspect ratio" is off by default when resizing canvas

[Mark T. <mar...@gm...>]

Hello Sam & Dmitry.

This sounds like an interesting use-case that I had not considered when I
originally created this feature back in 2004/2005.

Although I haven't maintained the project for over 8 years and I am merely
a normal mtPaint user, I think this small change would be useful.
 Specifically I mean a situation where the resize and scale dialog windows
restore the previously user set state for the aspect ratio toggle (getting
the state on startup from the inifile, or defaulting to on if unset).

I don't think this would involve code complexity or annoying GUI behaviour,
so I feel the benefits outweigh the costs.

BTW, its always great to have people who are intelligent, bold and good at
improving things.  This is how I would describe Dmitry too!  ;-)  Hopefully
you will both be applying these qualities to mtPaint and other free
software projects for many years to come.

​
-- 
Regards,
Mark.


On 25 July 2014 04:46, Sam Watkins <sa...@ni...> wrote:

> On Fri, Jul 25, 2014 at 12:27:36AM +0400, Dmitry Groshev wrote:
> > If your usage pattern is this way, you are welcome to patch your own
> > copy. This is the whole point of FOSS. ;-)
>
> I did do that.
>
> I also got a vote of confidence from one user off-list.
>
> > Myself, I use this tool differently, and fixed aspect ratio is more
> > useful than not.
>
> That's cool.
>
> For my workflow this patch halved the time to get things done.  If
> different settings suit different people / workflow, it sounds like what
> we should do is make the resize and scale windows remember the setting
> the user chose for that toggle button, rather than setting it back to
> "on" each time.  I'm pretty sure gimp does that.  Does that seem
> reasonable?  I can prepare another hacky patch ;)  (on head this time)
>
> > Too many config choices can drown the really useful ones
>
> Ok, but this is exceedingly useful to me, and presumably to anyone doing
> a similar task.  Scaling and Cropping images to fit a certain
> "wallpaper" or "screen" size is a very common task, one that mtpaint is
> very good at - especially with this change.
>
> > Given that no one else in all the years of mtPaint had asked for
> > anything like this, the part seems to be good enough as it is. :-)
>
> So it's clear: I am intelligent, bold and good at improving things.
>
> > For processing any large number of images, it is usually better to use
> > commandline tools, such as ImageMagick.
>
> I use those tools often, but they are not suitable for what I am doing -
> I want to do a good job of it, framing the images properly with an
> artistic eye.  This is not something ImageMagick can do by itself,
> and it is very efficient to do it in mtpaint.
>
> > P.S.: And current dev version of mtPaint has had all its GUI rewritten
> > already. So there is no such thing as:
> > > -   sisca_toggles[0] = sig_toggle(_("Fix Aspect Ratio"), TRUE,
> (gpointer)0,
> > > +   sisca_toggles[0] = sig_toggle(_("Fix Aspect Ratio"), sisca_scale,
> (gpointer)0,
> > in mtPaint 3.44.80 anyway. ;-)
>
> Ok then, I was hacking on the version from Debian sources; I did not
> know there was such active rework development on the program and assumed
> this line of code would not have been rewritten!  No doubt I can apply a
> similar patch to the new version if necessary; I request that the main
> developer considers making this fixed-aspect-ratio setting "sticky" in
> some way (and independent for resize vs scale) since this feature is
> certainly of great benefit for people who are cropping and resizing
> images using mtpaint.
>
> I am helping you to improve this program; or that is my intention.  Like
> you said, for my own needs I can just patch my own copy, and I did that
> of course.  I have suggested a good comprimise which should work well
> for all users.  Please try to meet me half-way here.
>
>
> Sam Watkins
>
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Mtpaint-devel mailing list
> Mtp...@li...
> https://lists.sourceforge.net/lists/listinfo/mtpaint-devel
>

Re: [Mtpaint-devel] mini patch so "fix aspect ratio" is off by default when resizing canvas

[Sam W. <sa...@ni...>]

On Fri, Jul 25, 2014 at 12:27:36AM +0400, Dmitry Groshev wrote:
> If your usage pattern is this way, you are welcome to patch your own
> copy. This is the whole point of FOSS. ;-)

I did do that.

I also got a vote of confidence from one user off-list.

> Myself, I use this tool differently, and fixed aspect ratio is more
> useful than not.

That's cool.

For my workflow this patch halved the time to get things done.  If
different settings suit different people / workflow, it sounds like what
we should do is make the resize and scale windows remember the setting
the user chose for that toggle button, rather than setting it back to
"on" each time.  I'm pretty sure gimp does that.  Does that seem
reasonable?  I can prepare another hacky patch ;)  (on head this time)

> Too many config choices can drown the really useful ones

Ok, but this is exceedingly useful to me, and presumably to anyone doing
a similar task.  Scaling and Cropping images to fit a certain
"wallpaper" or "screen" size is a very common task, one that mtpaint is
very good at - especially with this change.

> Given that no one else in all the years of mtPaint had asked for
> anything like this, the part seems to be good enough as it is. :-)

So it's clear: I am intelligent, bold and good at improving things.

> For processing any large number of images, it is usually better to use
> commandline tools, such as ImageMagick.

I use those tools often, but they are not suitable for what I am doing -
I want to do a good job of it, framing the images properly with an
artistic eye.  This is not something ImageMagick can do by itself,
and it is very efficient to do it in mtpaint.

> P.S.: And current dev version of mtPaint has had all its GUI rewritten
> already. So there is no such thing as:
> > -	sisca_toggles[0] = sig_toggle(_("Fix Aspect Ratio"), TRUE, (gpointer)0,
> > +	sisca_toggles[0] = sig_toggle(_("Fix Aspect Ratio"), sisca_scale, (gpointer)0,
> in mtPaint 3.44.80 anyway. ;-)

Ok then, I was hacking on the version from Debian sources; I did not
know there was such active rework development on the program and assumed
this line of code would not have been rewritten!  No doubt I can apply a
similar patch to the new version if necessary; I request that the main
developer considers making this fixed-aspect-ratio setting "sticky" in
some way (and independent for resize vs scale) since this feature is
certainly of great benefit for people who are cropping and resizing
images using mtpaint.

I am helping you to improve this program; or that is my intention.  Like
you said, for my own needs I can just patch my own copy, and I did that
of course.  I have suggested a good comprimise which should work well
for all users.  Please try to meet me half-way here.


Sam Watkins

Re: [Mtpaint-devel] mini patch so "fix aspect ratio" is off by default when resizing canvas

[Dmitry G. <wj...@us...>]

Hello!

You wrote:
> Here is a single-word patch so that "fix aspect ratio" is off by default
> when resizing a canvas, but on by default when scaling a canvas.
> When scaling, I want to keep the proportions of the image, but when
> cropping to fit a certain image size I want to change the shape of the
> canvas by typing only one number.  I would resize to fit one dimension
> in the target size, then crop the other dimension to the target size.

If your usage pattern is this way, you are welcome to patch your own
copy. This is the whole point of FOSS. ;-)
Myself, I use this tool differently, and fixed aspect ratio is more
useful than not.

> Don't know if you think this is a good default, ideally it might be
> configurable and/or remember the setting for each tool (resize/scale
> canvas) separately while the program is running.  But this is good for
> my use case, which is scaling and cropping a lot of images to 800x480
> "wallpaper" size for a handheld device.

Too many config choices can drown the really useful ones; and if
remembered, this specific setting could be getting in the way no less
frequently than be of use. Given that no one else in all the years of
mtPaint had asked for anything like this, the part seems to be good
enough as it is. :-)
And besides, mtPaint will soon be getting scripting support - then the
problem, such as it is, will be mooted.

> This tool even without the patch is very easy to use for scaling and
> cropping a large number of images, it's been very useful to me, I find
> it's much quicker and eaiser than e.g. gimp for this particular purpose.

For processing any large number of images, it is usually better to use
commandline tools, such as ImageMagick.

P.S.: And current dev version of mtPaint has had all its GUI rewritten
already. So there is no such thing as:
> -	sisca_toggles[0] = sig_toggle(_("Fix Aspect Ratio"), TRUE, (gpointer)0,
> +	sisca_toggles[0] = sig_toggle(_("Fix Aspect Ratio"), sisca_scale, (gpointer)0,
in mtPaint 3.44.80 anyway. ;-)


-- 
-= With best regards, Dmitry Groshev =-

[Mtpaint-devel] mini patch so "fix aspect ratio" is off by default when resizing canvas

[Sam W. <sa...@ni...>]

g'day,

Here is a single-word patch so that "fix aspect ratio" is off by default
when resizing a canvas, but on by default when scaling a canvas.

When scaling, I want to keep the proportions of the image, but when
cropping to fit a certain image size I want to change the shape of the
canvas by typing only one number.  I would resize to fit one dimension
in the target size, then crop the other dimension to the target size.

Don't know if you think this is a good default, ideally it might be
configurable and/or remember the setting for each tool (resize/scale
canvas) separately while the program is running.  But this is good for
my use case, which is scaling and cropping a lot of images to 800x480
"wallpaper" size for a handheld device.

This tool even without the patch is very easy to use for scaling and
cropping a large number of images, it's been very useful to me, I find
it's much quicker and eaiser than e.g. gimp for this particular purpose.

Sam Watkins
Australia


diff --git a/src/otherwindow.c b/src/otherwindow.c
index a57b258..d571613 100644
--- a/src/otherwindow.c
+++ b/src/otherwindow.c
@@ -1199,7 +1199,7 @@ void sisca_init( char *title )
 	}
 	add_hseparator( sisca_vbox, -2, 10 );
 
-	sisca_toggles[0] = sig_toggle(_("Fix Aspect Ratio"), TRUE, (gpointer)0,
+	sisca_toggles[0] = sig_toggle(_("Fix Aspect Ratio"), sisca_scale, (gpointer)0,
 		GTK_SIGNAL_FUNC(sisca_moved));
 
 	sisca_hbox = sisca_gc = NULL;

Re: [Mtpaint-devel] pick up rgbpaint for sugar, real users

[Mark T. <mar...@gm...>]

Hello Sebastian.

I haven't maintained or used rgbPaint since 2007 so sadly I can't really
help sort these issues out.

The good news is that its free software so anyone else can carry on
developing the program without me needing to help out, or even requiring my
permission.  In other words you are very welcome to carry on modifying
rgbPaint and distribute those changes using the GPL licence.

As you mention, some Debian people have provided some patches to help
improve the program.  If you would like your own improvements to be shared
with a wider audience it may be worth contacting the Debian rgbPaint
maintainer directly to see if co-operation is possible.

Other people have also made changes such as adding a quit button here:

http://www.mobileread.com/forums/showthread.php?t=223760

I'm very sorry I can't help any more but I have no spare time available as
I am working on other free software projects.  However, I do wish you well
with your work in Colombia, and I hope your work is helpful to other people.

-- 
Regards,
Mark.


On 11 March 2014 23:19, Sebastian Silva <seb...@fu...> wrote:

> Hi friendly mtpaint coders!
> I want to use rgbpaint with underprivileged children in Colombia and they
> have XO 1.75.
> I was having trouble to build but finally managed to do it (by adding
> -lX11 to LDFLAGS).
>
> I applied some patches that I found in the debian package.
>
> Then I fixed Sugar activity code so that it will work again, with latest
> Sugar.
> Currently I'm seeing still an issue when quitting the application, a grey
> window remains open.
>
> For it to comply with Sugar UI guidelines, it needs a Stop button on the
> right side of the toolbar.
> Toolbar icons in Sugar need some love, they are inconsistently colored and
> sized.
>
> My purpose is to use this for pixel painting with children doing a
> videogame.
> So I made the default canvas 64x64. I would like it to be zoomed by 1200%
> by default but I just spent an hour looking for this parameter. Help is
> appreciated on any of the aforementioned goals and ideas.
>
> Attached is my tree as it stands now, in one patch.
> I would find it nice to release this app as Pixel Paint Activity to the
> Sugar Activity Library, tweaked for doing pixel art, much like Pixelesque
> application on Android.
> Of course if this is fine by you.
>
> Regards,
> Sebastian
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> Mtpaint-devel mailing list
> Mtp...@li...
> https://lists.sourceforge.net/lists/listinfo/mtpaint-devel
>
>

[Mtpaint-devel] pick up rgbpaint for sugar, real users

[Sebastian S. <seb...@fu...>]

Hi friendly mtpaint coders!
I want to use rgbpaint with underprivileged children in Colombia and 
they have XO 1.75.
I was having trouble to build but finally managed to do it (by adding 
-lX11 to LDFLAGS).

I applied some patches that I found in the debian package.

Then I fixed Sugar activity code so that it will work again, with latest 
Sugar.
Currently I'm seeing still an issue when quitting the application, a 
grey window remains open.

For it to comply with Sugar UI guidelines, it needs a Stop button on the 
right side of the toolbar.
Toolbar icons in Sugar need some love, they are inconsistently colored 
and sized.

My purpose is to use this for pixel painting with children doing a 
videogame.
So I made the default canvas 64x64. I would like it to be zoomed by 
1200% by default but I just spent an hour looking for this parameter. 
Help is appreciated on any of the aforementioned goals and ideas.

Attached is my tree as it stands now, in one patch.
I would find it nice to release this app as Pixel Paint Activity to the 
Sugar Activity Library, tweaked for doing pixel art, much like 
Pixelesque application on Android.
Of course if this is fine by you.

Regards,
Sebastian

[Mtpaint-devel] Hi, all

[PuppyLinux <pup...@so...>]

Hi all,

I'm cecc from China mainland, could anyone give me a mtpaint 3.31 po file
and also a zh_TW po file for reference?

Thank you all very much, special thanks to Wei-Lun Chao of mtpaint zh_TW
language team(繁体中文组).

Best regards,

cecc

Re: [Mtpaint-devel] Hungarian translation

[Dmitry G. <wj...@us...>]

Hello!

You wrote:
> Here is the Hungarian translation. The translation status: 76%
> translated, 24% (188 strings) untranslated.
> I have not got enough free time to finish the translation but this is
> more than nothing.

Many thanks for your work. Now I'll review it, and include the
translation into the dev version of mtPaint.
Sorry for late replying - I was on a vacation, far away from any computers. :-)


-- 
-= With best regards, Dmitry Groshev =-

[Mtpaint-devel] Hungarian translation

[Úr B. <urb...@gm...>]

Hi

Here is the Hungarian translation. The translation status: 76%
translated, 24% (188 strings) untranslated.
I have not got enough free time to finish the translation but this is
more than nothing.

-- 
Balázs Úr

Re: [Mtpaint-devel] New brushes

[Dmitry G. <wj...@us...>]

Hello!

You wrote:
> Well, the spattering tool (looks more like spatters than sparks, it's
> cool for drawing paint splashes or a starry sky) shouldn't be more
> CPU-intensive than the spray or the circle brush; it just draws circles
> at random positions and sizes, one per mouse move. It's not actually
> image-based like the one on Gimp.

In point of fact, this is *precisely the problem* here. Neither
f_circle() nor sline() was ever meant to be used in this way, and a
procedural brush based on them wastes a lot of cycles. While blitting
an image-based brush is trivial, and mtPaint has had an optimized code
path for that for years; see section 4.7 "Brush pasting" in the
handbook:
http://mtpaint.sourceforge.net/handbook/en_GB/chap_04.html#SEC7
And the only reason why mtPaint doesn't yet support bitmap brushes as,
well, brushes, is because I consider single-frame bitmap brushes not
very useful - and for "image hose" brushes, I need support for
animated sequences as first-class objects. Which is planned for
version 4.00.

> The sketch tool might be more CPU-intensive: it selects a random
> orientation (4 possibilities, which are specularly symmetric), does some
> math (no sines, square roots or other advanced math involved) and draws
> 4 lines. Ok, maybe a bit much CPU usage for low-end machines, but the
> result is cool.

Again, in fact it's quite the reverse; your "sketch tool" isn't really
that bad, and with some optimization, can yet be made acceptable.
While the spattering tool is hopeless; f_circle() is designed for
drawing *equal sized* circles, and optimizes the use case by caching
circle's contour for ONE radius value. Calling it for a bunch of
random radii makes the caching useless, leading to multiple calls to
the costly retrace_circle(). And while optimizing it is technically
possible, through caching and reusing circle contours for each radius
value - I see no need to go to such lengths to create just a poor
workalike of GIMP's "Sparks", when version 4.00 will be able to use
the real deal.

> never mind. Another solution would be some kind of mtPaint addons, but
> that seems complicated to implement given the current mtPaint code,
> which has everything compiled on it.

Plugin support is costly in terms of code size; exporting a function
for use in a plugin excludes certain optimizations, and requires input
validation code to be added. This overhead may go unnoticed in a
behemoth like GIMP, but with mtPaint's 530-Kb binary, extra 30+ Kb
would be very obvious.
And code size notwithstanding, mtPaint's codebase is very dynamic; as
new functionality gets added, old code is refactored to reuse the
common parts. This is necessary for mtPaint to remain compact, but a
plugin made for one release of mtPaint, almost certainly will not work
with any other release.


-- 
-= With best regards, Dmitry Groshev =-

Re: [Mtpaint-devel] New brushes

[Javier M. <cou...@gm...>]

Dmitry Groshev wrote:
> Thanks, but this kind of thing really is outside mtPaint's niche. Had
> I wanted any CPU-busting procedural brushes in mtPaint, I could have
> ported brush engine of MyPaint

Well, the spattering tool (looks more like spatters than sparks, it's 
cool for drawing paint splashes or a starry sky) shouldn't be more 
CPU-intensive than the spray or the circle brush; it just draws circles 
at random positions and sizes, one per mouse move. It's not actually 
image-based like the one on Gimp.
The sketch tool might be more CPU-intensive: it selects a random 
orientation (4 possibilities, which are specularly symmetric), does some 
math (no sines, square roots or other advanced math involved) and draws 
4 lines. Ok, maybe a bit much CPU usage for low-end machines, but the 
result is cool.

> Anyway, support for bitmap brushes and "image hose" brushes, of which
> GIMP's "Sparks" is one example, is planned for mtPaint 4.00.

As I said, this wouldn't have been a problem anyway because the brushes 
are not image based (anyway... wasn't PaintBrush's spray image-based? 
and a single image, not random/cyclic ones...)

Anyway, if you consider that these brushes might be too heavyweight for 
mtPaint's scope, or that it just doesn't have to do with mtPaint, then 
never mind. Another solution would be some kind of mtPaint addons, but 
that seems complicated to implement given the current mtPaint code, 
which has everything compiled on it.

---

About what I said on the other mail, I keep thinking it would be a good 
thing to try to place the gradient tool among the fill patterns, I think 
it's more intuitive and consistent that way.

(And yes, mtPaint is a bit tricky to get used to, but it's like for 
example learning AutoCAD when you only know Paint, PhotoShop and PowerPoint)

Re: [Mtpaint-devel] New brushes

[Dmitry G. <wj...@us...>]

Hello!

You wrote:
> The first one draws random spots with random size (max size determined
> by Flow parameter), and the second one draws lines in random directions
> that make cool shading effects (as many lines as Flow indicates; too
> many lines with small Size may cause results differ from expected due to
> rounding problems).
> Patches and xbm cursors attached (I hope everything's ok and I'm not
> missing anything, I don't have much experience on doing patches).

Thanks, but this kind of thing really is outside mtPaint's niche. Had
I wanted any CPU-busting procedural brushes in mtPaint, I could have
ported brush engine of MyPaint
http://wiki.mypaint.info/index.php?title=Brushlib
But I believe one MyPaint is quite enough, and turning mtPaint into a
clone of it - and especially, into a _bad_ clone - would be ill
advised.

Anyway, support for bitmap brushes and "image hose" brushes, of which
GIMP's "Sparks" is one example, is planned for mtPaint 4.00. Brushes
of this kind allow for efficient implementation, and once mtPaint
gains native support for animation sequences in version 4.00, "image
hose" brushes will be a natural application for it.

> BTW, would it be possible to add a Tracker section to the Sourceforge page?

Last time I looked, Sourceforge-provided tracker hadn't even had an
option of deleting the predefined example categories; so I left the
halfbaked thing alone.
Anyway, I try to use no more of Sourceforge services than absolutely
necessary; with the steady degradation of the site in the last couple
years, the more of it you use, the more problems you have. mtPaint's
git repository is on GitHub and not Sourceforge for this very reason.


-- 
-= With best regards, Dmitry Groshev =-

[Mtpaint-devel] New brushes

[Javier M. de S. <cou...@gm...>]

I've created 2 new brushes copied from Gimp: "Sparks" and "Sketch".
http://img444.imageshack.us/img444/7702/mtpaintwithsparkstool.png
http://img401.imageshack.us/img401/7615/mtpaintwithsketchtool.png

The first one draws random spots with random size (max size determined 
by Flow parameter), and the second one draws lines in random directions 
that make cool shading effects (as many lines as Flow indicates; too 
many lines with small Size may cause results differ from expected due to 
rounding problems).

Patches and xbm cursors attached (I hope everything's ok and I'm not 
missing anything, I don't have much experience on doing patches).


BTW, would it be possible to add a Tracker section to the Sourceforge page?