On 2013-05-20 07:25, Tyler Jameson Little wrote:
> I've been looking into trying to fix QtD, but it seems writing a binding
> to a C++ library is a bit complicated. I've read on the forums that a
> native D GUI toolkit is the most desirable long-term, so I'd like to
> start that discussion.

Here we go again, yet another massive thread about GUI toolkits :)

-- 
/Jacob Carlborg

On 2013-05-20 21:52, Nick Sabalausky wrote:

> WPF/XAML is first-party, therefore it's native by definition
> regardless of whether or not it internally hands off to the older UI
> code. Saying WPF isn't native is like saying that Quartz isn't native
> just because it doesn't use...uhh, whatever the UI was called in Mac OS
> 9.
>
> Besides, having access to all of MS's internal code, documents,
> probably even some of the original developers still around, etc., is
> naturally going to change the feasibility in a way that no third party
> toolkit (which is exactly what we're talking about here) is
> realistically going to be able to match.
>
> In other words, despite your antagonism, I was implicitly **agreeing**
> with your assertion that it's one a hell of an undertaking,
> *especially* if you don't make use of native APIs under-the-hood.
>

I completely agree.

-- 
/Jacob Carlborg

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"?

-- 
/Jacob Carlborg

On 2013-05-20 22:36, Timothee Cour wrote:
> The following will take much less time and can achieve good, native
> results quickly:
>
> Design a user-code facing clean api using idiomatic D (front end code):
> windows, widgets, callbacks via delegates, etc.
> Design a glue layer to talk to different backends: gtkd, wxd, qtd, fltk etc.
>
> This is what python does with matplotlib:
> http://matplotlib.org/faq/usage_faq.html : they support pygtk, wxpython,
> tkinter, qt, macosx, or fltk, and also non interactive backends)
> The user code stays clean, the results are native (depending on
> backend), and the wheel is not reimplemented.

That is a huge a mount of work as well. Yes I know, I'm working on DWT. Seems a bit unnecessary to support non-native backends? I mean, you will get a couple of extra backends. It's more then enough work with the native ones.

-- 
/Jacob Carlborg

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

> A UI toolkit in D would be a fantastic showcase for demonstrating just
> how powerful D is. But make no mistake, it will not be easy getting it
> done.

I agree. It's a massive amount of work. Before we can even think if starting a project like this there are a lot of things needed to be implemented and fixed. I don't keep list of these things but, I'm thinking: runtime reflection, ABI compatible with Objective-C (this is really needed before doing any work on Mac OS X), other similar things that can be implemented regardless if the GUI toolkit gets implemented.

-- 
/Jacob Carlborg

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.

-- 
/Jacob Carlborg

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.

-- 
/Jacob Carlborg

On Tuesday, 21 May 2013 at 06:41:24 UTC, Jacob Carlborg wrote:
> On 2013-05-20 07:25, Tyler Jameson Little wrote:
> Here we go again, yet another massive thread about GUI toolkits :)

Anyway, the thread is already started, I think the alternatives are:

1) pick up a major well-known GUI library, fork it and spend some important time to re-write in D. Choices: Qt, GTK, wxWindows etc.

2) pick up a lighter GUI library, while still cross-platform, and re-write it in D. Spent time is less. Choices: FLTK, FOX Toolkit

3) start from scratch and write something new, while still having to decide if will wrap OS widgets or no.

Just to be sure that you know about FOX Toolkit:

http://fox-toolkit.org/goals.html

On Monday, 20 May 2013 at 22:48:01 UTC, Adam Wilson wrote:
> On Mon, 20 May 2013 15:35:57 -0700, Flamaros <flamaros.xavier@gmail.com> wrote:
>
>> 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
>>>
>>
>> Dereclit and SDL already does that. Rewrite SDL isn't needed, for my work it's already something I do and can tell you that it's really hard to support many platforms as Android, iOS, Windows, MacOS, consoles,... It's too long to learn all specifications and issues.
>
> Well I talked to Mike Parker (Derelict maintainer) at DConf and even he seemed to think that Derelict wasn't up to the task. The general consensus was that Derelict is primarily targeted at games. Which poses a number of issues in terms of UI toolkits, most of the relating to font rendering.
>
> Specifically:
> Font rendering is allowed to be vastly different across platforms.
> Much of what we would require in UI's of the font rendering engine is not available at all, wrapping, line spacing, layout, etc.
> Sub-pixel font hinting. Almost no games use this, and almost every OS toolkit does.
> There was more that I am forgetting...
>
> Derelict may be useful as a binding to OpenGL, but that's about where it ends, there is still MUCH work to be done on top of it.

QML do sub pixel with a shader, but us think to start with a pixel perfect alignment. In games we works on, we don't have issues specifics to OS with fonts. Default font can't be the same but FreeType support many types of font files. As our games are mainly on smartphone we use kerning to save spacing, and space character to automatic wrapping. An advanced wrapping can only be done with dictionaries.

My vision is actually to start something to see if it's a valid choice. After other questions will find answers with the communauty.

On Tuesday, 21 May 2013 at 06:39:39 UTC, Peter Williams wrote:
> On 21/05/13 16:21, Brad Roberts wrote:
>> On 5/20/13 9:49 PM, Peter Williams wrote:
>>>
>>> Yes, if D aspires to be a systems programming language it can't keep
>>> relying on wrappers around C/C++ libraries (especially C++).  In the
>>> long term, it should be D all the way down to the OS API.
>>
>> You wrote this as if not using c and c++ libraries is a predicate for
>> being a systems language.  It's not.
>
> It is for me. I also won't count D as a systems language until DMD is implemented in D.
>
>>
>> What's with the D community's (yes, I'm over generalizing some)
>> not-invented-here syndrome?  Avoiding the incredible body of existing
>> code out there that's accumulated over the decades is foolhardy and
>> narrow sighted.
>
> I did say "in the long term".
>
>> Are all c and c++ libraries great bodies of code,
>> absolutely not.
>
> I am not a fan of C++ (and don't really trust C++ libraries).  I went to C++ from Modula-2 due to job constraints but eventually ditched it and moved on to C - yes, I went from C++ to C.  The main reasons were that I felt C++ caused more problems than it cured.  Plain C is a perfectly good language for OOP as GTK+ demonstrates and there's no need for all the complexity that comes with C++.
>

I went from Turbo Pascal to C++, with a very short stop on C.

Security exploits by design? No thanks. C++ might still have the C security quicksand underneath, but at the same time it offers more secure constructs.

Of course the best way would be to drop C and C++ altogether, but it will take a few decades I would say.

--
Paulo