| |||||||||||||
Sobotka: Why GIMP is inadequateSobotka: Why GIMP is inadequatePosted Jan 12, 2011 11:44 UTC (Wed) by boudewijn (subscriber, #14185)In reply to: Sobotka: Why GIMP is inadequate by HelloWorld Parent article: Sobotka: Why GIMP is inadequate
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.
(Log in to post comments)
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.
|
|||||||||||||