[based on my suggestion about changes to the TDBNavigator component]

What is Lazarus's take on "delphi compatibility"?

Does that mean...

a) Lazarus simply makes it easy to move Delphi projects to Lazarus - a once off process, and only in that specific direction.

b) Or does it mean "having a shared code base where developers still use Delphi under Windows, and Lazarus under Mac/Linux/etc".

If (b), then how does Lazarus handle VCL vs LCL forms? *.dfm vs *.lfm in a shared code base. Or does it mean for example myform.pas unit would have a myform.dfm and myform.lfm. This would suck big time, because you would constant have to keep all form changes in sync between Delphi and Lazarus - no easy task, and very error prone.

Regards,
Graeme.

That's all I would sign up for, where visual things are concerned.

Michael.

Personally i think of it as "that looks familiar to people who used Delphi before".

Sadly, most Lazarus developers seem to be more chained by Delphi :-P (case in point: TColor in 2012 does not have support for alpha channel in order to be compatible with old Delphi code that was designed in early 90s...).

Graeme Geldenhuys wrote

[based on my suggestion about changes to the TDBNavigator component]

More specifically: can a LCL equivalent of a standard VCL component have public methods/properties that the VCL component does not have?

Like for example giving LCL's TBitButton a Smiley property?

In the past this was frowned upon.

Bart

Bart wrote

More specifically: can a LCL equivalent of a standard VCL component have public methods/properties that the VCL component does not have?

Yes, that is what brought up the question [today], but that is not the only issue. There are many like this over the years.

As most of you know, I'm not a LCL developer or user, so whatever the answer, it will not affect my paying work. What does surprise me is that no Lazarus community member has thought of this. Anyways...

The Lazarus project is old enough to have clear direction and goals [if not you better get some]. That is why I purposely posed the question as clear as possible, so as to avoid the usual "vague" answers. Having an answer as to what the Lazarus project means my "delphi compatible" would give all current and future Lazarus contributors a clear indication of what they can and cannot contribute to the open source project.

So can the Lazarus core members/organisers [who ever you may be] please answer the question, so the whole Lazarus community knows the answer. This definition should possibility also be posted on the Lazarus wiki - some place easy to find.

Graeme.

I would also like some clarification on this question. I think personally that it should be a one-way conversion process... i.e. it should be possible to port/import any Delphi project into Lazarus without problems, but not necessarily the other way round.

One possible way to implement it is to create the exact same "base class" for all the Delphi components and then have the Lazarus (LCL) components inherit from these base classes.The descendent classes can then have all the nice-to-have feature like extra properties etc. that we want in Lazarus (or just be an exact copy of its parent class if no change is required). In this case it might even be possible to port back from Lazarus to Delphi, as long as you only use the "base class" components and not the LCL inherited classes.

But I think FPC might have a similar problem with the Delphi language that has already changed a bit from the original. What is the the situation on that side?

Cheers
Chavoux

This would be my choice too.

Which also means LCL contributors should be able to freely implement new features (like the ImageList addition to TDBNavigator) or improve exiting feature (like Alpha support in TColor) - as long as the "Import a Delphi project" or "Import a Delphi Form" functionality still works.

This way Lazarus could stand out, and be a "better Delphi than Delphi".

If you decide on option (b), you should know the following... You're on your own buddy!

Graeme.

Graeme Geldenhuys wrote

b) Or does it mean "having a shared code base where developers still use Delphi under Windows, and Lazarus under Mac/Linux/etc".

For me it is (b)

Yes, it is a problem but there is no other way. You need to support older delphi versions the same way.

Think of component developers. You always need to care that your forms does not contain something which does not work on all supported delphi versions. Lazarus support is similar.

Best regards,
Paul Ishenin

That's problematic, since already LCL TControl has some more properties than in the VCL. Some modifications are required for widgetset compatibility, so that even the Win32 widgetset does not implement everything as in the VCL.

For best portability, in both directions, I'd suggest an *true* Windows/VCL widgetset, which may not be (fully) available on other platforms.

And of course the LCL will never include the new Delphi/RadStudio cross-platform widgetset, which now exists in parallel to the VCL. I'm not sure whether Lazarus can ever support such an LCL-incompatible widgetset.

But I think FPC might have a similar problem with the Delphi language that has already changed a bit from the original. What is the the situation on that side?

Most FPC incompatibilities result from a mix of features from different Delphi versions, so that it's impossible to maintain compatibility with one specific Delphi version. Most boring is the {$mode} compiler option, which exists only in FPC, along with other syntax incompatibilities. But these can be made somewhat compatible by {$IFDEF FPC} directives. A really breaking change will be the UnicodeString, introduced in D2009[?], once it will replace the previous generic/default string type (AnsiString).

It may or may not be possible to use older FPC versions for true compatibility with older Delphi versions. But since the LCL requires the latest FPC release version, it will be impossible to create a VCL compatible LCL now, fully compatible with older Delphi versions.

DoDi

Delphi of course is not compatible to itself. ;-)

(Not regarding the very old pre long-string versions of Borland Pascal,) especially with Strings, there is a huge incompatibility between the pre- Unicode versions and the Unicode versions (and AFAIK there are some compatibility issues between the different Unicode aware versions.

No wonder that the current Lazarus is not very compatible to either of them, while the pre Unicode Lazarus was very compatible with the pre Unicode Delphi.

And it is debatable whether "full" compatibility with the current Delphi version really is desirable.

Nonetheless, as FPC seems to be moving to (rather) Delphi compatible Unicode strings (i.e. 16 Bit character code by default), Lazarus supposedly will need to follow some day and get rather compatible with D-XE? .

-Michael

As the Delphi VCL is Windows only, it supports sending arbitrary messages to to a visual component. This of course it not at all portable.

The main benefit of Lazarus is the ability top generate platform independent projects. So portability is a major point to be considered - sometimes even in is compatibility is broken.

Future Delphi versions seem to discourage the Windows-centric VCL and suggest using the completely incompatible - but portable - Firemonkey visual user interface. No idea if it makes sense for Lazarus to provide a Firemonkey compatible designer (e.g. based on free code that Firemonkey once was).

-Michael

Hans-Peter Diettrich wrote

For best portability, in both directions, I'd suggest an *true* Windows/VCL widgetset, which may not be (fully) available on other platforms.

Not a good idea, IMHO.

I don't see a great point in using Lazarus for Windows-only projects, at least for those that already did projects with Delphi. At least for former Delphi users, portability is the main reason for using Lazarus so this should be the primary goal, even when thinking about Delphi compatibility.

-Michael

Michael Schnell wrote

(e.g. based on free code that Firemonkey once was).

On a side note:
I don't think Firemonkey or DXScene & VGScene (FM's predecessor) was ever free. DXScene/VGScene was simply compatible with Free Pascal compiler and the Delphi compiler.

Graeme.

In my case this is *NOT* true; and I suspect it's not true for many Windows users of Lazarus. In my previous company I used Delphi versions 3, 5 and 7. Beyond version 7 there were too many compatibility issues with existing code, and the price became too high.

Now that I'm self employed I have moved over to Lazarus/Free Pascal. This is partly because of the cost but mainly because I'm comfortable with the IDE, form designer and compiler. In many ways it is similar to the older versions of Delphi; this is NOT meant as a criticism.

Looking at the download statistics at SourceForge it seems that over 70% of this year's downloads have been for Windows. Now, it may be that people are using Windows to cross compile for Linux; but I doubt that it is very common.

The customers I write software for are exclusively Windows based. For me it might seem that having Lazarus cross-platform is a hindrance since the developers are continuously having to deal with OS differences/incompatibilities. In practice it probably makes Lazarus a better product since more care has to take place during design.

It would be interesting to know what percentage of programmers using Lazarus are developing cross platform software. Unfortunately I suspect that answers obtained via this list would be skewed towards multi-platform.

Malcolm

Malcolm Buckingham hat am 4. Oktober 2012 um 10:38 geschrieben:

The sf downloads only counts the sf binaries. They exclude svn, git, daily snapshots, etc.
The percentages are only good for marketing. Hardly any developer is driven by download/poll percentages.

[...] It would be interesting to know what percentage of programmers using Lazarus are developing cross platform software. Unfortunately I suspect that answers obtained via this list would be skewed towards multi-platform.

... and if you ask pupils learning Lazarus in school, they will probably ask: multi-what?

Mattias

Points seconded.

Which applies to both Lazarus/FPC and to projects built using them: even if targeting Windows, it's probably worth running a project through the compilers for different platforms so that potential problems are at least identified.

It would be interesting to know what percentage of programmers using Lazarus are developing cross platform software. Unfortunately I suspect that answers obtained via this list would be skewed towards multi-platform.

However, I think that you're confusing "cross platform" with "not using Delphi's supported platform(s)". My own suspicion is that far more people are targeting a single platform (Linux, BSD, potentially Android etc.) than are seriously trying to make sure that their code runs on a collection of different OSes and CPUs (with different word size, endianness and alignment requirements).

Perhaps a straw poll either here or in lazarus-other is in order: "Of what you consider your live projects, what percentage do you actively maintain for more than one combination of OS and CPU?".

In my case I'd say about 75%, but I'm not shipping to customers these days.

I'm sure you are correct when you say that many people are writing for a single platform. If I had to write for Linux then Lazarus would be my first choice. The software I write is usually for controlling scientific hardware and then processing the data obtained. Some of the core software tends to be low level and difficult to write in an OS independent way. Things like shared memory, USB drivers, etc. Not impossible to write but definitely more work. Once you instrument control software is Windows based then any other data processing software has to run on Windows as well.

I've seen other companies working in this area supporting both Windows and Linux only to discover that 95% of the installations were for Windows but customer support issues were about 50/50. In the end they dropped Linux support. This is nothing to do with which OS is the best, but if most of your customers are wedded to Windows then supporting Linux is a lot of work for very little gain.

On the other hand things may change in the future. If Tablets really take off in business then maybe there will be a more even split between Windows, Android and Apple. Then having a cross-platform development would make a lot of sense.

Malcolm

This discussion is derailing the thread, Lazarus was is and will always be crossplatform with support for Windows, Linux, Mac OS X and whatever other widgetset people need and LCL will have to be designed with crossplatform support in mind.

Platform popularity doesn't matter, it is up to the Lazarus developers and contributors to decide that by submitting actual working code - code "speaks" better than words.

What this thread is about and some of us want to make it clear so said code can be better be thought and designed is the stance and exact meaning of "Delphi compatibility". Does it mean we screw everything if it is incompatible with Delphi? Does it mean making Delphi users' lives easier but without compromising better solutions and if a clearly better solution is available use that instead of Delphi's way? Does it mean screw Delphi, any compatibility is a coincidence nowadays due to Lazarus' past history? Does it mean something else?

Kostas "Bad Sector" Michalopoulos

Malcolm Buckingham wrote

you are correct when you say that many people are writing for a single platform.

Until the day they realize that they need to support another platform as well. And here they will be happy to have done the development on a in a way that easily supports platform swapping. So I vote for decently supporting programmers (even pushing them to) thoughtfully do platform independent work.

-Michael

Malcolm Buckingham wrote

This is nothing to do with which OS is the best, but if most of your customers are wedded to Windows then supporting Linux is a lot of work for very little gain.

That's highly dependent on the gui toolkit you use. Some gui toolkits are just crap at multi-platform support, and others are very good. Developing our company apps, there is absolutely no extra effort in supporting Linux, FreeBSD, Solaris or Embedded ARM Linux devices over Windows. I'm sure with some internet searching you can figure out what gui toolkit I use, but our toolkit is not the only one that makes such reliable cross-platform development easy.

Graeme.

Kostas Michalopoulos wrote

What this thread is about and some of us want to make it clear so said code can be better be thought and designed is the stance and exact meaning of "Delphi compatibility".

+1

Graeme.

As the Delphi VCL is Windows only, it supports sending arbitrary messages to to a visual component. This of course it not at all portable.

It is portable, when messages are sent within a single program. Only inter-process communication is affected by the platform API.

DoDi

Hans-Peter Diettrich wrote

It is portable, when messages are sent within a single program. Only inter-process communication is affected by the platform API.

I don't believe the control elements will understand all the messages that they understand in a Windows environment.

-Michael

Delphi developers tend to use messages that the Windows control itself understands, but are not necessarily handled by the VCL. So these messages might also not necessarily be implemented by the LCL at all and thus the corresponding messages will be sent for nothing on non-Win32 widgetsets.

Regards,
Sven

How that? In a different environment the messages are generated by the widgetsets, as expected by the controls.

DoDi

Hans-Peter Diettrich wrote

How that?

Yep. Something like that is just to be called incompatible :-) :-) :-)

-Michael

I see. Every widget should recognize and handle its *specific* messages. When a widget cannot implement the requested functionality, due to widgetset restrictions, the message is lost of course. The same would happen when a (handler) method were called directly, instead of sending the message.

I know that the communication between the LCL and the widgetsets is based on method calls, instead of messages. This turned out to be problematic, as can be seen e.g. in the implementation of TTabControl and TPageControl. These controls cannot implement all the features of the the Win32 widgets, due to an inappropriate widget interface.

It's also known that many messages *must* be handled by the LCL, in order to keep the states of an LCL control and its related widget in sync. This were not necessary when using messages for LCL/widgetset communication.

Perhaps its clear now why I vote for an additional Windows widgetset, with a message-driven communication between the widgetset and the native controls. Then at least on a Windows platform no control messages can get lost, and the full functionality of the controls is available to the coders.

DoDi

ping....

So what's the official word on this?

Graeme.

2012/10/10 Graeme Geldenhuys :

ping.... So what's the official word on this?

Short counter question: What is official?

Long answer without any status, official nor unofficial: Lazarus is open source. Who contributes, determines. Paul constributes Delphi compatibility fixes and improvements. See his answer.

Vincent

Vincent Snijders wrote

Short counter question: What is official?

A unanimous answer - something that the majority of the "core team" agrees on. Something that can be put on the front page of the wiki saying "This is the goals of the Lazurus project". The Lazarus core team does not only consist of Paul. Or did the team make a decision behind the scenes, and Paul was the spokesperson for the team?

Then again, who is the official core team nowadays. Before you give yet another counter question. I consider the "core team" to be everybody with full write access to the SubVersion repository.

Long answer without any status, official nor unofficial: Lazarus is open source. Who contributes, determines.

An official answer will determine how we can contribute and move the project forward.

eg: Could we modify and improve the LCL components (in ways Delphi's VCL doesn't compare), as long as we keep the "Delphi converter" in sync for a seamless one-way "Delphi to Lazarus conversion"?

What frustrates the hell out of me about the Lazarus project is the sheer lack of giving straight answers. The Lazarus project is run by a team of developers. A team is supposed to work together towards one goal. But THIS team seems to mostly dodge any specific answers, and every developer for himself. Just like the help file format issue, and a few others. I know of no other open source project that is so disorganised.

Regards,
- Graeme -

Vincent Snijders wrote

Who contributes, determines.

True, but in this very short wording not a helpful principle. ("Those who contribute, decide in some democratic way" would be more appropriate. )

With basic, far-reaching decisions with great influence on future contribution, it does make sense to seek a common agreement between the possible contributors before deciding or accepting a certain contribution that defines a direction.

"Delphi compatibility" is one of such issues.

-Michael

But there are few if any open source projects that are so wide-ranging. Lazarus (and ancillaries) is not just a straightforward compiler processing a well-defined language where correctness can be tested, it covers everything from parsing source as it's read into the IDE through the IDE and widget sets' aesthetics to the mechanism of incorporating packaged extensions.

As with most if not all open source projects, if we don't like it we can fork off. However my own position is that I trust the core developers, who are effectively defined by their understanding of how the code works.

Mark Morgan Lloyd wrote

As with most if not all open source projects, if we don't like it we can fork off. However my own position is that I trust the core developers, who are effectively defined by their understanding of how the code works.

But then again, it would be nice for committers to know if extending an LCL component beyound it's Delphi's counterpart is considered to be "officially" OK (as long as the extension is considered usefull and meaningfull and not just fullfilling the needs of very few people (and there may be more criteria)).

Getting back to the thread that stated this discussion: I could spend time and energy on implementing an ImageList for TDBNavigator (which Delphi doesn't have, and which maybe usefull for more than just a few people). But i would then become very frustrated if the patch was rejected because of "Delphi incompatibility".

Bart

We already have added extensions to LCL classes.

Things coming in mind are TGraphic and descendants. Or TImagelist, or ...

I see no reason we should limit ourselves to what Delphi has implemented (which version of Delphi)

Extensions are ok as long as they make sense and don't over complicate the component. (IIRC we have Control.SetSize(width, Height), while in delphi you need 2 calls)

I won't reject it, but I would depend on others to apply it

Marc

Vincent Snijders wrote

Lazarus is open source. Who contributes, determines.

You can't mean this seriously.
Are you saying that no changes have ever been rejected?

Contribution means also dedication. Just slapping some patch into the bug tracker which turns upside down is probably not meant with "Who contributes, determines." But if somebody works continously on a certain topic, takes care of bug reports etc. he is also in the position to do some breakage.

The point is probably: how big is the breakage of other people's work? Extreme example from FPC: from time to time people suggest to replace begin ... end by { ... } even in FPC because it is easier to type. This might be even true for a German keyboard where { means also three key strokes but nevertheless this would break everybody's code with little benefit because modern IDEs can take care of useless typing.

Are you serious yourself?

Yes.
The question was: What is the intention of the developers regarding Delphi compatibility? This has not been answered IMO.
And saying that any direction would be accepted is not correct. So the question still holds: What changes would be accepted and which would be rejected? The people who judge about changes are the persons who define the direction (unless someone forks another project).

At least for FPC holds: as much as possible as long as it does not hurt too much.

This has not been answered IMO. And saying that any direction would be accepted is not correct.

Contribute for several years high quality work and prove that you take care of what you have broken etc. then a lot of directions will be accepted I guess.

So the question still holds: What changes would be accepted and which would be rejected?

Does it matter for you? What are you working on?

The people who judge about changes are the persons who define the direction (unless someone forks another project).

Perhaps there is no intention. Probably, every developer has their own threshold/desired level of Delphi compatibility

This has not been answered IMO. And saying that any direction would be accepted is not correct.

Why?

So the question still holds: What changes would be accepted and which would be rejected?

Depends on who accepts them.

The people who judge about changes are the persons who define the direction (unless someone forks another project).

Yes.

I don't necessarily agree with the way things are going right now but it seems an oligarchic group of more or less benevolent dictators are in charge.

Unless somebody comes up with a better idea regarding how to manage this, there will be endless discussions but no change. This means you have to make them an offer you can't refuse.... or can't be seen to refuse.

Florian Kl?mpfl wrote

> So the question still holds: What changes would be accepted and which > would be rejected? Does it matter for you? What are you working on?

The answer is important not only for contributors. I am often doubting whether it is worth to stay with Pascal. If it is an dead end I would not want to waste any more time on it.

If you are in doubt, then switch. There are enough enviroments fitting everybody's need so it is not necessary to stay with an enviroment which does not fit perfectly one's needs.

If it is an dead end I would not want to waste any more time on it.

How is this related to what patches lazarus accepts? There are e.g. Mse and fpGUI only to name a two other options which follow very different directions. If this does not fit you, you are indeed wrong in the pascal world and you have to look somewhere else for other options.

2012/10/10 J?rgen Hestermann :

I am often doubting whether it is worth to stay with Pascal. If it is an dead end I would not want to waste any more time on it.

Is here any alternative that can seriously compete with FPC/Lazarus?

2012/10/10 Bernd :

> I am often doubting whether it is worth to stay with Pascal. > If it is an dead end I would not want to waste any more time on it. Is here any alternative that can seriously compete with FPC/Lazarus?

s/here/there

Hi

I'm a chemist in South Africa and I'm trying to start a new line in programming. I started out with Delphi 4 and being a poor chemist I thought Lazarus was the answer to my programming needs. I cannot afford to fork out thousands of Rands for a new programming language and besides Pascal was the language I grew up any of you guru's advise me what the best option is? I like Delphi and made my first US$ 10 000 using Delphi 4. I'd like to continue with Lazarus and pay a donation for everything I earn using lazarus. However it seems there are many ego's involved with the development of lazarus and that makes me jittery. If Lazarus is not the best cross platform programming language then what is? In South Africa we don't have the luxury of pensions and I'll have to work until I die. My idea is to develop technical solutions to companies in C++, Pascal and Matlab but if I cannot count on Lazarus what must I do?

Deon

Hi:

2012/10/10 Deon de Wet-Roos :

Lazarus/Freepascal just works. About the egos, not sure if the first mail is from bully or troll. I think that developers of both Lazarus and Freepascal are nice guys with a cool spirit.

Gustavo

Deon de Wet-Roos wrote

If Lazarus is not the best cross platform programming language then what is?

No idea, this has to be answered by J?rgen, he told he is not sure about staying with pascal. I think lazarus is a very good cross platform environment and it fits perfectly my needs: an IDE for pascal to do FPC development :)

Well, FPC/Lazarus is the best cross-platform programming language. I myself am currently staking my career on this.

And there really are no egos involved in its development.

However, it is held dear by those that develop it, and it is ferociously defended from critique. This is what you observe on the mailing lists. By itself, this can be considered a sign that it will live for a long time still :) (touch wood)

Michael.

the language is not and never has been a "dead end"... while some may think so, and we all know that old mantra of "pascal is a teaching language" and its associated "reasonings" for not using it outside of educational facilities, we also know that this statement and its reasonings are patently false... one can easily witness all of the pascal apps and tools written over the years to see this ;)

lazarus is "simply" a programing environment for the pascal language as developed and implemented by the FPC and lazarus groups... lazarus' main offering is a GUI environment with RAD methods by which you can drop components onto a pallet and generate programs... some of us use other editors instead of lazarus... some of us use all custom code instead of any pregenerated library objects you drop on the pallet... some of us are still trying to wrap their heads around this whole GUI thing...

don't worry about the egos involved... we all have them... instead, concentrate on your tasks at hand and use what you feel is the best tool for the job... since you know pascal and have used delphi, using FPC and lazarus isn't all that much of a change ;)

yeah, i'm just another FPC/Lazarus newbie and have been for several years ;)

[APPLAUSE!]

I think ImageList for TDBNavigator would be good. At work we searched for a way to change those glyphs in Delphi because they now use strange colors.
So, go ahead!

The Delphi compatible LCL components have been extended already in many ways. I don't see any core developer being against it. A practical issue only has been that LCL was not ready and it made more sense to get the basic functionality working first before extending it much.

The focus may change when things mature. My personal opinion is that both the IDE and the libraries must innovate and go beyond the Delphi equivalents to be successful. No project ever has become successful by ONLY imitating something else. On the other hand, backwards (and Delphi) compatibility is important. Most people would not be interested in this project otherwise.
Like with any library there is a fine balance between those things but I don't see any fundamental problem.

Sometimes a patch gets ignored for a long time which is bad of course. The core devels are busy or their interest happens to be somewhere else.
Bart, you have commit rights for LCL. Your judgement is trusted. Please use your super-powers. :)

More personal thoughts:
Lazarus starts to be so big that it is more like an umbrella project. Libraries, components, LCL widgetset bindings etc. can be added without disturbing the rest of the system. A whole new GUI library could be added and the designer could be adjusted for it. Yes, Mattias has made a proof-of-concept designer extension for it. So, things are flexible. Anything can be done.

And more:
I think this is a sweet spot in Lazarus development. Some diligent developers have put huge amounts of time and effort without getting much positive feedback. Now the results are showing, Lazarus is very usable and gets more attention.
I sense respect and trust between developers, not big egos as somebody wanted to explain.
The areas of response got divided rather naturally. For example I have improved the IDE's usability, nobody told me to do so and I didn't "decide" to do so. It just happened.

My experience in life says that things cannot work so nicely for long. Lazarus gets more popular, more developers join. At some point some developers start pulling to opposite directions. But, let's not think of that now ...

Hmmm... What was the problem? I don't see any big problems. More high quality code would be needed, that is a problem of course.

Juha

Bernd wrote

Is here any alternative that can seriously compete with FPC/Lazarus?

That's just the question.
I don't have much experience with other environments. And I hoped that I don't have to do so on my old days. But I am no longer sure.
Maybe Java/Eclipse?

I think waldo is absolutely right. As in any project, egos are involved. Look at Linux where a certain Finnish ego is famous.

Borland/Codegear/Embarcadero undoubtedly had egos involved as well.

The difference is that with open source projects, these dynamics are a bit more visible due to the open nature of discussion.

However, please distinguish between developers with commit rights and people who don't. The latter group is much bigger than the former and often people drift in and out of mailing list, the forum, stridently proclaim things are all wrong etc.
The former group may well be as Juha described earlier: much more harmonious.

Then we get follow up questions like: is Lazarus/FPC development more "doomed" due to the ego thing compared to say the egos in GCC+Qt development?

I'm quite happy with the way Lazarus+FPC supports a huge amount of functionality. On Win32, Lazarus ease of use has increased hugely the last couple of years; I have the feeling finishing touches are being applied rather than major missing functionality is being filled in. I occassionally run Laz on Linux VMs and it works fine there, too.

Yes, there are still some issues, as in all code, but I got the chance to scratch my pet niggles and contribute to the project, so I'm happy.

Cheers,
Reinier

Guys

I think we might be getting slightly off-track. Am I right in saying that the consensus seems to be that Delphi compatibility is basically one-way? I.e. from Delphi to Lazarus, but not necessarily the other way round? If we make extensions to the the IDE that does not exist in Delphi, I can see no other option.

The only alternative I can think of is if we keep for example a "Delphi compatible" TDBNavigator without the ImageList that can be used by those who want to be able to port their Lazarus project to Delphi. (So we might have a "Delphi compatible" tab for those components where the default Lazarus components have been improved/extended in ways that cannot be ported back to Delphi. (Or alternatively put all the "extended" components in their own tab instead). Is this worth the while?

Cheers
Chavoux
P.S. I am speaking just as a Lazarus user and not the one (or more) who would need to implement this compatibility. :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20121011/e167ac7c/attachment.html>

In my opinion those people haven't understood the spirit of Pascal... :(

I would even go into the opposite direction and adjust Delphi's attribute syntax:

=== delphi example ===

type
[SomeAttribute(1, 2, 3)]
[SomeOtherAttribute]
TSomeClass = class
[Some3rdAttribute('a', 'b')]

     property SomeProperty {...};
   end;

=== delphi example ===

to a more Pascal like:

=== hypothetical example ===

type
   TSomeClass = class
     property SomeProperty {...} attributes [Some3rdAttribute('a', 'b')];
   end attributes [SomeAttribute(1, 2, 3), SomeOtherAttribute];

=== hypothetical example ===

And if Joost isn't fast enough with his attributes branch I might do
that indeed ;P

Regards,
Sven

Extensions in the IDE don't affect portability. The IDE is already much better than Delphi 7 which was the original goal. Some parts (like CodeTools functionality) are better than the equivalent thing in latest Delphi XE3.

Changes in LCL and other libraries do affect portability. However, the extended features prevent moving the code back to Delphi only if you use them. It is up to the user to decide if he wants to use them.

In practice a big GUI oriented Lazarus/LCL application is already difficult to move back to Delphi.
You must maintain separate form files (.dfm and .lfm) because of differences in properties. In .pas files you can use IFDEFs but not in form files.
LCL has been extended already since a long time. Using those extensions has prevented moving the code back to Delphi. It is not a new thing.

My personal view is that LCL will be (and must be) extended still more in future. It means the 2-way conversion of GUI applications will be more difficult. But, does it really matter? Delphi itself has moved from VCL to a more modern design, FireMonkey.
Lazarus project must innovate, too. Only imitating a 10+ year old Delphi 7 is a dead end.

The TDBNavigator will be Delphi compatible if you don't use the new ImageList feature. That is the whole point. The functionality is extended, not broken.

Different tabs for extended components does not make sense. Instead, the new property that extends a component could be marked somehow. But again, which Delphi version should you compare with? LCL already has many properties from later Delphi versions (later than Delphi 7). I think this would be a swamp to implement. It may be better if the user reads documentation and tests the compatibility himself.

Regards,
Juha

I agree with Juha on this. Chaining Lazarus to 2 way comparability with any version of Delphi is placing an artificial limitation on Lazarus that should not be there. Even Delphi is suffering from backward compatibility issues. That Delphi should be a starting point for Lazarus is obvious, but to say that Lazarus can never be more than Delphi is a horrible idea. The last version of Delphi that I used (D6) made Globalization virtually impossible. Lazarus is a global community and needs to address this even if it means making compatibility a one-way process.

Thanks, will do

Thanks, I'll continue using it and contribute where i can.

I don't know if you participated in the discussion about this feature before I started the first implementation. But we discussed this then. I decided not to do it, for the simple reason that I don't need it since I'm doing this for an application that has to be compiled by both Delphi and fpc. And as I was the one who implemented it, I had to decide.

But feel free to add this syntax to objfpc mode. This can be done on the parser level only. And it's simpler then the 'Delphi' syntax as it does not need to remember the attribute until it parses the next statement. (Which is off course why the Delphi-class-attributes-syntax is not a Pascal syntax at all)

And if Joost isn't fast enough with his attributes branch I might do that indeed ;P

In fact that branch works completely, as far as I know. I have to add some more tests, and maybe some checks here and there. But the attributes do work.

Joost.

What stops you from merging this to trunk ?

Michael.

The tests. I want to add those first. I'll do this next week.

Joost.

Yes, I did participate in that discussion where I raised this remark as well. :)

The reason that the syntax suggested by me is "easier" for the parser is the main reason why I suggested it at all... (besides being more Pascalish ;) )

I will answer to this on core.

Regards,
Sven