Lost a new commercial user this week :(

[Rikki Cattermole via Digitalmars-d]

On 14/12/2014 11:15 p.m., ketmar via Digitalmars-d wrote:
> On Sun, 14 Dec 2014 22:52:59 +1300
> Rikki Cattermole via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>
>>> p.s. sorry for me being rude. DWT, GtkD and others are great project of
>>> great value. it's not about "their authors doing wrong things", that's
>>> about "i want something completely different!"
>>
>> Yeah they are great projects.
>> But they won't ever be what I'm looking for.
>>
>> Personally?
>> - I want a gui toolkit that is accelerated e.g. OpenGL.
>> - That can be layered drawn on top of other OpenGL content.
>> - Completely configurable at runtime e.g. change of shaders.
>> - Centralized themeing.
>> - That works on all major platforms without heartache.
>>
>> But here's the thing about guis in general.
>> Gui toolkits are not really designed to work with OpenGL like this.
> GUI toolkits are not really designed. that is. a good GUI toolkit
> should be able to use any backend the end user want. DirectFB? OpenGL?
> custom framebuffer library? anything, it should not matter at all.

Agreed and I know. I'm using OpenGL as an example. You'll notice heavily 
that I abstract interface from implementation to the point of there is 
literally a subpackage called opengl for the OpenGL implementation.

> the abstraction GUI toolkint using should be designed like X server.
> want anything? ask the underlying layer to do that. pixmap with
> gradient? don't do that in control painting code, ask the underlying
> pixmap layer to do that. want text output? don't do that, use the
> underlying layer that does ALL text rendering. and so on. this way GUI
> toolkit can use any acceleration the underlying layer can provide. and
> writing new control is a matter of compositing some high-level calls.
>
> and if we'll go to the design stage, we can find markup language
> useful. with markup language and constraint engine we moving our
> rendering code even further away. thus we need two layers: basic
> rendering engine that can draw pixels, and markup processing engine
> that convert our declarative GUI description to basic operations.
>
> and then comes the things like OpenGL, shaders and so on. on the lower
> level, which can be controlled from markup. do we have only framebuffer?
> ok, ignore advanced styling and degrate to that. modern OpenGL with
> shaders? ok, pass the necessary info down the pipe.
>
> that's where Devisualisation comes into play. it provides mechanics we
> need, with simple and well-defined interface. what we also need is
> high-level engine that will convert our declarative GUI descriptions to
> low-level calls. HTML is not the best language to build GUIs, but the
> overall way Harmonia takes looking fine. declarative language for
> high-level descriptions and translation layer for low-level calls.

Agreed, I hate to say it, because I'm basing off of Google Material 
design, I would have to use what ever Google does on Android out of pure 
ease of porting.
So its not something I'm able to create new. Just a new implementation.