ESS-Model again

[Thaddy]

I have done a first cut over of passrc as the parser and hopefully fixed up the mouse issue on Linux somewhat. So no crashes from dangling pointers anymore.

I have sent it down LCL. fcl and Components. Parser errors somewhat less than before and as it is a read then act stlye it is a little slower.

This cut over does not yet have project parsing, use directory for the moment.

Now hosted at https://github.com/dicepd/Laz-Model



Peter

I had to do quite a lot of work to build it:
- the git version depends on uDelphiIntegrator --> needs to be uFPCIntegrator. And it is in a sub-directory called "Delphi" ? You need to split that up.
- the paths in the project configuration file (lpi) are completely wrong or incomplete. I had to set the library paths manually.
- You have chosen to use mode objfpc. Well, that is not to my taste and makes it more difficult for you to maintain. In mode delphi I got the original working in less than 10 minutes! (but with the syntax limitations, of course) Changing mode to objfpc is a bad idea if you want to keep Delphi compatibility. (Frankly it is always a bad idea (opiniated, don't react... plz))

But finally it does compile and it does work.. It needs some polishing, though.

[dicepd]

You have chosen to use mode objfpc.

Will look at the lpi, tbh it's the last thing I check as I have not put a filter in my beyond compare.

Personally I gave up with Delphi years ago when they added all the .NOT crap into it.
That was the last time I bought Delphi, I was an enterprise user or whatever they called it way back back then!

Objfpc always seems to be a good lowest common demonitator for cross platform. And yes the orignal was easy to get going. Once you ripped out the Delphi integration.
 
EDIT Just worked out why I don't like changing the lpi too much it has a lot of local settings in it.
Not everyone wants to run with -gh all the time

Uploaded new lpi to github
Peter

[Thaddy]

Not everyone wants to run with -gh all the time

The -gh setting will change/go away if the user changes build mode to release.And saves.

Also note my remark about the original sources. These are old, but in Delphi dialect and compile with very, very minor changes.

[dicepd]

Labels now owner drawn without mouse events.

Mouse handling reworked, no ifdef Linux left. Works as well in Linux now as Windows. Mouse handling code is now functionally seperated.

memleaks in new parser. Not all as yet.
Project loading works again.
Project  loading still leaks in the passrc modules.

Auto sizing works, ish, some issues with class labels. The first improvement on original.

Next on the list is object selection to a new property inspector / treeview style Model View plugin to enable debuging/view of full model to ease future development to the central Model. Also to verify  edit mode flow from an editor to model to view without building specific test forms. 

[marcov]

Objfpc always seems to be a good lowest common demonitator for cross platform. And yes the orignal was easy to get going. Once you ripped out the Delphi integration.

objfpc is barely more portable than mode delphi. I agree with Thaddy that deliberately changing mode delphi code to mode objfpc is futile. It only increases burdens, or provokes extra forks from people that do want to keep delphi compatibility, for negligible or outright zero benefits.
 

[dicepd]

The reason for choosing this is simple. I grepped the source for most common mode.

LCL
Searching for: {$mode delphi}
Found 15 occurrence(s) in 15 file(s)
Searching for: {$mode fpc}
nothing
Searching for: {$mode objfpc}
Found 379 occurrence(s) in 379 file(s)

fpc packages
Searching for: {$mode fpc}
Found 4 occurrence(s) in 4 file(s)
Searching for: {$mode delphi}
Found 39 occurrence(s) in 38 file(s)
Searching for: {$mode objfpc}
Found 1046 occurrence(s) in 1043 file(s)

Components
Searching for: {$mode fpc}
nothing
Searching for: {$mode delphi}
Found 39 occurrence(s) in 38 file(s)
Searching for: {$mode objfpc}
Found 876 occurrence(s) in 857 file(s)

[Thaddy]

I am prepared to fix that for you. This is probably legacy from a time (years ago) when FPC's Delphi mode was not good enough.
Since this is source-code from a long time ago, and you are putting in efforts to re-use /re-vitalize this essentially good code, I will be glad to work with you together if you want? I can make the necessary clean up in just a few days.

[djzepi]

Would you do the translation (po-file)?

(hint
http://wiki.freepascal.org/Step-by-step_instructions_for_creating_multi-language_applications)

[Thaddy]

For English (UK and US), Dutch, German (main) and Lithuanian, yes
For French (I was at one point very good, lack of practice) , Spanish and Italian I'll need a corrector...
Russian I can speak and read, but only to discuss.

But in general: no. Better have all native or bi-lingual speakers that do that kind of job.

[Graeme]

It only increases burdens, or provokes extra forks from people that do want to keep delphi compatibility, for negligible or outright zero benefits.

And I would like to disagree. The objfpc mode has more logical and readable code syntax than the delphi mode. For those reasons I always write code in objfpc mode. I do the same when I port Delphi code to FPC.

Plus the fact that I hardly ever hear about anybody moving backwards and forwards between Delphi and FPC compilers. The only logical migration that makes sense is to move from Delphi to FPC. You get the most benefits that way - free and open source compiler and rtl, secure future, more supported platforms, more prompt bug fixes and the list goes on.....

To quote the most famous saying from the FPC development team... "He who does the work can decide how to implement it."

[Thaddy]

To quote the most famous saying from the FPC development team... "He who does the work can decide how to implement it."

Well, I agree with that... But I do not necessarily agree with sectarians (of any camp)

[dicepd]

The objfpc mode has more logical and readable code syntax than the delphi mode. For those reasons I always write code in objfpc mode.

I agree with Graeme on this, Delphi's allowance of parameters and local variables with the same name as properties is so wrong in Wirthian style languages. I like the fact that assignation of a method is clear with the @. It makes maintaince so much easier as you know what that variable is.

However I have no reason to be exclusionist on this, if someone is willing to  reintroduce Delphi uses and if def any other quirks I am perfectly happy to enclose all {$mode objfpc} with {ifdef fpc}

Peter

[dicepd]

On another note a quick change of ancestor of TModelEntity to TInterfacedPersistent and we have the the ability to have a property style editor.

 Some very rough test code has a seperate form editing the class name and propagting through to the diagram vai the existing eventing mechanism. Also picking up the class to be edited as the item is selected on the diagram.

This does not seem to have affected performance.

[marcov]

The reason for choosing this is simple. I grepped the source for most common mode.

Those are not delphi originating codebases, so that is not comparable.

While I do also think that setting up new codebases in objfpc is not the best option, the point
was mainly about hacking a known, existing delphi mode library to use objfpc, forking it unnecessarily in the process. which is totally illogical and counterproductive.

[Graeme]

was mainly about hacking a known, existing delphi mode library to use objfpc, forking it unnecessarily in the process. which is totally illogical and counterproductive.

A project that hasn't seen the light of day in years - by any Delphi developer. I again see no problems in making it a Lazarus only project and giving it a future.

The you also forget about the fact that LCL is not as "VCL compatible" as advertised. Yes, I have a set of custom controls that are shared between VCL and LCL. It a damn awful mess with tons of IFDEF's and such. Clean code, clean syntax and a true cross-platform toolkit (in this case LCL) is by far the best way to go, and makes for the most maintainable code.

Bringing this last argument closer to home. The Lazarus TSynEdit component was "supposed to be" backwards compatible with the original VCL version. Nobody bothered to backport anything. Nobody bothered to test how backward compatible it was. The Lazarus TSynEdit code was riddled with IFDEF's for years - it was a mess. Then finally they decided to start getting rid of the IFDEF's and not bother with VCL support, as it simply didn't make any sense. Good riddance.