8:25 a.m.
Dear GIMP lovers,
for the first time after update to Fedora 17, I've needed to do
some simple edits to a few photos.
Now I feel it is time to say goodbye to GIMP and start saving for
Photoshop ...
There is no point for me in reporting bugs - this is some
fundamental difference between my and the GIMP developers'
thinking ("it is not a bug, it is a feature").
The first thing was that GIMP had asked me if I want the photos
rotated according to EXIF. Hell yes, I can hardly remember any
single case where I wouldn't want this. - There was just a little
problem that I simply don't know which orientation is "standard".
So I was really not sure what to answer, will the photo get
rotated according to EXIF or will it be rotated from EXIF
orientation to the physical orientation of the JPEG data in the
file? And that's where I got the suspicion ...
I wouldn't mind that "resize" got renamed to "scale".
What do I mind is that "Save as" no longer works as before. I
still have the possibility to choose the file extension, however
trying to use "jpg" tells me that it won't save the file as JPEG
and that I have to "export" the file. That sounds very "logical"
when I've opened somefile.jpg and I just want to save it as
someothername.jpg not to overwrite original; I do not want to
"export" to any other format than what was the original.
Ok, so I went to "export", did all the "advanced" settings and
saved the file. Then the same for the rest of files I had
altered. Oh, the JPEG settings dialogue doesn't remember the
settings over the editing session as it always did? The only
possibility not to spent half an hour clicking the same twenty
times in a row is to save the settings as default. But I don't
want these exact settings to be the default ...
Cool, so I've spent half an hour "exporting" the files. So I'm
finished, let's close GIMP. Hey, but what's that dialogue asking
me to save unsaved changes of a file that I have just saved?
Every single file that just got saved is treated as unsaved just
because I was so bold not to use the one and only holy XCF format
for reprocessed JPEGs? Okay, just enough for me ...
Next time I'll rather spend my time studying ImageMagick usage to
script the task even for less than ten images, rather than doing
monkey work.
So, feel free to join me with the moment of silence for the good
old GIMP that is just getting buried.
K.
--
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp kavol(a)jabber.cz
:: "Never attribute to malice what can
:: easily be explained by stupidity."
8:48 a.m.
I agree. The save vs. export thing in the new version of gimp is mind-numbingly stupid.
Sent from my iPhone
On Apr 29, 2012, at 9:25 AM, Karel Volný <kvolny(a)redhat.com> wrote:
Dear GIMP lovers,
for the first time after update to Fedora 17, I've needed to do
some simple edits to a few photos.
Now I feel it is time to say goodbye to GIMP and start saving for
Photoshop ...
There is no point for me in reporting bugs - this is some
fundamental difference between my and the GIMP developers'
thinking ("it is not a bug, it is a feature").
The first thing was that GIMP had asked me if I want the photos
rotated according to EXIF. Hell yes, I can hardly remember any
single case where I wouldn't want this. - There was just a little
problem that I simply don't know which orientation is "standard".
So I was really not sure what to answer, will the photo get
rotated according to EXIF or will it be rotated from EXIF
orientation to the physical orientation of the JPEG data in the
file? And that's where I got the suspicion ...
I wouldn't mind that "resize" got renamed to "scale".
What do I mind is that "Save as" no longer works as before. I
still have the possibility to choose the file extension, however
trying to use "jpg" tells me that it won't save the file as JPEG
and that I have to "export" the file. That sounds very "logical"
when I've opened somefile.jpg and I just want to save it as
someothername.jpg not to overwrite original; I do not want to
"export" to any other format than what was the original.
Ok, so I went to "export", did all the "advanced" settings and
saved the file. Then the same for the rest of files I had
altered. Oh, the JPEG settings dialogue doesn't remember the
settings over the editing session as it always did? The only
possibility not to spent half an hour clicking the same twenty
times in a row is to save the settings as default. But I don't
want these exact settings to be the default ...
Cool, so I've spent half an hour "exporting" the files. So I'm
finished, let's close GIMP. Hey, but what's that dialogue asking
me to save unsaved changes of a file that I have just saved?
Every single file that just got saved is treated as unsaved just
because I was so bold not to use the one and only holy XCF format
for reprocessed JPEGs? Okay, just enough for me ...
Next time I'll rather spend my time studying ImageMagick usage to
script the task even for less than ten images, rather than doing
monkey work.
So, feel free to join me with the moment of silence for the good
old GIMP that is just getting buried.
K.
--
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp kavol(a)jabber.cz
:: "Never attribute to malice what can
:: easily be explained by stupidity."
--
test mailing list
test(a)lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
9:19 a.m.
On 04/29/2012 09:48 PM, Jonathan Kamens wrote:
I agree. The save vs. export thing in the new version of gimp is
mind-numbingly stupid.
Have you used Lightbox and Photoshop from Adobe? Some of their dialog stuff can be
equally complex and counter-intuitive...especially Lightbox. Nothing like paying
money to be frustrated. :-)
--
Never be afraid to laugh at yourself, after all, you could be missing out on the joke
of the century. -- Dame Edna Everage
4:36 p.m.
On Sun, 2012-04-29 at 09:48 -0400, Jonathan Kamens wrote:
I agree. The save vs. export thing in the new version of gimp is
mind-numbingly stupid.
Makes perfect sense to me. It's the same logic used in Audacity. You are
always losing information when 'saving' to an image format - the record
of your edits to the file. You're exporting for production, you're not
saving your work.
BTW, CCing Red Hat internal lists and public lists on the same mail is
very bad form, Karel.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4:45 p.m.
On 05/02/2012 05:36 PM, Adam Williamson wrote:
On Sun, 2012-04-29 at 09:48 -0400, Jonathan Kamens wrote:
> I agree. The save vs. export thing in the new version of gimp is mind-numbingly
stupid.
Makes perfect sense to me. It's the same logic used in Audacity. You are
always losing information when 'saving' to an image format - the record
of your edits to the file. You're exporting for production, you're not
saving your work.
It doesn't make sense for most people, because most people
don't give a
flying fig about "lost information," they just want to edit an image and
be done with it. Optimizing an interface for the minority of people who
use it is not wise, especially when the people who /do/ care about it
are knowledgeable enough to know how to make the program do what they
want even without changing the interface.
You could argue that it might make sense for those people when they're
starting something new from scratch, but when loading an image of a
particular format into GIMP, it should save in that same format by default.
In any case, changing the behavior without making it configurable by the
user, was just totally gratuitous and stupid.
The /smart/ way to accomplish what they were trying to accomplish would
have been to add a File | Import... command, and a corresponding
"--import" command-line option, and a corresponding "Import into GIMP"
context menu item, which takes an image in whatever format is being
imported but then defaults to saving in XCF format.
jik
4:59 p.m.
Another option would have been the LibreOffice approach... Warn the user about saving in a
non-native format but allow it (and allow the warning to be turned off).
Another option would have been for the save dialog to default to FCC but allow the user to
change it to any other format. Instead, it's an entirely separate command to save the
image to the file it was loaded from. Ridiculous.
Jik
5:53 p.m.
On Wed, 2012-05-02 at 17:45 -0400, Jonathan Kamens wrote:
On 05/02/2012 05:36 PM, Adam Williamson wrote:
> On Sun, 2012-04-29 at 09:48 -0400, Jonathan Kamens wrote:
> > I agree. The save vs. export thing in the new version of gimp is mind-numbingly
stupid.
> Makes perfect sense to me. It's the same logic used in Audacity. You are
> always losing information when 'saving' to an image format - the record
> of your edits to the file. You're exporting for production, you're not
> saving your work.
It doesn't make sense for most people, because most people don't give
a flying fig about "lost information," they just want to edit an image
and be done with it. Optimizing an interface for the minority of
people who use it is not wise, especially when the people who do care
about it are knowledgeable enough to know how to make the program do
what they want even without changing the interface.
GIMP is a professional image editing suite, just like Photoshop. It's
not a basic touch-up tool. It doesn't really make sense to criticise it
on the basis that you want to use it for something it's not really
designed to do.
In any case, changing the behavior without making it configurable by
the user, was just totally gratuitous and stupid.
Don't get me started, but I'll give you the short version: it's very
easy to say "well just give me an option to make it do whatever it is I
wanted!", but it's very often not a very good idea for the developers to
actually do so. This is the cause of featuritis, which is in turn the
cause of impossible-to-use interfaces and almost all bugs (which are, at
root, usually the result of code complexity). When your app has a
hundred interface configuration options and consequently, say, a few
billion codepaths, it's almost impossible to anticipate all the
consequences of _any_ code change. Keeping the number of codepaths to
the minimum possible is vitally important to producing stable and
reliable code; implementing any old UI option anyone asks for is a great
way to wind up with an excessive amount of codepaths.
The smart way to accomplish what they were trying to accomplish
would
have been to add a File | Import... command, and a corresponding
"--import" command-line option, and a corresponding "Import into
GIMP"
context menu item, which takes an image in whatever format is being
imported but then defaults to saving in XCF format.
Did you check and see if they considered it and saw some drawbacks to
it, perhaps? Did you try simply suggesting this, to the GIMP authors
rather than the Fedora test list (I'm still not sure why this thread is
here), without the disapproving editorial? As someone else replied to
this thread, it's vital to present criticism with an attitude that makes
the person you're giving it to want to act on it, rather than get
defensive. Saying what they are doing is 'ridiculous', implying that
it's dumb (by saying another way would be 'the smart way'), making
unsubstantiated assertions about 'most people' (have you done a
scientifically supportable poll?), and calling their software
'mind-numbingly stupid' are all excellent ways to make developers more
inclined to be defensive and less inclined to believe that you have
something constructive and useful to suggest.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
6:32 p.m.
Dude, the only reason I continued the discussion here is because you did. :-) You're
right, this is not the place. I'll take it up with the GIMP folks.
Jik
5:31 a.m.
Dne St 2. května 2012 23:53:36, Adam Williamson napsal(a):
GIMP is a professional image editing suite, just like
Photoshop. It's not a basic touch-up tool. It doesn't really
make sense to criticise it on the basis that you want to use
it for something it's not really designed to do.
and which tool are we supposed to use?
so far, Shotwell and Digikam were proposed
but these aren't "basic touch-up tools" either:
Shotwell - A photo organizer for the GNOME desktop
digiKam - A digital camera accessing & photo management
application
K.
--
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp kavol(a)jabber.cz
:: "Never attribute to malice what can
:: easily be explained by stupidity."
6:18 a.m.
On Thu, 2012-05-03 at 12:31 +0200, Karel Volný wrote:
Dne St 2. května 2012 23:53:36, Adam Williamson napsal(a):
> GIMP is a professional image editing suite, just like
> Photoshop. It's not a basic touch-up tool. It doesn't really
> make sense to criticise it on the basis that you want to use
> it for something it's not really designed to do.
and which tool are we supposed to use?
Even if the answer were 'there isn't one', that's not GIMP's fault.
The
GIMP authors want to write a professional photo editor. If no-one wants
to write a simple touch-up tool, that's hardly the GIMP authors' fault,
is it?
so far, Shotwell and Digikam were proposed
but these aren't "basic touch-up tools" either:
Shotwell - A photo organizer for the GNOME desktop
digiKam - A digital camera accessing & photo management
application
And we all know summary lines are always kept carefully up to date and
fully accurate and contain a complete description of all the app's
functionality in their 80 characters or less! (email really needs
a :rolleyes: emoticon).
It's really not difficult to actually _run_ either app and have a look
at what it can do. Shotwell has some pretty basic editing tools - more
'enhancement' than editing - but Digikam has some pretty advanced
functionality these days. See
http://docs.kde.org/development/en/extragear-graphics/digikam/image-edito... , for a
quick indication of what it can do.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
6:49 a.m.
So, I took my concerns over to the gimp-user mailing list, where
apparently this issue has been argued over a number of times.
According to the developer who designed and implemented this change,
GIMP has a "vision" for what it wants to be and a "target audience" of
intended users, and people like me who find the new interface to be
awful "are probably not a targeted GIMP user."
The purpose of the new change was explained during the thread. Several
alternative methods of accomplishing the same purpose without breaking
any existing use cases were described. To every one of them, the
developer responded that those methods either weren't in accord with the
"vision" of the application or would interfere with unspecified
functionality to be implemented later.
The developer in question is perfectly happy with the idea that by
remaining true to its "vision," GIMP is going to drive away many users.
As for alternatives, krita (the RPM is "calligra-krita") and pinta, both
of which are available in Fedora, were suggested for people who just
aren't professional enough to grok the One True GIMP Way.
jik
7:39 a.m.
On Thu, 03 May 2012 07:49:28 -0400
Jonathan Kamens wrote:
The developer in question is perfectly happy with the idea that by
remaining true to its "vision," GIMP is going to drive away many users.
Just another example of the Vogon Effect...
http://home.comcast.net/~tomhorsley/game/rules-change.html
5:12 a.m.
Dne Čt 3. května 2012 07:49:28, Jonathan Kamens napsal(a):
So, I took my concerns over to the gimp-user mailing list,
where apparently this issue has been argued over a number of
times.
thanks a lot; also for sumarising here
As for alternatives, krita (the RPM is "calligra-krita")
and
pinta, both of which are available in Fedora, were suggested
for people who just aren't professional enough to grok the One
True GIMP Way.
krita is more a painting tool than photo manipulating
pinta is a mono bloat - and it doesn't work for me:
[kvolny@kvolny ~]$ pinta
Unhandled Exception: System.ArgumentException: 'gtk-close' is not
a valid resource name of assembly 'Pinta.Resources,
Version=1.2.0.0, Culture=neutral, PublicKeyToken=null'.
at Gdk.PixbufLoader.InitFromAssemblyResource
(System.Reflection.Assembly assembly, System.String resource)
[0x00000] in <filename unknown>:0
at Gdk.PixbufLoader..ctor (System.Reflection.Assembly assembly,
System.String resource) [0x00000] in <filename unknown>:0
at Gdk.Pixbuf..ctor (System.Reflection.Assembly assembly,
System.String resource) [0x00000] in <filename unknown>:0
at Gdk.Pixbuf.LoadFromResource (System.String resource)
[0x00000] in <filename unknown>:0
at Pinta.Resources.ResourceLoader.GetIcon (System.String name,
Int32 size) [0x00000] in <filename unknown>:0
at Pinta.ResourceManager.GetIcon (System.String name, Int32
size) [0x00000] in <filename unknown>:0
at Pinta.ResourceManager.GetIcon (System.String name) [0x00000]
in <filename unknown>:0
at Pinta.Gui.Widgets.OpenImagesListWidget..ctor () [0x00000] in
<filename unknown>:0
at Pinta.OpenImagesPad.Initialize
(MonoDevelop.Components.Docking.DockFrame workspace, Gtk.Menu
padMenu) [0x00000] in <filename unknown>:0
at Pinta.MainWindow.CreateDockAndPads (Gtk.HBox container)
[0x00000] in <filename unknown>:0
at Pinta.MainWindow.CreatePanels (Pinta.WindowShell shell)
[0x00000] in <filename unknown>:0
at Pinta.MainWindow.CreateWindow () [0x00000] in <filename
unknown>:0
at Pinta.MainWindow..ctor () [0x00000] in <filename unknown>:0
at Pinta.MainClass.Main (System.String[] args) [0x00000] in
<filename unknown>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.ArgumentException:
'gtk-close' is not a valid resource name of assembly
'Pinta.Resources, Version=1.2.0.0, Culture=neutral,
PublicKeyToken=null'.
at Gdk.PixbufLoader.InitFromAssemblyResource
(System.Reflection.Assembly assembly, System.String resource)
[0x00000] in <filename unknown>:0
at Gdk.PixbufLoader..ctor (System.Reflection.Assembly assembly,
System.String resource) [0x00000] in <filename unknown>:0
at Gdk.Pixbuf..ctor (System.Reflection.Assembly assembly,
System.String resource) [0x00000] in <filename unknown>:0
at Gdk.Pixbuf.LoadFromResource (System.String resource)
[0x00000] in <filename unknown>:0
at Pinta.Resources.ResourceLoader.GetIcon (System.String name,
Int32 size) [0x00000] in <filename unknown>:0
at Pinta.ResourceManager.GetIcon (System.String name, Int32
size) [0x00000] in <filename unknown>:0
at Pinta.ResourceManager.GetIcon (System.String name) [0x00000]
in <filename unknown>:0
at Pinta.Gui.Widgets.OpenImagesListWidget..ctor () [0x00000] in
<filename unknown>:0
at Pinta.OpenImagesPad.Initialize
(MonoDevelop.Components.Docking.DockFrame workspace, Gtk.Menu
padMenu) [0x00000] in <filename unknown>:0
at Pinta.MainWindow.CreateDockAndPads (Gtk.HBox container)
[0x00000] in <filename unknown>:0
at Pinta.MainWindow.CreatePanels (Pinta.WindowShell shell)
[0x00000] in <filename unknown>:0
at Pinta.MainWindow.CreateWindow () [0x00000] in <filename
unknown>:0
at Pinta.MainWindow..ctor () [0x00000] in <filename unknown>:0
at Pinta.MainClass.Main (System.String[] args) [0x00000] in
<filename unknown>:0
/me is going to file a bug
thanks for the suggestions anyway
K.
--
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp kavol(a)jabber.cz
:: "Never attribute to malice what can
:: easily be explained by stupidity."
6:17 a.m.
pinta is a mono bloat - and it doesn't work for me:
....
/me is going to file a bug
https://bugzilla.redhat.com/show_bug.cgi?id=821398
--
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp kavol(a)jabber.cz
:: "Never attribute to malice what can
:: easily be explained by stupidity."
5:04 a.m.
Dne Čt 3. května 2012 12:18:46, Adam Williamson napsal(a):
On Thu, 2012-05-03 at 12:31 +0200, Karel Volný wrote:
> Dne St 2. května 2012 23:53:36, Adam Williamson napsal(a):
> > GIMP is a professional image editing suite, just like
> > Photoshop. It's not a basic touch-up tool. It doesn't
> > really
> > make sense to criticise it on the basis that you want to
> > use
> > it for something it's not really designed to do.
>
> and which tool are we supposed to use?
Even if the answer were 'there isn't one', that's not GIMP's
fault. The GIMP authors want to write a professional photo
editor. If no-one wants to write a simple touch-up tool,
that's hardly the GIMP authors' fault, is it?
I don't blame anyone for not writing an alternative -
unfortunately, the thing is that until recent version, I was able
to use the "professional" tool for my "amateur" tasks without
much problems
now it breaks my workflow
I like examples so another one:
I'm no professional lumberjack
I'm perfectly happy to prepare some wood for our garden fireplace
using some cheap electric chainsaw from the nearest hobbymarket -
the "amateur tool"
now if someone would give me a "professional tool", some heavy
duty chainsaw like Husqvarna 595 XP, I bet I would have no
problem to use it for my task
why this doesn't work for (some) software? - do really all the
professionals scratch their right ear with left hand?
> so far, Shotwell and Digikam were proposed
>
> but these aren't "basic touch-up tools" either:
> Shotwell - A photo organizer for the GNOME desktop
> digiKam - A digital camera accessing & photo management
> application
And we all know summary lines are always kept carefully up to
date and fully accurate and contain a complete description of
all the app's functionality in their 80 characters or less!
(email really needs a :rolleyes: emoticon).
okay, so you say the sole purpose of these are to be "basic touch
up tools"?
It's really not difficult to actually _run_ either app and have
a look at what it can do.
yep, I've actually run Digikam
the startup takes longer than for GIMP
it trashes my system with useless databases and steals the
control over my files
and manipulating images eats more memory than in GIMP
Shotwell has some pretty basic
editing tools - more 'enhancement' than editing - but Digikam
has some pretty advanced functionality these days. See
http://docs.kde.org/development/en/extragear-graphics/digikam/i
mage-editor.html , for a quick indication of what it can do.
that doc doesn't say (or I don't see it) how to start just the
editor, without all the bloat of "collection management"
K.
--
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp kavol(a)jabber.cz
:: "Never attribute to malice what can
:: easily be explained by stupidity."
1:02 p.m.
On Mon, 2012-05-14 at 12:04 +0200, Karel Volný wrote:
I like examples so another one:
I'm no professional lumberjack
I'm perfectly happy to prepare some wood for our garden fireplace
using some cheap electric chainsaw from the nearest hobbymarket -
the "amateur tool"
now if someone would give me a "professional tool", some heavy
duty chainsaw like Husqvarna 595 XP, I bet I would have no
problem to use it for my task
why this doesn't work for (some) software? - do really all the
professionals scratch their right ear with left hand?
That's not a very good analogy. Chainsaws are designed to do precisely
one thing: cut through certain types of material very quickly. A
'professional' chainsaw is only one that can cut even faster and,
probably, with higher reliability when used frequently. The professional
chainsaw user may cut down more trees more often than the amateur, but
they're both fundamentally _just cutting down trees_.
This is not very comparable with the situation under discussion here,
where the amateur user is likely to be, say, adjusting the brightness of
a photo or rotating it 90 degrees, while the professional user is likely
to be designing the graphics for an entire website from scratch, or
something like that. You see the difference in complexity.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
3:34 p.m.
On Mon, May 14, 2012 at 11:02:36AM -0700, Adam Williamson wrote:
This is not very comparable with the situation under discussion here,
where the amateur user is likely to be, say, adjusting the brightness of
a photo or rotating it 90 degrees,
If you think that "amateur" photo editing is limited to that then indeed
gthumb, or such over overwrought concotion like digikam, will be good
enough. The reality is somewhat different from your limited view.
while the professional user
Anybody involved professionally or "semi-professionally" with
_photography_ will not touch GIMP with a ten foot pole for that simple
reason that GIMP is using 8-bit colour. Nothing particular about
vagaries of a user interface. This is not a snobbery. For a serious
manipulation of photographs, especially raw files, 8 bits is definitely
not enough. Even if GIMP will eventually get a deeper colour I am
afraid that this damage is already done and not likely reversible.
is likely to be designing the graphics for an entire website from
scratch
Websites can be filled with impunity with all kind of graphics junk.
I am not sure what this has to do with complaints from Karel but
apparently some like it one way and some other. Still GIMP is supposed
to be scriptable. Gratituous changes likely to break an untold number
of accumulated scripts do not sound like a sane idea.
Michal
9:40 a.m.
On Sun, Apr 29, 2012 at 10:25, Karel Volný <kvolny(a)redhat.com> wrote:
So, feel free to join me with the moment of silence for the good
old GIMP that is just getting buried.
I share your pain. I've given up on Linux image editors.
For simple stuff (circling text on screenshots, writing text over them) I
just install WINE and use good old Paint Shop PRO 5.0.
It's from the age of Windows 98 yet works wonders for my needs.
Google "PSP501ev.exe". It's damn small too.
Another option is Java Image Editor.
http://www.jhlabs.com/ie/index.html
But sadly it bombs with OpenJDK, it worked fine with JRE. I keep forgetting
to report the bug, I might do it now...
FC
--
During times of Universal Deceit, telling the truth becomes a revolutionary
act
- George Orwell
7:27 a.m.
Dne Ne 29. dubna 2012 11:40:49, Fernando Cassia napsal(a):
On Sun, Apr 29, 2012 at 10:25, Karel Volný <kvolny(a)redhat.com>
wrote:
> So, feel free to join me with the moment of silence for the
> good old GIMP that is just getting buried.
I share your pain. I've given up on Linux image editors.
For simple stuff (circling text on screenshots, writing text
over them) I just install WINE and use good old Paint Shop PRO
5.0. It's from the age of Windows 98 yet works wonders for my
needs.
Google "PSP501ev.exe". It's damn small too.
which reminds me ... I want my pmail.exe back ... and irfanview
... oh, those early win95 days ... where is all the free software
that was able to do exactly what I needed to do (about the same I
need now) with hundreds times less resources?
many years of development passed, and kmail is still unable to
join divided messages ... and recently it has lost the search
ability, all I get now is the message:
'The Nepomuk semantic search service is not available. Searching
is not possible without it. You can enable it in "System
Settings".'
wohoo, back to trees, is pine still in repos?
Another option is Java Image Editor.
http://www.jhlabs.com/ie/index.html
But sadly it bombs with OpenJDK, it worked fine with JRE. I
keep forgetting to report the bug, I might do it now...
FC
yes, please do that, report the bug if you like the software,
contribute to the development ... it's just that I don't like
GIMP any more ;-)
K.
--
Karel Volný
QE BaseOs/Daemons Team
Red Hat Czech, Brno
tel. +420 532294274
(RH: +420 532294111 ext. 8262074)
xmpp kavol(a)jabber.cz
:: "Never attribute to malice what can
:: easily be explained by stupidity."
4362
days inactive
4377
days old
19 comments
7 participants
participants (7)
-
Adam Williamson -
Ed Greshko -
Fernando Cassia -
Jonathan Kamens -
Karel Volný -
Michal Jaegermann -
Tom Horsley