Hacker News Reader

Comment by coldtea | Hacker News Reader

>But I have never before seen the terms "immediate mode GUI" or "retained mode GUI". And I'm pretty sure there are many developers like me who will have no idea what you're talking about.

Well, developers who write their own GUI toolkits (what the article is about), probably know retained vs immediate mode. Those are two very basic distinctions when it comes to GUIs.

Retained mode is the average GUI toolkit you probably know (Swing, GTK, Cocoa, etc). Immediate mode is where the GUI is draw directly frame by frame by the application.

In retained mode you deal with buttons, windows, panels, checkbox objects, textboxes, etc, arranged in a tree-like structure.

In immediate mode you deal with painting commands (of course you usually will abstract them to a higher level too). You want a button? You draw a square and the label in it, and depending on the user input (e.g. clicking at the moment or not), you might draw it depressed.

View on HN

> Retained mode is the average GUI toolkit you probably know (Swing, GTK, Cocoa, etc)

Not quite. Certainly Cocoa, and probably the others as well, are mixed mode.

An NSView has a drawRect:: method that draws that particular view in "immediate mode", with drawing commands of the underlying procedural graphics API (essentially Quartz/CoreGraphics).

If you want pure immediate mode, you create a single NSView and just draw everything.

If you want pure retained mode, you exclusively use predefined widgets, which hide the "immediate mode" drawing that they do.

Or you mix and match as you see fit.

>An NSView has a drawRect:: method that draws that particular view in "immediate mode", with drawing commands of the underlying procedural graphics API (essentially Quartz/CoreGraphics).

Yes, but that's the case for almost all retained mode GUI toolkits (they provide something akin to that), and it's used as a last resort (when you need a custom look or to implement your own widget, or complicated UI for something like plotting or a piano keyboard, etc).

Regular use of the APIs in Cocoa (and what all books advice) is retained mode style, using pre-made widgets with the Interface Builder and so on. Not "drawRect".

> it's used as a last resort

Usage appears to have shifted that way. However, that wasn't the case not so long ago and the fact that a facility is no longer being used (as much) does not mean it's not there. If you need it, it's right there to use as you wish.

Just because you tend not to open the roof doesn't mean your convertible is no longer a convertible, as long as you still can open the roof.

And yes, I did mention that other toolkits probably work the same way.

>Usage appears to have shifted that way. However, that wasn't the case not so long ago and the fact that a facility is no longer being used (as much) does not mean it's not there. If you need it, it's right there to use as you wish.

I recall having discussed this with you here again.

I'd say it was the case for as long as I'm on IT (so, as long as mid-nineties or so). Heck, even back to Delphi and co.

>Just because you tend not to open the roof doesn't mean your convertible is no longer a convertible, as long as you still can open the roof.

Well, if 99% of the car has been designed for one use (A), but has the option (that few use) to do B, doesn't mean the car's a B.

So, this is more like "just because the car has a lot of storage space in the trunk, doesn't mean it's a truck".

> case for as long as I'm on IT (so, as long as mid-nineties or so)

Late 80s for me. What you saw depends very much on which part of "IT" you were in.

When doing forms automation, maybe you only ever saw the widgets. And that's OK. However, forms/widgets are not all of IT and all of UI work. So when doing graphics, DTP, CAD/CAM, document processing etc.: not so much.

>if 99% of the car has been designed for one use

But it hasn't. Not 99% and not one use. These frameworks are flexible and were explicitly designed to be flexible. drawRect:: and handling mouse events is a fundamental feature of the view, and widely used. The fact that you have convenience widget libraries that encapsulate its use (they ALL use it), doesn't mean it's not there.

Just because you use your truck like a car doesn't mean it's not still a truck.

>So when doing graphics, DTP, CAD/CAM, document processing etc.: not so much.

Yeah, haven't done graphics, DTP, CAD/CAM, etc, and I guess immediate mode or mixed mode is more prevalent there.

But I'd say the vast majority of GUIs (whether enterprise or desktop/business apps etc) are forms and regular widgets based. If they need some custom part (e.g. a plot or a custom drawn control) they implement it by drawing it, but still use it in retained mode, in the classic widget tree, embedded in some window, layout widget, etc.

Immediate mode is almost non-existent in enterprise GUI work for example -- except niches like CAD apps for factories or some special case (a custom widget drawn but embedded in an otherwise retained mode UI).

>These frameworks are flexible and were explicitly designed to be flexible.

Yes, they have escape hatches to draw your own widgets when needed.

But their main idea wasn't "immediate mode", but "we provide these ready-made widgets", and they're judged by how many and good those are, not by the ability to drop in drawRect or such.

In the same way, that OpenGL and DirectX is 99% immediate mode, regular GUI toolkits is 99% retained mode (on the API level programmers are meant to use, and mainly use).

Almost any book on GUI programming on Cocoa, GTK, QT, etc I've read, primarily focuses on the available widgets and retained mode use, and any "drawRect" equivalent is an aside about what you can achieve if needed.

> But I'd say the vast majority of GUIs

(a) not convinced that's true

(b) not relevant

> But their main idea wasn't "immediate mode",

No, as I've written, their main idea was to provide mixed mode. On top of which you can provide a widget set. Something like GKS or Phigs was true retained mode graphics, and toolkits like AppKit were reactions to the limitations of those types of mechanisms.

There is a reason the Mac had QuickDraw and NeXT had DPS and not GKS or Phigs. Well, many reasons, but one was that the limitations of pure retained mode graphics systems were well known.

> they have escape hatches to draw your own widgets when needed.

Yes and no. While you can view them as escape hatches if you're primarily doing widget-only programming, they aren't really escape hatches as the entire system is based on / built on them. Just like in Objective-C, objc_msgSend() is not the escape hatch, it is both the basis for all messaging and it enables the escape hatch, which is -forwardInvocation:. Similarly -drawRect:: and responder handling: they are the basis on which everything else is built. Since they are exposed, that means you can build your own views/widgets as peers to the ones provided.

> Almost any book on GUI programming on Cocoa ...primarily focuses on the available widgets

The books I learned AppKit with focused on creating a custom view, drawing with DPS and pswrap, handling mouse events and the responder chain.

What's more - things like drawRect, QPainter etc. are hardly comparable to what a real immediate mode GUI toolkit offers - you'd need to basically reimplement something like Dear ImGUI on top of Cocoa or Qt in order to get something similar.

Reply on news.ycombinator.com