Lazarus

Programming => General => Topic started by: Chan on April 25, 2019, 05:31:12 am

Title: Can we learn something from Avalonia project?
Post by: Chan on April 25, 2019, 05:31:12 am
Avalonia is an open source, cross-platform XAML Framework base on .NET Core. It's render engine is Skia which is a high performance, cross-platform vector graphic engine. And XAML enable declarative ui like HTML+Javascript+css, which can simplify ui development hugely.

I just wander if we can do something like it, to make a true modern ui framework. Since Skia is cross-platform, and FPC is cross-platform. So the only thing we need to do is to translate it's c# code to FP.

 http://avaloniaui.net/ (http://avaloniaui.net/)

Edit:
Comparing to C#,  Free Pascal is native, without CLR and GC overhead, so it's performance and memory footprint is much better than C#. So a FP version Avalonia will much better than it's C# version. This is just what lots of programmer want.

Title: Re: Can we learn something from Avalonia project?
Post by: skalogryz on April 25, 2019, 06:23:58 am
Firemonkey.
Cross-platform, efficient vector-graphic.
True modern ui framework!
This is just what lots of programmer want.
Title: Re: Can we learn something from Avalonia project?
Post by: Chan on April 25, 2019, 06:48:26 am
Firemonkey.
Cross-platform, efficient vector-graphic.
True modern ui framework!
This is just what lots of programmer want.

Well, cross-platform and vector-graphic rendering is the two main pros of Firemonkey, but it have lots of cons too:
1. License: the price of commercial license is high, and the community license is too limit;
2. It has source code, but it's not an open source project;
3. And the most important: it's not declarative UI, which is the future of UI development, it can significantly simplify the UI development.
Title: Re: Can we learn something from Avalonia project?
Post by: AFFRIZA 亜風実 on April 25, 2019, 07:23:01 am
How about the QML.
Title: Re: Can we learn something from Avalonia project?
Post by: Chan on April 25, 2019, 07:37:59 am
How about the QML.

AFAIK, QML is rendered by OpenGL and it's declarative ui. To parse, compile and run QML script, It embedded a Javascript engine(V8), which make it's memory footprint very big.  That's a huge overhead.

But the most important thing is C++. It's popular but even the dedicated c++ programmers hate it. Free Pascal is comparative with C++ in performance, and it is much more elegant.

btw: I'm familiar with C# + WPF/UWP development, but I don't like the language, it's like Java, has GC, compiled to msil, which hurts its performance greatly. But I like XAML, it make rich ui development much easier. And Bindings can separate your business code from UI code. I believe this is the ultimate future of GUI development.
Title: Re: Can we learn something from Avalonia project?
Post by: marcov on April 25, 2019, 09:14:56 am
Usually frameworks from the GC world are hard to convert to the non GC world. The assumptions simply permeate every line of code.

If you want this, better start over.
Title: Re: Can we learn something from Avalonia project?
Post by: Chan on April 25, 2019, 09:45:59 am
Usually frameworks from the GC world are hard to convert to the non GC world. The assumptions simply permeate every line of code.

If you want this, better start over.

Good point, marcov.
btw: The GC part of C# really hearts, you just can't control the memory footprint, although it seems that GC has little impact on performance. The low performance of C# is mainly caused by the design of C#. 'A .NET programming language (C#, VB.NET, J# etc.) does not compile into executable code; instead it compiles into an intermediate code called Microsoft Intermediate Language (MSIL). '
That's why I love Free Pascal, it's oo, native, and without GC, which make it an idea alternative of c++.
But the problem with FP is it lacks a vector graphic GUI framework/library, LCL of Lazarus is like VCL of Delphi, WinForm of .Net, outdated. Most modern ui Framework is based on vector-graphic rendering engine now. It's the trends. 
I know LCL is proud of providing native UI on support platform, but now  it seems that own-draw UI will win the future. Besides Avalonia, QT+Qml, Google has start the Flutter project, which is own-draw and quickly get its popularity.
To survive, we need to evolve. Maybe it is time to move to a whole new world, modern world now, for Lazarus.
I suggest we should first move Lazarus project to GitHub, and then start a new modern ui framework like Avalonia, or Firemonkey+xaml.

Title: Re: Can we learn something from Avalonia project?
Post by: marcov on April 25, 2019, 10:07:29 am
I know LCL is proud of providing native UI on support platform, but now  it seems that own-draw UI will win the future. Besides Avalonia, QT+Qml, Google has start the Flutter project, which is own-draw and quickly get its popularity.
To survive, we need to evolve. Maybe it is time to move to a whole new world, modern world now, for Lazarus.
I suggest we should first move Lazarus project to GitHub, and then start a new modern ui framework like Avalonia, or Firemonkey+xaml.

I suggest you first start creating something to show before abandoning working code. Just start making it, and fork lazarus to tweak the designer. If it is really working etc, at some later point, work can be done towards unification, multiple designer support etc.

But your first goal should be to show something working and workable, since you won't get many followers and buy-in without that. Proof that the principles work and can be transplanted to native coding, and show applications that demonstrate advantages over the existing candidates (that means Lazarus, but also competing frameworks from other language, ... including Avalonia).

At this point, trying to lug along and transform the whole lazarus infrastructure with you would hold you back, and only mire you in weeks if not months long discussions without much result.

Start coding lean, mean and clean, and work quick towards the actual goal, creating a new codebase that demonstrates basic principles.

For me, ownerdrawn always has been the niche. It is simply a lot of work, needs a lot of work to keep it updated (no OS/widget level skinning/theming)
Title: Re: Can we learn something from Avalonia project?
Post by: Chan on April 25, 2019, 10:23:31 am

I suggest you first start creating something to show before abandoning working code. Just start making it, and fork lazarus to tweak the designer. If it is really working etc, at some later point, work can be done towards unification, multiple designer support etc.

But your first goal should be to show something working and workable, since you won't get many followers and buy-in without that.

But at this point, trying to lug along and transform the whole lazarus infrastructure with you would hold you back. Start lean, mean and clean, and work quick towards the actual goal, creating a new codebase.

Sorry, I just found that Lazarus already on GitHub.
Starting new is good idea. The first thing to is to translate Skia header files to Pascal, and then learn from Avalonia.
But I'm not an professional programmer, and have not touch Delphi/FP for several years, so I don't know if I can do this. But in case if I have start the project, I will post here. I just hope more experienced people can look into this thing instead an unexperienced programmer.
Title: Re: Can we learn something from Avalonia project?
Post by: marcov on April 25, 2019, 10:38:06 am
Sorry, I just found that Lazarus already on GitHub.
Starting new is good idea. The first thing to is to translate Skia header files to Pascal, and then learn from Avalonia.
But I'm not an professional programmer, and have not touch Delphi/FP for several years, so I don't know if I can do this. But in case if I have start the project, I will post here. I just hope more experienced people can look into this thing instead an unexperienced programmer.

If you don't have development organized, the project is doomed. Just posting and waiting for people to show up is pointless. People need to be very strongly motivated and persist to pull off initiating a successful project. (and that persistence is often even more important than development skills, those are sometimes learned/improved during the project).

In the early stages it is all about creating code, and that needs to be sorted out before the project is even started.
Title: Re: Can we learn something from Avalonia project?
Post by: Chan on April 25, 2019, 11:04:59 am
For me, ownerdrawn always has been the niche. It is simply a lot of work, needs a lot of work to keep it updated (no OS/widget level skinning/theming)
IMO, skinning/theming will not be a big problem, based no two reasons:
1.Owner-drawn framework often has its own style/theming and provide many themes(e.g., UWP, WPF, Flutter, QT). 2.And the users doesn't always prefer native look either. Own-theme sometimes can be a selling point.

Native look doesn't always preferable for users. Just look at the 'native' ui controls of Windows, i.e., those win32 controls in WinForm/VCL/LCL. Yes, they are native, but native doesn't mean attractive, especially compare with the new Metro UI?
Also, just look at you windows desktop, how many serious softwares adopt 'native' UI looks? Almost all of them implement their own skin/theme system, either using GDI or DirectX/OpenGL.
Flutter uses Skia, QT/QML uses OpenGL, and they are very popular and we seldom heard the users complain about the non-native look.
In fact, the only problem with owner-drawn framework is it needs a lot of work. 
Title: Re: Can we learn something from Avalonia project?
Post by: PascalDragon on April 25, 2019, 11:41:01 am
It's not only the look that is important, but also the feel. E.g. integration with the systems input methods (IMEs on Windows) and such. It's for example where GTK on Windows completely fails (and why I'm really annoyed with Pidgin). If one implements a custom drawn UI framework then one needs to reimplement all these little tidbits.

E.g. did you know that you can copy/paste the content of a standard Windows dialog simply by using Ctrl+C? (very useful for customer support ;) )

Not everyone may use every feature, but good integration into the host system is important.
Title: Re: Can we learn something from Avalonia project?
Post by: Chan on April 25, 2019, 12:00:19 pm
It's not only the look that is important, but also the feel. E.g. integration with the systems input methods (IMEs on Windows) and such. It's for example where GTK on Windows completely fails (and why I'm really annoyed with Pidgin). If one implements a custom drawn UI framework then one needs to reimplement all these little tidbits.


Good point! I forget these. Owner-drawn framework also must impalement one dedicated input system on each support platform, like WPF/UWP. That's indeed lots of work, although it's not impossible.

 
Title: Re: Can we learn something from Avalonia project?
Post by: marcov on April 25, 2019, 12:11:57 pm
IMO, skinning/theming will not be a big problem, based no two reasons:
1.Owner-drawn framework often has its own style/theming and provide many themes(e.g., UWP, WPF, Flutter, QT).

Yeah, but that again requires extra work to keep that up to date. And usually the similarity is only visual, and very superficial. "Feel", as PascalDragon rightly says is not emulated (I do quite a lot of application manipulation over keyword like ctrl-tab to jump over controls etc, and that usually fails miserably)

So yes, you can implement your own theming as a workaround, but that is a very large extra burden.

Quote
2.And the users doesn't always prefer native look either. Own-theme sometimes can be a selling point.

Sure, like for POS or machine software. Though that is not 100% a selling point for owner drawn, since a few different styled buttons and colors confuse most users enough to not recognize VCL apps as standard either. A few opengl widgets with some animations also throw them off.

So while true, that is a bit the "niche" application I was talking about, and it is in addition to native apps, and not instead of.

Quote
Native look doesn't always preferable for users. Just look at the 'native' ui controls of Windows, i.e., those win32 controls in WinForm/VCL/LCL. Yes, they are native, but native doesn't mean attractive, especially compare with the new Metro UI?

I don't really like the Metro UI. For desktop, the apps look like upscaled phone apps and are very bad in making the most of screen space. Keyboard navigation is next to impossible.   

Quote
Also, just look at you windows desktop, how many serious softwares adopt 'native' UI looks? Almost all of them implement their own skin/theme system, either using GDI or DirectX/OpenGL.

Because most apps on your desktops are made by companies with billions in turnover that can set trends. Unless you have that kind of power behind you, it is pointless to try to imitate their decisions, because you can't emulate the main reason why they can get away with just about anything.

Quote
Only compare
Flutter uses Skia, QT/QML uses OpenGL, and they are very popular and we seldom heard the users complain about the non-native look.

Can't remember an app using flutter/skia. Most of those apps are not payed for, and usually business users are the critical ones, wich often already balk at installing extra libraries or frameworks.

You must regard this as a one developer company trying to sell a product based on the framework as the main product, and think of e.g. an office environment and intensive use. Not as e.g. Spotify or Netflix peddling a service and giving you an app for it. The service is more the attraction, and the app is only there to instrument it. YOu often only bother to look at it, after you already forked over the cash.

QT is as old as the road to Rome, and more a portable winapi than something radical different. QT is also about the only ownerdrawn framework that is somewhat done. The others never reach their goal (like own theming and decent look feel, and not being the lowest common denomitor subset)

QT (and then specially that there is only one such widgetset, and that it is commercial) is more a reason against ownerdrawn than for it. Apparently there is only room for one such kit, and it has been filled.

GTK tried to emulate it, and is still a sad, sad heap of dung.

Quote
In fact, the only problem with owner-drawn framework is it needs a lot of work.

It is not the only one (theming , often subpar look/feel and lowest common denominator in just about everything), but it is the main one.

And that lot of work is both the initial effort, and the keeping it up to date effort.
Title: Re: Can we learn something from Avalonia project?
Post by: Chan on April 25, 2019, 12:51:14 pm

So yes, you can implement your own theming as a workaround, but that is a very large extra burden.
In WPF/UWP, to change skin/theming, developers just need to write some XAML code, it's not too hard, in praise of the great theming mechanism of WPF/UWP.

Quote
I don't really like the Metro UI. For desktop, the apps look like upscaled phone apps and are very bad in making the most of screen space. Keyboard navigation is next to impossible.
 
As just mentioned, the appearance of UI can be tweaked easily if a owner-drawn framework provide a good theming mechanism. For UWP, to achieve the win32 looking, you only need to write some XAML code, set some properties. As far as appearance, one of the most important things is resolution independence. Native win32 controls doesn't support true scaling. That's why UWP can mimic the look of Win32, but not vice versa.


I think the biggest problem of a 'true' cross-platform owner-drawn framework is the restriction of mobile OS. Mobile system like iOS, UWP, are not as 'open' as desktop like windows/Linux/MacOs, there're lots of restrictions, which force the developer to use their native API/Framework. In this case, only the 'native' strategy is feasible, just like what Lazarus/Firemonkey do on iOS.

Title: Re: Can we learn something from Avalonia project?
Post by: Newsom on April 25, 2019, 01:24:33 pm
Do you think it's going to be possible to import/export the UI?
Title: Re: Can we learn something from Avalonia project?
Post by: Chan on April 26, 2019, 05:00:38 am
Do you think it's going to be possible to import/export the UI?

Sorry, just don't get it. What do you mean?
TinyPortal © 2005-2018