LVCL vs KOL-MCK

Arioch · 2012-04-03 18:21:01

by chance found LVCL http://bouchez.info/lvcl.html

But it references LightVCL for description, which is in French.
So i did not saw, what were the ideas behind it.
Especially if it uses non-optimised, slow and fat DFM :-)

I wonder if anyone compared LVCL to KOL-MCK.
I remember using D5 to make 2KB DLL plugin - only to find that MS OE 6 / Win2K cannot load it :-)

ab · 2012-04-03 20:07:36

See http://synopse.info/fossil/dir?name=LVCL for the latest version.

KOL is not compatible with the IDE designer, whereas LVCL is.
It makes a huge difference.
But LVCL apps are of course a bit bigger in size than KOL... but much smaller than VCL...

For each purpose, its library...
The idea behind LVCL is clearly stated in the site, in English.
And maintained, with some contributions (even last week), whereas KOL is not so alive today...

Arioch · 2012-04-04 08:24:22

> KOL is not compatible with the IDE designer

KOL is not, but KOL-MCK is.
And KOL w/o MCK existed for very short time far far ago.

Last KOL release was yeas ago, but news on the site shows changes as recent as Feb 2012.
Though probably KOL-MCK is more ambitious and requires more work.

The problem maybe is that both projects are little known

Arioch · 2012-04-04 08:32:21

The idea "make apps smaller" is too generic. "let's make good to everyone"
iI talked about more techy description, how and to which extent this ismade.

Last edited by Arioch (2012-04-04 08:33:28)

Starkis · 2012-05-23 12:56:53

interesting. Just a though, that it would be nice to have an unbiased comparision of LVCL and KOL-MCK by the VCL coverage/interface congruence, features, performance/efficiency & etc. (benefits and weaknesses)

Arioch wrote:

>The problem maybe is that both projects are little known

louis_riviera · 2013-09-26 23:43:49

Are both of these even supported for XE4/XE5? Delphi makes really really fat exe files. With all the unnecessary crap.
Also what about 64 bit for both of these projects? Background, server apps are 64 bit aswell..

It seems all of these projects KOL-CE,MCK,LVCL are discontinued..

Last edited by louis_riviera (2013-09-26 23:51:42)

ab · 2013-09-27 05:10:19

We do not plan to support any Unicode Delphi versions.
Nor any 64 bit port, since current LCVL relies heavily on optimized x86 asm blocks.

Pure executable size does not matter for speed.

A server project compiled with Delphi XE4/XE5 (once you did remove the unneeded "new" RTTI information e.g. by defining NEWRTTINOTUSED conditional in SynCommons.inc) is not so fat.

Purpose of LVCL is to be able to define small tools, setups or loaders, not to replace the official VCL/RTL.

Arioch · 2014-02-06 16:36:20

Well, in post-XE Delphi you cannot have neither small nor fast EXE

http://kazav.blogspot.ru/2014/01/delphi-2.html

ab · 2014-02-07 08:51:25

In our code, we tried to prevent such patterns in the pascal code which may produce such asm.
For instance, XE4 is only a few percent slower than Delphi 7.
Even when compiled with the 64 bit DCC compiler, mORMot code speed is almost the same as with Win32.

But this is mainly due to the fact that we follow our own patterns, and our own optimized string-process functions and classes, in SynCommons.pas.
See http://blog.synopse.info/post/2012/12/2 … ke-it-fast

Arioch · 2014-02-07 09:05:58

Thanks. Perhaps if you also blogged about which patterns in DCC trigger the most weird code generation lapses, it also would be of benefit.

OTOH i feel likeyou tend to "old school" programing, avoiding language features that missed from D5/D7 era... Delphi tries to be more high-level, and you have choses your own ground and don't move nether up nor down.

ab · 2014-02-07 15:36:55

It depends...
Sometimes I'm pretty 'old school', when performance is a need, at low level.
But when we reach the high level, I use interfaces, late binding (via variants), and other high-level structures.
Some part of the code (e.g. SynProject is very high-level, without any pointer arithmetic, nor allocation trick).

So our coding style goes "up or down", depending on the part of the code involved.

I just avoid to use generics, since we need to maintain compatibility with older version of Delphi, and because we do not need it - the "class of ..." types are pretty powerful, and are enough to create instances from a class type.

mORMot Open Source

#1 2012-04-03 18:21:01

LVCL vs KOL-MCK

#2 2012-04-03 20:07:36

Re: LVCL vs KOL-MCK

#3 2012-04-04 08:24:22

Re: LVCL vs KOL-MCK

#4 2012-04-04 08:32:21

Re: LVCL vs KOL-MCK

#5 2012-05-23 12:56:53

Re: LVCL vs KOL-MCK

#6 2013-09-26 23:43:49

Re: LVCL vs KOL-MCK

#7 2013-09-27 05:10:19

Re: LVCL vs KOL-MCK

#8 2014-02-06 16:36:20

Re: LVCL vs KOL-MCK

#9 2014-02-07 08:51:25

Re: LVCL vs KOL-MCK

#10 2014-02-07 09:05:58

Re: LVCL vs KOL-MCK

#11 2014-02-07 15:36:55

Re: LVCL vs KOL-MCK

Board footer