On Friday, 6 March 2015 at 16:59:19 UTC, Chris wrote:
> I've just downloaded and compiled it. I will play around with it later, when I have time. Any tips?

About web UI: http://www.fossil-scm.org/index.html/doc/trunk/www/webui.wiki

On Friday, 6 March 2015 at 12:29:46 UTC, Chris wrote:
> HTML5 ... HTML5 ... JS ... JS.. and so on
>
> To cut a long story short, ideals and pragmatism are at loggerheads here, but at the end of the day, you have to get your apps out there for as many people and as many platforms as possible, with the least effort possible. So HTML5 and related technologies win in this respect. And users don't care what's under the hood. They simply ask "Can I download an app?". If they can't, they are very annoyed. D should find a way to interact with the "app world".

Microsoft already tried this by aggressively promoting WinJS/HTML5, hoping that they will attract the large crowd of HTML5/JS developers. It seems that nobody in Windows world likes it. Only 12% of apps from Store are developped in HTML5/JS. 8% in C++/XAML. 80% in C#/XAML.

Even Facebook and Google developed their own applications in C#/XAML. Curiously, it seems that only Microsoft is developing apps in WinJS/HTML5: http://www.zdnet.com/article/windows-8-developers-are-shunning-winjs/

In the same time, I think they learnt the lesson and they reactivated .net platform by open sourcing it and making it available also on Linux & Mac. And finally, the last .net blame is fading away: C# compiles directly to native code.

Anyway, it's clear for me that the age of native controls is history. Today interfaces are described in markup languages, the OS is responsible to render it, there is a clear separation between the user interface and the code behind.

On Friday, 6 March 2015 at 06:30:45 UTC, Rikki Cattermole wrote:
> I'll summarize my views on all of this.
> We keep making the same damn mistakes time after time. Especially with GUI's.
> Stop trying to make GUI toolkits! Seriously just stop.
> WE DO NOT HAVE THE INFRASTRUCTURE FOR IT. Yes I know that is yelling but it is true. We're still a long way off having proper image manipulation. Or even basic OpenGL wrapping functions. DirectX don't even joke.

Agree to some extent. But we can make small steps. At least if we figure out right architecture.

> TLDR: We think far too big and never actually work with a clear strategic path towards a goal in mind.

Can you write briefly somewhere an analysis for gui development? Or possibly use add ideas/comments here:

https://github.com/D-Programming-Language-Labs/Proposals/blob/master/proposals/1_std_gui.md

I don't have too much time for gui as I'm currently in the process of including Phobos proposal modules into drafting library.

Piotrek

On Fri, 2015-03-06 at 11:30 +0000, via Digitalmars-d wrote: […]
> 
> Not sure what you mean by a "non-browser UI". You need a model, a layout engine, a composition engine and know-how. Competing with browser engines is a lot of work.

I meant a user interface not using a browser as the infrastructure. Cocoa, Qt, GTK, JavaFX, etc. are all there already, and have everything browsers are still trying to get. I agree the pressure of fashion and orthodoxy is moving to HTML and JavaScript as the one true UI framework, but it's only real positive is that it is (supposed to be) pre-installed and the same on every machine. Sadly though, from what I can see, vast amounts of code and time is spent dealing with the differences between browsers.

> It is going to be very hard to compete with reusable UI components implemented in html+javascript, when they have worked out the quirks, due to:
> 
> 1. ease of development
> 2. ease of modification
> 3. volume of UI components
> 4. styling know-how
> 5. integration
> 6. installed base

HTML and Javascript may have an edge on ease of deployment, but regarding the other dimensions, I fear you must have imbibed of the Kool-Aid. I agree that most people creating UIs do so with browsers, HTML and JS, but that doesn't mean they are doing it right or not blindly recreating from scratch a whole mass of things that were already known. We would be a lot further forward today on UI and UX if people in the Web arena had researched more and taken NIH attitudes less. Clearly new technology and new application require new things, but simply ignoring already known stuff is just wrong.

> What you need is a reactive layer that access native data. And webtech provides the basic building blocks for it, thanks to the requirements of asm.js/pnacl.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Friday, 6 March 2015 at 21:22:31 UTC, rumbu wrote:
> Anyway, it's clear for me that the age of native controls is history. Today interfaces are described in markup languages, the OS is responsible to render it, there is a clear separation between the user interface and the code behind.

Markup is just a frontend, it can work with anything. In fact, history only returned to where it started: UI was described in DSL since early versions of Windows (resources), you couldn't waste RAM on UI-building code, instead OS was instructed to read dialog resource and build the window for you, the resource was discarded right away, every byte was counted.

On Friday, 6 March 2015 at 16:17:05 UTC, Chris wrote:
> True. Users are more willing to use different UIs these days

Probably they just got used to web being crap and take it easy, and glad it's not as bad as it can be.

On Saturday, 7 March 2015 at 10:04:21 UTC, Kagamin wrote:
> On Friday, 6 March 2015 at 21:22:31 UTC, rumbu wrote:
>> Anyway, it's clear for me that the age of native controls is history. Today interfaces are described in markup languages, the OS is responsible to render it, there is a clear separation between the user interface and the code behind.
>
> Markup is just a frontend, it can work with anything. In fact, history only returned to where it started: UI was described in DSL since early versions of Windows (resources), you couldn't waste RAM on UI-building code, instead OS was instructed to read dialog resource and build the window for you, the resource was discarded right away, every byte was counted.

Oh so it was for RAM reasons.
I've always wondered why it was that way for MFC. Since then I much prefer UI-building code.

On Saturday, 7 March 2015 at 11:16:44 UTC, ponce wrote:
> On Saturday, 7 March 2015 at 10:04:21 UTC, Kagamin wrote:
>> On Friday, 6 March 2015 at 21:22:31 UTC, rumbu wrote:
>>> Anyway, it's clear for me that the age of native controls is history. Today interfaces are described in markup languages, the OS is responsible to render it, there is a clear separation between the user interface and the code behind.
>>
>> Markup is just a frontend, it can work with anything. In fact, history only returned to where it started: UI was described in DSL since early versions of Windows (resources), you couldn't waste RAM on UI-building code, instead OS was instructed to read dialog resource and build the window for you, the resource was discarded right away, every byte was counted.
>
> Oh so it was for RAM reasons.
> I've always wondered why it was that way for MFC. Since then I much prefer UI-building code.

MFC has an interesting background.

I always favoured OWL and VCL, which had a more C++ friendly programming model than what MFC does.

Apparently Microsoft did a poor job making a similar framework and from AFX ashes, MFC was born. Hence the Afx prefix.

http://computer-programming-forum.com/82-mfc/d13ea80282846f9f.htm

So we had to wait until Windows 8, to have finally something similar to VCL, via XAML/C++.

--
Paulo

On Saturday, 7 March 2015 at 07:33:03 UTC, Russel Winder wrote:
> On Fri, 2015-03-06 at 11:30 +0000, via Digitalmars-d wrote:
> […]
>> 
>> Not sure what you mean by a "non-browser UI". You need a model, a layout engine, a composition engine and know-how. Competing with browser engines is a lot of work.
>
> I meant a user interface not using a browser as the infrastructure.
> Cocoa, Qt, GTK, JavaFX, etc. are all there already, and have everything
> browsers are still trying to get. I agree the pressure of fashion and
> orthodoxy is moving to HTML and JavaScript as the one true UI framework,
> but it's only real positive is that it is (supposed to be) pre-installed
> and the same on every machine. Sadly though, from what I can see, vast
> amounts of code and time is spent dealing with the differences between
> browsers.
>
>> It is going to be very hard to compete with reusable UI components implemented in html+javascript, when they have worked out the quirks, due to:
>> 
>> 1. ease of development
>> 2. ease of modification
>> 3. volume of UI components
>> 4. styling know-how
>> 5. integration
>> 6. installed base
>
> HTML and Javascript may have an edge on ease of deployment, but
> regarding the other dimensions, I fear you must have imbibed of the
> Kool-Aid. I agree that most people creating UIs do so with browsers,
> HTML and JS, but that doesn't mean they are doing it right or not
> blindly recreating from scratch a whole mass of things that were already
> known. We would be a lot further forward today on UI and UX if people in
> the Web arena had researched more and taken NIH attitudes less. Clearly
> new technology and new application require new things, but simply
> ignoring already known stuff is just wrong.

I'm the first who would welcome a better approach to UIs. However, in the real world you cannot wait until the industry finally "gets it". You cannot tell users "Yeah, no, we won't make an app, because we are not happy with existing frameworks, you know".

I hate JS for various reasons, one reason is that HTML5/JS makes you reinvent the wheel again and again. However, while reinventing the wheel, it helps you to understand that existing frameworks are not the be all end all either.

>> What you need is a reactive layer that access native data. And webtech provides the basic building blocks for it, thanks to the requirements of asm.js/pnacl.

On Saturday, 7 March 2015 at 07:33:03 UTC, Russel Winder wrote:
> I meant a user interface not using a browser as the infrastructure.
> Cocoa, Qt, GTK, JavaFX, etc. are all there already, and have everything
> browsers are still trying to get.

All I can say that you can cut down on development time, get better portability, greater reuse and greater flexibility by using HTML5. The only downside has been performance and toolkits, but that is changing over time. Shadow DOM is an essential component to that, by encapsulating GUI elements, and reactive frameworks allows you to tie them together with effortless two-way binding.

> but it's only real positive is that it is (supposed to be) pre-installed
> and the same on every machine. Sadly though, from what I can see, vast
> amounts of code and time is spent dealing with the differences between browsers.

That's in the past. The time spent referencing caniuse.com (about once every 15 minutes for me) allows you to use new features without having to reimplement for another browser. I spend less than 1% on cross browser issues now that I am on IE10+. Before that, 10-20%.

But that is not relevant here, since we are talking about building Chromium into the app, as in statically.

> HTML and Javascript may have an edge on ease of deployment, but
> regarding the other dimensions, I fear you must have imbibed of the Kool-Aid.

No Kool-Aid, just a fair knowledge about usability, GUIs and the cost of doing native development as well as what browser engines now provide. Going native costs you twice as much in GUI work than a design that fits HTML5.

HTML is by far the most stable and portable platform over time... Because it is backed by an adopted standard. Without a standard, it would be worth nothing. Low risk implies adoption.

Flexibility is also important for creating good UIs. Complex applications never reuse much from existing GUIs, they create their own for all the critical tasks. That applies to just about all applications where screen estate and workflow matters: audio-visual applications, CAD etc.

> Clearly
> new technology and new application require new things, but simply
> ignoring already known stuff is just wrong.

I am not ignoring anything. I am pragmatic, and I also know the UI theory and what the portable UI frameworks has offered since the 1980s.

HTML5 is an adopted agreed upon standard with backwards compatible enhancements that works cross platform. Everything else is not. Therefore HTML5 will grow more over time. Just like C++ will grow more than D...