create07 at sfina.com
Tue Aug 31 06:10:17 PDT 2010
On August 31, 2010 03:16:25 am a.l.e wrote:
> but if you write that gimp is like photoshop
gimp is not like photoshop. gimp is a tool used to edit bitmap images.
photoshop is a tool used to edit bitmap images. they have the same purpose,
but they are not alike. analogy: a train brings you from A to B, and a car
brings you from A to B. they have the same purpose but they are not alike.
Sometimes you'll find the first one more convenient, sometimes the other one.
And other times it will be a plane.
> i won't start discussing what happens when the LG (or any software
> which is not called photoshop) does the same task in a slightly
> different way or misses some features.
software A vs. software B.
COMPETING WAYS OF DOING THE SAME THINGS:
1a - A is superior than B
1b - B is superior than A
2 - neither A not B is superior
* (1a+1b): the developers of the inferior tool best course of action is to
swallow their pride and learn from the developers of the superior tool.
Example: I have always complained about the handling of timestamps in
Nautilus when I was using Ubuntu and in Dolphin since I use Kubuntu. Nautilus
has bin fixed to more than a year ago; Dolphin finally followed with 10.4. I
still used the CLI command `copy -a` by habit, but I have timidly started to
use drag & drop like I do in Windows and OSX.
* (2): the users should choose what works better for them. Or if they are so
convinced that their way is superior, they can fork the code if the software
note that this applies to all software, Free or Proprietary. Free just gives
the user more options, so all other things being equal, Free is inherently
superior, except for the irrational user that belongs to the cult of the
follower of the dictator of the forbidden fruit. Warning: this kind of cults
can easily develop in the Free world too.
IMHO, when (2) is the case, it is the time to have a hard look at whether
adding a preference and supporting the two ways of doing the same thing is an
COMPLEMENTARY TOOLSET (the missing feature): feel free to
a - add the feature
b - complement tool A with tool B
Besides the practical difficulty of (a) - most users don't have the coding
skills nor the resources to pay for a coder - one must also consider whether
the perceived lack of the feature is a feature in itself. Inkscape and sK1
are both SVG editing tools, but they have different purpose.
In my toolbox, gimp and photoshop are complementary. Where the tools overlap
I use the one that I feel more comfortable with and my decision in this case
is driven by how good and fast I am at doing the task with tool A vs. tool B
and not by LG vs. PG). It's not a statement about the tools, but about
Where they don't overlap I'm happy that they share some common file formats by
which I cam shift my work from tool A to tool B and back.
In a perfect world interoperability is symmetrical: tool A supports files of
tool B and vice versa. In the real world sometimes there are practical
constraints as in Inkscape and sK1 not supporting the same SVG subset; and
sometimes there are tactical ones as in PG setting roadblocks to keep the user
in their walled garden by
- not providing import filters (gimp imports PSD quite decently, but Photoshop
does not even know about XCF . Shame on Adobe
- even worse, the Adobe SDK comes with strings attached that prevent devs from
writing Open Source code based on the file format documentation. So Free
developers must reverse engineer it. Shame on Adobe again.
Exposing those negative tactics should IMHO be part of an informative website
targeting users of all G-software. But it's a couple of levels deep down.
Users generally don't care about PG vs. LG (yes, I know they should). They
care about whether they will be able to access their files twenty years down
the road; and whether they will be able to use the tools they are acquainted
with twenty years down the road.
If for whatever reason a user preferred Hugin-0.7.0 to Hugin-2010.2.0 (a LG
tool to make panoramas), they can go back to the source code and build it /
adapt it to their newest O/S.
If for whatever reason a user preferred PTgui 5.0 to PTgui 9.3 (a PG tool to
make panoramas), they can only hope the binary installer will work on their
> my stand is: we should take the effort to describe what our software
> does, independently of which other packages do something similar.
exactly. and we should describe what our software does in relationship to its
purpose / use - not to its tech specs, features and licenses.
> this discussion started in a very promising way, but i have the feeling
> that this thread is going nowhere...
> it's a lucky hazard that you, yuval, in your next mail say more or less
> exactly what i wanted to write and you do it in a brilliant way...
> i guess i should start to read (and answer) my mails from the bottom up!
I don't think it's a lucky hazard. You will notice a pattern in my last few
posting, with exception of this thread: I always started a new thread. I did
it also this time  - mostly to avoid energy dissipating arguments.
In this last case, I did not find an optimal way to place the message that
unlike you, I find plenty of websites which
| talks to b (graphics
| enthusiasts and professionals) and c (users of PG who do not know
| about LG) and to
| i - users of PG who have heard about LG
| j - users of PG who have already been using LG without knowing it and
| now want to check what else can the LG offer
when I google for topics such as "layer masking tutorial".
It was also an experiment to understand our way of interaction. We are biased
toward argument-counterargument threads that do make sense when discussing
technical details. We sometimes lack the overview to consider the big picture
implication of seemingly simple details.
This is what happened with the argument whether to mention or not PG in a
software directory. Most comments I read implicitly assume there is only one
way to do it: LG software A is like PG software B. Getting rid of this
assumption is what I've been trying to achieve in the past few weeks. Is this
bug fixed now?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the CREATE