"eles" <eles@eles.com> wrote in message news:ksirfxsiejlweyhomwmh@forum.dlang.org...
> 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
>

There is also IUP...

http://www.tecgraf.puc-rio.br/iup/

-=mike=- 

On 2013-05-20 23:47, Andrej Mitrovic wrote:

> 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 :) ).

I hardly believe it has anything to do with being a (native) GUI library. Most D projects look like this.

-- 
/Jacob Carlborg

On Tuesday, 21 May 2013 at 09:29:36 UTC, Jacob Carlborg wrote:
> I hardly believe it has anything to do with being a (native) GUI library. Most D projects look like this.

I'd say it is about having a persistent user. If project floats around as an abstract one without any frequent practical application and demands for improvements, it can become very hard to move forward.

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.1428.1369071743.4724.digitalmars-d@puremagic.com...
> On Tuesday, May 21, 2013 03:33:01 Daniel Murphy wrote:
>> I don't know much about Qt's source, but automatic conversion to D, like
>> we
>> are doing for the compiler, might be worth looking into. If it is written
>> in modern-ish C++ (not too many preprocessor hacks), which from a quick
>> look
>> it appears to be, this might be a much more reasonable task than writing
>> a
>> new gui lib from scratch.
>
> IIRC, they use macros quite a bit for various stuff (like signals and
> slots),
> and they have their own version of make to set up some stuff for you. So,
> my
> first guess is that conversion would be a bit of a beast. But it's been a
> while
> since I did much with Qt.
>
> - Jonathan M Davis

If the macro can be easily converted to a mixin or function call, it usually isn't too bad.  It's when the code is not even close to valid c++ (COM class definitions spring to mind) that things get tricky.

eg
#define INC(x) do { (x)++; } while(0)
is fine as it can be translated to a function call, but
#define BEGIN {
is a huge problem, because it won't parse.

Even if the macros are hairy, so long as there are a relatively small number, they can be special cased.

Qt's special preprocessor is a whole other story, but hopefully that can be emulated somewhat in D code.  Requiring a template mixin per Qt class is not too big a deal.

On 5/21/13, Adam Wilson <flyboynw@gmail.com> wrote:
> Well, it comes down to how you want to render. My preferred solution woulbd be a rendering thread running all the time doing nothing but the GPU leg-work

Why a GPU? Aren't most GUIs static? And aren't there issues with GPUs where feature X isn't supported on all GPUs or is buggy on a particular one (e.g. driver issues)? Or maybe that was true in the past, I was out of the loop for a while. :)

On 5/21/13, Jacob Carlborg <doob@me.com> wrote:
> On 2013-05-20 23:47, Andrej Mitrovic wrote:
>
>> 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 :) ).
>
> I hardly believe it has anything to do with being a (native) GUI library. Most D projects look like this.

Heh, yeah, you're probably right.

On Tuesday, 21 May 2013 at 11:06:44 UTC, Andrej Mitrovic wrote:
> On 5/21/13, Adam Wilson <flyboynw@gmail.com> wrote:
>> Well, it comes down to how you want to render. My preferred solution
>> woulbd be a rendering thread running all the time doing nothing but the
>> GPU leg-work
>
> Why a GPU? Aren't most GUIs static? And aren't there issues with GPUs
> where feature X isn't supported on all GPUs or is buggy on a
> particular one (e.g. driver issues)? Or maybe that was true in the
> past, I was out of the loop for a while. :)

If you only use basic features (everything you need for GUI), you're not going to have issues. In any case if you go the GPU route it's best to isolate the GPU code behind an interface so you can add a software implementation later if absolutely necessary.

I think the best idea is to stop arguing and just do something. I recommend trying a minimalist project (at most Clutter sized) instead of something massive like Qt that's likely never going to see the light of day. Implement the basics, create a few example apps, and _then_ start a discussion. You might not get a perfect library/framework, but at least you'll get something that exists instead of an infinite flame war getting nowhere as is the tradition in the D world. Getting more than one contributor _and_ not stopping work on it is going to be the main issue, there've been a few D GUI attempts and they're mostly dead due to lost interest.

My (subjective) preferences:

* Human-readable markup, not just through a tool (a tool can be built later). YAML and JSON work well here.

* Look at Hybrid API. Clutter and Qt also have nice APIs, but D allows some things not possible there.

* Library instead of a framework - one of things I like about the Hybrid design

On 2013-05-20 22:40, Diggory wrote:
> UI toolkits are a lot of work but they're not as unreasonably big as
> everyone seems to be suggesting... I've written a couple myself in a
> procedural language using Direct3D to draw everything. Had all the
> standard controls, various layout options, even a syntax highlighted
> code editor, clipboard interaction, keyboard focus, etc.

I think you underestimate what's needed and the controls people want to have. Did you have date picker, color picker, support for internationalization, field formatters and so on.

-- 
/Jacob Carlborg

On Tuesday, 21 May 2013 at 00:04:03 UTC, Kiith-Sa wrote:
> H3r3tic had a more advanced GUI framework (still not native), hybrid, which IMO has a far better API than any framework I've seen, but I never found the source,
> only documentation somewhere on his (unmaintained) site.

https://bitbucket.org/h3r3tic/boxen/src.

That project repo is worth a try for many of Tomasz' (resp. team0xf's) projects.

David

On Tuesday, 21 May 2013 at 12:12:12 UTC, Jacob Carlborg wrote:
> On 2013-05-20 22:40, Diggory wrote:
>> UI toolkits are a lot of work but they're not as unreasonably big as
>> everyone seems to be suggesting... I've written a couple myself in a
>> procedural language using Direct3D to draw everything. Had all the
>> standard controls, various layout options, even a syntax highlighted
>> code editor, clipboard interaction, keyboard focus, etc.
>
> I think you underestimate what's needed and the controls people want to have. Did you have date picker, color picker, support for internationalization, field formatters and so on.

I had support for custom dialogs, drawing etc. and file dialogs were built in so it was possible to create your own color picker, etc. in a very few lines of code. The way it was designed, custom field formatters were trivial. The point is we don't need to have a date picker and color picker and every other control built in, at least not initially. All we need is an easily extensible framework with the simple controls, and then we can add more complicated controls as they are requested. Once the framework is in place it will be very easy for many people to contribute and everything will get done much more quickly.