Re: Framework design, initialization and framework usage
On 2019-05-20 19:26:38 +, 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
Re: Framework design, initialization and framework usage
On Sunday, 19 May 2019 at 13:07:36 UTC, Robert M. Münch wrote: On 2019-05-12 17:33:16 +, 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?
Re: Framework design, initialization and framework usage
On 2019-05-12 17:33:16 +, 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
Re: Framework design, initialization and framework usage
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
Re: Framework design, initialization and framework usage
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
Re: Framework design, initialization and framework usage
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
Re: Framework design, initialization and framework usage
On 2019-05-09 20:42:54 +, 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
Re: Framework design, initialization and framework usage
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.
Re: Framework design, initialization and framework usage
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.
Re: Framework design, initialization and framework usage
On 2019-05-08 13:31:40 +, 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
Re: Framework design, initialization and framework usage
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.
Re: Framework design, initialization and framework usage
On 2019-05-08 09:15:41 +, 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
Re: Framework design, initialization and framework usage
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?
Re: Framework design, initialization and framework usage
On 2019-05-07 18:02:16 +, 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
Re: Framework design, initialization and framework usage
On 2019-05-07 17:43:57 +, 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
Re: Framework design, initialization and framework usage
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?
Re: Framework design, initialization and framework usage
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.
Re: Framework design, initialization and framework usage
On 2019-05-07 09:06:03 +, 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
Re: Framework design, initialization and framework usage
On 2019-05-07 09:06:03 +, 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
Re: Framework design, initialization and framework usage
On 2019-05-07 09:06:03 +, 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
Re: Framework design, initialization and framework usage
On 2019-05-06 18:21:27 +, 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
Re: Framework design, initialization and framework usage
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() {...}
}
Re: Framework design, initialization and framework usage
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
Re: Framework design, initialization and framework usage
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.
Re: Framework design, initialization and framework usage
On 2019-05-06 17:04:47 +, 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
Re: Framework design, initialization and framework usage
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.
}
---
