www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Framework design, initialization and framework usage

reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
I want to build a framework which gives some structure to the app using 
it. To create this structure I would like to use interfaces. The 
application then uses these interfaces and implements the required 
functions. I want to provide a clear initialization sequence for the 
app through the framework. Which means, specific functions are called 
at specific points in the framework startup code. The framework should 
be the main frame for the application.

struct myFramework {
	myFrameworkApp myFWApp;
}

interface myFrameworkApp {
	void init();
}

main(){
	myFramework mf = new myFramework;

	mf.myFWApp.init(); // this bombs because myFWApp is NULL
}

class myAppCode : myFrameworkApp {
	void init() {...}
}


How can I create an instance of myAppCode from within the framework 
code an have it call the init function? Or do I have to create a 
myAppCode global with a predefined name and use this symbol within the 
framework code?

I'm a bit lost, now to get things started from the framework and 
plug-in user specific application code.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
May 06 2019
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 6 May 2019 at 16:50:14 UTC, Robert M. Münch wrote:

 	myFramework mf = new myFramework;


I'd make that thing's constructor private, and then offer a 
helper template function that actually creates it and the user 
passes a type.

---
// inside your library
struct myFramework {
    private MyFramework app;
    private this(MyFramework app) {
       this.app = app;
    }
}

myFramework initializeMyFramework(FrameworkClass)() 
if(is(FrameworkClass : myFrameworkApp))
{
     return myFramework(new FrameworkClass());
}
---

Then the user's code would look something like this:

---
import my_framework;
class myAppCode : myFrameworkApp {
     // implementations....
}

void main() {
    auto thing = initializeMyFramework!myAppCode;
    // if you have other stuff to do with thing, you can here.
}
---
May 06 2019
parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2019-05-06 17:04:47 +0000, Adam D. Ruppe said:


 I'd make that thing's constructor private, and then offer a helper 
 template function that actually creates it and the user passes a type.


Any reason why makeing things private? The struct is more like an 
application state to avoid globals. And I expect that the struct 
members are needed in many places.


 ---
 // inside your library
 struct myFramework {
     private MyFramework app;
     private this(MyFramework app) {
        this.app = app;
     }
 }
 
 myFramework initializeMyFramework(FrameworkClass)() 
 if(is(FrameworkClass : myFrameworkApp))
 {
      return myFramework(new FrameworkClass());
 }
 ---
 
 Then the user's code would look something like this:
 
 ---
 import my_framework;
 class myAppCode : myFrameworkApp {
      // implementations....
 }
 
 void main() {
     auto thing = initializeMyFramework!myAppCode;
     // if you have other stuff to do with thing, you can here.
 }
 ---


What I want to avoid is that explicit init line in main(). So, the user 
should derive whatever make sense for the app, but main() is never 
touched by the user. main() should initialize the user's app code 
"automatically" and be part of the framework.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
May 06 2019
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 6 May 2019 at 18:03:18 UTC, Robert M. Münch wrote:

 Any reason why makeing things private?


Just the constructor. It is so they don't try to skip a step 
calling the constructor themselves.

But, of course, it doesn't have to be private.


 What I want to avoid is that explicit init line in main().


I did things that way with cgi.d and regretted it later (and the 
vibe.d authors, as I understand it, also did something like you 
are describing and regretted it later too).

It is actually really useful to have the user write their own 
main. It makes the flow clear with a familiar starting point. 
Even if all it does is actually call a framework function to do 
all the real work, having that main gives people unfamiliar with 
your framework an idea of where to start in understanding this 
code.

And besides, you are going to need some kind of user-customized 
code to select which class they want to use. You could create a 
global variable with some predefined name... but how will it know 
which class to put in there? Is it going to be static?

extern(C) __gshared MyFramework _framework = new MyApp;


like you could do that... but it will be a weird error if the 
user does it wrong, or does it twice, or whatever. Or if their 
MyApp constructor can't be run at compile time, that is also an 
error here.


You could create a factory function with a magic name that 
returns the new object:

extern(C)
MyFramework frameworkFactory() { return MyApp; }


but again, the errors are going to be weird and this really just 
obfuscates the code.

void main() {
    useFramework!MyApp;
}


there you go, simple code, it works, and it is customizable with 
other classes.

And you, as the framework author, still get to define  all what 
useFramework does - just name it that instead of main and you are 
good to go.


If you must avoid the user calling it main, you could do what my 
cgi.d does and define main inside a mixin template.

library code:

mixin template UseFramework(Class) {
    void main() { useFramework!Class; }
}

user code:

import framework;

class MyApp : MyFramework { ..... }

mixin UseFramework!MyApp;



but like i said, i am actually moving away from that after using 
it for many years, because the main function calling another 
function works just as well and is imo simpler.
May 06 2019
parent =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2019-05-06 18:21:27 +0000, Adam D. Ruppe said:


 Just the constructor. It is so they don't try to skip a step calling 
 the constructor themselves. But, of course, it doesn't have to be 
 private.


Ok, that makes sense.


 What I want to avoid is that explicit init line in main().


 
 I did things that way with cgi.d and regretted it later (and the vibe.d 
 authors, as I understand it, also did something like you are describing 
 and regretted it later too).
 
 It is actually really useful to have the user write their own main. It 
 makes the flow clear with a familiar starting point. Even if all it 
 does is actually call a framework function to do all the real work, 
 having that main gives people unfamiliar with your framework an idea of 
 where to start in understanding this code.


Yes, I agree and think that makes a lot of sense in many cases, but I 
need to elaborate on my framework context a bit, why I would like avoid 
it: The application framework contains a message event loop (let's use 
the Windows case) and set's up all the necessary Windows environment 
and boilerplate code.

While a default window etc. is created, the user app should be called 
with different init functions. Like: init_1 when the program execution 
started, init_2 when the debug console is available, init_3 when the 
windows classes are registered, init_4 when the window is shown.

During one of the init functions, the user app would register for the 
events it is interested in. And the app framework would do the message 
dispatching.

So, in my case there would be a clear sequence how things are started 
and where the app fits in.


 And besides, you are going to need some kind of user-customized code to 
 select which class they want to use. You could create a global variable 
 with some predefined name... but how will it know which class to put in 
 there? Is it going to be static?
 
 extern(C) __gshared MyFramework _framework = new MyApp;
 
 like you could do that... but it will be a weird error if the user does 
 it wrong, or does it twice, or whatever. Or if their MyApp constructor 
 can't be run at compile time, that is also an error here.


My idea is more, that the user code somehow needs a simple to follow 
"registration" step to tell the framework: This is the main object to 
use to call the init functions, etc. I think a static constructor or so 
can do the job.

For the "to be registered" type I see two options:

1. use a base class that provides virtual functions for a small set of 
application functions that need to be implemented.

2. use an interface from which the user app class is derived. But can I 
use an interface as a type in my framework? I don't think so. So, how 
to get the user's app object type into my framwork, so that the 
framework can call the appropriate functions.


-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
May 07 2019
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2019-05-06 20:03, Robert M. Münch wrote:


 What I want to avoid is that explicit init line in main(). So, the user 
 should derive whatever make sense for the app, but main() is never 
 touched by the user. main() should initialize the user's app code 
 "automatically" and be part of the framework.


I strongly advice against the framework containing the "main" function. 
It just going to cause problems. Take a look at vibe.d, that initialize 
started with containing the "main" function and the user writing their 
code in a "shared static this". That's just ugly and there's no 
advantage.  This caused problems with testing and various versions 
identifiers had to be enabled or disabled to get it to work properly.

Since this is a framework you might want to consider having a tool that 
generates a project and outputs the necessary scaffolding. The tool 
could output the "main" function. This is what Ruby on Rails does.

-- 
/Jacob Carlborg
May 06 2019
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
struct myFramework {
	myFrameworkAccessor myFWApp;
}

interface myFrameworkApp {
	void init();
}

main(){
	myFramework mf = new myFramework;

	mf.myFWApp.init(); // this bombs because myFWApp is NULL
}

struct myFrameworkAccessor {
	myFrameworkApp instance()
	{
		if(_instance==null)_instance=new myAppCode();
		return _instance;
	}
	myFrameworkApp _instance;
	alias instance this;
}

class myAppCode : myFrameworkApp {
	void init() {...}
}
May 07 2019
next sibling parent =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2019-05-07 09:06:03 +0000, Kagamin said:


 struct myFramework {
 	myFrameworkAccessor myFWApp;
 }
 
 interface myFrameworkApp {
 	void init();
 }
 
 main(){
 	myFramework mf = new myFramework;
 
 	mf.myFWApp.init(); // this bombs because myFWApp is NULL
 }
 
 struct myFrameworkAccessor {
 	myFrameworkApp instance()
 	{
 		if(_instance==null)_instance=new myAppCode();
 		return _instance;
 	}
 	myFrameworkApp _instance;
 	alias instance this;
 }
 
 class myAppCode : myFrameworkApp {
 	void init() {...}
 }


That's a very smart idea... I like it.

Going to take a look if myFrameworkAccessor can be templatized so that 
a user can provide his own class which is then used.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
May 07 2019
prev sibling next sibling parent =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2019-05-07 09:06:03 +0000, Kagamin said:


 struct myFramework {
 	myFrameworkAccessor myFWApp;
 }
 
 interface myFrameworkApp {
 	void init();
 }
 
 main(){
 	myFramework mf = new myFramework;
 
 	mf.myFWApp.init(); // this bombs because myFWApp is NULL
 }
 
 struct myFrameworkAccessor {
 	myFrameworkApp instance()
 	{
 		if(_instance==null)_instance=new myAppCode();
 		return _instance;
 	}
 	myFrameworkApp _instance;
 	alias instance this;
 }
 
 class myAppCode : myFrameworkApp {
 	void init() {...}
 }


Tried this in a simplex example but get a compile error:

Error: cannot implicitly convert expression `new 
myFramework(myFrameworkAccessor(null))` of type `myFramework*` to 
`myFramework`


-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
May 07 2019
prev sibling parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2019-05-07 09:06:03 +0000, Kagamin said:


 struct myFramework {
 	myFrameworkAccessor myFWApp;
 }
 
 interface myFrameworkApp {
 	void init();
 }
 
 main(){
 	myFramework mf = new myFramework;
 
 	mf.myFWApp.init(); // this bombs because myFWApp is NULL
 }
 
 struct myFrameworkAccessor {
 	myFrameworkApp instance()
 	{
 		if(_instance==null)_instance=new myAppCode();
 		return _instance;
 	}
 	myFrameworkApp _instance;
 	alias instance this;
 }
 
 class myAppCode : myFrameworkApp {
 	void init() {...}
 }


I had to make some changes:

1. struct myFramework 	=> class myFramework

2. mf.myFWApp.init()		=> change into two different steps. Otherwise I 
get an: Error: no property opCall for type 
app_framework.myFrameworkApp, did you mean new myFrameworkApp?


import std.experimental.all;

struct myFrameworkAccessor {
	myFrameworkApp instance()
	{
		if(_instance is null) _instance = new myAppCode();
		return _instance;
	}
	myFrameworkApp _instance;
	alias instance this;
}

class myFramework {
	myFrameworkAccessor myFWApp;
}

interface myFrameworkApp {
	void init();
}

class myAppCode : myFrameworkApp {
	void init() {}
}

void main(){
	myFramework mf = new myFramework;
	myFrameworkApp ma = mf.myFWApp;

	ma.init();
}


-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
May 07 2019
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, May 07, 2019 at 07:21:52PM +0200, Robert M. Münch via
Digitalmars-d-learn wrote:
[...]

 interface myFrameworkApp {
 	void init();
 }




[...]

Note: it's a very bad idea to call a member function 'init'. It
conflicts with the built-in .init property of all types, and can lead to
strange bugs / confusing behaviours.

Call it something else, like 'initialize'.


T

-- 
If lightning were to ever strike an orchestra, it'd always hit the conductor
first.
May 07 2019
parent =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2019-05-07 17:43:57 +0000, H. S. Teoh said:


 Note: it's a very bad idea to call a member function 'init'. It
 conflicts with the built-in .init property of all types, and can lead to
 strange bugs / confusing behaviours.
 
 Call it something else, like 'initialize'.


Yes, thanks. I'm currently just building prototype code to get the 
single parts I need up & running. Next steps are to merge them together 
step-by-step.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
May 07 2019
prev sibling parent reply Ron Tarrant <rontarrant gmail.com> writes:
On Monday, 6 May 2019 at 16:50:14 UTC, Robert M. Münch wrote:

 I want to build a framework which gives some structure to the 
 app using it.


I'm curious. What's the ultimate aim of the framework you're 
working on? An aid to building web apps? Desktop apps? Or 
something more specific like 3D, 2D, text editors...

Or am I misinterpreting what you're talking about?
May 07 2019
parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2019-05-07 18:02:16 +0000, Ron Tarrant said:


 I'm curious. What's the ultimate aim of the framework you're working 
 on? An aid to building web apps? Desktop apps?


The goal is to have a generic framework for desktop apps where you can 
directly start to work on the app and don't have to care about getting 
all the necessary environment and building-blocks up & running.


 Or something more specific like 3D, 2D, text editors...


Some features we have in mind:

* High speed 2D graphics (working)
* GUI widget set, self-drawn via 2D graphics. Not using any OS widgets. 
Portable. (only simple tests so far)
* Flex-Box like layouting of GUI elements (working)
* Framework and App logic linked/using Reactive pattern. Message 
passing everywhere. (working)
* Selfcontained executables, no external dependencies (working)
* SQLite3 included (working)
* LuaJIT as embedded scripting layer for declarative GUIs (not yet decided)

Our focus is executable size (I'm an old school guy) and speed.

For some simple real-time grid example see: 
https://www.dropbox.com/s/eyya0brc5sbcs09/Bildschirmaufnahme%202019-05-02%20um
2022.09.54.mov?dl=0 


This one is doing on resize: a new layout, draws the grid and blits it 
to screen. It still has a double blit that we already removed.

We are currently all in prototype state to find out what's the best 
architecture and desing to link all these elements. But so far things 
look very promising, since the code is very compact. The major work 
will be to build up the GUI widget library. But we will do this 
step-by-step as we need things. And we start with the most complex ones 
first. If these work, the rest is a home-run.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
May 07 2019
parent reply Ron Tarrant <rontarrant gmail.com> writes:
On Wednesday, 8 May 2019 at 06:30:56 UTC, Robert M. Münch wrote:


 The goal is to have a generic framework for desktop apps where 
 you can directly start to work on the app and don't have to 
 care about getting all the necessary environment and 
 building-blocks up & running.



 * High speed 2D graphics (working)
 * GUI widget set, self-drawn via 2D graphics. Not using any OS 
 widgets. Portable. (only simple tests so far)
 * Flex-Box like layouting of GUI elements (working)
 * Framework and App logic linked/using Reactive pattern. 
 Message passing everywhere. (working)
 * Selfcontained executables, no external dependencies (working)
 * SQLite3 included (working)
 * LuaJIT as embedded scripting layer for declarative GUIs (not 
 yet decided)


This sounds like a complete replacement for either QT, MFC, or 
GTK as well as Glade/QT Designer all rolled into one.


 Our focus is executable size (I'm an old school guy) and speed.


Right with you there.


 For some simple real-time grid example see: 
 https://www.dropbox.com/s/eyya0brc5sbcs09/Bildschirmaufnahme%202019-05-02%20um%2022.09.54.mov?dl=0


Very impressive. Is there somewhere I can follow along with what 
you guys are doing? Do you have a GitHub presence?
May 08 2019
next sibling parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2019-05-08 09:15:41 +0000, Ron Tarrant said:


 This sounds like a complete replacement for either QT, MFC, or GTK as 
 well as Glade/QT Designer all rolled into one.


Let's say it's an alternative ;-)

All the ones you listed are either too big, too complicated, bring too 
much stuff that we don't need etc. We took a look at every approach out 
there. Unbelievable, but non really fit or impressed me.

Since we created such a framework on a different technology stack in 
the past, and our product is based on it, we have quite some experience 
how such a framework should work. GUI wise we did a lot of rounds in 
the last 15 years and the single best decision I made was: Draw the 
stuff yourself.

Oh, and I forgot one thing on my feature list: Text rendering. This 
already works, but there is quite some work on editing text, and 
layouting etc. But we have a zero dependency font loading and rending 
system. Pretty neat.


 For some simple real-time grid example see: 
 https://www.dropbox.com/s/eyya0brc5sbcs09/Bildschirmaufnahme%202019-05-02%20um
2022.09.54.mov?dl=0 
 


 
 Very impressive.


Thanks, at the core, leaving out all the necessary envrionment code, 
it's really only 50 lines of code. And the framework idea is, that I 
can focus directly on those 50 lines of code after adding one import 
statement.


  Is there somewhere I can follow along with what you guys are doing? Do 
 you have a GitHub presence?


We have one, but nothing published at the moment. I need to think about 
this. A framework needs to have enough stuff included, to be usable for 
others out-of-the-box. And it needs to be supported to lift off. So, I 
think it's a bit early at the moment.

However, I'm happy to post some updates/screenrecordings to show our progress.

What are you interested in or what would you do with such a framework?

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
May 08 2019
parent reply Ron Tarrant <rontarrant gmail.com> writes:
On Wednesday, 8 May 2019 at 10:21:34 UTC, Robert M. Münch wrote:


 However, I'm happy to post some updates/screenrecordings to 
 show our progress.


Works for me.


 What are you interested in or what would you do with such a 
 framework?


You sparked my interest because it sounds like you're working on 
something similar to what I cover in a blog I've been writing 
since January (http://gtkdcoding.com).

Rather than write something from scratch like you guys (I'm not 
that brave) I take an OOP approach to GtkD, modularizing so it's 
as close to using Lego as possible.

This blog is a revamp of another I started back in 2006 for 
PHP-GTK, but using D rather than PHP and updated to GTK 3.x. The 
original also included an application framework (which I haven't 
yet reproduced in D) with a pluggable do/undo/redo system.

So you can see why I perked up when I read your thread.

And I assume your framework is written with D as a base language? 
And you said it's cross-platform, too? Windows, Mac, Linux? Are 
any of the BSDs supported?

Assuming all that, we're very much of the same mind: 
cross-platform GUI applications made fast-n-easy using a single 
language and toolkit.
May 08 2019
parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2019-05-08 13:31:40 +0000, Ron Tarrant said:


 On Wednesday, 8 May 2019 at 10:21:34 UTC, Robert M. Münch wrote:
 

 However, I'm happy to post some updates/screenrecordings to show our progress.


 
 Works for me.


Ok, so I need to find a good name for this thing which I can use as 
thread subject :-)


 What are you interested in or what would you do with such a framework?


 
 You sparked my interest because it sounds like you're working on 
 something similar to what I cover in a blog I've been writing since 
 January (http://gtkdcoding.com).


Ah, sorry, didn't catch the link. I saw this but didn't read anything 
yet. Will do.


 Rather than write something from scratch like you guys (I'm not that 
 brave) I take an OOP approach to GtkD, modularizing so it's as close to 
 using Lego as possible. This blog is a revamp of another I started back 
 in 2006 for PHP-GTK, but using D rather than PHP and updated to GTK 
 3.x. The original also included an application framework (which I 
 haven't yet reproduced in D) with a pluggable do/undo/redo system.
 
 So you can see why I perked up when I read your thread.


Good to know that there are not only web-stack people around these days.


 And I assume your framework is written with D as a base language?


Yes. Of course we use some C bases libs but the overall goal is to make 
a D framework.


 And you said it's cross-platform, too? Windows, Mac, Linux? Are any of 
 the BSDs supported?


Since we are going to draw all GUI stuff ourself it should work on all 
platforms where you can blit a memory buffer to screen. The part that's 
most platform specific is the event loop. But that's not rocketscience. 
Overall we try to keep the OS specific integration to an absolut 
minimum.

The application won't know/see a difference on which platform it runs. 
I expect some differences in how GUI actions are handled or 
communicated to the framework, however these should be rare and can be 
handled with conditional compilation.


 Assuming all that, we're very much of the same mind: cross-platform GUI 
 applications made fast-n-easy using a single language and toolkit.


Great :-) Let's see how quick we move forward.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
May 09 2019
next sibling parent Ron Tarrant <rontarrant gmail.com> writes:
On Thursday, 9 May 2019 at 11:48:59 UTC, Robert M. Münch wrote:


 The application won't know/see a difference on which platform 
 it runs. I expect some differences in how GUI actions are 
 handled or communicated to the framework, however these should 
 be rare and can be handled with conditional compilation.


This is sounding more and more interesting.
May 09 2019
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 9 May 2019 at 11:48:59 UTC, Robert M. Münch wrote:

 Good to know that there are not only web-stack people around 
 these days.



i do web and gui

Though my gui library is 100% from scratch on linux, and... 
barely even good enough for myself to use. I really need to write 
a new text edit widget.
May 09 2019
parent =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2019-05-09 20:42:54 +0000, Adam D. Ruppe said:


 i do web and gui


:-)


 Though my gui library is 100% from scratch on linux, and... barely even 
 good enough for myself to use. I really need to write a new text edit 
 widget.


Ok, so a GUI based app framework really seems to be a "hot topic". I'm 
going to push a couple of prototypes a bit more forward to prove my 
ideas fitting together while fulling my constraints how I want such a 
framework to be.

I keep you informed.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
May 11 2019
prev sibling parent reply kdevel <kdevel vogtner.de> writes:
On Wednesday, 8 May 2019 at 09:15:41 UTC, Ron Tarrant wrote:

 On Wednesday, 8 May 2019 at 06:30:56 UTC, Robert M. Münch wrote:



 Our focus is executable size (I'm an old school guy) and speed.




What about correctness?

[...]

 For some simple real-time grid example see: 
 https://www.dropbox.com/s/eyya0brc5sbcs09/Bildschirmaufnahme%202019-05-02%20um%2022.09.54.mov?dl=0


 Very impressive.


Don't want to curb anybody's ambitions but I see massive aliasing 
in the space and in the time domain. I actually wanted to post a 
link to the antigrain website, which, however, was removed after 
its author had passed away 2013. Apparently there is no archive 
copy of that impressing website. Remains: Wikipedia [1].

[1] https://en.wikipedia.org/wiki/Anti-Grain_Geometry
May 12 2019
next sibling parent reply ztop <ztop nospam.com> writes:
On Sunday, 12 May 2019 at 17:33:16 UTC, kdevel wrote:

 On Wednesday, 8 May 2019 at 09:15:41 UTC, Ron Tarrant wrote:

 On Wednesday, 8 May 2019 at 06:30:56 UTC, Robert M. Münch 
 wrote:



 Our focus is executable size (I'm an old school guy) and 
 speed.




 What about correctness?

 [...]

 For some simple real-time grid example see: 
 https://www.dropbox.com/s/eyya0brc5sbcs09/Bildschirmaufnahme%202019-05-02%20um%2022.09.54.mov?dl=0


 Very impressive.


 Don't want to curb anybody's ambitions but I see massive 
 aliasing in the space and in the time domain. I actually wanted 
 to post a link to the antigrain website, which, however, was 
 removed after its author had passed away 2013. Apparently there 
 is no archive copy of that impressing website. Remains: 
 Wikipedia [1].

 [1] https://en.wikipedia.org/wiki/Anti-Grain_Geometry


The old site is archived in wayback
https://web.archive.org/web/20180103191733/http://antigrain.com/

And here is GUI framework done using it.
https://www.creativedocs.net/devs/gui

ZTop
May 13 2019
parent kdevel <kdevel vogtner.de> writes:
On Monday, 13 May 2019 at 09:25:05 UTC, ztop wrote:

[...]

 The old site is archived in wayback
 https://web.archive.org/web/20180103191733/http://antigrain.com/


Thanks. That is the page I have been looking for:

https://web.archive.org/web/20180306023416/http://www.antigrain.com/research/font_rasterization/index.html
May 17 2019
prev sibling parent reply =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2019-05-12 17:33:16 +0000, kdevel said:


 On Wednesday, 8 May 2019 at 09:15:41 UTC, Ron Tarrant wrote:

 On Wednesday, 8 May 2019 at 06:30:56 UTC, Robert M. Münch wrote:


 

 Our focus is executable size (I'm an old school guy) and speed.




 
 What about correctness?


Correctness of what? Of the framework? Of course...


 Don't want to curb anybody's ambitions but I see massive aliasing in 
 the space and in the time domain.


Not sure what you mean by this... it's a simple prototype. And, if you 
minify a responsive layout at some point your get rounding errors in. 
If course the screencast shows an artificial case.


 I actually wanted to post a link to the antigrain website, which, 
 however, was removed after its author had passed away 2013. Apparently 
 there is no archive copy of that impressing website. Remains: Wikipedia 
 [1].
 
 [1] https://en.wikipedia.org/wiki/Anti-Grain_Geometry


Of couse we know AGG. Quality and speed is better than AGG.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
May 19 2019
parent reply kdevel <kdevel vogtner.de> writes:
On Sunday, 19 May 2019 at 13:07:36 UTC, Robert M. Münch wrote:

 On 2019-05-12 17:33:16 +0000, kdevel said:


[...]

 What about correctness?


 Correctness of what?


Open a new document in MS Word or any other word processor and 
then press and hold the "L" key until the cursor hits the right 
margin. What do you see? Evenly spaced els?
May 20 2019
parent =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2019-05-20 19:26:38 +0000, kdevel said:


 Open a new document in MS Word or any other word processor and then 
 press and hold the "L" key until the cursor hits the right margin. What 
 do you see? Evenly spaced els?


The layout stuff we do is not meant to handle text layouting. That will 
be something different. How about a LaTeX like layout option? But 
correct font handling and text rendering is not easy... but 
step-by-step. Text rendering works so far...

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
May 20 2019