On Tue, 2010-03-23 at 14:19 +0100, Lennart Svensson wrote:

When you start gimp from the promptline you got the Application Options: -a, --as-new Open images as new

Why is this not available (as a button) when you open a file inside gimp ?

It is considered useful for applications that want to send images to GIMP by means of opening them from a temporary location. We haven't seen any potential use for it in the user interface so far.

Sven

On Wed, 2010-03-24 at 23:03 +0100, Lennart Svensson wrote:

Sven Neumann wrote, On 2010-03-23 21:38:

On Tue, 2010-03-23 at 14:19 +0100, Lennart Svensson wrote:

When you start gimp from the promptline you got the Application Options: -a, --as-new Open images as new

Why is this not available (as a button) when you open a file inside gimp ?

It is considered useful for applications that want to send images to GIMP by means of opening them from a temporary location. We haven't seen any potential use for it in the user interface so far.

Sven

This button should inhibit the possibility to save the file during editing and destroy the original file. Same as the command line option -a.

You can already do that using "Save As...". I see the point of your request of being able to do that decision when opening the file. But adding yet another way of opening a file would also add complexity to the user interface. Not sure if that's worth it.

Sven

On 03/24/2010 11:03 PM, Lennart Svensson wrote:

Sven Neumann wrote, On 2010-03-23 21:38:

On Tue, 2010-03-23 at 14:19 +0100, Lennart Svensson wrote:

When you start gimp from the promptline you got the Application Options: -a, --as-new Open images as new

Why is this not available (as a button) when you open a file inside gimp ?

It is considered useful for applications that want to send images to GIMP by means of opening them from a temporary location. We haven't seen any potential use for it in the user interface so far.

Sven

This button should inhibit the possibility to save the file during editing and destroy the original file. Same as the command line option -a.

There are plenty of other strategies you can use * Only open copies of files
* Version control your files
* When you discover you overwrote a file, if possible, undo to the initial state of the image and resave

Having a button as you propose is not an elegant solution to the problem you are trying to solve.

BR,
Martin

On 03/24/2010 06:18 PM, Martin Nordholts wrote:

On 03/24/2010 11:03 PM, Lennart Svensson wrote:

Sven Neumann wrote, On 2010-03-23 21:38:

On Tue, 2010-03-23 at 14:19 +0100, Lennart Svensson wrote:

When you start gimp from the promptline you got the Application Options: -a, --as-new Open images as new

Why is this not available (as a button) when you open a file inside gimp ?

It is considered useful for applications that want to send images to GIMP by means of opening them from a temporary location. We haven't seen any potential use for it in the user interface so far.

Sven

This button should inhibit the possibility to save the file during editing and destroy the original file. Same as the command line option -a.

There are plenty of other strategies you can use * Only open copies of files
* Version control your files
* When you discover you overwrote a file, if possible, undo to the initial state of the image and resave

Having a button as you propose is not an elegant solution to the problem you are trying to solve.

BR,
Martin

Martin's options above and Sven's option to open and then do a SaveAs.... all, in my opinion, sort of miss the point.

My observation is that the "OpenAs" protects the user from themself. If a user (myself included!!!) is going is screw up a file, these sensible methods that Martin and Sven list are probably not going to save the user from themself.

However, IF you want to argue that such a user won't think to use (or understand the meaning of) an OpenAs feature, I would probably agree with you. People who need to be protected from themselves often find ways around every such protection. And that includes me. ;-)

For myself, I can see OpenAs being useful.

If Gimp had taskbar kinds of icons (my 2.6.6 on Linux does not; maybe some others do?), I would _not_ include OpenAs on a taskbar by default (but I like configurable taskbars to which one can add icons as one pleases, but that is different subject).

However, I would include OpenAs in the File menu, if there is to be such a feature.

My 2 øre worth...

Jay

P.S. More importantly, please let's be sure that all the file "create" PERMISSIONS are being created correctly. I already posted a bug on this, but I sure am getting tired of files being created with "rw- r-- r--" even though the umask, directory perms, etc., and everything else is exactly as it should be. This may have already been fixed, but I don't have the skills to compile/install or whatever without hiring somebody, which I am too cheap to do until I upgrade my OS from Ubuntu 8.04 to the latest and redo everything.

On Tue, 23 Mar 2010 14:19:29 +0100, Lennart Svensson wrote:

When you start gimp from the promptline you got the Application Options: -a, --as-new Open images as new

Why is this not available (as a button) when you open a file inside gimp ?

If I understand correctly you want to open the same image as the one currently opened, but as separate image ?

If this is what I have understand (?) you can open as many same-but-different image by simply drag and drop the image over the toolbox.

(opening images by drag and drop is always an easier method for me than to browse for a file via the open dialog each time I want to open something; unfortunately the save by drag and drop is not possible :)

Cristi

On Thu, 2010-03-25 at 08:19 +0200, Cristian Secar? wrote:

(opening images by drag and drop is always an easier method for me than to browse for a file via the open dialog each time I want to open something; unfortunately the save by drag and drop is not possible :)

It is possible. You can save an image by dragging the image from the image preview in the toolbox or from the image previews in the Quit dialog (there might be more places, I am not sure...) to a file-manager or desktop that is XDS-aware. Works nicely for me on GNOME 2.28.

http://freedesktop.org/wiki/Specifications/XDS

Sven

On 03/24/10 18:00, Jay Smith wrote:

Martin's options above and Sven's option to open and then do a SaveAs.... all, in my opinion, sort of miss the point.

My observation is that the "OpenAs" protects the user from themself. If a user (myself included!!!) is going is screw up a file, these sensible methods that Martin and Sven list are probably not going to save the user from themself.

If said user is unsure of their own abilities or worried about destroying a file, creating a backup copy (just cp image1.ext image1-bak.ext is an easy enough command to run, with Windows just right click on the file icon, copy, right click on an open part of the file manager or desktop, paste and you wind up with "Copy of image1.ext") is the best solution instead of trying to add complexity to the tool used to edit them.

You could also set the perms on Windows or *Nix to read-only on the original. Both are easy enough to do.

However, IF you want to argue that such a user won't think to use (or understand the meaning of) an OpenAs feature, I would probably agree with you. People who need to be protected from themselves often find ways around every such protection. And that includes me. ;-)

When you make something idiot-proof, the universe creates a better idiot.

For myself, I can see OpenAs being useful.

I disagree for the reasons stated above.

P.S. More importantly, please let's be sure that all the file "create" PERMISSIONS are being created correctly. I already posted a bug on this, but I sure am getting tired of files being created with "rw- r-- r--" even though the umask, directory perms, etc., and everything else

Um, that is. You'll find every file you save will by default rw-r--r--

From my own $HOME directory:

-rw-r--r-- 1 user1 user1 2492 Feb 2 09:32 .vimrc

Or even better, a file that's recently been created:

-rw-r--r-- 1 user1 user1 8336 Mar 25 11:28 .xscreensaver

Those perms give user1 (user, group) read and write permissions and everyone else read permissions (which is how it should be by default). The only time you need execute (x) permissions are on executables and if you want someone else to be able to read them without copying the file to them, just add them to your group.

is exactly as it should be. This may have already been fixed, but I don't have the skills to compile/install or whatever without hiring

Seriously? Even when I was a Linux n00b I was compiling and installing in a matter of minutes. To each their own (and I will say that doing such on Ubuntu is very hard).

On 03/25/2010 04:33 PM, Programmer In Training wrote:

P.S. More importantly, please let's be sure that all the file "create" PERMISSIONS are being created correctly. I already posted a bug on this, but I sure am getting tired of files being created with "rw- r-- r--" even though the umask, directory perms, etc., and everything else

Um, that is. You'll find every file you save will by default rw-r--r--

From my own $HOME directory:

-rw-r--r-- 1 user1 user1 2492 Feb 2 09:32 .vimrc

Or even better, a file that's recently been created:

-rw-r--r-- 1 user1 user1 8336 Mar 25 11:28 .xscreensaver

Those perms give user1 (user, group) read and write permissions and everyone else read permissions (which is how it should be by default). The only time you need execute (x) permissions are on executables and if you want someone else to be able to read them without copying the file to them, just add them to your group.

[I may not have this 101% exactly worded properly, but I am 99.99% sure I have the concept correct.]

The examples you just gave are appropriate for what they are specifically because they are in your own $HOME. Notice that in your example, both user and group are user1. That is appropriate for $HOME, but it is *NOT* appropriate for a wider-access data area in which all images are often edited by multiple staff members.

More appropriate to this discussion would be /somedir/images directories, containing myimage.tif

drwsrws--- 1 user1 mygroup 4096 Mar 25 11:28 somedir

containing drwsrws--- 1 user1 mygroup 4096 Mar 25 11:28 images

containing -rw-rw---- 1 user1 mygroup 35123 Mar 25 11:28 myimage.tif

On *nix Create-file perms should be set by the creating program based on umask / directory perms.

If the perms of the directory /somedir/images look like drwsrws--- user me group mygroup

then if files are created BY A MEMBER of the group "mygroup", files created in /somedir/images should look like rw-rw----

(actually on my system they end up rw-rw-r-- for some reason).

I am speaking simply of file creation, for example, by doing

touch junk.txt

However, Gimp 2.6.6 on Ubuntu 2.04 refuses to create files using the same methods that "every" other *nix programs use.

This bug WAS CONFIRMED as a bug.

This is very important in a multi-user work environment.

Jay

Hi,

On Thu, 2010-03-25 at 16:57 -0400, Jay Smith wrote:

However, Gimp 2.6.6 on Ubuntu 2.04 refuses to create files using the same methods that "every" other *nix programs use.

This can hardly be true in the general sense that you are putting it. Files are created by GIMP plug-ins and how the files are created depends on the implementation of the plug-in. For many formats the actual creation of the file is performed by a library that deals with this particular format. So can you point out the particular file formats that are problematic for you?

Sven

On 03/25/2010 05:39 PM, Sven Neumann wrote:

Hi,

On Thu, 2010-03-25 at 16:57 -0400, Jay Smith wrote:

However, Gimp 2.6.6 on Ubuntu 2.04 refuses to create files using the same methods that "every" other *nix programs use.

This can hardly be true in the general sense that you are putting it. Files are created by GIMP plug-ins and how the files are created depends on the implementation of the plug-in. For many formats the actual creation of the file is performed by a library that deals with this particular format. So can you point out the particular file formats that are problematic for you?

Sven

I finally found the bug report I made: https://bugzilla.gnome.org/show_bug.cgi?id=578630

It was FIXED 2009-06-15 which means that if I can get my Gimp upgraded, then it should work. Unfortunately, I have to depend upon somebody else for that (and get trained on doing it myself, but it is a mission-critical application in our company, so breaking something is not an option).

But, to answer your question....

The problem I am (on 2.6.6) having is with TIF files.

Martin N. confirmed this on April 10, 2009 and said....

=== This happens to me as well and from looking at the code it also happens for gbr, gih, pat, pnm and raw which opens a file for writing like this:

fd = g_open (filename, O_CREAT | O_TRUNC | O_WRONLY | _O_BINARY, 0644);

E.g png instead uses

fp = g_fopen (filename, "wb");

This inconsistency doesn't make any sense, feel free to open a bug report. The latter is identical to the former apart from the permissions, so we probably want to use the latter for all plug-ins.

- Martin ===

Hi,

On Thu, 2010-03-25 at 16:57 -0400, Jay Smith wrote:

On *nix Create-file perms should be set by the creating program based on umask / directory perms.

If the perms of the directory /somedir/images look like drwsrws--- user me group mygroup

then if files are created BY A MEMBER of the group "mygroup", files created in /somedir/images should look like rw-rw----

(actually on my system they end up rw-rw-r-- for some reason).

You obviously did not quite understand how file permissions actually work. The setgid bit which is set on your example directory says that new files and subdirectories created within it should inherit the groupID, rather than the primary groupID of the user who created the file. It doesn't say anything about the permission bits of files created in that directory. The permissions are determined by the mode that is used with the call to open(2) modified by the process's umask.

The typical default value for the process umask is S_IWGRP | S_IWOTH (octal 022). In the usual case where the mode argument to open(2) is specified as:

S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH

(octal 0666) when creating a new file, the permissions on the resulting file will be:

S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH

(because 0666 & ~022 = 0644; i.e., rw-r--r--).

Whether the directory has the setgrp bit set or not does not have an effect on the permissions of the resulting file. It only affects the groupID of the resulting file.

So please stop spreading misinformation like this. You claimed that the described behavior was confirmed a bug. I doubt that it was confirmed by someone who actually knew what he/she was talking about.

Sven

On 03/25/10 16:05, Lennart Svensson wrote:

When using gimp in a shell and open a file r/o you write: prompt> gimp -a picture.jpg

So what I want is to use the '-a' feature when I use 'open image' window. This feature exist in the application but you can only reach it from the shell prompt. So my question is why it is not reachable inside gimp ?

I can live without the feature but if I press Contr-S will my original file be destroyed.

/Lennart

PS. I use the '-a' to inhibit destroying

Use Ctrl+shift+s instead of ctrl+s

Adding the shift opens the "save as" dialog and will not destroy the original.

I don't see the additional complexity as needed since ctrl+shift+s does what you need it to do (preserve the original).

Again, I also suggest copying the file (cp original.ext original.bak.ext) before you begin editing it. I generally use ctrl+shift+s out of habit even if I plan on destroying the original by overwriting it.

Hi,
just.gimp@lesve.org (2010-03-25 at 2205.15 +0100):

I can live without the feature but if I press Contr-S will my original file be destroyed.

C-d to make a duplicate, then close the original.

GSR