These aren't written in D, but they are *for* D (or any other non-C++ language in need of its own canonical, language-native GUI). They export a C API for maximum ease of use.

OpenWL[1] - cross-platform top-level windowing library, with native menus, events, clipboard/DnD.

OpenDL[2] - cross-platform drawing library (with Quartz2D/CoreText-compatible API), built on the native APIs for each platform: Quartz2D/CoreText for Mac, Direct2D/DirectWrite for Windows, and GTK/Pango for Linux.

There is still plenty of work to be done on these, but they're ready to make public and start getting some feedback / bug reports / etc.

Right now only Windows/Mac/Linux are (equally!) tested/supported, and I'll have to focus on those for the time being to really polish these libraries, but I fully intend to port them to more niche platforms in the future.

Why? I know there are some people who want to start GUI projects with their language of choice (D/Nim/Haskell/Rust/etc), but trying to lay the foundation to abstract away platform differences is a big, annoying detour for people who just want to get started. So I did all that annoying work because I'm a weird dude and find this kind of thing enjoyable ... to an extent :)

You can ask any questions here, or on the Gitter[3] I've created for both projects:

[1] https://github.com/dewf/openwl
[2] https://github.com/dewf/opendl
[3] https://gitter.im/GUImakers/OpenWL-DL?utm_source=share-link&utm_medium=link&utm_campaign=share-link

On Friday, 12 April 2019 at 06:45:01 UTC, DanielG wrote:
> These aren't written in D, but they are *for* D (or any other non-C++ language in need of its own canonical, language-native GUI). They export a C API for maximum ease of use.
>
> OpenWL[1] - cross-platform top-level windowing library, with native menus, events, clipboard/DnD.
>
> OpenDL[2] - cross-platform drawing library (with Quartz2D/CoreText-compatible API), built on the native APIs for each platform: Quartz2D/CoreText for Mac, Direct2D/DirectWrite for Windows, and GTK/Pango for Linux.
>
> 

Nice!

On Friday, 12 April 2019 at 06:45:01 UTC, DanielG wrote:
> OpenWL[1] - cross-platform top-level windowing library, with native menus, events, clipboard/DnD.

I'm currently using glfw for that, how does OpenWL compare?

On Friday, 12 April 2019 at 08:03:01 UTC, Dennis wrote:
> I'm currently using glfw for that, how does OpenWL compare?

Good question. I've not spent much time with OpenGL-y things, but from what little I know:

- OpenWL doesn't use or provide OpenGL contexts. I'm sure it will be added eventually, but at this time it's meant to provide a canvas for platform-native drawing - such as Quartz2D (still CPU-rendered AFAIK), Direct2D (GPU accelerated), and Cairo (CPU).

- With OpenDL, you ideally don't have to write any of your own drawing-primitives code. Need beziers, gradients, fancy masking with text outlines? If Quartz2D/CoreText supports it, then it's either already present, or I can add it quickly.

- OpenWL/DL aren't designed for games or insane frame rates. I *do* think a smooth, 60fps experience is worth shooting for, but because it's CPU-bound with Quartz2D on Mac, and Cairo on Linux, that will depend entirely on the user's resolution / CPU. (But Direct2D is GPU-accelerated and already crazy fast)

  When I get a chance, I do plan on looking into how difficult it would be to implement a Core Animation compatible API, to allow for smooth scrolling / scaling / etc of large pre-rendered areas via GPU. (MacOS uses CoreAnim to speed up things like scrolling, which would otherwise be choppy when CPU-rendered on a 5K display).

- OpenWL is event-based, not polling-based. In the OpenGL demos I've seen in the past, the render loop goes as fast as it can. Whereas OpenWL waits for the platform windowing system to notify it of whatever events have occurred. If nothing is happening, there is no drawing/activity.

Now, an alternative to OpenWL/DL might be something GLFW+NanoVG. And I certainly looked into those kinds of options before going this route. But ultimately I decided against it, because I wanted to build on top of what Apple/Microsoft/GNOME are actively working on. I figured, let the big companies focus on making what they feel are the best drawing APIs for their respective platforms, and I'll just ride on their coattails (and optimizations) ...

At this time, a purely OpenGL drawing library is still a little too DIY for me. Now maybe if the Slug text rendering library were open source, and a number of people were actively trying to integrate it with NanoVG, then I could be persuaded...

Another benefit of not using OpenGL, is that I can eventually support esoteric platforms with no modern OpenGL support, but for which Cairo/Pango can be compiled. Things like: MorphOS/Amiga, QNX Photon, OS/2, Mac OS9/Carbon, etc. Pretty much anything with a conventional single-threaded GUI, really.

On Friday, 12 April 2019 at 08:03:01 UTC, Dennis wrote:
> I'm currently using glfw for that, how does OpenWL compare?

Oh, and I see now you were only asking about OpenWL, not the both of them. Derp.

So yeah, just the complete lack of OpenGL support really :P

On Friday, 12 April 2019 at 10:02:53 UTC, DanielG wrote:
> Oh, and I see now you were only asking about OpenWL, not the both of them. Derp.
>
> So yeah, just the complete lack of OpenGL support really :P

Well I don't mind you telling more about OpenDL either. :)

My first reaction to "I made a cross-platform windowing library with C API" was "glfw already got that covered", but I now see how this focuses more on static windows for GUI's rather than hardware-accelerated drawing. I've worked with high-level GUI libraries and with low-level OpenGL canvasses before, but I'm not familiar with platform-native CPU drawing so this project actually piqued my interest now.

On 2019-04-12 08:45, DanielG wrote:
> These aren't written in D, but they are *for* D (or any other non-C++ language in need of its own canonical, language-native GUI). They export a C API for maximum ease of use.

May I ask why?

-- 
/Jacob Carlborg

On 2019-04-12 11:47, DanielG wrote:

> - OpenWL/DL aren't designed for games or insane frame rates. I *do* think a smooth, 60fps experience is worth shooting for, but because it's CPU-bound with Quartz2D on Mac, and Cairo on Linux, that will depend entirely on the user's resolution / CPU. (But Direct2D is GPU-accelerated and already crazy fast)

"Whenever possible, Quartz 2D leverages the power of the graphics hardware." [1].

[1] https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/drawingwithquartz2d/dq_overview/dq_overview.html

-- 
/Jacob Carlborg

On Wednesday, 17 April 2019 at 18:39:47 UTC, Jacob Carlborg wrote:
> May I ask why?

Please be more specific so I don't answer the wrong question. (Why not in D? Why a C API? Other?)

And re: hardware acceleration of Quartz2D ... at least up to 10.12, I see no evidence of that in my testing. Compared to Direct2D on Windows, native Quartz2D drawing on a 5k iMac (i7 6700k) over a large enough area is noticeably sluggish.

I would be interested to know exactly what API functions are supposed to be accelerated. Ever since QuartzGL went away, there doesn't seem to be any public information about what, if anything, is GPU-assisted. Of course I'm talking about pure Quartz2D (Core Graphics) here, nothing else.

Well, I have some time on my hands so I guess I'll answer "Why not write this in D?"

1) The easiest way to access platform-native stuff is to use platform-native tools (Xcode/Objective-C, Visual Studio/C++/COM, etc). At a minimum I would have to translate header files, and rely on D having perfect Objective-C and COM support, or whatever else some future/exotic platform might require. By doing it this way, I completely bypass all that extra work, and I can always utilize the latest platform SDKs with a few simple clicks. "When in Rome..."

2) I intend to support other platforms where D currently doesn't exist, which means I would either have to port it myself, or wait for somebody else to do it. But this way I can go pretty much anywhere that Cairo/Pango can be built (and someday hope to even drop the Pango requirement).

3) If I used D, then invariably the GC haters would complain and refuse to depend upon my libraries purely on superstitious grounds. And if they aren't using them, they certainly aren't going to help porting/bugfixing/etc. And I consider it more than a little likely the D crowd would reject my work if I wrote it all in pure D, on account of being disappointed in whatever idiosyncratic API I came up with!

4) D isn't the only language I use, and I want to be able to take advantage of these libraries anywhere I happen to go in the future. If I did what Qt did, and build everything at ground-level in a specific language, then it's no longer language-agnostic and I would keep having to reinvent the cross-platform wheel every time I want to change languages. Or else struggle with trying to create bindings, and we all know how that goes (how many Qt bindings have been attempted in non-C++ languages, and ultimately abandoned?)

I'm doing this for myself, and while I'm using D for my current project (which inspired all this), I won't be here forever. But I will probably always need a GUI wherever I go, and I'm doing my part to make that available for my future self. I know from experience, 20 years ago, that writing a GUI from scratch in a single language / for a single platform (or in this case, for a platform abstraction) is reasonably realistic for one focused individual. And with modern languages and tooling? Heavenly.