Weekly Edition
Return to the Development page
| |||||||||||||
Sobotka: Why GIMP is inadequate
Troy Sobotka looks
at problems with the GIMP and its development state. "How is it
that the flagship imaging application struggles along with only two
principal developers working on it and an alternate project such as Blender
is absolutely thriving in Libre software? To an outsider, this might be
interpreted as a symptom of a lower level dysfunction."
(Log in to post comments)
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 13:14 UTC (Tue) by dwmw2 (subscriber, #2063) [Link]
Article lacks bug numbers.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 13:58 UTC (Tue) by boudewijn (subscriber, #14185) [Link] Well, all three main points -- 16 bit rgb, linear light rgb and performance with large brushes -- are all well known, and the first one even does have a bug report (https://bugzilla.gnome.org/show_bug.cgi?id=74224) and that big brushes are slow is reported as well (https://bugzilla.gnome.org/show_bug.cgi?id=304798, though I guess that also the painting itself should be faster according to the original author). And nobody is denying that these are problems: the first two problems are supposed to go away once gegl gets properly integrated, and Alexia Death is doing extremely cool things with the painting engine in Gimp -- as well as willing to integrate gimp-painter patches. But what you mean, I guess, is "Nobody should talk about problems and deficiencies in an open source application without filing the bugs and proving that to me!" And that seems to me unfair. Not that I think that this guy has hit the nail on the head -- he seems completely unaware that there's actually work going on in all areas, he mentions Krita's decision to focus on painting, being unaware that it was Gimp's interaction design maintainer Peter Sikking who helped us reach that decision, just as he previously helped the Gimp team make the decision to go for high-end image manipulation. Gimp hasn't reached that goal yet, and I guess it'll take a long time, but the team knows what they want and they have a plan to reach their goal. More power to them! They are doing some things right: a rigorous focus on stability (with to me, as Krita developer, enviable results), an interaction design maintainer who really watches over the interaction design (also with enviable results), a large support community in forums and a fame that attracts capable graphics coders for special features and experiments. But it takes time to reach a goal once you've set yourself one. (I think there are problems in the gimp development, but those aren't mentioned in this article: gimp is extremely hard to contribute to because the codebase is huge (10 times as big as Krita), all in C, with a very strict coding style, not very modularized, not very well documented, with a development team that's not exactly known for welcoming newcomers. Also, Alexia Death seems to me to be right if she says that what Gimp needs now is a dedicated GTK hacker, because GTK is so broken (https://lists.xcf.berkeley.edu/lists/gimp-developer/2011-January/026012.html) that they cannot implement many of Peter Sikking's design because GTK won't allow it.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 14:12 UTC (Tue) by dwmw2 (subscriber, #2063) [Link] 'But what you mean, I guess, is "Nobody should talk about problems and deficiencies in an open source application without filing the bugs and proving that to me!" And that seems to me unfair.'When talking about bugs in any software, it's useful to ensure that they have been reported coherently. And then to refer to the bug reports directly when discussing them. In this particular case there was little chance that the bugs hadn't already been reported, but it would still have been useful to give links to bugzilla, so that anyone interested in them could easily track the progress and get notification when they are (potentially) fixed. It is simply a good habit to get into, and a sign of responsible discussion. Nothing annoys me more than people whining in public fora about bugs that they haven't even bothered to report to the developers. Not that that's what was happening in this case, of course, but still I do expect people to be in the habit of citing bug numbers. Thanks for providing them.
Don't think everyone is a developer Posted Jan 13, 2011 13:28 UTC (Thu) by khim (subscriber, #9252) [Link] Nothing annoys me more than people whining in public fora about bugs that they haven't even bothered to report to the developers.You may not like it, but it's not something to fight against: people rarely report problems do developers. If the car's steering wheel is too tight you may find the information on forum for said car, but rarely (if ever) it'll be reported to developers. People apply the same logic to the software, too. If you think it's alloying it's your right, but try to change the people in this regard is as futile as the try to force everyone to use "GNU/Linux" term.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 14:29 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
>Alexia Death
Now that's a cool name.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 15:07 UTC (Tue) by alvieboy (subscriber, #51617) [Link]
According to website http://alexia.death.pri.ee/about/
" Alexia Death, obviously, is not a real name, but an alias, an artists name if you will and no matter how much I hate my real name, this is how it must stay. The name itself developed in high school, one of the worst periods in my life. Death was the part of me that had been trampled down and killed by years of harassment and teasing, Alexia was the little girl I had been before feeling the guilt of life. The rest was nothing, a void full of echoes. "
Always interesting :)
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 14:32 UTC (Tue) by sorpigal (subscriber, #36106) [Link] It seems ironic that GTK flaws are holding back the GIMP, given the history of the two projects.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 20:08 UTC (Tue) by daniel (subscriber, #3181) [Link]
In my humble opinion, GTK is a boat anchor around the neck of any project. That a number of projects manage to make progress despite this handicap is a testament to the sheer stick with it ness of a few key soldiers. The other great boat anchor is C, as was noted above. Having been coding C continuously for 30 years in projects both big and small, I can say with some confidence that for any project over a thousand lines long, C sucks. A lot. For almost anything, with the exception of heavy array manipulation where C++ lacks modern features such as variable sized arrays and designated initializers. Such number crunching can easily be compiled as separate units where the C's paucity of high level organizational constructs does very little damage.
I am a heavy user of Gimp and I love it. But the C-ishness really shows. I would strongly suggest adding at least a few islands of C++ code. Feel the quality of the goods and all that. Perhaps contrary to popular wisdom, C++ can be called perfectly well from C code, so no wholesale re-engineering is necessary, the sort of project that never gets finished because it takes too long to get to a usable state. Incremental intrusions of sanity is the way to go.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 20:52 UTC (Tue) by Trelane (subscriber, #56877) [Link]
> GTK is a boat anchor around the neck of any project.
> ... > I would strongly suggest adding at least a few islands of C++ code. Feel the quality of the goods and all that. Perhaps contrary to popular wisdom, C++ can be called perfectly well from C code, so no wholesale re-engineering is necessary, the sort of project that never gets finished because it takes too long to get to a usable state. Incremental intrusions of sanity is the way to go.
HTH.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 9:36 UTC (Wed) by romanfi (guest, #72329) [Link]
Trelane wrote:
That's not as good as Qt. It really doesn't make much sense to build a GUI toolkit on top of C, and a GUI toolkit is crying for object oriented designs, and then write a C++ wrapper around it.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 15:36 UTC (Wed) by Trelane (subscriber, #56877) [Link]
>That's not as good as Qt.
In what (concrete) way?
>It really doesn't make much sense to build a GUI toolkit on top of C
because....?
>a GUI toolkit is crying for object oriented designs
Yes, and that's why it's object-based (GObject is the root object).
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 5:54 UTC (Thu) by romanfi (guest, #72329) [Link]
Trelane wrote:
> In what (concrete) way?
- compatibility between platforms
- documentation
- structure of GUI components
- stability
- the designer IDE (here I'm not 100% sure)
- L&F
> because....?
A GUI is composed of elements that in some natural way inherit from each other. E.g. there are push buttons, radio buttons, which are all buttons. And buttons and many other elements are widgets. The main windows, dialogs and so on are frames or windows.
Motif already had an object oriented design, implemented using standard C. They even had public and private data members, faked using two header files defining two structures for every element, one of them for Motif itself, including the private members, the other one with just the public part, layout compatible. They've got virtual functions, implemented with function pointer arrays, and so on. And I can see the same thing in GTK.
So why not using the right tool for the job?
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 20:09 UTC (Thu) by daniel (subscriber, #3181) [Link]
You omitted the biggest issue: casts. C makes you do this, the result is a nasty abomination. Been there.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 20:55 UTC (Thu) by Trelane (subscriber, #56877) [Link]
Perhaps you mean C-style casts? You still have to cast in C++, but it looks different and often does it implicitly (which can be a bad thing, see also passing a Manager to a function accepting an Employee instead of reference to Employee, as discussed in Stroustrup).
Sobotka: Why GIMP is inadequate Posted Jan 18, 2011 17:56 UTC (Tue) by daniel (subscriber, #3181) [Link]
"Perhaps you mean C-style casts?"
I meant pointer casts that attempt to simulate a C++ class hierarchy using C structs with casts.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 20:53 UTC (Thu) by Trelane (subscriber, #56877) [Link]
> compatibility between platforms
This is pretty nebulous. Please be specific in what ways Qt is better than gtkmm in this regard.
> documentation
Again, this is very nebulous. Be specific.
> structure of GUI components
Yet again, this is not at all specific. What precisely is better about Qt's "structure" than gtkmm's? List examples where you can.
> stability
This is simply a laundry list of things that are "better" (and most of the items aren't concrete examples of anything; they're categories) and nothing more. Please be specific with your argument and back it up with examples.
I'm going to learn Qt for maemo, so I hope to be less ignorant of Qt in the near future, as time permits. I do have a degree of experience in gtk and gtkmm, so I want to know what you think is failing (and perhaps even fix it). I can't fix "documentation"; I can fix the fact that there aren't any tutorials on how to frob the critical blort property in gtk/gtkmm, though.
> A GUI is composed of elements that in some natural way inherit from each other. E.g. there are push buttons, radio buttons, which are all buttons. And buttons and many other elements are widgets. The main windows, dialogs and so on are frames or windows.
Honestly, right here you sound like you haven't even looked at gtk+/gtkmm documentation, let *know* anything at all about it.
How about looking at the "Object Hierarchy"
> So why not using the right tool for the job?
I think you've confused me for you. I'm wondering why you think gtk+ is inferior to Qt in all situations (implicit in the statement "[gtkmm is]That's not as good as Qt." which is without qualifications. I don't mind Qt at all, and would like to improve gnome/gtk.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 21:00 UTC (Thu) by Trelane (subscriber, #56877) [Link]
Heh. I missed the thread. never mind the latter part. :)
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 20:51 UTC (Wed) by prokoudine (guest, #41788) [Link]
> That's not as good as Qt.
And yet the best free vector graphics editor, Inkscape, is written in GTKMM.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 6:08 UTC (Thu) by romanfi (guest, #72329) [Link]
okoudine wrote:
> And yet the best free vector graphics editor, Inkscape,
GTKMM is an object oriented wrapper using an object oriented programming language around an object oriented design using a non object oriented programming language. For me, that's a quirk or suboptimal workaround.
And, can you prove that GTKMM wouldn't have been better in terms of
- easier design
- faster design and/or coding
- better L&F (yes, I work with inkscape from time to time)
when using e.g. Qt instead of GTK(MM)? Because all the arguments I listed above in my answer to another posting still hold true, e.g. compatibility across platforms, documentation, stability, etc.
If Qt would already hade been GPL when the developers started writing Goll and Sodipodi, do you think they would have had selected this one instead of Qt?
Of course, one aspect must never be forgotten. Would be GTK(MM) as good as it is now without Qt, and would Qt be as good as it is now without GTK(MM)? I think you understand what I want to say with this last sentence.
Please forgive me my bad english, it's not my mother's language.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 6:16 UTC (Thu) by DOT (subscriber, #58786) [Link]
One counter-argument trumps all others: Qt uses the dreaded MOC. Yes, stupid argument. Stupid language wars.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 20:17 UTC (Thu) by daniel (subscriber, #3181) [Link]
"Qt uses the dreaded MOC"
Big deal, its better than casts. Even the original QT developers agree SigC++ or similar would have been better solution but these didn't exist at the time. The practical impact on design is negligible.
By the way "dreaded" is inappropriate rhetoric in this context. You might as well say the same of the the C preprocessor.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 22:12 UTC (Thu) by DOT (subscriber, #58786) [Link]
Of course it's inappropriate. That's the point. This whole discussion is fucking tiresome.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 3:01 UTC (Wed) by bug1 (subscriber, #7097) [Link]
"Having been coding C continuously for 30 years in projects both big and small, I can say with some confidence that for any project over a thousand lines long, C sucks. A lot."
The Linux kernel (and the majority of Free software projects) are doing it all wrong ?
What sucks, is when experienced programmers think a language makes large projects complex. They should instead acknowledging the complexity of design.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 9:47 UTC (Wed) by romanfi (guest, #72329) [Link]
bug1 wrote:
> The Linux kernel (and the majority of Free software projects)
Does the kernel have a GUI? Not really ... except ... xconfig is coded using C++, in Qt3 oder Qt4, depending on the kernel version.
The kernel code itself is full of object oriented designs, be it the kobjects, SCSI, ATA, DMA, MMU and almost all of the low level drivers as well, be it inheritance, virtual functions, inline functions, member functions, namespaces, etc. It all has to be programmed in C, Motif did and does something similar, resulting in code that's not readable that much.
One of Linus' arguments also was that many programmers just do not know how to code in C++. Then my question is, following this argumentation, why's the kernel not written using compiled BASIC? ;)
The argument C is good to piss of bad C++ programmers is only acceptable because Linus "invented" Linux, because there are at least as many good C++ programmers as there are C programmers.
Of course you can create bad designs using C++, but when I look at horrible macro constructs to circumvent C's shortcomings, the you'll have to admit, that the language itself is no reason to create or avoid horrible designs.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 11:32 UTC (Wed) by HelloWorld (guest, #56129) [Link]
> The Linux kernel (and the majority of Free software projects) are doing it all wrong?
It may be debatable for low level projects like the kernel; there were probably no good alternatives around in 1991. But for an application like the Gimp, C is about as bad as it gets. Yes, they did it wrong.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 11:44 UTC (Wed) by boudewijn (subscriber, #14185) [Link]
Well, back when Gimp started, there wasn't much choice either. They even started with motif... And it's not fixable, but I am convinced that it's a problem for interested newcomers to have to write in C within the constraints of the gobject system.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 12:04 UTC (Wed) by anselm (subscriber, #2796) [Link] The GIMP developers might have started by implementing a pixel-based image editing widget for Tk, which was very much available at the time. That would have saved them from having to come up with a complete graphics toolkit, freeing that many resources for the development of the actual image editor in the process, and might even have changed the GUI toolkit landscape considerably (since somebody else would have had to come up with Gtk). But then again NIH remains a potent incentive to reinvent the (square) wheel.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 20:20 UTC (Thu) by daniel (subscriber, #3181) [Link]
However much GTK sucks, Tk sucks more.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 21:43 UTC (Thu) by anselm (subscriber, #2796) [Link] Thank you for this well-reasoned contribution :^) Speaking as somebody who has done Tk development at a variety of levels, including Tk widgets in C, I'm personally convinced that Tk doesn't actually suck all that much. Certainly not enough to write a whole new toolkit instead – Tk did have its shortcomings but they aren't anything that the application of developer effort on the order of that wasted on Gtk wouldn't have been able to sort out (as, in fact, many of them have indeed been sorted out over the years). YMMV.
Sobotka: Why GIMP is inadequate Posted Jan 18, 2011 18:35 UTC (Tue) by daniel (subscriber, #3181) [Link]
"Thank you for this well-reasoned contribution"
Fair comment. Like many projects, Tk gets better with age. I have always basically hated every single interface I have ever used that is implemented in Tk (e.g., Gitk) but who knows, maybe it got better recently. I picked tkdesk as a representative example. Installed it, did a file open, and saw that much of what I'd expect to be present in a modern file dialog is actually there. And the mouse and keyboard interaction is basically OK and what you would expect. The icons less than pretty and lack text labels, a failing I have long associated with Tk. Theming is just the basic ugly Tk look. Then things started going south, Tk toolbar icons started painting themselves on top of my other windows. I closed the main tkdesk but the toolbar refused to go away. I right click on the topmost toolbar icon, which has no label, I just guess there could be some forward progress there and a menu pops up... *under* the toolbar. I go back to my browser to continue this report and the toolbar icons are now overlaid on top of my text entry window, and now right clicking on the toolbar has no apparent effect.
Basically, a bucket of bugs. This is exactly the sort of mess I have come to associate with a program that grew beyond the ability of the underlying framework to structure it. So I stand by my initial overly curt characterization of Tk. IMHO, the only practical cure is to migrate to a better structured language.
By the way, I'm still trying to figure out how to get rid of tkdesk and its phantom icons. Xkill didn't work. Time to kill -9.
Sobotka: Why GIMP is inadequate Posted Jan 19, 2011 21:37 UTC (Wed) by anselm (subscriber, #2796) [Link] I don't think I would want to judge a toolkit based on a single »representative« application. I've seen Tk applications that work really well, as well as applications using other toolkits – such as Gtk or Qt – that really suck. In general, this probably tells us more about application developers than toolkit developers. As far as Tkdesk is concerned, I just installed the Debian package and gave it a quick spin. The first thing that occurs to me is that the splash screen says »2004«. I wouldn't say that this is an application that is representative for Tk as of 2011, just like a 2004-vintage Qt application would not be representative for Qt as of 2011. (In 2004, Qt was still at version 3, and the fact that, e.g., the KDE project decided to rewrite basically their whole desktop environment for Qt 4 should give one pause. I don't recall having to rewrite lots of code, either at the Tcl or C level, for Tk version changes, not since Tcl/Tk 8.0 at least, which came out in 1997.) I didn't notice any of the adverse effects you describe but many of these sound suspiciously like window manager issues (rather than Tk issues). The icons are a matter of taste (I don't find them that hot either), but it does not seem entirely fair to compare them to the SVG-based icon sets that desktop environments like KDE, with a much larger number of artists behind them, have acquired in the meantime. Even within the Tcl/Tk community, Tkdesk is not a program with lots of mindshare, and to my knowledge there are no people who have seen fit to dedicate themselves to creating artwork especially for it. (If there was enough interest it would probably be possible to have Tkdesk use the same icon sets that, say, KDE uses.) Some of the things in Tk that people regularly find fault with, such as the fixed Motif look (which used to be the latest fashion when Tk was new) have been successfully addressed in the meantime – Tk now supports a fairly capable theming engine. Tk itself is quite well-engineered and well-documented, arguably more so than various competing products. Finally, your contention that tkdesk should »migrate to a better structured language« suggests that you seem to be confusing Tk (the X11 toolkit) with Tcl (the programming language). Tk was first developed for Tcl, but there are Tk bindings for various other programming languages that one can use if one isn't enthusiastic about Tcl. Tcl is admittedly not everyone's cup of tea – but then again, which single programming language is? In my own experience it is quite possible to write large, reasonably maintainable programs in Tcl. In fact, I personally, having tried both Tcl and C++, would much rather program in Tcl. YMMV.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 16:32 UTC (Wed) by daniel (subscriber, #3181) [Link]
"The Linux kernel (and the majority of Free software projects) are doing it all wrong?"
I find your claim that the majority of free software projects are written in C to be dubious. In the Graphics world for example, C++ projects vastly outnumber C projects, the latter relegated largely to low level libraries such as Mesa and Xlib.
Linux kernel is entirely written in C for exactly one reason: Linus wants it that way. It's Linus's ball and bat, I won't comment further. Oh, just one comment. C99 is also banned from Linus's kernel, nuff said.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 20:49 UTC (Wed) by bug1 (subscriber, #7097) [Link]
I had read that C is more popular than C++, but double checking, on freshmeat.net there are 5367 projects tagged C++, 9594 tagged C.
However, the point i was trying to make in my original post is that complexity doesnt come from language, it comes from design.
If you have a really good design for a project, it should be just as easy for a C programmer to implement that design in C, as it would be for a C++ programmer to implement it in C++.
Design can be really hard, for simple tasks a lot of programmers do it themselves without thinking about it, its only when projects get larger that it gets recognized as a separate problem.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 21:53 UTC (Wed) by HelloWorld (guest, #56129) [Link] However, the point i was trying to make in my original post is that complexity doesnt come from language, it comes from design. If you have a really good design for a project, it should be just as easy for a C programmer to implement that design in C, as it would be for a C++ programmer to implement it in C++. This is just nonsense. The whole point of a programming language is to give you the means to express things more easily. The converse of your argument is essentially that we shouldn't have bothered with programming languages in the first place, since, given the right design, we might as well implement it in assembly language. An object-oriented design with heavy use of inheritance, virtual function calls etc. will be much cleaner, terser and simpler in C++ than in C.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 16:11 UTC (Thu) by mgedmin (subscriber, #34497) [Link]
Why not go all the way and recommend something like Python then? *Much* cleaner, terser and simpler than C++.
(Of course there's a cost -- larger memory usage, slower running speed. Just like C++ has costs that C doesn't have -- gotchas in the language design, longer compilation times, increased memory usage, slower application startup due to eager linking overhead for vtables, etc.)
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 17:27 UTC (Thu) by HelloWorld (guest, #56129) [Link]
It's all about tradeoffs. Python is slow and uses more memory. I also dislike dynamic typing, and it's easier to use a C library in a C++ program than in Python. If these aren't problems for you - great, use Python.
If instead you're looking for a programming language that offers both flexibility and suitability for systems programming (perhaps even in the embedded world), then C++ is in my opinion a reasonable option.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 20:31 UTC (Thu) by daniel (subscriber, #3181) [Link]
"The point i was trying to make in my original post is that complexity doesnt come from language, it comes from design."
If you are saying that design complexity cannot possibly be caused by the language then I strongly disagree. The absence of essential organizational constructs in C is a breeding ground for complexity. Look at Xlib for example, you have to match up discriminated unions properly by hand, which involves keeping track of struct names, typedefs and union field names, all spelled differently and sometimes inconsistently. The resulting code is unnecessarily hard to write, harder to read (at least if "understanding" is a required part of reading) and full of accidents waiting to happen. I do not see how that can fail to translate into design complexity. You just can't cover up those flaws with a design, the underlying mechanism insists on showing through.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 22:31 UTC (Thu) by bug1 (subscriber, #7097) [Link]
"If you are saying that design complexity cannot possibly be caused by the language then I strongly disagree."
Design _should_ be separate from its implementation, they are separate stages.
But if you are designing as you go then its likely to all turn to shit a few times anyway, the efficiency loss of the language probably isnt significant compared to lost time due to re-writing whole sections of code.
Sobotka: Why GIMP is inadequate Posted Jan 18, 2011 17:54 UTC (Tue) by daniel (subscriber, #3181) [Link]
"Design _should_ be separate from its implementation, they are separate stages."
That is the waterfall method. I do not find it as effective or efficient as the iteration method.
Sobotka: Why GIMP is inadequate Posted Jan 18, 2011 17:52 UTC (Tue) by daniel (subscriber, #3181) [Link]
It is hard to get reliable data on language popularity. That said, a search for "int main" lang:c vs lang:c++ on code.google.com shows C and C++ nearly tied. I think it is safe to say that a few years ago C++ would not have been anywhere close. (Caveat: it is naive to assume that a lot of care and attention goes into ensuring accurate search stats in a search engine.)
As far as freshmeat goes, it would be nice to know the relative popularity of C vs C++ for active and new projects versus inactive and old projects.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 12:16 UTC (Thu) by error27 (subscriber, #8346) [Link] C99 is also banned from Linus's kernel, nuff said.Kernel style is one variable declaration per line. The declarations are separated from the code by a blank line. C99 allows people to mix code and variable declarations, but in the kernel it's considered horribly bad style. The kernel style is to use kernel-doc comments and so C99 comments are considered non-standard and thus wrong. On the other hand, the kernel has pretty much all been updated to use C99 style structure initialization and it uses __func__ instead of using the old GCC extensions. And the kernel often takes advantage of the latest features in GCC where possible. For example, v2.6.37 uses the new local label declarations. When you say that we've banned C99 code that makes it sound like we're retarded. There are tons of things that we hate but only because they are ugly and not because they are new.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 20:34 UTC (Thu) by daniel (subscriber, #3181) [Link]
"When you say that we've banned C99 code that makes it sound like we're retarded."
It does sound like that, doesn't it?
Sobotka: Why GIMP is inadequate Posted Jan 14, 2011 7:36 UTC (Fri) by bronson (subscriber, #4806) [Link]
Yep. So why don't you apologize? Your statement was clearly wrong.
Sobotka: Why GIMP is inadequate Posted Jan 18, 2011 18:45 UTC (Tue) by daniel (subscriber, #3181) [Link]
"So why don't you apologize?"
I will when the ban on inline declarations and // comments ends.
Sobotka: Why GIMP is inadequate Posted Jan 19, 2011 16:56 UTC (Wed) by bronson (subscriber, #4806) [Link]
haha, fair enough.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 7:01 UTC (Wed) by cmccabe (guest, #60281) [Link]
The worst kind of projects are the ones that have islands of code written in random and widely differing styles.
The C versus C++ thing has been discussed to death before. Read Linus Torvalds' take on it. He's not very diplomatic, but he is right. In short, object orientation isn't a language feature; it's a programmer feature.
It would be nice if gimp were somehow a set of C modules controlled by, say, a python GUI. That would also allow people to write scripts that made new and interesting programs out of the basic components. I know that gimp is scriptable now, but I'm thinking of something that goes well beyond that.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 9:58 UTC (Wed) by romanfi (guest, #72329) [Link]
mccabe wrote:
> object orientation isn't a language feature; it's a programmer feature
That's like saying "as long as it's possible to put nails into the wall by hand, why using a hammer?".
A language has to support common and daily tasks to be done by programmers. The kernel is full of object oriented designs like inheritance, virtual functios, namespaces, inline functions, member functions, member access, etc., why not using a hammer?
Of course, I also know people and designs who try to do every thing object oriented, drawing bubbles around everything they can find, and the connecting them via funny lines with arrows and bars. That's not the way I'd like to see C++ in the kernel, more the way I use it since g++ supports C++ and we were using C++ for embedded designs a lot, even down to standalone code in very fast boards e.g. inside FlexRay data loggers. No new/delete from libc++ but own implementations, no artificial inheritance or virtual functions with pointer arrays, simple and readable code, not overdoing it.
Not everything is a nail... Posted Jan 13, 2011 13:50 UTC (Thu) by khim (subscriber, #9252) [Link] The kernel is full of object oriented designs like inheritance, virtual functios, namespaces, inline functions, member functions, member access, etc., why not using a hammer?Because not everything is a nail? Seriously: take a look on how kernel does thing and you'll see that C++ design will be more complex and much less flexible. C++ is great hammer but it's still a hammer. If you use C++ then you tend to think that every problem is a nail and this leads to truly ugly code. Today's C++ (especially C++ 200x in GCC 4.5+) includes more then hammer, but it's still quite hard to use right (and the code produced in C++ is usually significantly more resource-hungry and slower then code written in C), but 10 years ago it was a joke. I think it's good idea to use C++ for things where there are not enough developers ("bloated and slow, yet working program" is still better then lead and mean program which "will be delivered RSN for the last 10 years"), but for kernel C++ is bad choice.
Not everything is a nail... Posted Jan 14, 2011 4:55 UTC (Fri) by HelloWorld (guest, #56129) [Link] Because not everything is a nail? Seriously: take a look on how kernel does thing and you'll see that C++ design will be more complex and much less flexible. If you use C++ then you tend to think that every problem is a nail and this leads to truly ugly code.Everything that can be done in C can be done at least as well in C++. Claiming that C++ would have led to a more complex and less flexible design is thus downright absurd. C++ is a multi-paradigm language that doesn't force any particular programming style down anybody's throat, and if doing things like in C provides advantages, C++ won't stop you. (and the code produced in C++ is usually significantly more resource-hungry and slower then code written in C)That's outright bullshit. A key design decision in C++ has always been "don't pay for what you don't use", and it worked out pretty well in fact.
Not everything is a nail... Posted Jan 14, 2011 9:43 UTC (Fri) by dwmw2 (subscriber, #2063) [Link] The problem in the kernel is that we get a lot of drive-by contributions from people who don't really know what they're doing. A lot of driver code is pure crap.You are absolutely right that C++ can be used sparingly. Qt handles it fairly well, enforcing a sane use of a subset of C++ rather than the whole range of features. However, this does depend on restraint on the part of the developers. If we had C++ available, we would either spend a lot of time telling developers "no, you can't do that", or we'd accept a lot of use of C++ features that we would prefer not to use. It is often the case that certain developers don't have a full understanding of the cost of the code they're writing, even when they're using C. Not everyone is forced to spent part of their life looking at the compiler output from their code and seeing what it actually does, although they ought to be. While the "don't pay for what you don't use" principle has indeed worked out pretty well in general, the fact remains that people would be using more, and thus paying more. Unless you just want us to compile our existing C code with a C++ compiler? :) Which wouldn't work today because we make heavy use of C99 structure initialisation, and I don't believe that works in C++?
Not everything is a nail... Posted Jan 21, 2011 15:56 UTC (Fri) by daglwn (subscriber, #65432) [Link]
It is often the case that certain developers don't have a full understanding of the maintenance cost of the code they're writing,
I am sick and tired of kernel people spouting ignorance about C++. They look like fools. Every single project I've followed that places restrictions on the use of C++ ends up with bugs and misdesigns that could have been avoided had the leadership opened its minds to the idea that C++ is a cohesive language. Stripping parts of it out just means you're throwing away safety, code reuse or both.
Not everything is a nail... Posted Jan 21, 2011 20:31 UTC (Fri) by xilun (subscriber, #50638) [Link]
And only work with C++ experts in any cases (restrictions or not). Who are even more difficult to find than C experts, and C experts are already difficult enough to find...
Not everything is a nail... Posted Jan 21, 2011 23:41 UTC (Fri) by daglwn (subscriber, #65432) [Link]
I really question whether competent C++ developers are hard to find. There are lots of C++ jobs out there so it's not as if the language isn't being used. You really have to try _not_ to learn something about a language after using it for a while.
In my experience the problem is resistance to the unknown, no matter how much that unknown might improve one's productivity.
Not everything is a nail... Posted Jan 21, 2011 21:46 UTC (Fri) by Spudd86 (guest, #51683) [Link]
The problem is that many C++ features would need additional support code that doesn't currently exist in the kernel (for example, exception handling with zero overhead in the case of no exceptions thrown would need both new kernel code to support it and tighter coupling between the kernel and compiler).
In the kernel restrictions are more than just style or taste, they are also because the user space code that the compiler relies on being present in the final executable may not work in kernel space, if it doesn't that feature either cannot be used or replacement support code must be written, the latter option ties the kernel more tightly to the compiler and increases the chances that a new compiler version will break the kernel.
Not everything is a nail... Posted Jan 21, 2011 23:52 UTC (Fri) by daglwn (subscriber, #65432) [Link]
Of course something like exceptions would require support code in the kernel and I'm not advocating that exceptions are necessarily the best way to do error handling in the kernel. I'm not an expert in the kernel domain so I don't feel qualified to judge either way. The same goes for rtti, which can often be avoided anyway.
What I am advocating is that the kernel people unplug their ears, uncover their eyes and think about what benefits C++ might bring. It would help tremendously with writing code that uses callbacks. The whole filesystem architecture with the VFS layer and implementation layers is crying out for an inheritance model. RAII would help a lot with resource cleanup.
Heck, RAII *alone* should be enough to seriously consider C++ in any project.
Now rewriting the filesystem architecture is too much to expect (I'm just giving it as a well-known example) but these kinds of patterns abound in most code. C++ really can save a lot of lines of code and that usually means fewer bugs and often better performance.
But the trick is, you have to use the multi-paradigm features of the language. Multiple inheritance, templates, operator overloading and constructors/destructors complement each other in surprisingly beautiful ways. I have heard strong arguments against all of those features and I just shake my head in sadness every time I have to address them.
Not everything is a nail... Posted Jan 22, 2011 0:52 UTC (Sat) by jmm82 (guest, #59425) [Link]
The VFS already has an inheritance model in c, it is called function pointers.
Not everything is a nail... Posted Jan 22, 2011 1:25 UTC (Sat) by daglwn (subscriber, #65432) [Link]
Which is, of course, my whole point. Why go through the pain and bugs involved with function pointers when the compiler will generate it for you? It baffles me why anyone who advocates using tools to automate tasks (i.e. anyone who writes code) would abandon that principe at some arbitrary level of the development stack.
Not everything is a nail... Posted Jan 25, 2011 9:38 UTC (Tue) by paulj (subscriber, #341) [Link]
You can do RAII in C just fine...
Not everything is a nail... Posted Jan 25, 2011 16:06 UTC (Tue) by jrn (subscriber, #64214) [Link]
I suppose it depends what RAII means. But no, I am not aware of a simple way to, say, free memory on the heap when a pointer to it falls out of scope (especially when a "return" statement exits that scope).
Not everything is a nail... Posted Jan 25, 2011 16:41 UTC (Tue) by etienne (subscriber, #25256) [Link]
Maybe you do not have the problem of freeing memory when a local structure goes out of scope in C (outside of kernel space), because in that case the local structure is declared in the stack and will be freed automatically...
Maybe the real problem is that your "autoptr" is not able to manage an object in the stack, but you need an "autoptr" because one method has such an argument.
Not everything is a nail... Posted Jan 25, 2011 22:18 UTC (Tue) by daglwn (subscriber, #65432) [Link]
Will that local structure also close files for me when it goes out of scope? Or does that local structure free memory pointed to by members of that structure when it goes out of scope? Or does that local structure release a lock it holds when it goes out of scope?
RAII is about MUCH more than memory.
Not everything is a nail... Posted Jan 26, 2011 12:32 UTC (Wed) by paulj (subscriber, #341) [Link]
For me RAII in the abstract is an object/resource-lifetime management strategy, such that creation and destruction of composite objects appear atomic wrt resources/objects held internally, as far as users of the object are concerned. Obviously it's good programming to try make objects atomic in this way when designing code.
C++ has implicit calls to constructors and destructors, which tie in to scoping. C doesn't have that, true, and requires explicit construction and destruction (you can still hide destruction behind refcounting, obv). It's often bad practice and/or a sign of a (quick)? hack when C code uses automatic allocating for non-trivial, composite objects.
Whether language support for implicit ctor/dtors tied with scoping is required for a practice to be called RAII, I don't know. I guess to a C++ person it does. Still, the general sentiment of RAII seems more widely applicable than C++.
Not everything is a nail... Posted Jan 26, 2011 19:52 UTC (Wed) by daglwn (subscriber, #65432) [Link]
Implicit destruction (finalization, uninit or whatever you want to call it) seems to me integrally tied to the concept of RAII. Without it, one ends up having to cover all exit points of a scope with explicit calls to cleanup code. Either this means there are several such calls scattered around parts of the enclosing scope or there's a big ugly goto to a common piece of cleanup code. Neither is particularly attractive or maintainable.
This gets to be impossible if the exit points are not known statically. C++ exceptions are a classic example but since some seem to think the C++ exception model is broken, I will emphasize that the problem is NOT solved by eliminating exceptions. One still has to cover all exit points with cleanup code.
Perhaps a better term for this would have been "resource ownership is object lifetime."
Not everything is a nail... Posted Jan 30, 2011 0:37 UTC (Sun) by nix (subscriber, #2304) [Link]
*Closures* would help tremendously in writing code that uses callbacks. But they require quite a lot of runtime support which is not available in the kernel.
C++'s syntactic sugar is insignificant in comparison. (At least, in this area. I agree that RAII is really nice, but the kernel seems to be surviving without it.)
Well, it's quite simple, really... Posted Jan 18, 2011 11:34 UTC (Tue) by khim (subscriber, #9252) [Link] Everything that can be done in C can be done at least as well in C++. Well, this is strawman argument: of course you can just ignore all C++ extensions and then produce the same code in C++ as in C. But what's the point? If you try to use "real" C++ facilities... Claiming that C++ would have led to a more complex and less flexible design is thus downright absurd. Not really. Most C++ designs are indeed more flexible, but this is not a big factor for kernel development where you can always redesign anything (the infamous "stable API nonsense"), but the fact that they are "more flexible" usually means they are more complex and less efficient. (and the code produced in C++ is usually significantly more resource-hungry and slower then code written in C)That's outright bullshit. A key design decision in C++ has always been "don't pay for what you don't use", and it worked out pretty well in fact. Where "pretty well" == "bloat of about factor of two or three". Yup. C++ does not impose choice on your so you end up with 4-5 implementations for basic things. Heck, C++ standard includes two different string implementations from the start (I mean "char *" and "std::string") - and different libraries like to add additional ones! And we are talking about kernel, remember? Kernel shares L1 with userspace program and it's pitiful: 64K at most. And, please, don't talk about Moore's Law here: PowerPC 601 had 32K cache 18 years ago, Intel Core2 has 32K cache today. Yeah, it's kind of "apples vs oranges" because there are two 32K caches on Core2 and PowerPC 601 and AMD's Phenom has whopping 64K L1 cache, but anyway: even two doublings per 18 years is not enough to claim that endless adapters and transformers are no longer meaningful for kernel. The "don't pay for what you don't use" is only good when you don't use anything. When you actually do use some facilities you suddenly find out that they cost more then in case where language imposes things on you.
Well, it's quite simple, really... Posted Jan 18, 2011 12:08 UTC (Tue) by dwmw2 (subscriber, #2063) [Link] "Well, this is strawman argument: of course you can just ignore all C++ extensions and then produce the same code in C++ as in C."Can I? In the kernel we make heavy use of C99 structure initialisation. Where structures can so often change and gain new members, it's very important to have named initialisers. But this code will fail if compiled as C++:
struct foo {
int a;
int oh_we_introduced_this_optional_thing_later;
int b;
};
struct foo f = {
.a = 1,
.b = 2,
};
Losing that facility would introduce a lot of errors into the kernel, at a single fell stroke.
Well, it's quite simple, really... Posted Jan 18, 2011 13:27 UTC (Tue) by foom (subscriber, #14868) [Link]
Surprisingly, it didn't even make it into C++0x.
It seems to me it'd be a reasonable extension for "gnu++0x", though.
Well, it's quite simple, really... Posted Jan 18, 2011 18:57 UTC (Tue) by daniel (subscriber, #3181) [Link]
The lack of designated initializers in C++ is pure brain damage. I do not understand why the issue does not get more attention. That said, the old gnu syntax still works: {foo: x, bar: y} except that you have to specify the initializers in the order declared and insert nulls if you skip fields, the latter requirement serving no imaginable purpose whatsoever. But at least in this way you can protect yourself from structure field evolution. This C advantage in no way makes up for all the structuring primitives that C lacks.
Well, it's quite simple, really... Posted Jan 18, 2011 21:07 UTC (Tue) by foom (subscriber, #14868) [Link]
It doesn't sound like brain damage, but rather a brand new (well, 12 years old now, but by C standards, brand new) feature in C that has not been ported to C++ yet. C++ adds all sorts of additional complex interactions to such a feature that would have to be properly specified...and nobody's done that yet. You could probably get a proposal accepted for C++20 (or whatever) though...
The restrictions on the GCC extension seem like someone just didn't really finish implementing it yet. I'd bet you would be welcome to do so.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 15:15 UTC (Wed) by HelloWorld (guest, #56129) [Link] The C versus C++ thing has been discussed to death before. Read Linus Torvalds' take on it. He's not very diplomatic, but he is right. In short, object orientation isn't a language feature; it's a programmer feature.This is a bogus argument for two reasons. Firstly, C++ does not equal C+OOP. Even if C++ didn't have any support for OOP, it'd still be worth using because of features like templates, namespaces, RAII and all that. Secondly, an object-oriented design will look much, much cleaner and be more maintainable in C++ than in C.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 10:17 UTC (Thu) by paulj (subscriber, #341) [Link]
C may have limitations and deficiencies relative to modern programming concepts - I could accept that. However, how does it follow that the answer to this is C++, as the original commentator suggests? C++ perhaps has *even more* deficiencies than C, relative to modern programming concepts and other (often necessarily more recent implementations)? Let's look at your list:
Templates: These are a bodged implementation of generic/meta types (perhaps not C++'s fault, as generic/meta types were prototyped in C++ to an extent). Due to different instantiations of the same template literally copying the code, they're hell on I-caches - spectacularly inefficient. Due to its implementation roots as code that's inserted in a pre-processor phase, producing compilation error messages that don't look like incomprehensible gobbledygook to anyone but C++ compiler developers and/or language spec committee members can be challenging. At least one widely used C++ compiler still fails terribly at this.
RAII: This is a programming pattern popularised, in large part, because of the *deficiencies* of C++, wrt the many subtle ways exceptions interact with other parts of the C++ language spec (construction and deconstruction particularly). Further, you *can* quite easily (if you're adhering to OOP) do RAII in C, as I'm sure you must know.
Namespaces: Ok, I grant you that one. But there are other choices of language, beside C++, with namespacs. ;)
Then there are all the other problems with C++...
So, again, if you got fed up with C and wanted to switch to a better language for some large, high-level user-space project (e.g. GUI graphics processing app), why on earth would you choose C++? Surely C#, Java, or Vala, perhaps others, would be a much better choice? For the low-level, C beats C++. For the high-level, with the rise of much cleaner languages that have learned from C++ mistakes and have not been saddled by its baggage, has C++ not had its day?
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 11:33 UTC (Thu) by boudewijn (subscriber, #14185) [Link] "However, how does it follow that the answer to this is C++, as the original commentator suggests?" Where did I suggest that? A big C project that uses GObject is awfully difficult to get into for a newbie. Heck, I have spent more than once several weeks getting people up to speed with Qt and C++ so they could contribute to Krita (and C++ with Qt is awfully close to Java for a beginner) so I know that "C++" isn't the answer. I think there is no answer for Gimp -- but that doesn't mean it isn't a problem. Spending that time on beginners has almost always been worth it, by the way, with the newcomers becoming valued members of the development team and producing awesome stuff.
Sobotka: Why GIMP is inadequate Posted Jan 19, 2011 21:36 UTC (Wed) by DOT (subscriber, #58786) [Link]
"Heck, I have spent more than once several weeks getting people up to speed with Qt and C++ so they could contribute to Krita (and C++ with Qt is awfully close to Java for a beginner) so I know that "C++" isn't the answer. I think there is no answer for Gimp -- but that doesn't mean it isn't a problem."
Since Vala is embarassingly compatible with C and GObject, it should be possible to write new code in that language where appropriate.
But honestly, I think the problem is not in the code. You'll only have to look at LibreOffice and its awesome community to know that code doesn't really matter. I would start looking for the problem somewhere in human department.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 11:53 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> C may have limitations and deficiencies relative to modern programming concepts
That seems to be an understatement ;)
> Templates: These are a bodged implementation of generic/meta types
> Due to different instantiations of the same template literally copying the code, they're hell on I-caches - spectacularly inefficient.
Also, partial template specialization can be (and is being) used to reduce or eliminate copied code. For example, it is possible to specialize the vector<T> class so that if T is a POD type (POD = plain old data), a generic implementation based on memcpy etc. will be used and the template merely acts as a type-safe wrapper around it, the overhead of which can be trivially optimized away by the compiler.
> Due to its implementation roots as code that's inserted in a pre-processor phase, producing compilation error messages that don't look like incomprehensible gobbledygook to anyone but C++ compiler developers and/or language spec committee members can be challenging.
In Haskell, type classes solve a similar problem fairly elegantly. They tried to add a similar feature to C++0x but failed, so this problem will be with us for some time.
> Further, you *can* quite easily (if you're adhering to OOP) do RAII in C, as I'm sure you must know.
> So, again, if you got fed up with C and wanted to switch to a better language for some large, high-level user-space project (e.g. GUI graphics processing app), why on earth would you choose C++? Surely C#, Java, or Vala, perhaps others, would be a much better choice?
> For the low-level, C beats C++.
Sobotka: Why GIMP is inadequate Posted Jan 14, 2011 9:31 UTC (Fri) by paulj (subscriber, #341) [Link]
Re templates: I don't know enough about the history of C++, but that to me sounds like C++ settled for a bodged version of generics because of implementation compromises. I'm not sure what you mean by 'specialise', do you mean extend the base functionality, or modify/remove it? If the former, generic type theory allows that, if latter then that's no longer safe according to standard type-theory, no (but then templates themselves aren't really types in C++ - part of the bodge)?
Caching: What you describe is the relative efficiency of function pointers, branch-prediction v I-cache. That's not a constant thing at all and varies a lot between processors and over time as processor technology changes. E.g. there's no fundamental reason why branch-prediction can not predict branches behind repeated calls to the same function pointer - that branch predictors in the past have not dealt well with function pointers doesn't mean this always is so. On the other hand, that templates put pressure on I-caches *is* a fundamental fact. It will always be a factor, so long as CPUs need I-caches.
RAII: C doesn't explicitly have support for implicitly calling a custom per-object deallocator on free(), but setting up the scaffolding to do this is half a days work, and there are existing allocator libraries that can make this even easier (e.g. talloc). If you lack the imagination to put a header in front of your allocated objects and populate it with useful function pointers, and override free(), well.... ;) That half-days-work is much shorter than the *years* it takes to discover all the subtle ways C++'s historical baggage and design decisions can bite the programmer. ;)
As for C#, Java, Vala, etc and rewriting the GIMP: this discussion about C v C++ started because people criticised GIMP for being in C and suggested C++ would be better. Where's the evidence for this claim? Even if we accept C++ has merits over C, exactly how does this make C++ the correct choice *today* for programming large, end-user applications? If the answer isn't C, then it surely isn't C++ either...
Sobotka: Why GIMP is inadequate Posted Jan 14, 2011 15:00 UTC (Fri) by HelloWorld (guest, #56129) [Link] Re templates: I don't know enough about the history of C++, but that to me sounds like C++ settled for a bodged version of generics because of implementation compromises.They're not, and I already told you why: generics are less flexible and require a boxed data representation, at least in any implementation of generics I know of. And if templates were merely a sucky replacement for generics, why did the developers of the D language choose to implement templates as well? RAII: C doesn't explicitly have support for implicitly calling a custom per-object deallocator on free(),It's not about calling a custom deallocator on free but about implicitly doing something (like unlocking a mutex or decreasing a refcount) when an object leaves some scope. This needs some form of language support. <ramblings about caching>Well, if you think that qsort offers a better tradeoff than std::sort, you can still write an easier to use, type-safe wrapper.
template<typename T> int compare(const void *, const void *);
// implementation left as an exercise for the reader
template<typename T> void my_sort(T *base, size_t nmemb) {
return std::qsort(base, nmemb, sizeof(T), &compare<T>);
}
As for C#, Java, Vala, etc and rewriting the GIMP: this discussion about C v C++ started because people criticised GIMP for being in C and suggested C++ would be better. Where's the evidence for this claim? Even if we accept C++ has merits over C, exactly how does this make C++ the correct choice *today* for programming large, end-user applications? If the answer isn't C, then it surely isn't C++ either...I think that reasons were given for preferring C++ to C (templates, OOP, RAII, namespaces); of course, you're free to disagree with these. I also didn't claim C++ is the right choice for an application like the GIMP if it were written today, and it probably isn't, as a low level language like C++ is probably a poor choice for a graphical app today. It merely annoys me when people like cmccabe keep trolling against C++ and do as if C were the holy grail of systems programming languages.
Sobotka: Why GIMP is inadequate Posted Jan 14, 2011 16:29 UTC (Fri) by paulj (subscriber, #341) [Link]
Generics have a sound body of type theory behind them though. Boxing types - I don't see a problem with that for OOP. And from what you say, the error-message problem is actually somewhat fundamental to templates. I really hate templates I have to say.
Re implicit destructors for automatic variables. True, that requires language support. OTOH, C++ allowing automatic storage objects is one of those things that lead to subtle corner-cases, ISTR...
Anyway, our opinions clearly differ. ;)
Sobotka: Why GIMP is inadequate Posted Jan 14, 2011 18:32 UTC (Fri) by HelloWorld (guest, #56129) [Link] Generics have a sound body of type theory behind them though.C++ templates have been studied by type theorists too, see for example this paper. Boxing types - I don't see a problem with that for OOP.C++ is not only object-oriented, and in fact, containers are very often used for built-in types like int. Boxing these is ridiculously inefficient. Re implicit destructors for automatic variables. True, that requires language support. OTOH, C++ allowing automatic storage objects is one of those things that lead to subtle corner-cases, ISTR...Like what? I always found implicitly called destructors to be a boon. Much more so than, say, Java's finally blocks. Alas, YMMV and as you already said, we should probably just agree to disagree :).
Sobotka: Why GIMP is inadequate Posted Jan 14, 2011 20:34 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> And from what you say, the error-message problem is actually somewhat fundamental to templates.
A similar problem applies to dynamically typed languages like python though. The interpreter can't possibly know whether the type of a function argument satisfies the requirements of the function it is passed to. The difference being that a C++ compiler will point that out at compile-time, while a dynamically typed language won't throw up until run-time, much less give you a sensible error message.
Poor implementations are also part of the problem. g++'s error messages are worse than they could be, for example it always talks about std::basic_string<char, std::char_traits<char>, std::allocator<char> > instead of plain std::string (the latter being a typedef for the former). Clang++ is supposed to be much better at this, though I haven't tried it yet.
Sobotka: Why GIMP is inadequate Posted Jan 18, 2011 20:06 UTC (Tue) by daniel (subscriber, #3181) [Link]
"I really hate templates I have to say."
For me it's a love hate relationship. I love the way I can generate efficient code from terse, readable source. I hate the way compile errors get weirder and weirder, the the latter may be as much an implementation issue as anything. Templates are really just a highly automated form of cut and paste that allows you to create *maintainable* cut and paste code, and package it for general use.
The extent to which cut and paste code abuses the processor cache says more about the programmer than the mechanism. I use partially specialized templates to create efficient variant forms of low level graphical operations. The initial pure C code base I developed to do the same thing grew tendrils and degenerated to to an unmaintainable state rapidly so that working on it slowed down and became deeply unappetizing. After being recast as an orthogonal set of C++ templates the source code shrank by a multiple and I was able to add the sophisticated new capabilities that seemed only a distantly obtainable hope with the original C code base. The actual generated code hardly changed, just my ability to develop it.
Sobotka: Why GIMP is inadequate Posted Jan 14, 2011 20:01 UTC (Fri) by cmccabe (guest, #60281) [Link]
> On the other hand, that templates put pressure on I-caches *is* a
> fundamental fact. It will always be a factor, so long as CPUs need > I-caches.
Indeed. I'm working on a large C++ project now, and this is a big problem for us. We use the STL heavily, especially the container classes.
Incidentally, if anyone here knows some good workarounds, they would be much appreciated! I know about the void pointer trick, but unfortunately most of our containers don't contain pointers; they contain class types.
Sobotka: Why GIMP is inadequate Posted Jan 14, 2011 13:59 UTC (Fri) by dwmw2 (subscriber, #2063) [Link]
Unconditional branches aren't so hard to predict, FWIW.
Sobotka: Why GIMP is inadequate Posted Jan 16, 2011 21:11 UTC (Sun) by cmccabe (guest, #60281) [Link]
I wrote a little test, and apparently std::sort *is* faster than qsort, at least at sorting an array of 4 million ints. My CPU is an AMD Phenom(tm) II X4 820.
In my opinion, templates are the best feature of C++. They're really the *only* feature I miss in C-land. You can use macros to accomplish the same thing in C. I vaguely remember that the BSD kernel has a header file implementing qsort-as-a-macro. However, it's less convenient.
Sobotka: Why GIMP is inadequate Posted Jan 17, 2011 1:11 UTC (Mon) by jthill (guest, #56558) [Link] Glad to see somebody else sees them that way. The don't have to be all verbose and complicated, and if you collect the machinery they implement together in one spot and get the formatting right they can make things very much clearer.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 20:38 UTC (Thu) by daniel (subscriber, #3181) [Link]
"He's not very diplomatic, but he is right. In short, object orientation isn't a language feature; it's a programmer feature."
If that is truly Linus's position then he is wrong, way wrong, irrespective of the fact that on LKML Linus is always right, by definition.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 16:50 UTC (Thu) by Frej (subscriber, #4165) [Link]
I'm quite impressed by your ability to determine the C-ishnes of a program by running it, especially when running by clicking an icon.
Really! It would so cool to say "That's clearly a program written in C" Just by looking at it, the amount of street cred from fellow students would be awesome.
Can you teach me? How does C-ishness look like? Compare to say C++-ishnes or Python-ishnes?
Sobotka: Why GIMP is inadequate Posted Jan 18, 2011 20:11 UTC (Tue) by daniel (subscriber, #3181) [Link]
As a beginning language diviner, I suggest you start by recognizing Javaishness, it's really easy. Just count the seconds from program start to main screen appearing.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 14:50 UTC (Tue) by boudewijn (subscriber, #14185) [Link] "because the codebase is huge (10 times as big as Krita)" Aw, zut... That's no longer true. Krita is now (excluding the calligra libraries like pigment) about 25% of the codesize of Gimp.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 15:46 UTC (Tue) by loevborg (guest, #51779) [Link]
Insightful comment, thanks.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 17:53 UTC (Tue) by tao (subscriber, #17563) [Link]
Personally I think that at least two of the points you bring up as being detrimental to contribution are things that make contributions *easier*:
* A strict coding style is the only sensible way forward in any serious project; I may not always agree with the coding style in the projects I contribute to (GNU coding style *shudder*), but I rather have one single style than having total chaos because everyone uses their own style. If you have trouble with the coding style, indent can *probably* help you.
* Being implemented in C makes the code a lot easier to understand -- to me C is pretty much a pre-requisite for me to contribute to a project. C++ is usually a big turnoff (a restrictive use of C++ that some Qt-based software I've seen adhere to is fine by me, but sadly most C++ projects are totally impossible to understand without reading large parts of the code base)
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 18:07 UTC (Tue) by robert_s (subscriber, #42402) [Link]
"Being implemented in C makes the code a lot easier to understand"
I always find this attitude mind-boggling. I found writing large complex applications in C with C-APIs (gtk) to be crippling. You obviously like staring at long verbose pages of G_OBSCURE_MACRO_HACKs and t_obscure_pointer_type*s.
I found C++ and Qt to be incredibly freeing in comparison. I also found it so much harder to make mistakes.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 19:22 UTC (Tue) by theICEBear (subscriber, #23193) [Link]
I am right there with you. For me C completely breaks down when working on large codebases even with a rigorous coding standard. I prefer C++ for those (if I mandate the use of a higher level language like Python or Ruby which I usually can't).
We're current dipping our toes in the water with regards to C++1x or C++0x using the latest GCC and Visual Studio compilers on a new project. It is quite lovely especially lambdas and auto. I heartily recommend it.
I have had two developers who were dead set against using anything but the simplest of classes and who wanted the complete banning of templates in our coding standards come up to me and profess that the new project even if it uses more templates and even lambdas is just wonderful to code and read. I personally only have one doubt about auto's and that is that they can make some code a bit obscure to read if overused especially to capture return parameters.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 10:31 UTC (Wed) by dgm (subscriber, #49227) [Link]
> I found writing large complex applications in C with C-APIs (gtk) to be crippling.
Yes, C++ is much terse. But that's because there's so much implicitly going on. C has simpler constructs, so what looks like an operator *is* actually an operator and nothing else. That makes the casual contributor life so much easier.
Agreed, C++ makes it possible to write _new_ code that's easy on the eyes, but it's complex for newcomers. Specially in large codebases. There's so much you need to perfectly understand before you can grasp a nontrivial hunk of C++ code.
Also, C++ is so full of subtleties that you can miss when reading code...
My experience is that C++ is wonderful if you are the only one, or an small team, or have very good documentation of the class hierarchy and how *everything* fits together.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 23:34 UTC (Tue) by PaulWay (✭ supporter ✭, #45600) [Link]
> But what you mean, I guess, is "Nobody should talk about problems and deficiencies in an open source application without filing the bugs and proving that to me!" And that seems to me unfair.
And yet that's the understood process for getting problems in FOSS fixed. You submit bug reports. It's not particularly difficult.
The irony here, to me, is that he's complaining about having this opportunity at all. What do Photoshop users do when they think "if only there was a tool to do this" or "damn, it crashed again when I do that" or "why is it so slow when I do this"? File bug reports? Find a programmer to help them? Or sit around and whine on mailing lists and forums and in offices? Do they use their costly paid support calls to let Adobe know, only to be told "we're working on it, it'll be in the next version, and you'll have to buy that upgrade, see us in six months time."
Submitting bug reports isn't a chore - it's a privilege. You get to have your say in how the application improves. Yes, it's time and effort - like voting - but the alternative is to leave the choices to someone else.
I've talked to graphic artists who are still using Photoshop CS3 because CS4 introduced and took away things that made it harder to use. It sounds to me like all progress in proprietary software is not universal gain - just like in free software.
I can see the arguments against cash-for-features, especially if it's "wedge this thing in anywhere because that suits my particular workflow". And yet once again you have that opportunity. I'm sure there are photographers and artists using Photoshop that have paid a developer to have a feature that they then use exclusively in-house. You can do that with FOSS too - there's no need to share the code for that GIMP plugin or feature if you use it solely for yourself. Yet we also have the opportunity for the community of artists to get together to fund features which go into the core of GIMP and improve the whole thing for everyone. That's something you don't really get with proprietary software.
So I feel the 'bug reports required' tag (like [citation needed]) to be appropriate in this case.
Have fun,
Paul
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 8:27 UTC (Wed) by boudewijn (subscriber, #14185) [Link] "And yet that's the understood process for getting problems in FOSS fixed. You submit bug reports. It's not particularly difficult." Nonsense, really. There's plenty of reason to think first, formulate thoughts, canvas opinions, blog, analyze, write opinion pieces and so on. All valid steps before inundating a project with bug reports. Bugs in a bugzilla are not a particularly good way of interacting with developers, and bugzilla is not a particularly good way of tracking the wishes of a user community Especially when the wishes are so very broad that it may take years to implement them fully. As a maintainer of a free software application, I much prefer reading people's opinions, having them mail me, show me examples of what they need, write pages on my wiki -- and then, when I think we've digested it to implementable pieces, I might add those pieces to the feature plan. Bugzilla is for bugs, not for wishes or for tracking feature development.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 14:03 UTC (Tue) by cantsin (guest, #4420) [Link]
Unfortunately, the article is spot-on. And ever since cameras shooting raw have become cheap, the 8bit/channel limitation has become an issue for amateur users as well. It's the equivalent of a text editor not supporting UTF-8 in 2011.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 15:24 UTC (Tue) by gowen (guest, #23914) [Link]
As a keen amateur photographer, shooting with a Canon DSLR, I've never felt the need for 16 bit RGB.
It's interesting that the author talks about posterization at 8-bit, but demonstrates it with a 50-level gradation (i.e. less-than-6-bit). Why would someone do this?
He then add "Pundits that suggest this is negotiable are simply and flagrantly incorrect[2]" -- a footnote that leads to absolute no supporting evidence of our incorrectness.
Yes, certain specialised applications need higher bit depths, and yes, the gamma correction in GIMP could be considerably better, but overall this article adds literally nothing to the debate. He doesn't show us the better results of higher bit applications, just repeats the same old talking points. (And of course, everything he writes about 8-bits-per-channel is true about 12-bits-per-channel, and he makes no effort to demonstrate "12 is good enough"). The Pantone system, quantizes everything onto about 3000 spot colours, but no-one talks about the quantization effects of that.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 15:36 UTC (Tue) by boudewijn (subscriber, #14185) [Link] One Krita hacker, Dmitry Kazakov, is also a keen amateur photographer and he agrees with you. On the other hand, Martin Reynolds of MyPaint shows that there's advantage of 16 bit/channel when painting in http://mypaint.intilinux.com/?p=19. And in the final analysis, if my camera or scanner can produce 12 (or 16) bits/channel, and my expensive monitor (wish I had one) can show 12 (or 16) bits/channel, then it would be a pity not to keep all that precision, I guess.
eight bits... Posted Jan 11, 2011 15:45 UTC (Tue) by nettings (subscriber, #429) [Link]
...might be ok if you don't do very much with your image. the problem is you're going to apply a number of transformations, and then rounding errors accumulate.
take a look at an image histogram after changing the black and white points in colors->curves. that is data loss at work (a particularly graphic case, i admit). why should i put up with gaping holes in my histogram if the original image had 10 or 12 bits of depth?
the discussion is pretty much the same as with cd audio quality. a carefully mastered and dithered cd is capable of totally adequate sound quality. but its underlying format, 16bits at 44k1 sampling rate, is woefully inadequate for studio use. so what everyone does is work at higher bitdepths and possibly higher sampling rate, and only down-convert as a very last step, before the product goes out to the consumer.
eight bits... Posted Jan 11, 2011 18:24 UTC (Tue) by Imroy (guest, #62286) [Link]
> The problem is you're going to apply a number of transformations, and then rounding errors accumulate.
It's not just rounding errors. If you're dealing with an image using a wide colour gamut, you need the extra precision to properly represent the large colour space. Posterization will result if using 8-bit components with a wide colour gamut.
> A carefully mastered and dithered cd is capable of totally adequate sound quality. but its underlying format, 16bits at 44k1 sampling rate, is woefully inadequate for studio use.
It's important to distinguish between what is adequate for source material and temporary/intermediate results, versus the final output. For the latter, 8-bit sRGB (or CD-Audio) is indeed adequate most of the time. But if you pull that into an editor you may soon have problems from posterization (lack of precision), out-of-gamut colours, blown highlights, lost shadow detail, low resolution, etc.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 16:37 UTC (Tue) by welinder (guest, #4699) [Link]
> It's interesting that the author talks about posterization at 8-bit, but
> demonstrates it with a 50-level gradation (i.e. less-than-6-bit). Why > would someone do this?
It demonstrates the problem using two small on-screen images.
One operation always causes me to hit the 8 bit limit. If I have an
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 16:56 UTC (Tue) by gowen (guest, #23914) [Link] It demonstrates the problem using two small on-screen images. If 6 bits is not enough there, then clearly 8 bits is not going to cut it on anything you print.And if 8 bits is not going to cut it, then 10 bits can hardly be any better. And if 10 bits is not good enough, how can we expect 12 to be? And if ... well you get the idea. Your argument is not valid. If you want to convince me, show, don't tell.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 17:32 UTC (Tue) by nye (guest, #51576) [Link]
>If you want to convince me, show, don't tell.
Given that 8 bits per channel is the most that can be displayed by the average monitor, how exactly do you propose to demonstrate the problem?
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 17:51 UTC (Tue) by prokoudine (guest, #41788) [Link]
> Given that 8 bits per channel is the most that can be displayed by the
> average monitor, how exactly do you propose to demonstrate the problem?
Just check histogram after editing. You get hair-comb after levels and curves in 8bpc.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 18:11 UTC (Tue) by drag (subscriber, #31333) [Link]
Yes.
People hating the 8-bit limit has little to do with displaying colors on your monitor, unless they are just parroting. The 8-bit limit comes into play when it comes to _processing_ your images.
You can see it any time you want with Gimp if you play around with multiple layers and run a few filters. Before long you'll start seeing visual artifacts start showing up. Colors that are wrong, weird L-shaped artifacts, lots of graininess, and errors that look like the sort of things you get from highly compressed jpeg images.
One of the nice things about digital art is the ability to twist and deconstruct images to make new images. Like how you can take audio samples of every day things, manipulate them, and make music out of things.
With just 8-bits then this makes the process a lot more time consuming, depending on what your aiming for.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 11:21 UTC (Wed) by nye (guest, #51576) [Link]
>People hating the 8-bit limit has little to do with displaying colors on your monitor, unless they are just parroting. The 8-bit limit comes into play when it comes to _processing_ your images.
Indeed. To be clear, I was addressing the complaint that the article should have more convincingly shown the problem, which struck me as unfair.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 18:36 UTC (Tue) by foom (subscriber, #14868) [Link]
Good monitors support 8 bits/color output. Average ones only support 6 bits. Bad ones only support 6 bits, and don't do dithering. And there's a whole lot of bad ones out there. Surprisingly, you can even find them in Macs, which makes Apple's excessive use of gradient effects in OSX's UI look really crappy.
You can tell if you have a bad screen just by pulling down a menu, and look at the gradient shadow effect on the edge. You will see horrible banding. If you look at the screen from an angle, it's even more obvious (vertically usually works better). On an "average" display, you can see the dithering effect if you really look, but it isn't nearly so bad.
Oops, sorry for the diversion/rant. :)
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 21:51 UTC (Tue) by boudewijn (subscriber, #14185) [Link]
And some utterly drool-worthy monitors and graphics cards support 12 or even 16 bits... And I so wish someone with one of those monitors could check Krita to see whether the support I hacked in for those cards and monitors actually works correctly...
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 12:40 UTC (Wed) by romanfi (guest, #72329) [Link]
nye wrote:
> Given that 8 bits per channel is the most that can be
You can always look at the histogram.
And probably you want to do that after converting between color profiles, esp. wide gamut profiles like ROMM (Kodak ProPhotoRGB), esp. when you need such color spaces when you do a lot of transformations.
Of course, the average image can easily be handled fine with 8 bits. And the average digitial camera writing JPEGs also delivers no more than that, but who wants to be average?
Sobotka: Why GIMP is inadequate Posted Jan 18, 2011 21:07 UTC (Tue) by daniel (subscriber, #3181) [Link]
"And if 8 bits is not going to cut it, then 10 bits can hardly be any better"
Depends on whether you consider two binary orders of magnitude "hardly" vs "massive" (I take the latter view).
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 18:14 UTC (Tue) by tshow (subscriber, #6411) [Link]
> It's interesting that the author talks about posterization at 8-bit, but demonstrates it with a 50-level gradation (i.e. less-than-6-bit). Why would someone do this?
Because you only get all 8 bits of range if your endpoints are black and white, respectively. The place where low bit-depth bites you is in subtle gradients; the closer the endpoints are, the fewer steps you have.
Consider, for example, a gradient from (0.5f, 0.5f, 0.5f) to (0.6f, 0.6f, 0.6f), or in 8bit hex terms, from $808080 to $9A9A9A. That's a 27 step gradient.
You also lose precision when you blend gradients between layers.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 8:38 UTC (Wed) by gowen (guest, #23914) [Link] Consider, for example, a gradient from (0.5f, 0.5f, 0.5f) to (0.6f, 0.6f, 0.6f), or in 8bit hex terms, from $808080 to $9A9A9A. That's a 27 step gradient.It's a 27 step gradient over relatively small change of colour intensity. He's shown a 50 step gradient from WHITE to BLACK. That's not the same thing you are describing. All quantization involves introducing steps -- the question is to determine when those steps are perceptible, and when they are not. Show that 50 steps is too few from 0xFF to 0x00 does not tell us anything about what step size is perceptible from 0x80 to 0x9A.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 9:11 UTC (Wed) by farnz (guest, #17727) [Link] Where it becomes important is not when painting afresh, but when editing an image. Take, for example, a bad photograph taken with inadequate lighting, and shadow on an amateur DSLR like the Canon Rebel series (D550 in my part of the world). The sensor has 12 bits of accuracy, or, put differently, 4 to 5 bits I can throw away when trying to fix my mistakes before putting this photo on the web. If I'm working in 16-bit, I can lighten the bits that were hidden in shadow by a small amount (say the equivalent of 2 bits), and then enhance contrast image-wide, costing me the equivalent of 3 bits of accuracy. Because I started with 12 bits, my resulting, visually improved image has between 7 and 9 bits of accuracy - when I downconvert to 8-bit for final output, I get 7 to 8 bits of accuracy; some people may notice this in the areas that were shadowy, but it's no longer that bad. Now do the same process with an 8-bit image. I throw away 2 bits in the shadowy areas, leaving 6. I throw away up to 3 bits improving contrast, making the bits in shadow have just 3 bits of accuracy in the range 0x00 to 0xff. That makes the image look bad. This is part of why photographers disagree on why it's needed; a better photographer would have got a decent exposure in the first place, one that didn't need quite so much fiddling to make it look good. I'm no expert, so I get a bad exposure of a well-composed scene, and have to play to make it look good (fortunately, my current tool of choice, digiKam, works in 16-bit, and gives me the adjustments I need to fix things).
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 11:05 UTC (Wed) by dgm (subscriber, #49227) [Link]
Lighten 2 bits means multiplying the channel value by four, making the pixel 4 times more bright. It doesn't sound like an small amount to me.
Also, I don't have the algorithm for contrast enhancement in mind, but 3 seems quite a lot to me.
I do retouch amateur pictures with Gimp. Worse, I usually start with a JPEG, not raw, and I would swear that the output looks far much better than 3 bits per channel (that's 9 bits per pixel). Maybe you are losing some color information, but 15 bits? no way.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 12:08 UTC (Wed) by farnz (guest, #17727) [Link] I'm rescuing bad exposures that wouldn't be usable at all if not retouched from RAW. These are not subtle improvements; I'm still not a good enough photographer to get the exposure almost right first time. If I were working with JPEGs, I'd just have to discard the exposure entirely, no matter that it's the only one where I got the composition right. It's simple things like catching a reflection of the sun in an otherwise dark composition, resulting in the swan (that then chooses to fly off) being too dark, and the duck in the shade being virtually invisible. Now, you can argue that I should have made better use of the camera, and got an exposure where the sunlight reflecting on the metal object is overexposed, but the rest of the exposure is good, and I'd not disagree. I need to get better at using the tools I have in the field, not just fixing it up later. But the fact remains that I didn't manage that: I got an exposure with 12 bits per channel from the sensor; of those 12 bits, for most of the image, only the lowest 7 to 9 bits per channel are actually interesting data, except in the area that reflected the setting sun, where it's the top bits that are interesting data. By working in 16 bits per channel while I'm fixing my mistakes, I get to recover an otherwise lost exposure; if I were limited to 8 bpc, the major corrections I need to make will also trash the image.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 18:44 UTC (Wed) by dgm (subscriber, #49227) [Link]
Then you're clearly outside of the Gimp current capabilities. Fortunately that doesn't mean you're out of options.
You could use ImageMagick, that uses internally floating point operations, to create semi-enhanced versions, and then make the final combination with the Gimp or some of the many HDR tools out there.
Another option is, of course, waiting until GEGL gets fully integrated in the Gimp.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 19:50 UTC (Wed) by farnz (guest, #17727) [Link] I've never claimed to be out of options; for my needs, digiKam is powerful enough - and for the cases where it isn't powerful enough on its own, digiKam to get me a good 8 bpc source, then Gimp to fix the remaining defects (unfortunate spots on people, that tiny bit of light that makes it look like my father in law has a boil on his nose, the spaghetti sauce stain on the tablecloth etc) is an amazing combination, especially given the price. I'm just giving a real example of why 8 bits per channel isn't enough for all amateur uses of computer image editing; given that my needs stray into the high bit depth world from time to time, I can easily understand why a professional would sometimes need high bit depth. And, of course, extending your final point, if I really, really need Gimp to be the ultimate editing tool for my images, I can do things to help get GEGL fully integrated. Maybe I work on it myself, as I'm a programmer. Maybe I pay someone to get it in there, if I were a rich man. Maybe I make sure that there are bugs for all the limitations in Gimp that affect me, and I follow them and help with testing (including learning enough sysadmin stuff to build versions from git). The joy of Free Software here is that I'm not quite as stuck as I would be with proprietary software.
Sobotka: Why GIMP is inadequate Posted Jan 18, 2011 21:39 UTC (Tue) by daniel (subscriber, #3181) [Link]
"Then you're clearly outside of the Gimp current capabilities. Fortunately that doesn't mean you're out of options."
Upgrading to GIMP 2.6.11 for example, which supports 32 bits per channel?
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 13:42 UTC (Wed) by tshow (subscriber, #6411) [Link]
> It's a 27 step gradient over relatively small change of colour intensity. He's shown a 50 step gradient from WHITE to BLACK. That's not the same thing you are describing. All quantization involves introducing steps -- the question is to determine when those steps are perceptible, and when they are not. Show that 50 steps is too few from 0xFF to 0x00 does not tell us anything about what step size is perceptible from 0x80 to 0x9A.
The article's example is bad, but the problem is real, and it's one I have run into repeatedly in practice; that's why I gave you the $80 to $9A example. Throw a few gradients with that level of stepping on a few translucent layers, and the banding starts to get very noticeable. Dithering helps, mind you.
As a regular gimp user, higher color depth isn't the highest priority thing on my wish list; you can work around the color depth if you have to. It would be nice not to have to work around the problem any more, however.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 16:46 UTC (Tue) by dneary (subscriber, #55185) [Link]
The comparison with Blender seems a little odd.
Most software has only a small number of active long-term developers.
Looking at Ohloh for the GIMP: https://www.ohloh.net/p/gimp/contributors there are the following active developers:
And it looks like Alexandre Proukoudine is the 5th, and is pretty inactive, but still with a few commits a month.
Over the history of the project there are ~400 identified hackers.
For gegl: https://www.ohloh.net/p/gegl/contributors
So we can say that between the two, there are 5 or 6 active hackers on the GIMP.
Now, Blender: https://www.ohloh.net/p/blender/contributors
Then we have people who're pretty new and moderately active: jhk, gsrb3d, dingto, damien78, Dalai Quintanilha Felinto, nazgul, metaandrocto, ZanQdo, mindrones, nexyon (we're dropping off a big cliff here at this stage - nexyon has ~100 commits over 2 years)
And older contributors who have been quieter recently, but are still around: ben2610, schlaile, genscher, elubie
So that's 7 very active developers, 10 active newcomers, and 4 old-timers who are still coding occasionally. 21 or so.
Yes, they're doing better - they have 10 new developers in the past 2-3 years, to 2 for the GIMP, and they have managed to keep old heads and knowledge around better than the GIMP, but people overestimate the number of active hackers there are working on projects like these.
Blender is seen as an amazing success primarily because Ton does such a huge job of fundraising, planning & doing these amazing projects around film & game development with Blender, and is very conscious of the importance of the artists using the software when planning features. Basically, he runs the Blender Institute as a company, and manages to pay 3 or 4 hackers full time 6 months of the year to work on features - which is an amazing success story - and not something the GIMP has ever tried to replicate.
That said, all the comments saying "GIMP UI sucks, that's what is holding it back" can't have used Blender much - now there's a UI where you really need to know what you're doing to be productive...
Cheers,
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 17:39 UTC (Tue) by nye (guest, #51576) [Link]
>That said, all the comments saying "GIMP UI sucks, that's what is holding it back" can't have used Blender much - now there's a UI where you really need to know what you're doing to be productive...
But the difference is that when you do know what you're doing, it's like Blender becomes an extension of your brain[0]. Its major flaw is poor discoverability, which is improved to a great extent in 2.50. On the other hand the GIMP's UI is simply awful, no matter how much practice you have.
[0] I would say that Blender and Vim are the only two applications I've ever actually *enjoyed* using.
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 16:26 UTC (Thu) by n8willis (editor, #43041) [Link]
The fact that one can memorize Blender's UI in no way equates to its being well-designed. Humans can memorize anything -- people even memorize thousands of digits of pi for sport, and it is mathematically the most random sequence of numbers known. But Blender still doesn't ask you if you want to save your work when you quit.
Whatever (unspecified) awful-ness you assert there is in the GIMP UI, at least it gets that -- and plenty of other basic HCI -- right.
Nate
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 20:32 UTC (Thu) by jthill (guest, #56558) [Link] As I recall Blender _always_ saves your work when you quit. If you meant to save it, pop back in (it starts _fast_) and save the blend you quit on to the original file. It's even dead easy to get it to always start where you left off.
Sobotka: Why GIMP is inadequate Posted Jan 14, 2011 19:58 UTC (Fri) by n8willis (editor, #43041) [Link]
Sobotka: Why GIMP is inadequate Posted Jan 15, 2011 3:59 UTC (Sat) by jthill (guest, #56558) [Link] From that link:Other File Open Options [...] I must be missing something; it seems to me that's exactly what I described.
Sobotka: Why GIMP is inadequate Posted Jan 21, 2011 22:13 UTC (Fri) by n8willis (editor, #43041) [Link]
Actually, it's not. Taken by itself that snippet implies that Blender auto-saves changes made to open files. In fact, quit.blend is just the contents of the *last* file touched -- meaning, for example, if you are working on one file, then open another, you lose everything, and quit.blend will have stored the unmodified last-opened-file. Plus you still get no warning/confirmation-interrupt that the file-open-operation is also destructive. The proper way to do auto-saving is the way Inkscape does it (per-file). And even if it did proper autosaves, it still doesn't make up for lacking confirmation-on-close/quit-with-unsaved changes, which is the root problem. Autosaves are supposed to be for crash recovery.
Nate
Sobotka: Why GIMP is inadequate Posted Jan 22, 2011 2:15 UTC (Sat) by jthill (guest, #56558) [Link] that snippet implies that Blender auto-saves changes made to open filesblender does auto-save, in exactly the way you say is proper. The "Vitals" section of the manual says so, and it's hard to miss the big "Auto Save" button on the preferences panel. It defaults to every five minutes, per file.
if you are working on one file, then open another File-open? Ok, we can change the subject, but you never mentioned this before. Blender does save every time you quit. More: manually saving takes a backup, and if you want lots of those you can tell it how many right there on the same auto-save preference pane. So acquiring the habit of hitting ^W whenever you hit a nice spot, before moving on to the next thing to do, because you can casually recover from doing that by mistake too, seems like a no-brainer to me. More: hit F1, double-click the filename, ... nothing happens. You have to hit Open File or use the keyboard. Just a little syncopation to remind you, like it asking for confirmation when you quit -- which it does. The file-open behavior description is at least accurate, but that behavior doesn't seem to be a problem in actual practice - for reasons which are apparent to anyone who actually uses it.
Sobotka: Why GIMP is inadequate Posted Feb 2, 2011 22:21 UTC (Wed) by n8willis (editor, #43041) [Link]
You clearly have a radically different idea about what constitutes "proper" behavior in this use case. I stand by what I linked to, by the absurdity of placing the onus on the user to do the saving, and the differences between Inkscape and Blender are quite clear, so I'm declaring this a John-Henry point. Have a nice day....
Nate
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 17:40 UTC (Tue) by prokoudine (guest, #41788) [Link]
> And it looks like Alexandre Proukoudine is the 5th,
> and is pretty inactive, but still with a few commits a month.
Eeek. No, by no means I'm developer. I mostly maintain Russian translation. Admittedly I did some lousy attempts at porting scripts to new API, but that's about it.
Oyvind Kolas is famously not a GIMP hacker, not until you strap him and torture for a week or two :)
There really are just two active developers: Mitch and Alexia. Sven, Martin and few more new occasional contributors make the other 0.5 developers between them.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 17:48 UTC (Tue) by dneary (subscriber, #55185) [Link]
Well, Oyvind hacks a fair bit on gegl, and it looks like and Martin are both as or more active than Alexia from Ohloh stats, so I'd say 4. Unless you're saying gegl won't be part of the gimp...
Dave.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 18:07 UTC (Tue) by prokoudine (guest, #41788) [Link]
It's a matter of perspective. Oyvind doesn't see himself as GIMP hacker. That's what I heard him articulating multiple times. Good luck persuading him that it's otherwise :)
I'm afraid that you are doing rather quantitative analysis without referring to timeline. Martin hasn't been doing much in Git since last spring. I've been doing weekly digests of changes in Git for about a year, so I kind of watch that. If you are keen referring to Ohloh, look at the timeline and do comparative research re amount of commits for e.g. Martin and Mitch. You'll see what I mean ;)
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 19:04 UTC (Tue) by drag (subscriber, #31333) [Link]
With Blender's UI it was designed as a modeling software for a small studio, in house, with the developers working directly with the artists that used the software professionally.
As a result it's like the Vi of 3D modelers. It's extremely fast with a bit of a esoteric interface. (different though that it's extremely non-modular.. this was a design goal.)
Not 'fast' as in processing speed, but 'fast' in your ability to crank models out. For cranking out 3D models there is very few applications that can keep up with a experienced Blender user.
The problem with Blender is that it's not just a modeler. It's a entire product suite with integrated renderer, texture editor, animation, composition engine, game engine etc etc.
The stuff that was made AFTER it was open sourced, and all the non-modular stuff generally sucked. Especially UI-wised. It did not provide the functionality that artists need, nor did it provide the existing functionality in a way that was accessible to artists.
That is why.....
With those projects they went back to having the developers working with artists in professional-like settings. They were then much better able to identify missing functionality, poor functionality, and identify areas in the UI that needed improvement. As a result a lot of the animation suite and game engine was completely overhauled. The UI changes and new functionality is what makes up the major reason for the Blender 2.5 release.
Human communication is extremely difficult and if your going to depend on just mailing lists and bug reports then it's going to be extremely difficult to write good software for other people.
Linux has benefited heavily from the fact that it was written by developers for developers. The 'by hackers for hackers' type thing. When you have a close tie between yourself and your users then that allows you to really get done what is needed to get done. There is a lot of poor UI theory and guesswork, but every application is different, and every group of users are different. Unless your able to work directly with them and observe people using your software in a real world environment _during_development_ then it's going to put the developers at a real disadvantage.
How many times have Gimp developers had a chance to sit down and observe professionals using their software and interacted with them while this was happening? Users know what they need and what they want, but they are going to be very ill-equipped to actually communicate this with programmers. Users generally will do a poor job guessing on what they need to say to programmers in order to get what they want. Programmers will tend to focus on things they need and things that fascinates them or holds their attention.
Working closely with users and observing them work is something that Adobe would do with Photoshop on a regular basis...
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 21:57 UTC (Tue) by boudewijn (subscriber, #14185) [Link] "How many times have Gimp developers had a chance to sit down and observe professionals using their software and interacted with them while this was happening?" I would think quite a few times. And they are helped by a profession interaction designer right now, and the improvements are staggering. I regularly compile gimp's git master, and it's getting better all the time. But for the rest you're quite right, of course. It's why all graphics app projects went wild when David Revoy started giving feedback last year. It's so immensely useful. All I can say is that any artists who tests Krita gets a spot in the About box!
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 7:25 UTC (Wed) by prokoudine (guest, #41788) [Link]
> How many times have Gimp developers had a chance to sit down
> and observe professionals using their software and interacted > with them while this was happening?
At least once, during one week in 2006, as part of OpenUsability project. Some of the already implemented specs (new crop tool and rectangular tools, new freehand selection etc) comes as result of that.
Sobotka: Why GIMP is inadequate Posted Jan 24, 2011 7:00 UTC (Mon) by LetterRip (guest, #6816) [Link]
There are numerous reasons for Blenders success
1) Superb leadership - both at the top (Ton) but we also have a great deal of leadership throughout the team.
2) Good communication skills - we don't do flame wars, we hold a meeting once a week to plan technical goals and keep everyone on the same page.
3) Market related - When Blender first went open source, there weren't any decent tools that did everything Blender did for much under 10,000$. So unless one was willing to pirate, it was Blender or a huge up front cost, or a tool inferior to Blender that was still 500$+.
4) Sexiness - Working on 3D is something most programmers grew up dreaming about; simulation tools are a sexy, high prestige, and exciting part of programming.
The confluence of those factors have lead to Blenders success.
Note that the post I'm responding to actually underestimates our dev base by quite a bit, since we moved most of our scripts to a seperate svn which the main tree pulls from.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 17:29 UTC (Tue) by ssam (subscriber, #46587) [Link]
another difference with krita: the krita guys are happy to use donations to fund work. the gimp guys are very wary of it ( http://article.gmane.org/gmane.comp.video.gimp.devel/17550 ).
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 17:46 UTC (Tue) by prokoudine (guest, #41788) [Link]
> another difference with krita: the krita guys are happy to use
> donations to fund work. the gimp guys are very wary of it
Actually I remember either Sven or Mitch saying last year they totally wouldn't mind someone working full-time on GIMP. I just don't remember if it was in the list or IRC, so I can't link to it.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 18:04 UTC (Tue) by mattdm (subscriber, #18) [Link]
Huh. All of that and no mention of Adjustment Layers?
Sobotka: Why GIMP is inadequate Posted Jan 13, 2011 18:31 UTC (Thu) by luya (subscriber, #50741) [Link]
Let see, the issue is related to the use of RAW image on Gimp. Did the author try URaw and its gimp extension?
|
|||||||||||||