On Sat, May 16, 2009 at 3:38 PM, Martin Nordholts wrote:
One notable change is that Ctrl + E is now bound to File-Export by
default instead of View-Shrink Wrap. Hopefully this change will not be
too much of a pain. We may need to consider finding a new keyboard
shortcut for View-Shrink Wrap.
Alexandre wrote:
On Sat, May 16, 2009 at 3:38 PM, Martin Nordholts wrote:
One notable change is that Ctrl + E is now bound to File-Export by
default instead of View-Shrink Wrap. Hopefully this change will
not be
too much of a pain. We may need to consider finding a new keyboard
shortcut
peter sikking wrote:
after checking out Inkscape and Scribus, I think Alexandre just
added another valid factor, which means that the balance just
tipped the other way:
Export should be shift-ctrl-E
'Export to org.file' should be ctrl-E
Makes sense, I'll swap the shortcuts. It is quite
Martin Nordholts wrote:
Hi
I have been working on implementing the Save + export spec [1] for a
while.
And I have also merged the base work to GNOME master now, so to try it
out all you have to do is git pull. There is still work to be done (see
the merge commit message) but we are
Michal wrote:
This is a point that Martin and I discussed on irc.
Here is the main point that the changes are clarifying is:
a file is only safe when it is Saved (in xcf)
this means that export is never the solution to unsaved changes and
Export and Export to foo.png cannot be there in
Hi all,
peter sikking schrieb:
foo.png was never inside GIMP. it was an xcf that had foo.png as a
starting point. we try to reflect this in every way. one way that came
up during LGM discussions was that the layer should be always
(even for background) be named after the image that was
peter (yahvuu) wrote:
peter sikking schrieb:
foo.png was never inside GIMP. it was an xcf that had foo.png as a
starting point. we try to reflect this in every way. one way that
came
up during LGM discussions was that the layer should be always
(even for background) be named after the
Can one guarantee GIMP compositions will be at least correctly rendered
with third-party viewers as image browsing is not in GIMP goals? At
least recently xcf has been considered as internal GIMP format. Having
thousands files what cannot be easily and quickly viewed and organized
is not a
On Wed, May 13, 2009 at 9:57 AM, Alexander Rabtchevich wrote:
Pleasant interactive cropping
In fact tools like Lightroom or Rawstudio beat GIMP for me when it
comes to cropping of photos -- for reasons multiple times explained to
GIMP developers.
and scaling, required for web are enough
Alexander Rabtchevich wrote:
Can one guarantee GIMP compositions will be at least correctly rendered
with third-party viewers as image browsing is not in GIMP goals? At
least recently xcf has been considered as internal GIMP format. Having
thousands files what cannot be easily and quickly
I suspect thumbnailing will not be enough. Let's see an example of
high end workflow for photography. One has taken a bunch of RAW
images. He has to browse them and compare, delete the bad ones. Then the
images need conversion with desired comparing at that stage and the
selection goes on...
Michal wrote:
first of all, thanks for trying it out and commenting.
My comments and observations:
1. When I try to save and I change extension to (for example) .png,
GIMP
message appears:
You can use this dialog to save to the GIMP XCF format. Use File-
Export to
export to other file
While I haven't tried the new behavior, I would like to be able to see
either I have made any changes after the export in the title bar or not.
Now it is indicated with a star. I prefer to see it remained.
2. When I open image foo.png, do some changes and close it, GIMP
message
says:
Save
Alexander Rabtchevich wrote:
While I haven't tried the new behavior, I would like to be able to
see either I have made any changes after the export in the title bar
or not. Now it is indicated with a star. I prefer to see it remained.
that would mean we needed two indicators, one that is
I think you are too biased towards xcf as an everyday storage format. It
is not needed very often, at least for now. May I provide my usual workflow?
1. I take pictures in RAW.
2. I convert the pictures I liked in UFRaw and save the result in jpg
with maximum quality (1:1:1, floating point,
Alexander Rabtchevich wrote:
I think you are too biased towards xcf as an everyday storage
format. It is not needed very often, at least for now. May I provide
my usual workflow?
I read your workflow and I am confident that when you try it out
you will find that we support it well with
Peter, I think you (or me :) ) will be surprised if know the statistics
on the percentage of photos which really need complex retouching or
complex actions with layers. The most common cases I can give are face
retouching, repairing of a photo with too high dynamic range or
correcting
On Tue, May 12, 2009 at 9:16 PM, Alexander Rabtchevich wrote:
correcting perspective distortion. If a photo is properly exposed, has
not excessive noise and is not a portrait of a person you need to
improve, there is no need to retouch it after proper RAW conversion.
And therefore there is no
On Tue, May 12, 2009 at 6:16 PM, Alexander Rabtchevich
alexander.v.rabtchev...@iaph.bas-net.by wrote:
Peter, I think you (or me :) ) will be surprised if know the statistics
on the percentage of photos which really need complex retouching or
complex actions with layers. The most common cases I
Pleasant interactive cropping and scaling, required for web are enough
reasons. Red eyes reduction sometimes... Why should one use something
other if the tool he uses most of the time is convenient and powerful?
The above mentioned actions are not too complicated to be reproduced in
one
On Thursday, May 7, 2009, 0:24:12, Martin Nordholts wrote:
I have been working on implementing the Save + export spec [1] for a while.
Since it will affect the workflow for basically everyone it would be nice
with getting some testing and comments before we finalize
I built a Windows
Quoting Martin Nordholts ense...@gmail.com:
I have been working on implementing the Save + export spec [1] for a while.
:
:
Comments very much appreciated!
I haven't GITified my development yet and thus have not tried your
implementation. If your request for comments is only on the
On Thu, May 7, 2009 at 7:54 AM, Martin Nordholts ense...@gmail.com wrote:
Hi
I have been working on implementing the Save + export spec [1] for a while.
Since it will affect the workflow for basically everyone it would be nice
with getting some testing and comments before we finalize, merge
2009/5/7 David Gowers 00a...@gmail.com
patch #0010 fails:
Did you pull from GNOME master before you applied the patches? I should have
said that the patches requires latest GNOME master. If you apply the patches
on top of commit 9c2aae1281d.. you should be fine.
This works REALLY well! I 3
2009/5/7 saulgo...@flashingtwelve.brickfilms.com
If your request for comments is only on the
implementation and you are not expecting comments on the export spec
itself, I apologize for the following question:
Shouldn't the Save a copy... menu item be eliminated since its
functionality can
On Thu, 2009-05-07 at 17:08 +0200, Jernej Simončič wrote:
[...]
Show me one person outside GIMP developer community that thinks this
is a sane change.
I don't think many people think it's a sane change, but that's
not the right question. The question is, will the resulting
interface be good?
Show me one person outside GIMP developer community that thinks this
is a sane change.
Totally irrelevant comment, if you ask me; this is a patch on a
development version. Not many
users will have tried it. Sure, there's the windows installer, but it
remains a development version
and an
27 matches
Mail list logo
