Puppy Stardust 003

[Shep]

It throws me into mtPaint with the image loaded, and I try to save
it to a file, but it fails to. There is no confirmation that it
has succeeded, nor is there a message that it's unable to.

Only when I try to exit mtPaint does it point out that the
changes have not been saved. Try as I might, I cannot
get that image saved.

And in which way exactly do you "try to save it to a file"? Does selecting "File->Save" from the menu do nothing at all on your system, or what?

File->Save allows me to negotiate around the file system, but
when it comes to saving, it doesn´t. I found the same if I just
go into mtPaint from the menu (forget about involving a screenshot).
create a file, and try to save it. It doesn´t save.

[wjaguar]

File->Save allows me to negotiate around the file system, but
when it comes to saving, it doesn´t. I found the same if I just
go into mtPaint from the menu (forget about involving a screenshot).
create a file, and try to save it. It doesn´t save.

This is a technical impossibility - unless libc on your system isn't working properly. If fopen(), libc's file creation function, fails to create a file, it should return NULL - in which case, mtPaint displays an error box with "Unable to save file: /path/filename", and after user's pressing "OK", redisplays the file selector dialog. And if fopen() succeeds, then you should be able to see, at the very least, a zero-sized file with that name in that place afterwards - even if writing the file had failed utterly, its directory entry should already be created and cannot by itself disappear.

And BTW - if mtPaint believes that a file was saved successfully, it adds its name to the list of recently used files (in the "File" submenu, between "Actions" and "Quit" entries). And if the file had in fact been saved, you should be able to re-load it into mtPaint by clicking on its name in the menu (this list gets remembered across sessions, so you can quit and restart mtPaint before trying to re-load the file).
If mtPaint succeeds with re-loading the file, then obviously, the problem is elsewhere - with you somehow not seeing the saved file. So, please test if the above sequence works - and if it doesn't, then tell me in which way exactly does it fail.

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

[Shep]

Hi Dmitry. There is not even a zero length file created.

I´m also using mtPaint in Dpup, and it works correctly there.

So I think I´ll burn another cd with Stardust and see whether
it is any different. I checked the md5sum of the Stardust ISO,
but at the time didn´t check the md5sum of the cd with pburn
and now I don´t know how to retrospectively perform that on a cd.

[Shep]

Hi Dmitry. There is not even a zero length file created.

I´m also using mtPaint in Dpup, and mtPaint works correctly there.

Okayyyy. I've avoided using Stardust for a couple of days so that I could approach
it with refreshed vision, and I've found the problem. Me.

Clicking on SAVE brings up the Stardust directory navigator thingo.
This navigator software allows typing in two text boxes; the upper
one for the directory's pathname if you want to shortcircuit the navigation,
and the lower one for the filename itself.

I failed to notice that lower box, and was typing the full pathname + filename
in the upperbox and so was leaving the lower text box empty.

Despite this, my clicking on SAVE elicited no cogent error message nor
did it even (pointedly) chop off the filename from what I'd typed in the directory.
text box. I'd call that a software shortcoming; the lower box should at the
very least have a default name "untitled" in it.

So the cause has been traced. You can rest assured, Dmitry, it's nothing to
do with your creative efforts!

The reason this didn't arise in Dpup is that the directory navigator software
there has only one text entry box (the one for the filename), and the user
is forced to use mouse clicks to navigate to the desired directory.

Thanks for all inputs.

[Shep]

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

I'm curious to know why mtPaint allows the user to save a file as JPEG but not GIF
after modifying an existing file (e.g., a screenshot), yet after creating
a file from new, the options for saving the file include GIF but not JPEG ??

[wjaguar]

Despite this, my clicking on SAVE elicited no cogent error message nor did it even (pointedly) chop off the filename from what I'd typed in the directory. text box.

Actually, it should have been doing both...

I'd call that a software shortcoming; the lower box should at the very least have a default name "untitled" in it.

Myself, I prefer to leave files unsaveable unless given a name, than to promote accumulation of insane quantities of "Untitled*.*" image files in work directories.

So the cause has been traced. You can rest assured, Dmitry, it's nothing to do with your creative efforts!

No, in fact it is me who has to shoulder the blame. Thanks for discovering two bugs in mtPaint's new fileselector.

Myself, I have never used the directory box that way, so it escaped my attention that a bugfix for another issue interfered with error reporting in there, and that clicking "OK" didn't update the path if directory box had been edited.

I'm curious to know why mtPaint allows the user to save a file as JPEG but not GIF after modifying an existing file (e.g., a screenshot), yet after creating a file from new, the options for saving the file include GIF but not JPEG ??

This one is simple, really. Screenshots are 24-bit RGB, and cannot be saved into a 256-color format such as GIF, unless user does "Convert to indexed" first. And if defaults for a new image are set to indexed color, then such an image also cannot be saved into an RGB-only format such as JPEG, without "Convert to RGB" applied first.
http://mtpaint.sourceforge.net/handbook ... .html#SEC2