mtpaint 3.49.12- April 2016

[jamesbond]

Lazpaint 6.2 newest!!! available

So I hope now I can drop the mtPaint project?

Oh no ... please don't! We appreciate your maintenance of mtPaint, wjaguar Please keep it alive!

BTW: version 3.44.85 has commandline scripting. Like this:

Very interesting, this could potentially replace a lot of tools . How stable is the "interface", are you still in test/play phase, or is the commands are more or less fixed?

[wjaguar]

How stable is the "interface", are you still in test/play phase, or is the commands are more or less fixed?

The commands are every bit as stable as menu structure and dialog items' naming is. Because the "commands" are the very same names - or, any prefix of any word in them that does still match uniquely.
This self-naming and self-documenting is part of the reason why scripting is implemented through the V-code.

The script is commands with their parameters. Commands are prefixed with "-" and match to menu items; parameters are followed by "=" and a value, and match to dialog items. If a command itself is followed by "=" and value, that matches the unnamed item in the dialog. But such an unnamed option can just stand alone: "-file/as=zad" is fully equivalent to "-file/as =zad".

The entire name of a menu option, including spaces, is the canonical name of its matching command - with shell quoting used to protect the spaces. Like this:
mtpaint --cmd -file/'save as ...'=zad
It is safe to shorten the "save as ..." to just "as", because no word in other items' names in the same submenu starts with "as". And so it is done in the examples.
But "save" on its own is a match for another item in the same submenu: "File->Save", which stands before "File->Save as".

Parts separated by "/" are matched to corresponding menu levels in order. So to call up "Effects->Isometric transformation->Top side right", you can write a command "-eff/iso/top". Or more verbosely, "-effect/isometric/top".

Same thing about parameters. I can write:
mtpaint --cmd -file/'save as' =zad 'file format'=png 'transparency index'=0 'png compression'=9
But it is just as unambiguous in this case to write this instead:
mtpaint --cmd -file/as=zad f=png t=0 p=9
Still, for the sake of understandability it's better to use some more chars per option. Say, like this:
mtpaint --cmd -file/as=zad format=png trans=0 png=9
But it is not unambiguous to use "c=9", "comp=9" or even "compression=9", because there also exist "JPEG2000 compression" and "TGA RLE compression" in this same dialog (visible to user for different filetypes, but V-code sees them all at once).

So "-effect/unsharp r=1 am=0.4" in the example means the same as "-effects/'unsharp mask' radius=1 amount=0.4" would.

The unnamed parameter matches to the unnamed control in a dialog - usually it is the top one, but not always. For fileselector, it is filename; for most filters, it is value spinbutton; but for image scale, you can see it is filter name - everything above their list has names; for image resize - tiling mode, for the same reason. So you see "-image/scale=nearest" and "-image/resize=mirror" in the examples.

To select options from lists, such as filter names or file formats, values are matched to option names just the same way as parameters are matched to dialog items, and commands to menu items. So "image/scale=near" will select you the "Nearest neighbour" scaling method.

If you aren't sure whether a parameter would be present in the dialog at all (it is one such as might get disabled) but want to set it in case it's present, you prefix its name with "." Say, to scale an image of unknown type in a nearest neighbor mode, it's safe to write "-image/scale .=near", but "-image/scale=near" will fail to match in case the image turns out to be a GIF or other indexed format.

For ease of use, the "Width" and "Height" fields in "Scale canvas" and "Resize canvas" dialogs are made to understand a couple formats that a regular spinbutton wouldn't. Like this:
w=x1.5 - multiplies the original value by 1.5;
w=33% - 33% of the original value.
If "Fix aspect ratio" is toggled on ("fix=1" if you aren't sure it is) then setting the width will correspondingly modify the height, or vice versa. But only the first time; so you can write "w=200% h=x1" to make the image twice wider, and not bother with "Fix aspect ratio" setting.

This is how it works.

[don570]

New version 3.44.85 available in first post
___________________________________________

[don570]

A suggestion to wjaguar:

Add the list of non-gui command lines to the terminal help



_____________________________________________

mtpaint [option] [imagefile ... ]
mtPaint can accept one of the following options:

--help Output usage information
--version Output version information
-s Grab a screenshot
-v Start mtPaint in viewer mode
--cmd non-gui mode

Examples of non-gui-mode:

mtpaint --cmd -file/open=test.png -effect/unsharp r=1 am=0.4 -effect/unsharp r=30 am=0.1 -file/as format=pmm

mtpaint --cmd -file/open=test.png -effect/gauss=100 -file/save

mtpaint --cmd -file/open=test.png -image/scale w=x0.5 -file/save

mtpaint --cmd -file/open=test.png -image/scale w=50% -file/save

mtpaint --cmd -file/open=test.png -image/scale=nearest w=200% -file/as format=tga

mtpaint --cmd -file/open=test.png -image/resize=mirror w=x3 -file/as=zad

[vicmz]

version 3.44.85 has commandline scripting. Like this:

Code: Select all

mtpaint --cmd -file/open=test.png -effect/unsharp r=1 am=0.4 -effect/unsharp r=30 am=0.1 -file/as format=pmm

mtpaint --cmd -file/open=test.png -effect/gauss=100 -file/save

mtpaint --cmd -file/open=test.png -image/scale w=x0.5 -file/save

mtpaint --cmd -file/open=test.png -image/scale w=50% -file/save

mtpaint --cmd -file/open=test.png -image/scale=nearest w=200% -file/as format=tga

mtpaint --cmd -file/open=test.png -image/resize=mirror w=x3 -file/as=zad

Interesting. Is it possible to extend these for a series of picture files, or even better, for a folder of picture files?

[don570]

I only tested one picture

_______________________

[wjaguar]

A suggestion to wjaguar:
Add the list of non-gui command lines to the terminal help

Maybe one example, to better explain what "--cmd" is all about. Anything more would be a waste of space in the binary; the learning materials belong in the handbook.

And people who don't read the handbook, can hardly be expected to study the commandline help, either.

Is it possible to extend these for a series of picture files, or even better, for a folder of picture files?

The shell has "for"-loops for a reason.
for ZAD in test/*.png ; do mtpaint --cmd -file/open="$ZAD" -image/scale w=x0.5 -file/save ; done

[Pelo]

GQview >>> Viewnior would be better as defaut. Viewnior nowadays is the default image viewer in our Puppies. Now, we know how to change preferences in MTpaint, but could you make viewnior the master viewer.

[wjaguar]

Now, we know how to change preferences in MTpaint, but could you make viewnior the master viewer.

http://mtpaint.sourceforge.net/handbook ... html#SEC64

[don570]

I made new Ubuntu debian packages for Lucid , Precise and Trusty Tahr.
Available at first post.


Be careful to follow the instructions for installation for each distro.

I tested version 3.44.85 in Ubuntu Lucid , Precise and Trusty Tahr and they worked well
except for the following bug. The script window will open
and it has the text command but only one pixel high.
It will execute the command.


_____________________________________________

[wjaguar]

I tested version 3.44.85 in Ubuntu Lucid , Precise and Trusty Tahr and they worked well
except for the following bug. The script window will open
and it has the text command but only one pixel high.

Which versions of GTK+2 exhibit the bug?
Are there Puppies which use the same versions?
And if there are, does the problem happen in there?
And if it does, then where do I download such a distro?

Because it's easier for me to use a small distro for testing.

[don570]

I think Ubuntu switched to gtk+3.0 in Precise
https://launchpad.net/ubuntu/precise/+source/gtk+3.0

The Ubuntu trusty tahr distro I tested was ubuntu-14.04.1-desktop-i386.iso

I was able to boot up the ISO from a Fat32 partition.
Described HERE

EDIT: I forgot to mention that Ubuntu Lucid displayed the text properly.

Barry Kauler's puppies don't use gtk+3. Maybe that's why they're fine???

By the way ----> my method of compiling is to compile in puppy linux
which uses gtk+2. The libraries are updated to be same as Ubuntu's.
So the configuration script has gtk+2 as the option line.
Maybe if it was properly compiled in Ubuntu linux with the
option line gtk+3 the result would be different however I don't think
your configuration script is that sophisticated???

_____________________________________________

[wjaguar]

I think Ubuntu switched to gtk+3.0 in Precise

If mtPaint runs on a system, then the system must have some version of GTK+2 installed.
And GTK+3 is irrelevant. It is an entirely separate toolkit, more different from GTK+2 than the latter is from GTK+1. And naturally it installs under different sonames.

I was able to boot up the ISO from a Fat32 partition.
Described HERE

With my using LILO, that recipe is not much useful.

Barry Kauler's puppies don't use gtk+3. Maybe that's why they're fine???

Maybe - if there is some conflict between the two libs' installs.
But a much more likely reason is that the bug is in Ubuntu's default style engine. These things are evil - I have never seen one which wouldn't exhibit at least some rendering bugs.

Maybe if it was properly compiled in Ubuntu linux with the option line gtk+3

If it were this kind of easy, I would not have had to invent V-code, and would not now be preparing to make a Qt backend for it.
GTK+3 is made artificially incompatible with GTK+2; a single codebase cannot be adapted for use with both, unlike GTK+2/GTK+1. It needs a separate backend, much like Qt - but the future of GTK+3 is a lot more in doubt, given the mass exodus of projects from it to Qt.

[don570]

Lubuntu desktop iso (burnt to DVD) showed the script text correctly.
I checked to see which version of gtk was installed and all I saw
was a gtk+2 folder in python, so it looks like they are avoiding gtk+3

Here is an old site that explains the difficulties Lubuntu had with gtk+3
which may explain why their most recent ISO doesn't have it.

http://permalink.gmane.org/gmane.comp.d ... cmanfm/243

To sum up: Only Ubuntu versions that have gtk+3 have the
problem with the script text window.

____________________________________________________

[technosaurus]

I've seen issues with running a gtk1 app after a gtk2 app, (using a page cached function from gtk2) so I assume similar things can happen for gtk3.

I've been playing around with the command line interface to try and replace convert in a few scripts and had a look through the source. I didn't realize mtpaint supported svg before (it was cleverly hiding out in a file named png.c), but when I finally noticed it, the svg import block looks like it could just as easily be a general fallback to import any image format supported by gdk-pixbuf.

[technosaurus]

GTK+3 is made artificially incompatible with GTK+2; a single codebase cannot be adapted for use with both, unlike GTK+2/GTK+1. It needs a separate backend, much like Qt - but the future of GTK+3 is a lot more in doubt, given the mass exodus of projects from it to Qt.

That is the same impression I got ... a lot of change for change sake, mostly "WTF-Why?" type changes. I previously looked into libagar as a gtk replacement but am more interested in tekui now.

[jamesbond]

If it were this kind of easy, I would not have had to invent V-code, and would not now be preparing to make a Qt backend for it.
GTK+3 is made artificially incompatible with GTK+2; a single codebase cannot be adapted for use with both, unlike GTK+2/GTK+1.

That is the same impression I got ... a lot of change for change sake, mostly "WTF-Why?" type changes.

As someone who backported guvcview from GTK+3 to GTK+2, I am in thorough agreement with wjaguar and technosaurus.

[wjaguar]

the svg import block looks like it could just as easily be a general fallback to import any image format supported by gdk-pixbuf.

Import filters in gdk-pixbuf all are of uniformly appalling quality. The only reason I touch the thing at all, is because I wanted to avoid directly linking to librsvg.
And at present, the SVG loader simply cannot work in commandline mode - due to GObject system left uninitialized when not creating the GUI (and would be the same problem even if using librsvg - it also is GObject-based). Will have to call g_type_init() to fix this.

I previously looked into libagar as a gtk replacement but am more interested in tekui now.

Absolutely any library can get an insane "update", or get ignored to slowly bitrot. GTK+1/2/3 now can serve as example of both; but Qt5 also has a number of incompatibilities with Qt4, and a suspect direction of development ("declarative", in fact JavaScript-based, GUIs).
So I think the only remaining way to maintainability in this time of pointless change is an intermediate layer decoupling the semantics of the UI from the implementation details. And now that my V-code experiment is happily running mtPaint's GUI on a text console the idea is at least partly proven by practice.

[wjaguar]

I made changes to window show/hide/destroy process, to make focus from destroyed window, particularly fileselector, to reliably return to the window it was opened from. But while it works for me on KDE, I am not that sure about other WMs out there.
So if in this new version anyone sees that focus from a closed window or dialog went somewhere it is not supposed to, please tell me of that.

In other news, this version is able to load SVGs in commandline mode.

[gjuhasz]

I made changes to window show/hide/destroy process

Dear wjaguar,

It seems that mtpaint still cannot be started with the dock visible.

Are you planning to include this anywhere in the settings? Or, alternatively, is there any chance to add a command line switch for this?

Sorry for disturbing you if this option is already included and only I missed it.

Please advise

Thanks in advance.

Regards,

gjuhasz