I like how convenient it is but I’ve always found the object-based approach a bit awkward. An elm architecture-inspired interface would be interesting and more idiomatic, but I can’t find any library that implements it.
That’s an interesting idea. racket/gui was inspired by Smalltalk’s OO approach to GUI: traditional message passing style, encouraging you to augment and override (or overment and augride) existing classes to specialise them for your use case. Still, I’d like to see more applications of the Elm-style declarative GUIs, myself.
Do you know of other languages/frameworks using it?
It’s dated and awkward, and the class system isn’t great. (Modern Racket tends to prefer the interface system instead of classes.) But it’s still dramatically better than any alternative for building conventional GUIs I’ve ever seen.
Well, briefly, every send message you see in that list-box% manual page is override-able within a subclass, so you can just substitute a new class with whatever customisations you like (there are very few private or un-overridable behaviours). The class system is very flexible and you can do a lot with it that you can’t in many other languages.
I researched how it works after sending my response (of course) and it uses the platform widget toolkit, so there may be some platform-specific things you can’t directly change.
Well, I know that I can derive and override how my class responds to messages. The question is which messages handling should I change to change how entries are stored (and which I can leave as-is). It’s not clear (at least to me) from the code nor from documentation. Furthermore by using subclassing and not agregation/delegation with separate model it makes it hard to reuse same model for different widgets, right?
So I’m not sure that your original claim “Racket’s is the nicest GUI library I’ve ever had the pleasure of using” is correct, if you used cocoa/uikit or qt.
In that case it’s just a matter of using append, get-data, and set-data or just keeping an association of entries alongside - what use case do you have for changing exactly how entries are stored? (Why does this particular point bring into question the veracity of my opinion on the matter?)
It’s not forcing you to use inheritance; that was just an example. You can substitute any object for any other as long as it implements the right widget interfaces. Classes are first-class objects so you can pass them around between functions. It’s up to you to organise it nicely.
Racket’s is the nicest GUI library I’ve ever had the pleasure of using.
I like how convenient it is but I’ve always found the object-based approach a bit awkward. An elm architecture-inspired interface would be interesting and more idiomatic, but I can’t find any library that implements it.
Maybe it’s finally time to learn
syntax-parse…That’s an interesting idea.
racket/guiwas inspired by Smalltalk’s OO approach to GUI: traditional message passing style, encouraging you toaugmentandoverride(orovermentandaugride) existing classes to specialise them for your use case. Still, I’d like to see more applications of the Elm-style declarative GUIs, myself.Do you know of other languages/frameworks using it?
Elm was the first GUI “framework” I learned so I guess it’s had a big impact on what I’ve come to expect from these things.
As for other implementations of TEA, the only major one I know if is Elmish for F#, which is used by Fable for browser GUIs and Fabulous for mobile.
It’s dated and awkward, and the class system isn’t great. (Modern Racket tends to prefer the interface system instead of classes.) But it’s still dramatically better than any alternative for building conventional GUIs I’ve ever seen.
Is it really? It looks to me that it has many shortcomings, like e.g. it lacks tree widget (available externally) or a way to customize model of list.
You can do any customisation you want using the class system.
I’m not sure how to do that – care to explain?
Well, briefly, every
sendmessage you see in thatlist-box%manual page is override-able within a subclass, so you can just substitute a new class with whatever customisations you like (there are very few private or un-overridable behaviours). The class system is very flexible and you can do a lot with it that you can’t in many other languages.I researched how it works after sending my response (of course) and it uses the platform widget toolkit, so there may be some platform-specific things you can’t directly change.
Well, I know that I can derive and override how my class responds to messages. The question is which messages handling should I change to change how entries are stored (and which I can leave as-is). It’s not clear (at least to me) from the code nor from documentation. Furthermore by using subclassing and not agregation/delegation with separate model it makes it hard to reuse same model for different widgets, right?
So I’m not sure that your original claim “Racket’s is the nicest GUI library I’ve ever had the pleasure of using” is correct, if you used cocoa/uikit or qt.
In that case it’s just a matter of using
append,get-data, andset-dataor just keeping an association of entries alongside - what use case do you have for changing exactly how entries are stored? (Why does this particular point bring into question the veracity of my opinion on the matter?)It’s not forcing you to use inheritance; that was just an example. You can substitute any object for any other as long as it implements the right widget interfaces. Classes are first-class objects so you can pass them around between functions. It’s up to you to organise it nicely.
agreed, it’s very well designed and a joy to use
I wonder what the equivalent in tk would look like …