XDC2012: Programming languages for X application development [LWN.net]

By Michael Kerrisk
October 3, 2012

2012 X.Org Developers' Conference

To what extent is the choice of programming language important in terms of making it easier to build desktop applications? This was the question asked by Bart Massey in his talk on day two of the 2012 X.Org Developers' Conference.

Bart observed that we've now reached the point where it's harder to write a desktop application than it is to write a mobile or web application. Furthermore, the quality of desktop applications is often worse than for mobile and web applications. In Bart's opinion, the situation should be the other way round, and he is puzzling over why it is not.

Some factors that make programming desktop applications harder are beyond the X developers' control, he noted. For example, desktop applications may be much bigger than mobile and web applications. They may also have requirements that are not present, or are simply not addressed on mobile and web platforms. For example, desktop applications may need to manage quite sophisticated user interactions, and provide full internationalization support (which is omitted from many mobile and web applications). It's hard for the X developers to control these factors, but Bart noted one area where they can have some influence in making the development of desktop applications easier: the choice of programming language.

When it comes to programming languages, how are mobile and web applications different? Bart pointed out that—unlike desktop applications—it is notable that they are almost exclusively not written in C or C++. Objective C is used in the mobile space, but Bart noted that that language is special (because it provides some features not found in C/C++ that are found in the other languages used for mobile applications). In the mobile and web space, nearly everyone is using languages that have automated memory management; that eliminates problems with memory leaks and mishandled pointers. These programming languages commonly support late binding and dynamic loading. Languages that provide these sorts of features are attractive because they allow developers to be much more productive. That's especially important because the mobile and web spaces are fast moving and programmers need to be able to put applications together quickly. By contrast, developing for the desktop—and Bart made it clear that here he was speaking about desktops in general, not just X—requires a much greater initial effort before a programmer is productive.

On the X desktop, the common programming languages have been C and C++, and Bart noted a number of ways in which these languages have been a source of pain for application developers. There are many reasons to use multiple threads in GUI programs, most notably because a windowed interface in a GUI environment is naturally concurrent. However, threading support in C and C++ (typically via POSIX threads) is not easy to use for the average application developer. The frameworks used in C/C++ often involve callbacks and other complicated flows of control, which are likewise challenging for programmers. Manual memory management is tricky for programmers as well: monitoring memory usage of desktop applications on any platform (not just X), it's easy to find cases of applications that leak memory. And while its true that things can go wrong with automated memory management, in practice those problems are not as bad.

In Bart's view, the choice of programming language (and the accompanying frameworks that that choice implies) is one of the things getting in the way when it comes to developing X applications. The X tool kits have a widget mentality, and while he feels that that is probably a good mentality, the toolkits make widget creation a lot of work: too much boiler-plate code and "weird interaction" is required for building widgets. "The problem is that the language doesn't give you convenient ways to express what you want to express."

We use C and C++ on the X desktop because they've always been there, Bart noted. But, what are the alternatives? Bart estimated that there are some 400 programming languages in wide use, but noted that there are obvious attractions to using a mainstream language, in terms of the pool of developers and available support. Java is an obvious choice. C# is another possibility, but he thought that there were no advantages that made it clearly compelling over Java. If one widens the net, other alternatives might include SML, OCaml, or Haskell, but he felt sure that if he asked the room what language should be the future of desktop development, he'd get fifteen answers.

Bart then considered the toolkits used with X a little more deeply. He noted that low-level libraries such as XCB are written in C/C++. There are various reasons for that choice, among them efficiency and the ease providing foreign-function interfaces (bindings) for other languages. The choice of C/C++ at this level of the stack is okay, he thinks. But, as we go up the stack, the next thing we come to is the toolkits, and the choices there are Qt and GTK. Both are old, entrenched, and written in C/C++. Because of that, the applications created above them tend to be written in the same language. It's time to think hard about whether these are the right tool kits for applications built in 2012. The problems of building desktop applications are amplified by using these large, complex libraries, and they don't provide the automated support that is provided in mobile and web frameworks.

Bart noted some summary points from his work during the last ten years. If someone asks him what language to use to write a graphical desktop application, he is typically going to respond: Java. This is ironic, because he, an X developer, is recommending a language that will not produce a native X application. But, he noted that the overhead of writing a Java GUI application is simply lower (than C/C++), even when developing for the Linux/X desktop. Another reasonable alternative that he sees is Python with a toolkit (for example, wxWidgets). As a teacher (at Portland State University), Bart recommends those alternatives to his students, rather than the C/C++-based frameworks available for X.

Is programming language even the right thing to be thinking about, when considering problem of building desktop applications? Bart said that the audience might be able to convince him otherwise. But, he wanted to know, if programming language is not a part of the problem, then just how weird does a programming language need to be before it is a problem? He then mentioned a few factors that may or may not matter with respect to the choice of programming languages and toolkits. One of the more interesting of these was portability of applications across desktop, mobile, and web. It would be nice to have that, though it is "really hard." But, he asked, what can we do in terms of choice of programming language to facilitate that possibility?

On the other hand perhaps we are stuck with GTK and Qt, Bart said. He noted that it was hard enough to replace Xlib with XCB. The task has taken ten years, and Xlib is likely still to be with us for another decade. Perhaps replacing the toolkit frameworks is too difficult, and when it comes to developing desktop applications, we're consequently stuck with C/C++ forever. He concluded, however, that "if we're going to save the desktop—and don't fool yourself, it is in trouble—then I think programming language is part of the problem."

A lively discussion followed the formal part of Bart's presentation. In response to some comments from Supreet Pal Singh about the satisfactions of doing X application development in C/C++, Bart elaborated further on his point. He noted that that there is no ramp to being an X developer—it's a cliff. Developers have to master many technologies before they can do anything. He acknowledged that he too has a different feeling when developing X applications in C++, "but it's not a happy one: I feel smart for being able to do this in C++, but not smart for having done it".

Another audience member noted that Qt Creator can be used for rapid development of X applications. Bart observed that code-generation tools solve some problems, but replace them with other problems as one reaches the limits of what the code generator can do. At that point, the developer then has the problem of trying to understand what is going on under the hood of the generator and possibly tweaking its output, which can complicate code maintenance. He also noted that a GUI application created with a code generator tends to behave less well for the user. For example, he suggested, try using a GUI tool to build an application designed for a small window and then scale that window up and watch what happens. The result is very different from an application where the layouts and layout policy have been hand-crafted so that it works well for all window sizes.

Peter Hutterer pointed out that it may be because of the relative youth of the web and mobile application spaces that they are not suffering some of the same problems as desktop X applications. X has been around for well over 20 years; in 10 years' time, web and mobile applications may have some of the same issues. He mentioned Android fragmentation as a possible example of the kinds of problems to come. Bart agreed that the passage of time may bring legacy problems to mobile and web application development, but noted that many of his points were independent of legacy problems: the need to manage pointers and memory, wacky untyped (void *) interfaces, and complex linking interactions. He constantly sees his students struggling with these problems.

Matthias Hopf pointed out one language that was missing from Bart's discussion, but noted that he was hesitant to propose it as a candidate. That language is of course JavaScript, which started out in the web space, but is making its way to the desktop in the form of node.js. Bart responded that he wasn't against JavaScript as a development language. Some aspects of the language make him suspicious, "but the very fact that people are successfully developing web and mobile applications in JavaScript and HTML5 says that it's worth considering [for the desktop]. It would be interesting to consider what a set of JavaScript bindings for X would look like."

Other members in the audience noted that the combination of QML, JavaScript, and C++ is an effective framework for rapid development of X applications, though Keith Packard interjected that he didn't want to have to write an application in three languages. Although Bart acknowledged that some of the information about QML was new to him, by the end of the session, he still didn't seem to be convinced away from his thesis that the current X programming languages and the frameworks were part of the barrier to developing X applications.

Decades of experience have shown C and C++ are powerful languages for system programming, but few would deny that they provide application developers with too many opportunities to shoot themselves in the foot. Bart was facing a rather atypical audience: a room full of C/C++ experts. Nevertheless, there was some sympathy for his thesis, and one suspects that if a more typical cross section of application developers were asked, there would be rather more agreement with his position.

The X.Org wiki has a pointer to the video of this session.

Index entries for this article
Conference	X.Org Developers Conference/2012

to post comments

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 5:06 UTC (Thu) by etrusco (guest, #4227) [Link] (3 responses)

If only people were not so quick in dismissing Object Pascal (http://lazarus.freepascal.org/) and Visual Basic (http://gambas.sourceforge.net/en/main.html)...

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 11:51 UTC (Thu) by robert_s (subscriber, #42402) [Link] (2 responses)

...we would end up with a whole lot more low quality software?

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 14:42 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

Visual Basic is a severely deficient language, but Object Pascal (and Delphi/Borland/Turbo Pascal from which it derives) long, long ago fixed the worst problems with Pascal and left you with a language that is not really all that much worse than C. (Disclaimer: I started my procedural programming life with Turbo Pascal, waay back in 1988. It's quite possible to write things like memory allocators and tries and the like in it, which you really, really couldn't do with standard Pascal. It also has a not too deficient file I/O library, very much unlike standard Pascal.)

XDC2012: Programming languages for X application development

Posted Oct 5, 2012 9:13 UTC (Fri) by patrick_g (subscriber, #44470) [Link]

>>> Visual Basic is a severely deficient language

From the Gambas site :

The phenomenal quantity of bugs and inconsistencies that makes Visual Basic so delightful persuaded me to start this project ;-)
It seems that Microsoft was aware of the poor quality of its language, as VB .Net is not backward compatible with older versions of Visual Basic.
I want to clear up any misunderstanding immediately. Gambas does not try to be compatible with Visual Basic, and will never be. I'm convinced that its syntax and internals are far better than the one's of its proprietary cousin!
I took from Visual Basic what I found useful : the Basic language, the development environment, and the easiness to quickly make programs with user interfaces. That's all.

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 6:04 UTC (Thu) by flewellyn (subscriber, #5047) [Link] (12 responses)

I've found that, as far as GUI development goes, the really tedious part of coding is laying out the controls using a programming language. That's not really what they're for. I've often wished for something akin in spirit to HTML+CSS for layout and visual appearance, with the ability to tie code to events. It doesn't have to be HTML, of course (although I note the success of "widget frameworks" like Dashboard on OS X that use HTML, CSS, and Javascript on the desktop), but some kind of domain-specific language that is declarative, flexible, and easy to work with, would be great.

If the toolkits had a means of, say, importing a declarative description of a GUI layout, and generated the resulting code to draw the controls, with my own code called from callbacks as defined in the declaration...that would probably speed things up enormously.

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 8:29 UTC (Thu) by gidoca (subscriber, #62438) [Link] (4 responses)

That sounds exactly what QML is supposed to be, though I haven't tried it yet myself.

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 10:19 UTC (Thu) by halla (subscriber, #14185) [Link] (2 responses)

Qt Designer provides visual laying out of controls. It generates xml that, yeah, is translated into C++ that puts the controls in a layout. I wouldn't call it a code generator, even though it's possible to add some basic signal-slot connections in Designer.

Creating gui's in QML on the other hand is a more manual process. But it's awe-inspiringly productive, even if you have to mix the json-like gui description with little snippets of javascript and backend objects in C++. It feels a bit weird to start with, but after a certain point, QML makes developers really happy.

Then again, calling for application development in high-level languages is not something new in 2012. Python and Qt have been a great option for developing gui apps since 1999 at least, that's thirteen years ago. And it's used today, used for big, commercial applications like Nuke.

Personally, I've found very little difference in developer productivity between Qt/C++ and Python + Qt. Using QML does increase productivity quite a bit. Writing a gui application in Java is a horrible experience -- but I have to admit that my knowledge is not current anymore, I stopped doing that six or seven years ago.

I have the feeling that Bart Massey is maybe a bit too much out of touch with developments in the past decade to present on this topic.

XDC2012: Programming languages for X application development

Posted Oct 6, 2012 5:09 UTC (Sat) by lamawithonel (subscriber, #86149) [Link] (1 responses)

PyQt was my first thought. I've never actually tried it, but I've encountered enough quality applications using it that I would give it a go if I were starting a new project. A few examples I can think of off hand: the Eric IDE, HPLIP, the Calibre ebook manager, and Amarok, the KDE audio player.

XDC2012: Programming languages for X application development

Posted Oct 6, 2012 12:32 UTC (Sat) by hummassa (guest, #307) [Link]

Amarok is written in C++...

$ sloccount amarok-2.6.0/
...
Totals grouped by language (dominant language first):
cpp:         213236 (98.15%)
ansic:         2595 (1.19%)
xml:           1267 (0.58%)
ruby:            62 (0.03%)
python:          54 (0.02%)
perl:            27 (0.01%)
sh:              10 (0.00%)
...

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 23:16 UTC (Thu) by dashesy (guest, #74652) [Link]

Even Qt widgets support some CSS

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 8:49 UTC (Thu) by pabs (subscriber, #43278) [Link] (2 responses)

If you are using GTK+, then you want to look at GtkBuilder (and the GUI for creating them is glade).

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 14:04 UTC (Thu) by debacle (subscriber, #7114) [Link] (1 responses)

Yes, Glade is really nice, esp. with Python, but also with C. I used it some time back, before the existence of GtkBuilder, but with the obsolete libglade. For cross platform development (= MS compatibility) I think that wxWindows (and wxPython) are easier to deploy.

XDC2012: Programming languages for X application development

Posted Oct 12, 2012 20:00 UTC (Fri) by oak (guest, #2786) [Link]

While Glade is OKish, it forcing the UI creation to happen in the widget hierarchy root -> leaf direction makes the process of creating the UI almost as painful as creating the UI manually and changing of the resulting UI maybe even harder..

Qt GUI design tool has a really nice feature; you can add the basic widgets first and only as last thing drag the containers over their child widgets, in the way that makes the UI most scalable.

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 9:30 UTC (Thu) by alankila (guest, #47141) [Link] (1 responses)

Many people seem to agree. Android also has taken this XML-layout model, although to wire up the events you will need to find the controls from the layout tree and add the relevant event listeners that you need.

The key, I think, is that it's much easier to write tools to display and edit such XML documents, so interface designers become relatively sane to write. Contrast, for instance, to the problem of parsing a (possibly) hand-edited source file and working out how the controls are laid out there, and then allowing editing of it. I think it's not going to happen.

Android tools

Posted Oct 5, 2012 12:19 UTC (Fri) by man_ls (guest, #15091) [Link]

Exactly, I thought grand-parent was pining for Android tools too. The upside is that the layout design tool uses Eclipse and so it is tightly integrated with your code. The biggest downside is exactly the same: a monolithic IDE is a bit hard to use for graphical designers, and these days it hurts a little bit when people drive me away from my vim. (Also when those damn kids get close to my lawn, and likewise when the weather changes, but so it is with age.)

The idea is cool though, and much easier to use than HTML content creation tools (like e.g. Coda + Chrome). Often it is easier to touch the underlying XML file than delve in the endless lists of attributes, and the visual interface can do weird things; but you get to see the results of the tinkering in almost real time, and both options (graphical and text editing) are available.

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 13:03 UTC (Thu) by dskoll (subscriber, #1630) [Link] (1 responses)

If the toolkits had a means of, say, importing a declarative description of a GUI layout, and generated the resulting code to draw the controls, with my own code called from callbacks as defined in the declaration...that would probably speed things up enormously.

Such technology existed in the early 1990's with the Tk toolkit. Its pack and place and later grid geometry management commands made laying out controls a breeze. Furthermore, as windows are resized, the controls reflow naturally and intuitively.

I did my first GUI programming under Tcl/Tk and it was absolute bliss. When I see the horrible things people need to do to get going with Gtk+ or Qt, I realize how lucky I was that Tk hid all the nasties.

Unfortunately, Tcl/Tk has fallen out of favor. :( Just because Tcl is a bit idiosyncratic doesn't mean we should forget all the great advances made by Tk.

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 20:32 UTC (Thu) by sytoka (guest, #38525) [Link]

I used one time tcl/tk and that was horrible... I switch to Perl/Tk and program look quite good.

Tk can be use by many scripting language.

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 6:18 UTC (Thu) by salimma (subscriber, #34460) [Link] (2 responses)

GNOME application development is increasingly being done in JavaScript -- a bit surprised that that was not mentioned. Gtk+/GNOME libraries are reasonably pleasant to use as long as they can be introspected properly.

XDC2012: Programming languages for X application development

Posted Oct 8, 2012 18:24 UTC (Mon) by jond (subscriber, #37669) [Link] (1 responses)

…and regardless of what the programs are written in (C, Javascript, Vala, etc.); how common is it for people to write the UI code themselves anymore? GtkBuilder writes an interface file in XML, the libraries read it at run-time… and its not that new, glade did that for a while before that (but started with code generation, sure). I wonder how up-to-speed the speaker was on how things are actually done today.

XDC2012: Programming languages for X application development

Posted Oct 11, 2012 20:01 UTC (Thu) by HelloWorld (guest, #56129) [Link]

> I wonder how up-to-speed the speaker was on how things are actually done today.
Not at all, I wrote down a few more indications here:
http://lwn.net/Comments/519373/
It really makes me angry when people like him blather about stuff they don't understand at all and lead other people to believe things that aren't true.

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 10:33 UTC (Thu) by hunger (subscriber, #36242) [Link]

The first thing that crossed my mind reading this was: So UI builders are bad since if they break they form an additional layer between the programmer and the machine? This mindset is exactly what makes application development hard! People working on core elements need to help make good tools possible, and not argue against them. Good tools are essential for a good developer experience.

The second thing that hit me is that XCB is discussed. Is that in any way relevant to developers not working on tool kits nowadays?

Finally I was a bit sad that Qt was dismissed together with Gtk, even though both are hardly comparable. Qt's QML is a really interesting approach and the author did not even know about it... There is no mention at all of clutter in the article, suggesting that all the newer developments in Gtk-land were not covered in the presentation either.

I would have loved to be in that presentation though: I am sure the discussions it triggered were interesting:-)

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 11:02 UTC (Thu) by ortalo (guest, #4654) [Link] (1 responses)

From the point of view of programming languages and HCI (Human-Computer Interface) research, it seems that the declarative features of a language are those that offered pretty decisive advantages for GUI applications. I really support that view even though I am not so knowledgeable in the field.

(That was possibly surprising for programming languages researchers, but they usually acknowledge that obsevation. HCI researchers find the fact pretty natural but frequently do not seem to have such a clear view of declarative vs. functional features.)
I've seen a few examples of that in those (now old) projects: Garnet (CMU Common Lisp), Amulet (CMU successor to Garnet, C++ based, but very different from C++ in practice), and Mozart-OZ (GUI component).

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 12:46 UTC (Thu) by hunger (subscriber, #36242) [Link]

For some newer implementation of declarative UI design you might want to add Qt Quick (QML) to your list.

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 11:29 UTC (Thu) by njwhite (guest, #51848) [Link] (18 responses)

Tcl/Tk is the only language I've found GUI programming pleasant in. It really is superb, and I'm suprised more people don't use it. Cross-platform, stable, attractive, and very simply but powerfully expressive.

Is there a reason (other than tcl isn't taught in schools much) that people know of for its (comparative) lack of usage?

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 11:46 UTC (Thu) by juliank (guest, #45896) [Link] (17 responses)

Uglyness. Tk does not integrate into a desktop at all.

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 11:57 UTC (Thu) by njwhite (guest, #51848) [Link] (14 responses)

> Uglyness

Tk 8.5 on my Debian is at least as attractive as GTK applications, to me.

> Tk does not integrate into a desktop at all

If one uses ttk widgets it will use the desktop theme, AFAIK. But I've never bothered with it, because regular widgets in Tk 8.5 are quite pretty, and not very different to the default widget styles of Qt and Gtk.

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 16:18 UTC (Thu) by intgr (subscriber, #39733) [Link] (13 responses)

> Tk 8.5 on my Debian is at least as attractive as GTK applications, to me.

Are we talking about the same Tk that appears when you run gitk, hgk or use Tkinter in Python? Because every time I do, I feel like I'm going through a time machine, decades back, to the days of Motif.

And they still have no grid widget (list widget with multiple columns), so it has to be emulated via multiple single-column list widgets. Srsly?

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 18:13 UTC (Thu) by dskoll (subscriber, #1630) [Link] (12 responses)

Tk, in its default configuration, does look old, but I don't think ugly. I don't think gitk's interface is any uglier than those of my other desktop tools like Firefox, claws-mail, etc.

And the whole point of Tcl/Tk is that it's easy to build up "megawidgets" from simpler widgets so you don't *need* a multicolumn list box. Once the code is written to make a megawidget, you just use it.

If you don't like writing your own widget code, there are plenty of libraries (eg, BWidget) that have all the widgets you'd ever need.

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 18:24 UTC (Thu) by juliank (guest, #45896) [Link] (11 responses)

Old = Ugly here. Tk's look (motif ?) is older than me, so it feels totally alien to me.

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 22:25 UTC (Thu) by njwhite (guest, #51848) [Link] (10 responses)

> Tk's look (motif ?) is older than me, so it feels totally alien to me

I really feel like we must be talking past each other somehow. Here are screenshots from a couple of little GUI programs I wrote recently, with Debian's Tk 8.5, doing nothing fancy whatsoever:
http://njw.me.uk/getxbook/screenshot1.png
http://www.dur.ac.uk/nick.white/tmp/tess-tkgui/tess-tkgui...

Motif may well be older than me too; I really don't think Tk looks particularly dated. Tk 8.4 did, 'cos it didn't use proportional fonts (at least by default), but Tk 8.5 looks as modern as anything else to me. And as I mentioned above, it's really nice to code in.

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 22:53 UTC (Thu) by juliank (guest, #45896) [Link] (2 responses)

It looks a bit better than previously (it was darker previously IIRC), I'd say it looks OK. But it is easily recognizable as a non-native toolkit in a desktop, whereas all other major toolkits (GTK+, Qt, and wxWidgets if you like) are not (as they render using either GTK+ or Qt). What it needs are stuff like rounded corners and some more visual hints, like coloring of active tabs.

I want my graphical applications to look great, not OK. They a sort of a distraction from the main part of the screen content, the terminal. That's why I don't use stuff like Tk, Xfce, or Enlightenment. They're all ugly and inconsistent compared to the wonderful GNOME 3 desktop (GNOME 3 has other important problems though, like crashes on user switch).

XDC2012: Programming languages for X application development

Posted Oct 5, 2012 13:28 UTC (Fri) by dskoll (subscriber, #1630) [Link]

They're all ugly and inconsistent compared to the wonderful GNOME 3 desktop

Ah, I see. You're being ironic.

Seriously... "ugly" is absolutely in the eye of the beholder and I find Tk apps no more ugly than Qt or gtk+ ones.

XDC2012: Programming languages for X application development

Posted Oct 5, 2012 21:51 UTC (Fri) by sramkrishna (subscriber, #72628) [Link]

You should file a bug on that.

Tk look

Posted Oct 5, 2012 12:32 UTC (Fri) by man_ls (guest, #15091) [Link] (5 responses)

Ugh. Ugliness is in the eye in the beholder, definitely. Why do people think that white backgrounds are only for text documents?

Also, there are varying degrees of ugliness. I have deduced through various experiences that my aesthetic sense is a bit advanced for a developer, but completely backwards for regular people. The screenshots you posted are (no offense meant) definitely in developer-only land: function over form.

Tk look

Posted Oct 5, 2012 12:38 UTC (Fri) by mpr22 (subscriber, #60784) [Link] (2 responses)

Why do people think that white backgrounds are only for text documents?

Because large expanses of white background on emitted-light display are eye-stabby in much the same way that a thinly-overcast sky is.

Tk look

Posted Oct 6, 2012 9:16 UTC (Sat) by man_ls (guest, #15091) [Link] (1 responses)

I disagree. That might have been the case ages ago with CRTs, but TFTs have made it tolerable and even desirable. My browser window fills the whole screen and the web pages in it are usually large expanses of white, including right now LWN.net. It is not uncomfortable at all, and making the thin control stripes (menu and buttons) a little bit darker does not change the overall picture.

In fact, darker backgrounds on web pages decrease readability. I find white text on a dark background particularly nasty: after reading such a page I see dark spots everywhere for a minute or so. I have configured my terminal windows to be black on white too and now live in a bright, sunny world.

Tk look

Posted Oct 10, 2012 15:58 UTC (Wed) by Tet (subscriber, #5433) [Link]

TFTs have made it tolerable and even desirable

Nope. Still intolerable and undesirable here. TFTs have made it not quite as bad as before, but I still prefer light text on a dark background 90% of the time. How anyone can work with a dark on light terminal is beyond me. But hey, everyone's personal preferences are different.

Tk look

Posted Oct 6, 2012 7:13 UTC (Sat) by dirtyepic (guest, #30178) [Link] (1 responses)

> Why do people think that white backgrounds are only for text documents?

Everyone knows text documents should be chunky white text on a blue background. Those white backgrounds just give you screen burn.

Tk look

Posted Oct 6, 2012 10:48 UTC (Sat) by wazoox (subscriber, #69624) [Link]

Thank you. I've always thought that the one true color for term windows is the traditional IRIX winterm appearance ( example here: http://www.guidebookgallery.org/pics/gui/system/utilities... )

XDC2012: Programming languages for X application development

Posted Oct 6, 2012 6:55 UTC (Sat) by dirtyepic (guest, #30178) [Link]

Sorry, that screams Windows 98 to me. It's just boxy and generic with no visual variety. Though maybe it looks better when framed inside the standard window decorations.

XDC2012: Programming languages for X application development

Posted Oct 7, 2012 19:50 UTC (Sun) by Seegras (guest, #20463) [Link] (1 responses)

Totally. Even the code looks ugly.

Anyway: The problem here is, this beast comes with _another_ totally different look and feel.

What's needed is a consistent look & feel all over all applications, no matter what language they're written in. And the whole thing has to be theme-able, so I can change the look & feel of the whole desktop at the same time.

It's a big strength of Windows and MacOS that every application looks the same (apart from idiots taking pains "their" application looks different. They belong into the user interface hall of shame). But it's a big strength of the X11 toolkits (Gtk, Qt, even Athena) that the look of all the applications written in them is theme-able globally. You don't want to loose that, you want to expand it over different toolkits.

XDC2012: Programming languages for X application development

Posted Oct 8, 2012 18:28 UTC (Mon) by jond (subscriber, #37669) [Link]

> What's needed is a consistent look & feel all over all applications, no
> matter what language they're written in. And the whole thing has to be
> theme-able, so I can change the look & feel of the whole desktop at the
> same time.

We have that, now. You can write GTK apps in C, C++, Java, Perl, Python… You can write Qt apps in C++, Java, Perl, Python… (not sure about C). The problem is we have it more than once :)

Javascript for GUI development

Posted Oct 4, 2012 14:15 UTC (Thu) by rfunk (subscriber, #4054) [Link] (1 responses)

My understanding is that Windows is going in the direction of Javascript/HTML for desktop GUI development. Since Javascript is rapidly becoming a language that everyone needs to know a little bit, this can only help Windows keep attracting new developers, while Linux desktop development stagnates with C and C++. I wonder if we could pick the bones of WebOS to get something useful and attractive to developers and users.

Javascript for GUI development

Posted Oct 4, 2012 15:05 UTC (Thu) by halla (subscriber, #14185) [Link]

Except, of course, that the Linux desktop isn't stagnating with C and C++. That was the contention of the presenter, whose knowledge simply was years out of date.

I did my first Linux desktop GUI application in a "modern" language in 1998 -- python in that case. I did my first HTML and JavaScript desktop application in 2007. I am right now doing my first Qt Quick application -- which actually is a completely new GUI around an existing application engine. There heave been heaps of other options, like the tcl/tk others have mentioned which I personally am happy never to have to use again, but tastes differ.

X application development?

Posted Oct 4, 2012 16:00 UTC (Thu) by renox (guest, #23785) [Link] (4 responses)

Nobody do X application development, they do Qt or GTK application development.
As for the programming languages, few languages have good Qt support (D hasn't for example), I think that the situation is better for GTK..

X application development?

Posted Oct 4, 2012 16:22 UTC (Thu) by halla (subscriber, #14185) [Link] (3 responses)

I don't think so... In general, language tend to lag except for the most used languages, like Python or Ruby, and that holds for both Qt and GTK. According to http://en.wikipedia.org/wiki/Qt_%28framework%29#Bindings, the D language bindings to Qt only miss support for QtSQL, QtScript, QtTest and QtUiTools, hardly core parts of the Qt platform. Not that I've used it, I'm happy with C++, Python and Javascript, which are all fine.

X application development?

Posted Oct 4, 2012 17:56 UTC (Thu) by renox (guest, #23785) [Link] (2 responses)

According to recent messages on the D mailing list, QtD is stalled and contains critical bugs: http://forum.dlang.org/thread/mailman.461.1349112690.5162...

C++, Python, Javascript works well with Qt, but what else? GTK has many more languages supported.

X application development?

Posted Oct 4, 2012 18:10 UTC (Thu) by halla (subscriber, #14185) [Link] (1 responses)

And how active are those many more supported languages? How complete? Really, for all practical purposes the "GTK is C, so much easier to bind to than C++ Qt" is a canard, one that's been flapping around for a decade now.

X application development?

Posted Oct 5, 2012 1:24 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

The most popular and widely used languages for GTK are C, Python, Javascript, Vala, C++ and C#. They are all very complete. Others might be but not many apps are written in them.

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 18:16 UTC (Thu) by magnus (subscriber, #34778) [Link] (6 responses)

I would like to find a truly event-centric language where the main polling loop and callbacks etc are handled in the language itself and the GUI logic can be programmed in a more natural way through some kind of coroutines or lightweight threads instead of being chopped up into callbacks.

A well-integrated stable such language with good debugging/tracing support combined with a GUI builder would be excellent I think.

XDC2012: Programming languages for X application development

Posted Oct 7, 2012 17:57 UTC (Sun) by cmccabe (guest, #60281) [Link] (4 responses)

> I would like to find a truly event-centric language
> where the main polling loop and callbacks etc are
> handled in the language itself and the GUI logic
> can be programmed in a more natural way through
> some kind of coroutines or lightweight threads
> instead of being chopped up into callbacks.

Google Go (golang) might be a good choice. It has goroutines (http://golang.org/doc/effective_go.html#goroutines) and channels, which neatly encapsulate event-driven programming.

Go programs tend to feel a lot faster than Javascript, Python, or Perl programs. I hate the sloppy feeling of GUIs in scripting languages, where you press a button and wait for something to happen.

Also, Go is stable-- it's made it to 1.0 now.

There are gtk and fltk bindings, so you could use the GUI builders that have been developed for those.

XDC2012: Programming languages for X application development

Posted Oct 8, 2012 5:46 UTC (Mon) by magnus (subscriber, #34778) [Link] (1 responses)

The problem with most of these language bindings for GTK etc is that they are "shallow", just hooks allowing you to call into the C library. That's not adequate.

For example GTK/Glib has it's own object hierarchy, main loop, linked list handling, thread handling, reference counting and so on. All this should blend into the binded language so you shouldn't have to cast/convert things between your application code and the library, it should just work as if it was native. I don't know how many languages support that kind of deep library embedding.

For the GUI builder problem, say for example say you want to write a custom widget in Go (or whatever language you've chosen) and use that in the GUI builder. Can you do that? What happens when you need to debug the program, will you be able to do that cleanly in the high-level language or will you need to single-step through autogenerated junk? And so on...

XDC2012: Programming languages for X application development

Posted Oct 8, 2012 8:38 UTC (Mon) by ortalo (guest, #4654) [Link]

I have the feeling too, like you, that such bindings are not convenient enough.

But then, maybe it implies that the toolkit library itself should be written in a different language (hence pushing the language/{C,C++} frontier inside the toolkit and under the responsability of the {Gnome,Qt} project). Application developpers would lose some choice (but that's the objective after all).
However, in this case, the choice of the implementation language is critical and, given the number of available alternatives and the current domination of {C,C++}, it is pretty easy to predict an enormous resistance to change.
I wonder if someone will be able to challenge the situation someday. IMHO, Amulet (CMU) was the last attempt in the research domain.
Maybe Vala is another one that has its chance (in the Gnome realm)?
QML is interesting too (in Qt realm) but it seems to be more of an evolutionary approch than something disruptive (maybe that's more reasonable btw).

XDC2012: Programming languages for X application development

Posted Oct 11, 2012 19:48 UTC (Thu) by HelloWorld (guest, #56129) [Link] (1 responses)

A language with a type system that doesn't support some form of templates or generics? Thanks, but no thanks. And yes, I'm aware that they said they probably want to add generics at some point, but that attitude is misguided. The type system is the fundament of a programming language, and things like parametric polymorphism need to be integrated from the start, and not bolted on as an afterthought.

XDC2012: Programming languages for X application development

Posted Oct 12, 2012 15:23 UTC (Fri) by nix (subscriber, #2304) [Link]

The way they were bolted on to C++ as an afterthought, you mean? (Bjarne knew he wanted something like templates in C++ when he started work on it, but for some time thought it could be implemented via macros with no changes to the type system necessary. This turned out not to be true.)

It seemed to work quite well there -- though it is true that I can't think of another language where they were bolted on remotely as well.

XDC2012: Programming languages for X application development

Posted Oct 8, 2012 11:05 UTC (Mon) by renox (guest, #23785) [Link]

I don't think that this kind of design would use efficiently multiple CPUs..

XDC2012: Programming languages for X application development

Posted Oct 4, 2012 20:40 UTC (Thu) by louie (guest, #3285) [Link] (1 responses)

C/C++ certainly doesn't help, but focusing on the language problem (particularly by waving your hands and saying ObjC "has special features") is shuffling deck chairs on the Titanic. You can't:

1) easily deliver X apps to users (compare "set up a webserver" to "package something for anything more than a single X platform)
2) easily make money on X apps (compare web services, or worse yet mobile apps)
3) easily make X apps location/device independent (compare web services on both scores; mobile at least on location independence)
4) easily make X apps collaborative (consider the process of sharing a document in, say, Abiword/OOo v. gdocs).
5) easily take advantage of the desktop's advantages (local data search, rich inter-app integration, whatever else it is that you think desktop apps rock at- they're all hard to take advantage of, so people very rarely write apps that make you say "I could only do that on the desktop.")

Until those issues are fixed, you can use the exact same languages and technologies (literally, you can already to this - write a Java app, like the successful folks at Android, or HTML+Javascript via local webkit) but X development still won't be appealing.

What? No word about testing?

Posted Oct 5, 2012 10:15 UTC (Fri) by rwst (guest, #84121) [Link]

Probably the biggest reason for all the crappiness in Linux GUI applications is the lack of a testing paradigm with most languages used for the purpose. The notable exception is Java, but that still has no GUI testing framework in its dev kit. At the time people hear about something like FEST they have switched to another profession.

Recently I commented about a bug and got from the dev the answer "The tracker can be accessed here." but I had given him a link of a distro tracker issue before which he simply ignored. No wonder his application was crappy if he did everything to sweep bugs under the rug. As a dev, I'm willing to go miles to have a full tracker regardless of how a many issues are open, because I *know there must be hundreds of bugs, I just haven't found them.

XDC2012: Programming languages for X application development

Posted Oct 6, 2012 10:26 UTC (Sat) by Cato (guest, #7643) [Link]

How about Go? It has some GUI library bindings for GTK, Wx, etc: http://go-lang.cat-v.org/library-bindings

It seems like a nice language that has attracted both C++ and Python developers.

Unfortunately it has some problems with garbage collection for 32-bit apps, but that's less of an issue for GUIs and not an issue for 64-bit - see http://news.ycombinator.com/item?id=3814020 and http://code.google.com/p/go/issues/detail?id=909#c29 ... If 32-bit is required, probably Python is a better choice, and the GUI options are much more mature there.

XDC2012: Programming languages for X application development

Posted Oct 10, 2012 3:02 UTC (Wed) by ncm (guest, #165) [Link] (1 responses)

When I see "C/C++" referred to as if it identified a single language, it warns me that someone is about to write something foolish, or worse. That expectation was fulfilled here (albeit through no fault of Michael's.)

Where to start? If memory leaks in C programs are somehow a worse problem than reference leaks in GC languages, why are the GC programs (most commonly Java, and Javascript in browsers) predominantly the ones that trigger the OOM-killer, or just crash with out-of-memory? How is C++, which provides copious support for automated resource management (not excluding memory management) in the same category as C, which offers none?

To say, "C/C++", makes sense in exactly one context: when identifying languages that can call into a library without a wrapper layer. Then it is a statement about the library and its interface, not about the languages or their properties.

The ability of UI framework coders to make any supercomputer feel like an HP-41 is legendary. Machines are a thousand times faster than in the '80s, yet GUI programs are as slow as ever, achieving very little more useful work, and often less. The problem to be solved is not to discover some magical language to consume even more overhead. It's to deliver to coders the existing power of existing machines in a way that allows that power to be applied to benefit the user. The problem was identically the same ten years ago. The slow progress is a disgrace.

Qt and GTK displacing other frameworks is progress only in the sense of consolidation: fewer coders are obliged to use the even-worse ones. Both still define their own universe of data structures that must be translated to and from native structures and wire protocols. Both (but GTK more than Qt) fail to take advantage of advances in programming language design since 1983. These failings leak into code that uses frameworks: Mozilla code, while nominally C++, infamously shies from all of the language's facilities that post-date 1990.

Modern language facilities embodied in standard C++ enable writing libraries that are more expressive than is usually achieved in a specialized language, yet without the overhead of another abstraction layer.

There is one shining example of progress, of user interface design exposing the power of modern hardware to users: twitch games. How sad that whenever they must do what another programs does, they fall back to doing it the same way, with all progress forgotten.

XDC2012: Programming languages for X application development

Posted Oct 11, 2012 14:58 UTC (Thu) by HelloWorld (guest, #56129) [Link]

I agree, the article is wrong in so many ways that it's hard to tell where even to start.

You already mentioned C++' extensive support for automatic memory management through RAII.

Saying that C# offers no advantages over Java shows utter cluelessness. Just to name a few: properties, operator overloading, the yield statement, lambdas/delegates, LINQ, reified generics, extension methods and probably tons of others that I've missed.

He also seems to have no clue how GUI builders work nowadays. Qt designer and Glade aren't used as code generators. They generate an abstract description of the GUI (usually XML), and the event handlers are then connected automatically to the appropriate callbacks using things like GtkBuilder and QMetaObject::connectSlotsByName. And the fact that he doesn't know how to use these GUI builders right (as shown by his inability to create a flexible layout using these tools) speaks for itself.

That leads me to another point where he's utterly wrong: Objective C. He says that it provides features that C and C++ don't. While that is technically right, it doesn't really matter. There are GObject and moc, which add the same kind of introspection that makes Objective C successful (OK, GObject is actually a pain to use, which is why Vala exists) and allow technologies like the aforementioned GtkBuilder and QMetaObject::connectSlotsByName.

He also seems to be confused about control flow in web applications. Web applications use all kinds of callbacks for all kinds of things, yet he calls callbacks a "complicated flow of control" and "challenging for programmers" (I actually think that if you don't grok the idea of a callback, you shouldn't be programming at all, but the point is that web and desktop applications don't differ at all in that respect).

There are also a few very important points that are completely missing from his presentation.

Neither JavaScript nor C or C++ offer coroutines, which are a perfect fit for the kind of callback-based programming that GUI programs tend to necessitate
As pointed out by louie's comment, web apps have advantages that have nothing at all to do with programming languages
the question of why we should even care about desktop application development

So, all in all, I think that Mr Massey's presentation was a really poor one. So poor in fact that LWN would better not have written about it, as it'll surely lead some people to believe things that aren't true.

XDC2012: Programming languages for X application development

Posted Oct 11, 2012 5:08 UTC (Thu) by cyanit (guest, #86671) [Link]

Nobody cares about "X" or about "X applications", they care about creating portable software with an UI or, less likely, software with an UI that runs on Linux.