www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - OpenWL/DL - two foundation libraries for building a cross-platform GUI

reply DanielG <simpletangent gmail.com> writes:
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
Apr 11 2019
next sibling parent Mike Parker <aldacron gmail.com> writes:
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!
Apr 12 2019
prev sibling next sibling parent reply Dennis <dkorpel gmail.com> writes:
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?
Apr 12 2019
next sibling parent reply DanielG <simpletangent gmail.com> writes:
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.
Apr 12 2019
parent Jacob Carlborg <doob me.com> writes:
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
Apr 17 2019
prev sibling parent reply DanielG <simpletangent gmail.com> writes:
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
Apr 12 2019
parent Dennis <dkorpel gmail.com> writes:
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.
Apr 12 2019
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Apr 17 2019
parent reply DanielG <simpletangent gmail.com> writes:
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.
Apr 17 2019
parent DanielG <simpletangent gmail.com> writes:
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.
Apr 17 2019