I do notice a problem in pressure sensitivity compared to Krita and Photoshop. Take a look at this image that I just drew with my tablet. If you look at the red lines (and particularly the areas pointed to by the blue arrows), you'll see that the transition in brush width is not smooth. In my pressure sensitivity options, 'hardness' and 'size' are turned on. Turning on 'opacity' does not seem to help. For comparison, this is how a line looks like in Krita, and it looks much smoother.
I missed it because the idea never occurred to me. I thought it would have something to do with the Settings dialog, or the specific brush that I selected. The pressure sensitivity option never did anything for me when I'm using a mouse, so after I bought a Wacom the idea never occurred to me to look there. Perhaps this will help with your usability study.
Anyway, I now have one less reason to use Photoshop.:)
"GIMP does support variable brush width based on tablet pressure since version 1.2." It does? How does that work? It supports variable brush transparency, but I can't find variable brush width. Or is that ability limited to the ink tool?
"And yes, it is still being developed and we are very close to finally releasing GIMP 2.4 which will bring lots of new features and usability improvements." That's good news. Good luck.
Interestingly, I was banned from the #gimp IRC channel (actually, banned from the entire GIMPnet IRC network) for reminding the GIMP people about these complaints about the name. Was I being a jerk or are the GIMP developers really elitist like people on Slashdot usually claim?
That's only if the term really is derogatory. Gimp may refer to disabled people, but to me as a non-American, Gimp sounds more like a kind of shoes. Furthermore, Gimp can also refer to a pulp fiction character.
Mono can refer to a decease, to the Spanish word for monkey or to mono/stereo audio. Does the fact that Mono *may* refer to a decease automatically mean nobody should ever use the word "mono" for any product?
I know about that, and I read NEWS from time to time, but look at what has actually been changed. They're mostly bug fixes and relatively minor tweaks, not major features.
Would it really solve your frustrations if each and every open source app have names like these? - Linux Image Studio - EasyMail Professional - Open Vector Drawer - Web Navigator - Open Developer Environment - TextEdit Pro
Huh? This is the first time I hear anybody saying that GIMP 2 is more usable. Even years after the release of GIMP 2 (which was indeed a major UI overhaul) I keep hearing people saying that GIMP is totally unusable.
Then who defines what is "stupid" and what is not? Why are "Skype" and "Adium" better names than "Pidgin"? Why is "Excel" a better name than "OpenOffice Spreadsheet"? (I dare to say that the latter is better!) Why is "mIRC" a better name than "X-Chat"? Why is "Outlook" better than "Evolution"?
Is GIMP still being developed? This is a serious question.
I've been a big GIMP fan for years. Years ago, I was excited about the 2.0 release of GIMP. It brought many new features and the UI got a serious revamp. But now it has been several years, and it seems that GIMP development has slowed down. They're still releasing newer versions with bug fixes, but no new features. For example: I recently bought a Wacom tablet, and while GIMP has Wacom support, I miss some of the things that Photoshop has, such as support for variable brush width based on tablet pressure. The long-awaited GEGL, which was introduced years ago and will supposedly add CMYK and 16-bit support, is still not ready, and to my knowledge is still pre-alpha. (Not that I need CMYK and 16-bit, but at least that silence all the complainers.)
A year or two ago I also read an article about someone wanting to sponsor GIMP development. But that effort went nowhere, as his request was eventually ignored.
What is going on? Is GIMP still being actively developed? Are the GIMP developers still interested in adding new features?
Then how am I, back then a newbie RoR developer, supposed to distinguish Lighttpd "fanbois" from people who are genuinely trying to help me? Especially when RoR-on-Apache documentation was very bad back then (and may still be now)? Somehow you're blaming me for not being able to see the difference?
"Excuse me? I need to tailor my hardware purchases around my operating system? Are you nuts?" If you're an Apple user, then you are doing just that! The only reason why OS X works so well is because Apple controls its hardware market. If you install OS X on a random PC (assuming that can even be done) then millions of people will flood the forums about how much OS X sucks because $RANDOM_HARDWARE is not supported.
"This is all pretty irrelevant. Inexperienced users wouldn't know what to do if they were presented with a command line." But the geeks do. The geeks are the ones to fix the computers. If Windows doesn't even show a commandline then it severely limits the geek's ability to fix the computer.
"These days (i.e. at least the last ten years) you've got to make sure your GUI actually works." The whole discussion is about what happens when the GUI fails. And it *will* fail, one way or another.
"I didn't manage to run RoR on Apache" != "RoR cannot be run on Apache".... You know, you could have asked on any forum instead. Actually, "RoR cannot be run on Apache" is exactly what the people on the RoR mailing list and IRC told me. I asked them what's going on, they told me to stop wasting my time on FastCGI for Apache (which is abandoned, as they claimed) and that I should use Lighttpd instead.
Regardless of whether it can be done, it should be easy. If you have the time nitpicking about my post then why don't you spend your time doing useful things, like writing a correct guide on setting up RoR with Apache?
"What do you think all those RoR servers are running?" Lighttpd or Mongrel. The only site I know that runs RoR on Apache is Dreamhost.
"Great, so you download a.exe from some random website. You have no idea what's in it so you constantly run the risk of getting more spyware/adware/crap installed." What if it's not "some random website"? What if you know that it's good software, but it isn't in any repository?
"Locate package foo. Download it, ensure dependencies are met" Ensure that dependencies are met? Most people don't want to manually hunt down hundreds of dependencies.
"Alternatively download the source tarball and run./configure && make && sudo make install. What's hard about that?" Try explaining that to your mother and your grandmother. You'll find out what's so hard about that.
However, the fact that some software are not in repositories is just as much of a political/social problem as a technical one. It already starts with the question: DEB or RPM? What if I want to produce DEB but I'm using an RPM distro? If I produce a DEB, will it work on all Debian-based distros? (Answer is no, unfortunately.) If I produce an RPM will it work on all RPM-based distro? (No either). What about non-DEB non-RPM distros? Etc. Making an installer on Linux would hide the package format problem, but will not solve binary compatibility problems (FooApp needs libfoo.so.4 but AwesomeLinux only provides libfoo.so.5).
(Followup to my last post.) And for your information: I asked around on the RoR mailing list and IRC channel. Everybody told me that I shouldn't use Apache.
"Wildly incorrect"? Last year I spent 3 days trying to make mod_fastcgi and mod_fcgi work on Apache 2 on Fedora Core 4. I followed virtually all guides that I could find. Each and every one of them was outdated (at least 1 year old, most are 2 or 3 years old). I couldn't get it to work at all - mod_fastcgi keeps saying something about permission denied, even though the permissions are correct according to all the guides that I could find. Disabling SELinux also didn't help. Eventually I gave up and used Lighttpd - and it worked almost instantly.
"Yes, it cannot be run "in" apache, and this is a good thing."
While mod_ruby runs Ruby apps inside Apache, FastCGI doesn't. FastCGI is like CGI but keeps processes around so that they can handle requests more quickly.
"Now, if you serve up say, 5 images and 3 JS or CSS files on a page on average, that means that 5 out of 8 requests will use a bloated webserver process containing RoR, when in reality we need far fewer processes since only 1 in 8 requests actually ever touches ruby code. Less loaded and running code makes a big difference."
Actually, no, on Unix this will make no difference. All modern Unix systems support copy-on-write semantics. When a process forks, the memory between the two processes are shared, until one of the process writes to the memory. When that happens, that part of the memory will be copied. So suppose a hypothetical Photoshop for Linux uses 300 MB memory. If it forks a child process, the child process uses only a few kilobytes of memory, and not 300 MB, because 99% of the memory of the child process is shared with the parent process. When either the parent process or a child process writes to a piece of memory (say, an image buffer), then that memory is copied. Therefore child process cannot change the parent process's memory, even though they may share a lot of memory in the beginning. This is also true for Apache. Even if Apache has loaded RoR and uses 150 MB of memory, a typical Apache child process will only use a few hundred kilobytes.
Slashdot Mirror
Follow-up to my last comment.
I do notice a problem in pressure sensitivity compared to Krita and Photoshop. Take a look at this image that I just drew with my tablet. If you look at the red lines (and particularly the areas pointed to by the blue arrows), you'll see that the transition in brush width is not smooth. In my pressure sensitivity options, 'hardness' and 'size' are turned on. Turning on 'opacity' does not seem to help.
For comparison, this is how a line looks like in Krita, and it looks much smoother.
This may be a thing that one wants to improve.
Ah, thanks.
:)
I missed it because the idea never occurred to me. I thought it would have something to do with the Settings dialog, or the specific brush that I selected. The pressure sensitivity option never did anything for me when I'm using a mouse, so after I bought a Wacom the idea never occurred to me to look there.
Perhaps this will help with your usability study.
Anyway, I now have one less reason to use Photoshop.
"GIMP does support variable brush width based on tablet pressure since version 1.2."
It does? How does that work? It supports variable brush transparency, but I can't find variable brush width. Or is that ability limited to the ink tool?
"And yes, it is still being developed and we are very close to finally releasing GIMP 2.4 which will bring lots of new features and usability improvements."
That's good news. Good luck.
Interestingly, I was banned from the #gimp IRC channel (actually, banned from the entire GIMPnet IRC network) for reminding the GIMP people about these complaints about the name. Was I being a jerk or are the GIMP developers really elitist like people on Slashdot usually claim?
Don't you mean Clippy? :)
Hm? I just tested, and I *can* paint on a floating selection. I can also anchor it by clicking outside the selection area with the selection tool.
That's only if the term really is derogatory. Gimp may refer to disabled people, but to me as a non-American, Gimp sounds more like a kind of shoes. Furthermore, Gimp can also refer to a pulp fiction character.
Mono can refer to a decease, to the Spanish word for monkey or to mono/stereo audio. Does the fact that Mono *may* refer to a decease automatically mean nobody should ever use the word "mono" for any product?
I know about that, and I read NEWS from time to time, but look at what has actually been changed. They're mostly bug fixes and relatively minor tweaks, not major features.
Would it really solve your frustrations if each and every open source app have names like these?
- Linux Image Studio
- EasyMail Professional
- Open Vector Drawer
- Web Navigator
- Open Developer Environment
- TextEdit Pro
Let us call it Open Image Studio. Does that really sound like a better name to you?
I don't understand what is so difficult about it.
GIMP: click 'New layer' in the layers pane.
Photoshop: click 'New layer' in the layers pane.
What is it about GIMP's layer model that confuses you?
Huh? This is the first time I hear anybody saying that GIMP 2 is more usable. Even years after the release of GIMP 2 (which was indeed a major UI overhaul) I keep hearing people saying that GIMP is totally unusable.
Then who defines what is "stupid" and what is not? Why are "Skype" and "Adium" better names than "Pidgin"? Why is "Excel" a better name than "OpenOffice Spreadsheet"? (I dare to say that the latter is better!) Why is "mIRC" a better name than "X-Chat"? Why is "Outlook" better than "Evolution"?
Is GIMP still being developed? This is a serious question.
I've been a big GIMP fan for years. Years ago, I was excited about the 2.0 release of GIMP. It brought many new features and the UI got a serious revamp. But now it has been several years, and it seems that GIMP development has slowed down. They're still releasing newer versions with bug fixes, but no new features. For example: I recently bought a Wacom tablet, and while GIMP has Wacom support, I miss some of the things that Photoshop has, such as support for variable brush width based on tablet pressure. The long-awaited GEGL, which was introduced years ago and will supposedly add CMYK and 16-bit support, is still not ready, and to my knowledge is still pre-alpha. (Not that I need CMYK and 16-bit, but at least that silence all the complainers.)
A year or two ago I also read an article about someone wanting to sponsor GIMP development. But that effort went nowhere, as his request was eventually ignored.
What is going on? Is GIMP still being actively developed? Are the GIMP developers still interested in adding new features?
Then how am I, back then a newbie RoR developer, supposed to distinguish Lighttpd "fanbois" from people who are genuinely trying to help me? Especially when RoR-on-Apache documentation was very bad back then (and may still be now)? Somehow you're blaming me for not being able to see the difference?
Who said anything about developing Ruby on Rails apps? This is about software installation on Linux in general.
"Excuse me? I need to tailor my hardware purchases around my operating system? Are you nuts?"
If you're an Apple user, then you are doing just that! The only reason why OS X works so well is because Apple controls its hardware market. If you install OS X on a random PC (assuming that can even be done) then millions of people will flood the forums about how much OS X sucks because $RANDOM_HARDWARE is not supported.
"This is all pretty irrelevant. Inexperienced users wouldn't know what to do if they were presented with a command line."
But the geeks do. The geeks are the ones to fix the computers. If Windows doesn't even show a commandline then it severely limits the geek's ability to fix the computer.
"These days (i.e. at least the last ten years) you've got to make sure your GUI actually works."
The whole discussion is about what happens when the GUI fails. And it *will* fail, one way or another.
See my replies here.
"I didn't manage to run RoR on Apache" != "RoR cannot be run on Apache". ...
You know, you could have asked on any forum instead.
Actually, "RoR cannot be run on Apache" is exactly what the people on the RoR mailing list and IRC told me. I asked them what's going on, they told me to stop wasting my time on FastCGI for Apache (which is abandoned, as they claimed) and that I should use Lighttpd instead.
Regardless of whether it can be done, it should be easy. If you have the time nitpicking about my post then why don't you spend your time doing useful things, like writing a correct guide on setting up RoR with Apache?
"What do you think all those RoR servers are running?"
Lighttpd or Mongrel. The only site I know that runs RoR on Apache is Dreamhost.
Actually, that's my blog. :)
"Great, so you download a .exe from some random website. You have no idea what's in it so you constantly run the risk of getting more spyware/adware/crap installed."
./configure && make && sudo make install. What's hard about that?"
What if it's not "some random website"? What if you know that it's good software, but it isn't in any repository?
"Locate package foo. Download it, ensure dependencies are met"
Ensure that dependencies are met? Most people don't want to manually hunt down hundreds of dependencies.
"Alternatively download the source tarball and run
Try explaining that to your mother and your grandmother. You'll find out what's so hard about that.
However, the fact that some software are not in repositories is just as much of a political/social problem as a technical one. It already starts with the question: DEB or RPM? What if I want to produce DEB but I'm using an RPM distro? If I produce a DEB, will it work on all Debian-based distros? (Answer is no, unfortunately.) If I produce an RPM will it work on all RPM-based distro? (No either). What about non-DEB non-RPM distros? Etc. Making an installer on Linux would hide the package format problem, but will not solve binary compatibility problems (FooApp needs libfoo.so.4 but AwesomeLinux only provides libfoo.so.5).
(Followup to my last post.) And for your information: I asked around on the RoR mailing list and IRC channel. Everybody told me that I shouldn't use Apache.
"Wildly incorrect"? Last year I spent 3 days trying to make mod_fastcgi and mod_fcgi work on Apache 2 on Fedora Core 4. I followed virtually all guides that I could find. Each and every one of them was outdated (at least 1 year old, most are 2 or 3 years old). I couldn't get it to work at all - mod_fastcgi keeps saying something about permission denied, even though the permissions are correct according to all the guides that I could find. Disabling SELinux also didn't help. Eventually I gave up and used Lighttpd - and it worked almost instantly.
"Yes, it cannot be run "in" apache, and this is a good thing."
While mod_ruby runs Ruby apps inside Apache, FastCGI doesn't. FastCGI is like CGI but keeps processes around so that they can handle requests more quickly.
"Now, if you serve up say, 5 images and 3 JS or CSS files on a page on average, that means that 5 out of 8 requests will use a bloated webserver process containing RoR, when in reality we need far fewer processes since only 1 in 8 requests actually ever touches ruby code. Less loaded and running code makes a big difference."
Actually, no, on Unix this will make no difference. All modern Unix systems support copy-on-write semantics. When a process forks, the memory between the two processes are shared, until one of the process writes to the memory. When that happens, that part of the memory will be copied.
So suppose a hypothetical Photoshop for Linux uses 300 MB memory. If it forks a child process, the child process uses only a few kilobytes of memory, and not 300 MB, because 99% of the memory of the child process is shared with the parent process. When either the parent process or a child process writes to a piece of memory (say, an image buffer), then that memory is copied. Therefore child process cannot change the parent process's memory, even though they may share a lot of memory in the beginning.
This is also true for Apache. Even if Apache has loaded RoR and uses 150 MB of memory, a typical Apache child process will only use a few hundred kilobytes.