4 ms·

What's up with you people who design UI programmatically? This is 2008, jesus christ. http://code.google.com/android/devel/ui/xml.html http://code.google.com/

by cliff 18y ago

What's up with you people who design UI programmatically? This is 2008, jesus christ. http://code.google.com/android/devel/ui/xml.html http://code.google.com/android/devel/ui/xml.html http://en.wikipedia.org/wiki/Extensible_Application_Markup_Language http://en.wikipedia.org/wiki/Extensible_Application_Markup_L...

omouse 18y ago
In Lisp, code is data and data is code ;P so he's designing it in a markup language that happens to be Clojure :D
tomjen 18y ago
Almost nobody mixes lisp (or derivatives of lisp) and XML - sexpressions are the typical representation of lisp code and are isomorphic to xml.
epall 18y ago
As soon as I can find a well-tested, mature framework for this that has an awesome GUI designer, I'll switch! Until then Swing Designer is my friend.
michaelneale 18y ago
Markup only solves the shallow part of the problem anyway. Sure it can help communicate with graphic designers, but it doesn't do everything. Lots of OSX apps (the ones which most people think of as being friendly, usable and pretty) are done mostly programmatically, even with the interface builder stuff available...
corentin 18y ago
You didn't explain why it's a good thing. From what I understand, it only complicates development even more without providing any real improvement.
- etal 18y ago
  It can be a good thing the way HTML-CSS-Javascript separation can be a good thing. In the case of Clojure, it actually is possible to write the layout code in a declarative style and keep the handlers completely separate, but for most of the popular languages, it's easier to just use Qt Designer, Glade or similar to generate an XML layout and write the handlers in your language of choice. Compared to the old approach of GUI designers generating a pile of C/C++ code, which you then modify, the XML blob is actually much nicer. Also, most of the XML-presentation libraries offer multiple language bindings, so there's less of a requirement for your language to provide its own GUI toolkit, and it's easier to convert your app from one language to another (e.g. injecting Python into a legacy C app) without losing any of the details from the original interface.

by cliff 18y ago

omouse 18y ago

In Lisp, code is data and data is code ;P so he's designing it in a markup language that happens to be Clojure :D

tomjen 18y ago

Almost nobody mixes lisp (or derivatives of lisp) and XML - sexpressions are the typical representation of lisp code and are isomorphic to xml.

epall 18y ago

As soon as I can find a well-tested, mature framework for this that has an awesome GUI designer, I'll switch! Until then Swing Designer is my friend.

michaelneale 18y ago

Markup only solves the shallow part of the problem anyway. Sure it can help communicate with graphic designers, but it doesn't do everything. Lots of OSX apps (the ones which most people think of as being friendly, usable and pretty) are done mostly programmatically, even with the interface builder stuff available...

corentin 18y ago

You didn't explain why it's a good thing. From what I understand, it only complicates development even more without providing any real improvement.

etal 18y ago
It can be a good thing the way HTML-CSS-Javascript separation can be a good thing. In the case of Clojure, it actually is possible to write the layout code in a declarative style and keep the handlers completely separate, but for most of the popular languages, it's easier to just use Qt Designer, Glade or similar to generate an XML layout and write the handlers in your language of choice. Compared to the old approach of GUI designers generating a pile of C/C++ code, which you then modify, the XML blob is actually much nicer. Also, most of the XML-presentation libraries offer multiple language bindings, so there's less of a requirement for your language to provide its own GUI toolkit, and it's easier to convert your app from one language to another (e.g. injecting Python into a legacy C app) without losing any of the details from the original interface.