mtpaint 3.49.12- April 2016
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.don570 wrote:A suggestion to wjaguar:
Add the list of non-gui command lines to the terminal help
And people who don't read the handbook, can hardly be expected to study the commandline help, either.
The shell has "for"-loops for a reason.vicmz wrote:Is it possible to extend these for a series of picture files, or even better, for a folder of picture files?
for ZAD in test/*.png ; do mtpaint --cmd -file/open="$ZAD" -image/scale w=x0.5 -file/save ; done
GQviiew >>> Viewnior would be better as defaut
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.
- Attachments
-
- viewnior.jpg
- (36.72 KiB) Downloaded 364 times
Re: GQviiew >>> Viewnior would be better as defaut
http://mtpaint.sourceforge.net/handbook ... html#SEC64Pelo wrote:Now, we know how to change preferences in MTpaint, but could you make viewnior the master viewer.
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.
_____________________________________________
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.
_____________________________________________
Which versions of GTK+2 exhibit the bug?don570 wrote: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.
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.
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???
_____________________________________________
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???
_____________________________________________
If mtPaint runs on a system, then the system must have some version of GTK+2 installed.don570 wrote:I think Ubuntu switched to gtk+3.0 in Precise
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.
With my using LILO, that recipe is not much useful.I was able to boot up the ISO from a Fat32 partition.
Described HERE
Maybe - if there is some conflict between the two libs' installs.Barry Kauler's puppies don't use gtk+3. Maybe that's why they're fine???
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.
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.Maybe if it was properly compiled in Ubuntu linux with the option line gtk+3
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.
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.
____________________________________________________
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
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
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.
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.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
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.wjaguar wrote: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.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
wjaguar wrote: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.
As someone who backported guvcview from GTK+3 to GTK+2, I am in thorough agreement with wjaguar and technosaurus.technosaurus wrote:That is the same impression I got ... a lot of change for change sake, mostly "WTF-Why?" type changes.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
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.technosaurus wrote:the svg import block looks like it could just as easily be a general fallback to import any image format supported by gdk-pixbuf.
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.
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).I previously looked into libagar as a gtk replacement but am more interested in tekui now.
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.
Version 3.44.86
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.
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.
Re: Version 3.44.86
Dear wjaguar,wjaguar wrote:I made changes to window show/hide/destroy process
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
Re: Version 3.44.86
The specific cause of the problem is now determined. It is here:don570 wrote:To sum up: Only Ubuntu versions that have gtk+3 have the problem with the script text window.
/usr/lib/i386-linux-gnu/gtk-2.0/modules/liboverlay-scrollbar.so
It comes from this package: http://packages.ubuntu.com/trusty/libs/ ... llbar-gtk2 and is known as source of numerous, never fixed, bugs.
The simplest way to deal with it, is to disable it using an env variable:
LIBOVERLAY_SCROLLBAR=0 ./mtpaint
And if some other simple, and easy to find, workaround doesn't present itself, I'll add this to mtPaint's init code.
Not implemented yet. The idea of adding code to save one keypress per session still strikes me as exceedingly weird.gjuhasz wrote:It seems that mtpaint still cannot be started with the dock visible.
BTW, which would be preferable: restoring the dock state from the previous session, or a separate pref toggle for choosing the initial state?
Ubuntu hasn't given up "overlay-scrollbar" .Ubuntu site wrote: "overlay-scrollbar" versions published in Ubuntu
Utopic (0.2.16+r359+14.10.20140625-0ubuntu1): main/libs
Trusty (0.2.16+r359+14.04.20131129-0ubuntu1): main/libs
Precise-updates (0.2.16-0ubuntu1.1): main/libs
Precise (0.2.16-0ubuntu1): main/libs
It started in Precise and it's still in Utopic
Re: Version 3.44.86
This is not one keystroke, because the dock can be enabled only thru the menu (F12 does not work becaus ROX catches it, see the discussion above). Then resize the window to arrange its child items.wjaguar wrote:Not implemented yet. The idea of adding code to save one keypress per session still strikes me as exceedingly weird.
I assume that such an option should appear anyway in a config file among the others. I would be happy to see the last status (visibility, size, position, etc.,) of ALL child windows, including dock, in a config file based on which mtPaint opens next time. I think this is better than a pref toggle.wjaguar wrote:BTW, which would be preferable: restoring the dock state from the previous session, or a separate pref toggle for choosing the initial state?
Thanks in advance.
Regards,
gjuhasz
New version 3.44.86 available on first post.
__________________________________
I booted up Ubuntu Trusty tahr ISO and tried
Dmitry's suggestion and it worked!!
but I needed to cd to /usr/bin first.
To avoid the extra step I successfully tried
I noticed the following error warning when trying a script effect on an
indexed color image. I suggest more of an explanation. I added some
text in red.
___________________
As an experiment I tried putting the following two lines in ~/.profile
..and to my surprise it worked. I tried a couple of other apps and they
worked as well , but I imagine some apps won't like this???
_____________________________________________
__________________________________
I booted up Ubuntu Trusty tahr ISO and tried
Dmitry's suggestion and it worked!!
Code: Select all
LIBOVERLAY_SCROLLBAR=0 ./mtpaint
To avoid the extra step I successfully tried
Code: Select all
LIBOVERLAY_SCROLLBAR=0 mtpaint
______________________________________Ubuntu advice wrote:
Bash's quick assignment and inheritance trick
The bash shell has a trick to allow us to set one or more environment variables and run a child process with single command. For example, in order to set the "LANGUAGE" and "FOO" environment variables and then run "gedit", we would use the following command:
LANGUAGE=he FOO=bar gedit
Note: When using this command, the new values are only assigned to the environment variables of the child process (in this case gedit). The variables of the shell retain their original values. For instance, in the example above, the value of "LANGUAGE" will not change from its original value, as far as subsequent commands to the shell are concerned.
A similar behaviour can be achieved with other shells by using the env command.
I noticed the following error warning when trying a script effect on an
indexed color image. I suggest more of an explanation. I added some
text in red.
___________________
As an experiment I tried putting the following two lines in ~/.profile
Code: Select all
LIBOVERLAY_SCROLLBAR=0
export LIBOVERLAY_SCROLLBAR
worked as well , but I imagine some apps won't like this???
_____________________________________________