cerjones
Linux Support?
dun run under demo fails as
source/window.d(43,9): Error: undefined identifier LRESULT
source/window.d(43,9): Error: undefined identifier HWND
source/window.d(43,9): Error: undefined identifier UINT
source/window.d(43,9): Error: undefined identifier WPARAM
source/window.d(43,9): Error: undefined identifier LPARAM
source/window.d(71,17): Error: undefined identifier HWND
source/window.d(72,17): Error: undefined identifier DWORD
source/window.d(73,17): Error: undefined identifier DWORD
source/window.d(82,22): Error: undefined identifier HINSTANCE
source/window.d(84,14): Error: undefined identifier UINT_PTR
source/window.d(204,13): Error: undefined identifier LRESULT
source/window.d(204,13): Error: undefined identifier HWND
source/window.d(204,13): Error: undefined identifier UINT
source/window.d(204,13): Error: undefined identifier WPARAM
source/window.d(204,13): Error: undefined identifier LPARAM
Are there any plans for Linux support?
I'm sitting on Ubuntu 20.04.
What would be better:
- a solution based upon SDL and bindbc-sdl?
- a X11 window implementation including the (unfortunately static) X11 bindings
- keeping it as is?
Tbh I've never used linux so wouldn't know where to start. The only platform specific stuff is the main even loop and the Window class and a few bits that support that. I think I kept all the platform specific stuff in window.d, but there is some stuff that could be moved out into a separate module to make window.d even smaller, then I guess it's just making a linux version of that module. Assuming linux apps work similar to windows. So i have no problem with adding it if someone wants to do it, but I dont think i have the time to do it myself.
Honestly sounds more debt than it is worth. Examples need to be maintained, and in this case:
- either we implement a x11 window but it's quite a lot of code, that will end up unmaintained
- either we bring a SDL dependency, which is nice but also slow down people that just want to run the win32 example
arsd:simpledisplaycould be an option too; possibly the simplest however configurations are used for platforms... which is an incorrect way to use dub https://github.com/adamdruppe/arsd/blob/master/dub.json#L53
I'll need linux support when I come to test it on Arm i think, so if nobody has done it by then I'll look into it. Tbh all it needs is a window on screen, paint events, mouse clicks, and a message loop, just the bare bones.
Just in case. This is a small app that displays to SDL2 using dplug:canvas (a dg2d fork). It could be useful to copy code from in case you need a SDL-based example in dg2d.
I had tried building an example with SDL, but there is a fundamental difference: you'd have to forego local screen update (Invalidate and WM_PAINT) to perform a full screen update at all times. So it's also about what do you want @cerjones from the example.
The demo its just a demo, it's not intended as actual code anyone might use in production so it doesn't really matter i think. Ill probably get around to making a linux window at some point, but to be honest haven't had much time to do anything lately.
What about making the rendering API of dg2d operate on a pixel buffer (perhaps with different format and orderings but defaulted to RGBA32) that can be queried from the window API such as SDL or Wayland [1]?
[1] https://wayland.freedesktop.org/docs/html/apb.html
The rasterizer takes a externally supplied pixel buffer, the Canvas can be made to do so too no problem. There are a couple of requirements though... 32 bit ARGB, alpha in high 8 bits 16 byte alignment for the start of each scanline
The order of RGB could be different, but to have the alpha in say the low 8 bits would mean a fair bit of work.
made a quick and dirty x11 version in #9 to try out, but I think the demo should rather focus on rendering than on windowing backends
Awesome thanks, tbh I haven't had time to look at it yet but hopefully tonight / tomorrow maybe, just want to check it out on my system before I merge it. Yeah the demo stuff is really just for development / testing purposes, I have no intention of windowing being part of the main lib. Thanks again :+1: