On Mon, 20 May 2013 14:14:30 -0700
"Adam Wilson" <flyboynw@gmail.com> wrote:
> Some days I wish I had the charisma and vision to develop that team, because I badly want a D UI toolkit that can do with WPF can. I may or may not have the right vision, but I am no charismatic. ;-)
> 

What would you say would be a good introduction to WPF?

On Mon, 20 May 2013 22:40:06 +0200
"Diggory" <diggsey@googlemail.com> wrote:
> 
> The main difficulties with doing the same thing in opengl and making it cross platform seem to be:
[...]
> 
> On the other hand you get the advantages of hardware acceleration and pretty much unlimited custom drawing capabilities and I'd expect to see a lot of interesting custom controls out there. I'd definitely favour this option!
> 

These days, native UIs are already hardware accelerated. Aero is, Quartz is, etc. There was a huge push towards this ten-plus years ago.

On 5/20/13, Adam Wilson <flyboynw@gmail.com> wrote:
> * There is a deep-seated distrust of any toolkit that does not use the OS Native UI widgets.

That's a shame. If you go native you'll have the "look and feel", but you'll have X times the work where X is the number of platforms supported. Also, each platform has its own bugs, so you'd have to write a lot of workaround code as well (e.g. wxWidgets is full of win32 workarounds).

Doing it non-native slows you down at first, but it gives you a lot more control on how you can render things. You can add a feature without having to worry on how to port the feature to other platforms. And finally, you can simulate the native windowing environment.

Just to mention this, we already have native libraries (and written in D without wrapping C++ libs) such as DGUI, DFL, DWT. I hardly find them successful, they get the occasional pull request, but otherwise they seem to lack any sort of team effort or going-forward schedule. So I'd say going "native" has already been a failed experiment (take that with a huge grain of salt, it's just my personal viewpoint :) ).

> * Nobody believes that we can do it, you'll hear a lot of moaning about how much work it is. My reply to that is: And Linux is such a piece of cake right? It's only the most widely used kernel on the planet.

I think the lesson with Linux is that one person initially did a lot of heavy lifting, and then others joined in. I doubt it would work as it did if instead Linus opened a thread asking for a team of developers to create a new OS from scratch.

Anyway, there's no doubt a D GUI would be a huge undertaking. There would almost certainly be a lot of rewriting involved. It's very easy to make mistakes early on and hardcode something, only later to realize it's way too brittle so it requires a rewrite. If the system is modular enough then the rewrites become less painful. And if the system is properly unit tested then regressions become less likely, and this is important.

>From what I've seen when a codebase becomes large enough, what
inevitably happens is people stop hacking on the codebase almost entirely. It's usually because the codebase is huge and not modular, or undocumented, or not tested, or doesn't have any sort of schedule on the work that needs to be done.

I have zero doubt that we have the know-how or hacking ability to actually work and solve GUI problems in D, but I have big doubts that we would ever have leadership that would make sure we have a proper schedule and todo list, proper discussions, the guts to say "no" to features, etc. It's just not going to work if people randomly create pull requests with some code they thought would be nice to include in a GUI library.

So to actually do it, I think we need:

1) A "core" for a GUI library written in D that people can start hacking on (meaning you can create windows, and draw in a pixel buffer, capture device input, all platform-independent), and

2) Solid leadership.

I'd say #2 is more important than #1, because #1 is something many people can do, and #2 is the really hard bit.

On Monday, 20 May 2013 at 21:47:56 UTC, Andrej Mitrovic wrote:
> 1) A "core" for a GUI library written in D that people can start
> hacking on (meaning you can create windows, and draw in a pixel
> buffer, capture device input, all platform-independent), and

Hell, I've even done this.
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/simpledisplay.d

nothing fancy but it works.

> 2) Solid leadership.

but yeah this isn't me.

On Mon, 20 May 2013 14:44:04 -0700, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Mon, 20 May 2013 22:40:06 +0200
> "Diggory" <diggsey@googlemail.com> wrote:
>>
>> The main difficulties with doing the same thing in opengl and
>> making it cross platform seem to be:
> [...]
>>
>> On the other hand you get the advantages of hardware acceleration
>> and pretty much unlimited custom drawing capabilities and I'd
>> expect to see a lot of interesting custom controls out there. I'd
>> definitely favour this option!
>>
>
> These days, native UIs are already hardware accelerated. Aero is,
> Quartz is, etc. There was a huge push towards this ten-plus years ago.
>

Erm, when it comes to Aero, that depends. Aero Glass, the window chrome is rendered in Hardware. But the styling of each UI widget, buttons for example, is still done by GDI in software.

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

Oh btw I think a generic event loop is important too, for gui and non gui stuff.

I slapped something together to get started with that too:
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/eventloop.d

and even (optionally) use it in my (cross platform btw) terminal.d:
https://github.com/robik/ConsoleD/blob/master/terminal.d


But since it isn't something I personally use a lot it just gets updated when something comes up, more often than not from other people using it.

On Mon, 20 May 2013 14:38:51 -0700, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Mon, 20 May 2013 14:14:30 -0700
> "Adam Wilson" <flyboynw@gmail.com> wrote:
>> Some days I wish I had the charisma and vision to develop that team,
>> because I badly want a D UI toolkit that can do with WPF can. I may
>> or may not have the right vision, but I am no charismatic. ;-)
>>
>
> What would you say would be a good introduction to WPF?
>

If you want a high level overview of WPF the wikipedia article is a good place to start: http://en.wikipedia.org/wiki/Windows_Presentation_Foundation

If you want a more technical approach to working with WPF the Microsoft docs are king: http://msdn.microsoft.com/en-us/library/ms754130.aspx

Of particular interest should be it's rendering model and Dependency Properties.

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

On Mon, 20 May 2013 14:36:11 -0700, Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:

> On Tue, 21 May 2013 00:32:09 +0400
> Dmitry Olshansky <dmitry.olsh@gmail.com> wrote:
>
>> 20-May-2013 23:41, Adam Wilson пишет:
>> >
>> > Absolutely, but my point is that some of those are entire fields of
>> > study and bodies of knowledge that can take years or decades a too
>> > acquire.
>>
>> I believe this is a fallacy as given the current pace of progress
>> people can then no longer hope to become experts anymore ;)
>> (Or at least in anything even remotely actual). A year or 2 is more
>> then enough to get to the state of the art, and amount of experience
>> is not proportional to inventing something new (and advancing the
>> field).
>>
>
> With only a brief, cursory understanding of the current
> state-of-the-art, any attempts to "advance the field" automatically
> carry a high risk of *regression* under the false guise of advancement.
>
> And I strongly believe that's already been happening *a lot* over the
> past decade. Wheels are being reinvented, only this time most of them
> are squares.
>
>

Well arguably that regression in markup based UI was WPF. They made a lot of mistakes that to this day murder performance and the markup is pretty bulky. But they've gone backed and fixed a lot of the perf and markup issues with WinRT, and I am seeing some better markups in newer toolkits that look like they learned from WPF. But arguably HTML/CSS was the first, and IMHO they made WAY to many mistakes there and only now just starting to catch up to where WPF was in 2005.

>> Another thing to understand is that for example it took years to
>> develop classical analysis in math but nowadays it's just a couple of
>> semesters. Stealing a good vision from other expert(s) is a good
>> interim short-cut.
>>
>
> Well, there *is* that, too.
>


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

On 5/21/13, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> On 5/20/13, Adam D. Ruppe <destructionator@gmail.com> wrote:
>> Hell, I've even done this. https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/simpledisplay.d

It's also interesting how people implement GUI libraries in very different ways. Especially in D where you have CTFE/templates/mixins, you could literally do it any number of ways. Just discussion the initial approach would probably span a thousand replies, where everyone has their own unique idea and where they disagree with each other.

On Monday, 20 May 2013 at 22:04:06 UTC, Andrej Mitrovic wrote:
> everyone has their own unique idea and where they disagree with each other.

I don't even agree with myself! If I was restarting that simpledisplay from scratch right now, I'd probably do it differently. The method I used there was like an interface and then a bunch of mixins, the idea being that the OS implementations could then be easily moved to a different file and the interior interface and the exterior interface are decoupled... but adding features to it the way I did it here feels like it could be easier.

But this is partially why I just slap together these files myself and toss them out there: I think too many discussions have too much talk and not enough code. Even if it is crappy, something that works (yet is also disposable if it ends up being really awful) is better than nothing.