On Tue, 21 May 2013 00:24:30 -0700, Jacob Carlborg <doob@me.com> wrote:

> On 2013-05-21 05:32, Tyler Jameson Little wrote:
>
>> As for my opinionated ideals (doesn't affect the overall design much):
>>
>> * no XML (yaml maybe, but XML just isn't user-friendly)
>
> Do people actual "code" in the markup. Isn't that just for a GUI building tool.
>

I wouldn't call markup coding. It's designing, and ideally it's WYSIWYG, but properly done it's completely separate from code. A markup UI language should exist completely on top of the langauge. The best case scenario is where the markup language can be translated down to any other language supported by the UI framework by a compiler switch.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Tue, 21 May 2013 00:16:15 -0700, Jacob Carlborg <doob@me.com> wrote:

> On 2013-05-20 22:58, Adam Wilson wrote:
>
>> Depends on the system, in WPF the XAML is encoded into a binary form of
>> XML and then the objects are deserialized at runtime. Note that given
>> D's CTFE I would NOT choose this path for any D UI toolkit. D is perfect
>> for a system where you use markup to declare your UI in a CTFE manner
>> and then have the compiler do the dirty work of actually generating the
>> code. Fast AND Simple, Go D!
>
> Surely we want to have both. I'm thinking when you're developing you don't want to recompile you're application if you can avoid it just when the GUI is changed.
>

Well, that depends, if it comes down to a trade off between program execution speed vs. compile speed, i'll pick program execution speed. Right now, I know of no UI toolkit that lets you redesign without recompiling, so i'd say that should be a secondary priority.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Tue, 21 May 2013 00:01:36 -0700, Jacob Carlborg <doob@me.com> wrote:

> On 2013-05-20 21:41, Adam Wilson wrote:
>
>> HTML is markup. XAML is markup. QML is markup. XUL is markup. iOS is
>> markup. Android is markup. Realistically, the age of OS native toolkits
>> has passed, markup is the future. *shrug* For me it's a practical thing,
>> markup is extensible, OS widgets are not.
>
> What is exactly do you mean with "markup"? On iOS the native toolkit is used. But you create the interface graphically using Xcode, it then will serialize it to XML and/or binary. Is that XML what you refer to as "markup"?
>

Yes, I know it's a bit of stretch but it's the same basic idea as XAML, graphically created XML that is serialized to XML or binary. :-)

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On 2013-05-21 19:50, Adam Wilson wrote:

> Well, that depends, if it comes down to a trade off between program
> execution speed vs. compile speed, i'll pick program execution speed.
> Right now, I know of no UI toolkit that lets you redesign without
> recompiling, so i'd say that should be a secondary priority.

As far as I know on Mac OS X it works like this. It just reads the nib file at runtime.

-- 
/Jacob Carlborg

On 2013-05-21 19:51, Adam Wilson wrote:

> Yes, I know it's a bit of stretch but it's the same basic idea as XAML,
> graphically created XML that is serialized to XML or binary. :-)

Then markup has nothing to do with a GUI toolkit being native or not.

-- 
/Jacob Carlborg

On 2013-05-20 20:01, Adam Wilson wrote:

> So I've been around D a while pushing for native D UI toolkit. And here
> are a few trends I've seen in the community.

BTW, how do you intend the controls to behave:

* Emulate the behavior of each platform
* Picking one platform and emulate that across all platforms
* Doing something completely custom

?

-- 
/Jacob Carlborg

On Tue, 21 May 2013 10:50:40 -0700
"Adam Wilson" <flyboynw@gmail.com> wrote:

> On Tue, 21 May 2013 00:16:15 -0700, Jacob Carlborg <doob@me.com> wrote:
> >
> > Surely we want to have both. I'm thinking when you're developing you don't want to recompile you're application if you can avoid it just when the GUI is changed.
> >
> 
> Well, that depends, if it comes down to a trade off between program execution speed vs. compile speed, i'll pick program execution speed. Right now, I know of no UI toolkit that lets you redesign without recompiling, so i'd say that should be a secondary priority.
> 

Not that I'm pushing for it, but that doesn't strike me as something that would likely be a real bottleneck in a GUI application. Just my gut impression, though.

On Tue, 21 May 2013 11:38:31 -0700, Jacob Carlborg <doob@me.com> wrote:

> On 2013-05-21 19:51, Adam Wilson wrote:
>
>> Yes, I know it's a bit of stretch but it's the same basic idea as XAML,
>> graphically created XML that is serialized to XML or binary. :-)
>
> Then markup has nothing to do with a GUI toolkit being native or not.
>

Indeed, it does not, and I hope I didn't try to sound like I was saying it did. Markup is just one way to express the UI. DSL's are another. Personally I prefer the DSL approach, as it is usually more compact.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/

On Tue, 21 May 2013 13:33:18 +0200
"Kiith-Sa" <kiithsacmp@gmail.com> wrote:
> 
> My (subjective) preferences:
> 
> * Human-readable markup, not just through a tool (a tool can be built later). YAML and JSON work well here.
> 

*cough* SDL <https://github.com/Abscissa/SDLang-D> *wink, wink, nudge, nudge* ;)

> * Look at Hybrid API. Clutter and Qt also have nice APIs,

I will! I've never heard of Clutter before. Or some of the other ones that have been mentioned in this thread (Fox, IUP).

On Tue, 21 May 2013 11:40:15 -0700, Jacob Carlborg <doob@me.com> wrote:

> On 2013-05-20 20:01, Adam Wilson wrote:
>
>> So I've been around D a while pushing for native D UI toolkit. And here
>> are a few trends I've seen in the community.
>
> BTW, how do you intend the controls to behave:
>
> * Emulate the behavior of each platform
> * Picking one platform and emulate that across all platforms
> * Doing something completely custom
>
> ?
>

Controls will be completely "lookless". So a control is simply a class in code with no associated styling whatsoever. That means that "look" is defined entirely with styles. This presents us with the flexibility to automatically load the correct look and behavior for a platform by default, and then let the user override it with his own styles should he choose to do so.

In this plan styles, as with CSS, include much of the styling behavior too.

-- 
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/