The above comment seems to have stopped the previous Version 1.0 thread so I'm starting a new one with the hopes of hearing some additional comments and suggestions for achieving this goal. Of course the core compiler and ide development teams have done an awesome job over the many years that this project has been in process, but *many* others have also contributed their time and energy along the way and have an interest in seeing this project achieve a 1.0 release. Personally, I'd like to see Lazarus and FPC start to move forward and get the respect and larger following that they deserve... but with it's history and stalled 1.0, I don't blame any noob, experienced developer or business that makes an informed decision to avoid this toolchain.

The problem I see is credibility... or "if we write a lot of code with Lazarus/FPC, will it be maintainable with the project in perpetual beta?". Delphi was stable from release 2 and code I developed with it in versions 2, 3, 4 and 5 continued to "just work" as I upgraded. Not the case here. I've been writing new code with Lazarus since 2002 and have learned that anything I write today is virtually guaranteed to be broken and uncompilable tomorrow because somebody thought it would be cool to change some aspect of the Object Pascal language or completely revise a library interface or function. It's become a lot of work to maintain the stuff I've already written and I'm reluctantly considering not using Lazarus for any new projects.

Businesses laugh in our general direction over the code breakage issue where a project investment using Lazarus/FPC may end up a QA and maintenance nightmare. This view is shared by many of my colleagues who can't understand why I'm still using a beta ide on a "dinosaur language from the 80's". How's that for an insult? I agree with Graeme's posting that this has become a public relations issue... an obvious one. I'm also starting to see it as a squandered opportunity to displace the bloated languages on the Linux platform where fast, compact and self contained Lazarus apps should be a dominant presence right now... today.

Yes, Lazarus is an open source project, people work on it for fun and there is no business entity that is promoting it. Lazarus has been active for around 10 years and FPC even longer then that. The Linux OS also started to emerge during this same timeframe with the same type of development model. To compare, Linux is now running corporate datacenters around the world... and Lazarus is still in beta with very few public applications deployed.

I don't think a case can be made that the project isn't ready for 1.0... after 10 years of development and it's current, impressive state, of course it is. The next steps are to actively discuss the finer points of what "ready" is and to set a definite goal to achieve it. As I see it, this will involve a feature set freeze, establishing bug thresholds *and* making a reasonably sincere commitment to not break compatibility at the source level past the version 1.0 release that will hopefully be shared by the FPC team.

A version 1.0 milestone is crucial and much more then a given feature set and minimized bug list. It also conveys the idea of stability and confidence to anyone who may be interested in investing their time to learn the language, use the tools and create something of lasting value. If we don't start building that confidence in the larger community pretty soon, this project will continue to be viewed as a "toy" and will eventually become a relic to a once great development paradigm.

Thanks,

-Tom

My list of things to be fixed for 1.0 is the next:

- frames feature was first released in 0.9.28 but it had many unimplemented/wrong implemented parts. during the last month we have fixed/implemented much there. so the feature is only almost ready now and it still requires a week of development to be finished.
- docking. many parts of this features are in the experimental state
- LCL. it has bugs. I think this part does not needs to be extended with the new features but we need to fix most of the bugs we have in the tracker. who needs a component library with bugs?

Best regards,
Paul Ishenin.

I totally agree! Since the day I began to use Linux back in 1995 and the day when I discovered fpc, then Lazarus, I'm still convinced that fpc/Lazarus could be the game changer. Or kind of..

Now I'm sure that even if there's official websites & wiki, which are great & useful, 'something' is still missing. What about a task force, group (or whatever) focusing on Communication & PR issues?

Best,
Thierry

Calling Lazarus 0.9.30 Lazarus 1.0 won't fix that problem.

Vincent

...

Then this may be an argument against 1.0. I agree, that in a none beta (V1.0) the interface should be stable.
So if the interface isn't yet stable, if it still needs changes....

Besides this, I don't know, if it does need incompatibility changes.

I don't know neither which ones you experienced. Unless you checked on the mailing list or attempted to report them, they may or may not have been intentional? They could have been bugs introduced by a new feature?

On the other hand, even after reaching V1.0 such things can happen. Like in FPC: V2.x and there where changes in FPC, some of them resulted from because people exploided a bug (like using properties as var param). Now the bug is closed, the "feature" doesn't exist anymore.

Anyway, if you want to help stabilizing the LCL interface => start a thread with examples (unless it has been reasonable explained why a change was made). Then it can be established if it was needed. And if the cost for people to "fix/update" their code was to high.

It may be that a few people will be convinced by a V1.0..

I don't believe the majority will, they will change the wording of the argument, but keep it the same. It will then be:
- Lazarus, still about 10 versions behind Delphi (unless we skip a few versions and release V11.0)
- Lazarus they released to early, look at all the bugs.... (people a narrow minded in that they will ignore that delphi has bugs too)

And as for Graeme (correct me if I am wrong), who startet the topic in the other mail, IIRC it was him who mentioned one major argument for not going 1.0 => The debugger and it's usability (which is another thing people are going to hold against Lazarus, never mind what the version number is).

It is true, that Version numbers today are very often used for marketing. But that implies that you have a lot ot people, time, and money to go into marketing.

That you can advertise, that you can present your products on exhibitions, and that you can tell people about all the good. Because only if you tell people activly about all the good, only then they may stop seeing the bad.

Oh, yes, Of course I would like to see Lazarus being more popular. but I don't believe that V1.0 will do a major difference here.

For example: There was a recent mail about some Linux magazine reporting about Lazarus. That is the only time I heard it was in the press. What about all the other Computer magazines? Many of them have a section where they introduce new Hard/Software. Some CAD product released a new Version => it gets an article (How many people use CAD?). Lazarus does not. Why? Because the company behind that product has people who write a release article, and send it to every magazine.
Get that for Lazarus and you may see a major burst in visibility. (like in germany their is CT magazine). Give them an article (and hope they publish it), announcing the release of Lazarus 0.9.28(.2) and in this article point out that Lazarus besides it' version number includes features, that delphi only had far later (in V5 or so).

There was another mail about free places for open source on the CEBIT. It got lost. Get people who can represent Lazarus, and try getting such a place.

Of course, once you actually get Lazarus that much visibility (cebit), yes then I will agree: The version number can be used as a marketing argument. But now? I don't think so.

My 2 cents (probably a little more than 2 cents)
Martin

Hi,
here my comments about this:

Lazarus uses a "BugTracker"-driven release/version cycle. So the people who have rights to priorize the bugs actually decide about this.

I think this is OK.
But to get closer to a version 1.0 the handling of the bug-reports should be changed a little.

If I look at the remaining 44 Open Points of 0.9.30 then I suggest the following:

A) bugs without a simple test-project to reproduce the problem should be moved to next version.

B) bugs which are not reproducable should be moved to next version e.g. "modal form is sometimes buggy"

C) feature requests should be moved to the next version. e.g. "Combine the Find dialog and Find in Files dialog to a single dialog"

And if we one day really want to have a version 1.0, then we need to agree first on a feature freeze.

Happy coding to all of you.

Sam

--- Tom Lisjac schrieb am So, 29.11.2009:

Von: Tom Lisjac
Betreff: [Lazarus] Release 1.0, part 2
An:
Datum: Sonntag, 29. November 2009, 5:14

The above comment seems to have stopped the previous Version 1.0 thread so I'm starting a new one with the hopes of hearing some additional comments and suggestions for achieving this goal. Of course the core compiler and ide development teams have done an awesome job over the many years that this project has been in process, but *many* others have also contributed their time and energy along the way and have an interest in seeing this project achieve a 1.0 release. Personally, I'd like to see Lazarus and FPC start to move forward and get the respect and larger following that they deserve... but with it's history and stalled 1.0, I don't blame any noob, experienced developer or business that makes an informed decision to avoid this toolchain.

The problem I see is credibility... or "if we write a lot of code with Lazarus/FPC, will it be maintainable with the project in perpetual beta?". Delphi was stable from release 2 and code I developed with it in versions 2, 3, 4 and 5 continued to "just work" as I upgraded. Not the case here. I've been writing new code with Lazarus since 2002 and have learned that anything I write today is virtually guaranteed to be broken and uncompilable tomorrow because somebody thought it would be cool to change some aspect of the Object Pascal language or completely revise a library interface or function. It's become a lot of work to maintain the stuff I've already written and I'm reluctantly considering not using Lazarus for any new projects.

Businesses laugh in our general direction over the code breakage issue where a project investment using Lazarus/FPC may end up a QA and maintenance nightmare. This view is shared by many of my colleagues who can't understand why I'm still using a beta ide on a "dinosaur language from the 80's". How's that for an insult? I agree with Graeme's posting that this has become a public relations issue... an obvious one. I'm also starting to see it as a squandered opportunity to displace the bloated languages on the Linux platform where fast, compact and self contained Lazarus apps should be a dominant presence right now... today.

Yes, Lazarus is an open source project, people work on it for fun and there is no business entity that is promoting it. Lazarus has been active for around 10 years and FPC even longer then that. The Linux OS also started to emerge during this same timeframe with the same type of development model. To compare, Linux is now running corporate datacenters around the world... and Lazarus is still in beta with very few public applications deployed.

I don't think a case can be made that the project isn't ready for 1.0... after 10 years of development and it's current, impressive state, of course it is. The next steps are to actively discuss the finer points of what "ready" is and to set a definite goal to achieve it. As I see it, this will involve a feature set freeze, establishing bug thresholds *and* making a reasonably sincere commitment to not break compatibility at the source level past the version 1.0 release that will hopefully be shared by the FPC team.

A version 1.0 milestone is crucial and much more then a given feature set and minimized bug list. It also conveys the idea of stability and confidence to anyone who may be interested in investing their time to learn the language, use the tools and create something of lasting value.? If we don't start building that confidence in the larger community pretty soon, this project will continue to be viewed as a "toy" and will eventually become a relic to a once great development paradigm.

Thanks,

-Tom

To compare, Linux is now running corporate datacenters around the world... and Lazarus is still in beta with very few public applications deployed.

The same might be applied to delphi too: it appears that there are few public applications deployed.

source level past the version 1.0 release that will hopefully be shared by the FPC team.

When did FPC break source level stuff not being a bug fix?

A version 1.0 milestone is crucial and much more then a given feature set and minimized bug list.

It's rather easy to push this ;) Commit bug reports for 1.0 marked bugs ;)

I agree with you, when look Lazarus from bussiness point of view. There must be "freeze" at some point, and developers should respect it. It does not matter is it 0.9.28 or 1.0 (better to see 1.0 definitelly), but in case 0.9.28 (or 1.0) there must be full compatibility all the time (0.9.28.XX - or 1.0XX) and for such thing we need more developers who will maintain stable release (1.fixing bugs 2.adding new features without breaking compatibility).
I'll vote for 0.9.30 -> becomes 1.0rc with feature freeze (no interface changes) . Paul already mentioned what features are expected at that point (frames, docking etc).

zeljko

Tom Lisjac wrote

The problem I see is credibility... or "if we write a lot of code with Lazarus/FPC, will it be maintainable with the project in perpetual beta?".

Personally I think this discussion is funny, weeks before 2.4.0 comes out and lazarus faces a transition to a new resources system.

Anyway, if I have to choose between credibility for Delphi users searching for a quick fix, and the more deeply committed serious contributing users, I know which I choose.

The serious users will consider the current restrained version policy as more serious and see through a cheap spin.

ACK.

IMO it's time to provide a 1.0 version for the fully supported platforms and widgetsets. The remaining parts (components...) can stay in beta state. Then the users know what is considered usable, and where work is still in progress.

It's not required to have everything documented, as CodeGear has shown in the past years, but the community should know where documentation can be completed right now. Perhaps documentation should become a new project, to which (registered?) users can contribute immediately, not only by supplying patches. As long as documentation updates are not checked by the authorized developers (as is), no bureaucracy should prevent quick documentation updates.

DoDi

My list of things to be fixed for 1.0 is the next: - docking. many parts of this features are in the experimental state

The experiments are restricted to bypassing the Delphi-inherited problems. Where could we be today, almost one year after I started working on docking, if I had been allowed to erased all the flaws of that crappy Windows centric model...

IMO we should allow for different dragging models, so that the Delphi compatible implementation can be reverted to how it works in Delphi, and we can start developing new models for multi-platform use, based on the built-in capabilities of the widgetsets.

DoDi

2009/11/29 Paul Ishenin :

new features but we need to fix most of the bugs we have in the tracker. who needs a component library with bugs?

You do know Borland released Kylix v1, v2 and v3 with tons of bugs! :-) The difference between Kylix and Lazarus, is that Lazarus still has active developers willing to fix bugs.

Knowing that there will be timely release after v1.0 should be good enough incentive for users & companies to try Lazarus. This is how KDE team handled the v4 release as well. KDE v4 was full of bugs, but users knew soon there will be fixed releases, so they probably didn't loose that many users. KDE is and those issues in v4 release are long forgetten.

This is very different to how Borland managed Kylix (no incentive to fix anything after v3 release). Lazarus will not be in the same predicament as Kylix, but a v1 release will be a huge positive step for potential new Lazarus users.

+1
I couldn't say it better myself. I'm glad to see that I'm not alone is this thinking.

We switched all our simulation machines at work from kde to gnome. Admitted, one reason is also that KDE4 looks terrible ugly :)

2009/11/29 Florian Klaempfl :

That would be sneaky, but clever! :-)

Florian Klaempfl wrote

We switched all our simulation machines at work from kde to gnome. Admitted, one reason is also that KDE4 looks terrible ugly :)

Oh, now is time to switch back then. KDE 4.3.x looks good again. :-)

I see KDE 4.0 as a warning example of claiming the SW as "ready" too early. KDE 4.2 should have been 4.0. I think they lost many users, like Florian here. Suse made an even bigger mistake by including that alpha-quality desktop as a default in their distro. They also lost users.
People trust the recommendations given by those projects, and they should be able to trust them.

Version 1.0 (or 4.0 with KDE) should mean:
Usable for everyday work, no showstopper bugs and no missing features.

Version 0.9.x means:
Good for testing and experimenting, don't trust for serious work. Some features still missing.

I also say that Lazarus is nearly ready for 1.0. Feature freeze, RC1 version and then 1.0. Could happen quite soon. Early next year? From another message from Florian, about users looking at version numbers:

Do you really want such people using lazarus :)? They'll waste our time with whinning, no more no less.

This is an opposite of what commercial companies do. They cheat people by naming a beta-quality program v1.0 so people buy it happily.

You want to cheat people by naming a production-quality program v0.9.x to keep "whiners" out. I understand it. Development is most productive with a relatively small but talented and dedicated team.

This is about balance of interests. A commercial company would go bankruptcy with this mentality but this is not a company, it is an open source project. Interesting to learn...

Regards,
Juha Manninen

2009/11/29 Marco van de Voort :

The serious users will consider the current restrained version policy as more serious and see through a cheap spin.

That would be my view as well. Unfortunately we are then in the minority. Version numbers on Windows etc. and been in popularity for some time. No v1 release = rubbish software. Unfortunately that's what they consider fact.

FPC & Lazarus choose there market by trying to be Delphi compatible - so indirectly they are targeting Windows developers. Be that Windows developers that want to move to new platforms or Windows developers that want to move away for Delphi. Either way, it's Windows developers and the majority of them look at version numbers. Sad, but true.

I would simply like Lazarus to play the PR game a bit - we have much to benefit from that, and much to offer too. So why keep Lazarus a secret or for the select few. Maximize your audience (quoted from PR people I know).

2009/11/29 Hans-Peter Diettrich :

if I had been allowed to erased all the flaws of that crappy Windows centric model...

I don't know your docking code, but I know how you feel. It's reasons like that why I work on fpGUI Toolkit. Fresh toolkit, fresh start, no restrictions. But I know this doesn't suit everybody.

But if V1 = rubish, then Lazarus shouldn't go V1 ?

Of course there is an alternative approach. Remove versions (on windows) or lower their visibility. Brand the next version of Lazarus as "Lazarus 2010 Edition".

And offer it in different packages:
- 30 days Free Trial
- Gold Edition, 1 User unlimited
- Platinum Edition, Multi user unlimited (if the SVN package/component is ready and can be pre-installed)

scnr
Martin

And free updates for 1 year. :)

Mattias

Florian Klaempfl wrote

It's rather easy to push this ;) Commit bug reports for 1.0 marked bugs ;)

I assume you mean patches for bug marked for 1.0.

Vincent

As Florian noted, Lazarus needs developers more than users. There are more gtk2 issues than win32 issues, so we need to focus our martekting (if any) more to the potential gtk2 developers (on linux) than on the potential win32 developers.

Vincent

2009/11/29 zeljko :

case 0.9.28 (or 1.0) there must be full compatibility all the time (0.9.28.XX - or 1.0XX) and for such thing we need more developers who

This is where I prefer the Linux philosophy compared to Windows. Windows takes compatibly to the extreme and compromise better and cleaner designs in the process. Linux type software believes that if something is broken, fix it using the best design and cleaner code - even if this break compatibly.

With open source software, you have the code and there is more open discussions about future plans and changes. So you can be more prepared for things to come.

We use tiOPF based applications in our company. tiOPF introduces breaking changes every now and again, but enough warning is given. And if we don't have time to update our software immediately, simply don't get tiOPF updates, or branch and back-port minor fixes, until you have the time, in which case you get your software up to date with all the latest changes and features.

We have been working like this for the last 5 years. It works well, and is not as bad as one thinks.

You misunderstood my point.
If we have eg. 1.0, then we have 1.0 branch (like we have 0.9.28) where only bugs should be fixed and if we add new features there , it shouldn't break compatibility. Trunk is another story - there can be whatever. I also prefer Linux over Windows philosophy, but it's same like I said. If you are stucked to Qt-4.5.XXX then use it - nobody will break it.But if you prefer 4.6 then expect some incompatibility.
So if I build my bussiness apps over 1.0, I'll expect that 1.0999 will not break any compatibility (even there's 2.2424 current stable version).

As already Vincent pointed: at the moment we need developers not users.

gtk2 maintainer is deadly needed, like I do for qt or Felipe for wince etc...widgetset code must be watched everyday, not quarterly or monthly in best scenario.
Just compare num of issues per widgetset.

zeljko

2009/11/29 Juha Manninen :

I see KDE 4.0 as a warning example of claiming the SW as "ready" too early. KDE 4.2 should have been 4.0.

Well that applies to KDE only. Lazarus is NOT in that situation. Lazarus has been for the last 7+ years sure as hell isn't as "new" as KDE v4.0 was, so the KDE issues will not apply to Lazarus at all.

And version 0.9.x + "Beta" as in the title means: "We just started, so don't even bother trying us yet!"

THAT IS MY ISSUE. Lazarus is 99.99% ready, but it presents itself as rubbish. It's this that I would like to see improved. Silence those idiotic posts about buggy beta software or it hasn't even reached v1.0 yet in 10 years!!!

This gives all potential new users the wrong idea!

and then 1.0. Could happen quite soon. Early next year?

A agree! The next release should be 1.0 (release candidate)

Vincent Snijders wrote

As Florian noted, Lazarus needs developers more than users. There are more gtk2 issues than win32 issues, so we need to focus our martekting (if any) more to the potential gtk2 developers (on linux) than on the potential win32 developers.

What about potential QT developers?
My suggestion is to make QT bindings the default recommended (on Linux at least), and consider stable QT bindings as a requirement for v1.0.

This is a very realistic goal. I have compiled Lazarus for QT widgets and it works great. The bugs I found I have reported and Zeljan has already fixed them. Only some minor OpenSuse related issues remain. I already know some places where QT bindings work better than GTK2 bindings.

QT has better design internally than GTK2. Many programmers have stated that, it is not only my opinion.
Thus I believe bindings for QT are easier to make. (This was an "educated guess", I don't know the details.)

QT has lots of momentum now that Nokia bought it. There are more potential QT developers than GTK2 developers to attract if you advertise it as the number one stable binding.

Regards,
Juha Manninen

Why not ship via getlaz off the wiki with both sets of bindings?

2009/11/29 Martin :

But if V1 = rubish, then Lazarus shouldn't go V1 ?

Answer me this.... Do you consider the current Lazarus as rubbish? My answer is definitely NO, hence the reason I don't see a problem with making the next release v1.

Lazarus development will continue as normal for us that aren't so fussed (or know better). The only difference will be that it will project onto others that Lazarus is maturing and is good enough to try out.

It's a win-win situation.

As Florian noted, Lazarus needs developers more than users. There are more gtk2 issues than win32 issues, so we need to focus our martekting (if any) more to the potential gtk2 developers (on linux) than on the potential win32 developers.

More users will also attract more developers.

mfg
Michael

2009/11/29 Vincent Snijders :

As Florian noted, Lazarus needs developers more than users.

And as I have stated over and over. With new users come new contributors. I know I started as a user with no intention of contributing. But after a while I saw Lazarus and parts of FPC not that scary and managed to supply a few patches or features. Without me being a users first, those contributions would not have occurred.

And yes, for the 100x time I know that not all users are contributors, but it does increase the chances of contributions. Do you honestly want to deny those possible contributions.

"Grow Your Own" ... is one approach, the more users you have, the more Object Pascal programmers you have, the larger the base to potentially pull developers from!

Sure, but more users in last few months didn't attract single developer to sit with gtk2 and fix issues :), so how many new users we need to attract 1 developer to maintain gtk2 ? :)

2009/11/29 zeljko :

You misunderstood my point.

My apologies then. :)

As already Vincent pointed: at the moment we need developers not users.

A developer is a user. So if you don't want users, you ain't going to have developers. With more users comes a better chance of getting developers. As soon as users get confident with a product that might start experimenting or fixing minor bugs.

Any contribution, big or small should be wanted. Not everybody has the skill to implements new widgetset, but many do have the skills to fix other issues.

So scaring off potential users because Lazarus keeps telling everybody "I am still BETA" doesn't boast well. I think Lazarus has reached maturity - at least v1.0 status. Otherwise I would not have bothered starting this thread.

What do you think the ratio is now? 100:1 1000:1 ?

Also, stock Ubuntu is Gnome/GTK2, so, how would you raise awareness of Lazarus Development Environment to said target audience as an example?

Personally, if we are going to approach this marketing driven, I'm more in favour of the slackware approach (as they did when they jumped from 3.6 to 7).

- determine direct competitors
- determine their version numbers.
- versionnumer:=max(other versionnumbers)+1

its a clear policy (a new release always has the major release number of the competition +1), and a suffix in case there is no new competitor release.

At least it will put this kind of nonsensical discussions to rest (which is exactly why Patrick did this)

2009/11/29 zeljko :

Sure, but more users in last few months didn't attract single developer to sit with gtk2 and fix issues :), so how many new users we need to attract 1 developer to maintain gtk2 ? :)

Maybe that's because GTK2 is crappy! :-) Maybe that's why LCL-Qt was started, that's maybe why I allocated time working on LCL-fpGUI?

LCL is not the only part of Lazarus project! I don't use the LCL, but I sure do you the IDE extensively. So I may contribute to the IDE, and not the LCL. In seems in your eyes that doesn't count as contributions... that's sad.

If you then look at

http://delphi.wikia.com/wiki/Borland_Compiler_Conditional_Defines

the next lazarus version will be 15.0 or 22.0 depending on which Delphi version number you take.

Or 2012 if you use dates. Never be shy to run in front of the herd :-)

Heck, why not just January release, version 'Year', followed by a July release, version 'Year.5' ?

Year.5 being bug fixes for Year, and each new next Year being trunk?

Wash, rinse, repeat for each year of existence?

2009/11/29 Marco van de Voort :

At least it will put this kind of nonsensical discussions to rest (which is exactly why Patrick did this)

That does actually make sense.

So maybe Lazarus should start releasing using "year.revision"

eg:
Next release: Lazarus 2010
If another release in the same year: Lazarus 2010.1 The following year: Lazarus 2011

I know of quite a lot of software that uses this version numbering approach. And as you say, that might put an end to this discussion.

It would also eliminate any confusion as what version of toolset you are using. If it wasn't for that Linux Journal magazine getting me to actually try the IDE combined with a very cheap Delphi 4 book, I wouldn't be here. I am a systems administrator in need of a true RAD environment, and after learning basic Object Pascal over the last two weeks or so, I think this type of kit is sorely needed by many more than me, but things like version numbers definitely count to people like me. When I see '0.9.XXX', my first thought is, "YOUNG" project, not mature yet. If the team switches to YEAR numbering, combined with a very clear blurb on the main web site indicating how long the project has existed, along with a clearly defined release schedule (changes between 'official' releases don't have to be much, just improvements and bugfixes), you could definitely attract more users from which, eventually, more developers will grow from. You are not going to get more developers unless and until more people begin to develop stuff using the Lazarus. They have to have a reason to become a developer, providing them with a tool that they can use to scratch their own itches, so to speak, is a way to begin having people learn Object Pascal. Until people learn Object Pascal, there will be no developers to pull in.

2009/11/29 Michael Joyner ?? :

When I see '0.9.XXX', my first thought is, "YOUNG" project, not mature yet.

Just to second that. From http://en.wikipedia.org/wiki/Software_versioning:

In contrast to this, the free-software community tends to use version 1.0 as a major milestone, indicating that the software is "complete", that it has all major features, and is considered reliable enough for general release.

My point is: people defining the quality of software by its version number will never be valuable contributors for an OSS project, they even don't understand OSS.

That's true, but as I already mentioned we need gtk2 maintainer - person who should spend more than one hour monthly / quarterly over gtk2. That's different between maintainer and contributor.
Users and contributions are always welcome, and of course I would like that lazarus have x1000 times more users, but our problems still exists - gtk2 is blocking us at the moment.If we wait gtk2 fixes over small contributions, then 1.0 can be reached in the time of gtk 5.0 :)

zeljko

zeljko wrote

Well, ratio is pretty high for ide, win32, some smaller for carbon,qt, but for gtk2 there's no ratio :)

Isn't it infinite ? N : 0 = oo ;-)

The problem is that while this works for commercial projects (young/idiotic users pay too), it doesn't work for open source projects.

Well, ratio is pretty high for ide, win32, some smaller for carbon,qt, but for gtk2 there's no ratio :)

Also, stock Ubuntu is Gnome/GTK2, so, how would you raise awareness of Lazarus Development Environment to said target audience as an example?

don't know

I suspect that LCL widget set implementations might benerfit from some sort of separate versioning numbers as far is what is reported as being "official" version of installed Lazarus on the Help->About and in documentaton.

Please, take a look at the kind of (possible!) contributions.

I want more gtk2 developers (and thus users, that order), so I don't want to scare them away with a buggy 1.0. For windows users, I could use the trick of labeling beta quality software with 1.0, but for developers on linux, I doubt it?

So what do we get in your propase, more noise, testers (good!) and bug reports, because of more windows users, a better win32 lcl and ide and a lagging gtk2 widget set, partly because of less gtk2 widgetset contributors, partly because of current Lazarus resources will be spent more on win32 because that is where more using/testing/bug reports are coming from. And all because you traded to get more win32 users rather than gtk2 users. A bad strategy for Lazarus.

Vincent

That's one more reason why we *should* have a 1.0 version, based on the old FPC, before starting a breaking upgrade/update.

DoDi

2009/11/29 zeljko :

... but our problems still exists - gtk2 is blocking us at the moment.If we wait gtk2 fixes over small contributions,

And that is a classic case of "creeping requirements" that keep postponing projects.

GTK2 wasn't even a v1.0 item, it was post-v1. But somewhere along the line GTK1 was demoted and a new v1.0 requirement (GTK2) added. Postponing the v1.0 release by months (at least).

Maybe v1.0 should then move back to make GTK1 the default - but that might not be such a great idea, seeing that hardly any (if any) Linux distro's ship with GTK1 pre-installed. I know Ubuntu definitely doesn't.

So it took some 8-9 years to get GTK1 support where it is today. So if we now apply that same timeframe to GTK2 before we can release Lazarus 1.0, that mean we can expect Lazarus v1.0 in some 8 years time. :-)

Maybe Lazarus should adopt the Ubuntu versioning system. Two digit year + '.' + two digit month.

eg:
If next lazarus release is in this coming January, it would be Lazarus 10.01

If "fixes" are applied to previous releases (similar to Ubuntu's Long Term Support versions), then a single digit starting at one is applied to the end.

eg:
In June next year a new "fixes" release is applied to the January 2010 release, it would become: Lazarus 10.01.1, then Lazarus 10.01.2 etc..

If in November next year a new trunk release is made, it would be: Lazarus 10.11

This is the most logical version system I have ever seen. It make it easy to explain even to end-users. And I it can even work with Windows built-in versioning type size (which I believe is 16bit values).

We are even considering applying such versioning to our own company software.

Here are some interesting reading about various versioning implementations - clearly a mixed bag of ideas! Designed to confuse the hell out of everybody.

http://www.codinghorror.com/blog/archives/000793.html http://en.wikipedia.org/wiki/Software_versioning

2009/11/29 Marco van de Voort :

The problem is that while this works for commercial projects (young/idiotic users pay too), it doesn't work for open source projects.

Why? Can you supply examples where simple versioning doesn't work in open source projects? Of if I miss understood you can you give examples to explain whatever you think can't be applied to opes source projects?

No point in making a statement without examples. ;-)

2009/11/29 Michael Joyner ?? :

I'm starting to thing the same thing. Clearly there is a huge difference between development effort (contributors) and features between the IDE and the LCL.

I guess that should be to bad, considering that we already have a totally different version number for the compiler. Lazarus and LCL can't work without the compiler.

As Florian noted, Lazarus needs developers more than users.

Masturbation doesn't lead to propagation.

SCRN
DoDi

2009/11/29 Vincent Snijders :

I want more gtk2 developers (and thus users, that order), so I don't

I want many things too... if I'm going to get those things, is a whole different story. ;-)

reports, because of more windows users, a better win32 lcl and ide and a lagging gtk2 widget set, partly because of less gtk2 widgetset

Well, that's the case already isn't it?? Lazarus and LCL are already very Windows centric (due to Delphi and Windows compatibility requirements), so it will play right into there hands. This is no joke. As far as I understand Lazarus is a lot more "implemented" or stable under Windows compared to other platforms too... Thought I only work under Linux and it seems ok to me.

Getting back to the issue at hand... Version numbering has nothing to do with your guys design choice for LCL and lack of experienced widgetset contributors. I still stand to my argument that wrapping existing components on each platform (instead of creating custom written ones) is a disaster! That just invites odd bugs (component works here but not there), causes extensive regression bugs, divides developer effort etc... But that was your guys design, so live with it.

I'll emphasize the "divide developer efforts" part. If you guys choose a better design for LCL, any developer could contribute and it would apply to all platforms. This is the case in fpGUI Toolkit, and makes contributions MUCH easier.

GTK2 is also not the ideal widgetset for all Linux users - especially from a developer point of view, having to look at the GTK2 API. I personally dislike Gnome + GTK2 (from a user and developer point of view). Clearly other think the same, otherwise there wouldn't be efforts like from Felipe and friends to create a LCL-Qt widgetset.

I still stand to my argument that wrapping existing components on each platform (instead of creating custom written ones) is a disaster!

As far as I understood, it's an axiom of the lazarus project to use the native widgetset ;)

Don't forget that fpgui started before lazarus/lcl but people joined lazarus/lcl and fpgui died till you revived it.

- versionnumer:=max(other versionnumbers)+1

Then we should release Lazarus 2011 just now, signaling that it will be finished in 2011, or will be superseded by Lazarus 2012 next year. This should leave enough time to fix the most important issues...

DoDi

Which reports do you have in mind?

B) bugs which are not reproducable should be moved to next version e.g. "modal form is sometimes buggy"

This issue got a 0.9.28 target, when it was submitted, because it is considered a regression against 0.9.26. We want each release as good as the previous release and want to prevent things to stop working in a new release as much as possible. We tried to fix it, but didn't find a fix in the couple of weeks before the 0.9.28, so to prevent the release from delaying even more, we postponed the issue to 0.9.30 (against our policy of no known regressions in a new release). One of the things that helped to make this decision was that the issue was gtk1 and we were releasing for gtk2.

C) feature requests should be moved to the next version. e.g. "Combine the Find dialog and Find in Files dialog to a single dialog"

The reason, why this got 0.9.30, because we got a patch for it. To be responsive to the patch submitter, we have a policy to tag it for the next release. If this patch is not good enough, it will be rejected, it will turn in a feature request with no specific target (or post 1.0 target). So, this won't block 0.9.30, but still needs to be reviewed before 0.9.30, to prevent good patches laying in the bug tracker for years.

Thanks for your suggestions,
Vincent

2009/11/29 Florian Klaempfl :

Don't forget that fpgui started before lazarus/lcl but people joined lazarus/lcl and fpgui died till you revived it.

Well just imagine how far and how stable Lazarus & LCL could have been if there was only one widgetset everybody developed on. The speed at which MSEgui and fpGUI progress (and each only having one developer) is testament to that.

But that's a whole other argument I do not want to restart again - it's done and dusted.

My issue now is stopping unnecessary bad publicity for Lazarus, and I believe moving to v1.0 will help in that regard.

Juha,

I test the 5 major widgetsets with several packages of custom controls that I've ported from Delphi and the Qt widgetset appears to be the least stable:

http://web.fastermac.net/~MacPgmr/OrphPort/OrphStatus.html#Status_Controls

Thanks.

-Phil

It might be a good idea to separate the IDE from the LCL, and possibly to version every widgetset. E.g. the IDE will be out of beta state as soon as it can be compiled and used with at least one widgetset on every supported target platform.

I'd also favor a LCLX, with everything excluded that Borland could not make work with Kylix (e.g. docking), or that has already been changed in the LCL (e.g. GetText). It may be not a practical split, from maintenance view, but it would allow to deal with the (remaining) multi-platform issues in a very new way, independently from the VCL/LCL (to some degree).

When some people whine about lack of gtk2 developers, it might be a resonable decision to decouple the widgetsets from the LCL and IDE, giving room to third party libraries - maybe free or commercial. Remember that OpenSource does not mean that it must all be free, and it would be a quality indicator when commercial providers would start releasing adds to Lazarus. Of course this would mean that there must exists a consent about guaranteed interfaces, usable in continued development of related libraries and widgetsets, and not all current Lazarus developers will appreciate being bound to such restrictions. OTOH the feedback from such detached and specialized providers may lead to an improvement of the LCL internals. Perhaps somebody can translate the German martial strategy "Getrennt marschieren - vereint schlagen"? (Battle of K?niggr?tz)

DoDi

Now I want to ask a (maybe stupid) question:
Why there need to be bindings for both GTK and QT? They are not native platform UI libraries. They are multi-platform libraries. If you bind to one of them, you already have support for many platforms. Sounds like dividing developer efforts to me, too. Duplicated effort. Choices are good but if it is already blocking a release of Lazarus it doesn't make sense.

Juha Manninen

Guess why so many people work on Lazars/LCL ;)?

The speed at which MSEgui and fpGUI progress (and each only having one developer) is testament to that.

Why do you develop fpGUI and don't help to improve MSE :)?

2009/11/29 Florian Klaempfl :

Why do you develop fpGUI and don't help to improve MSE :)?

Have you ever tried to read the MSEgui code? I can't. :-) It's also too different from VCL to me. Plus Martin is VERY protective of HIS code (but that's his right). Those are simply points I can't work with.

...what implies that not all components will be available or work the same on all widgetsets :-(

While I agree that native look and feel is important for the acceptance of applications, I disagree that *everything* must work the same on every platform. A set of simple and commonly used components can be made available on all platforms and widgetsets, but everything else should not be considered as a release hindrance. He who wants easy cross-platform development has to be happy with the common denominator of the target platforms, or with a platform-independent solution like fpGUI (Java...). And he who wants best integration into every target platform will have to supply according specialization of his GUI and related code.

I'd not whine when e.g. skins and themes are not implemented (in the same way) for all platforms and components, which have no or different support for such things. But I'd whine when I had to respect the special requirements of *every* platform and component in my design and source code, even if I do not want to support really *all* available platforms and *every* possible eye candy.

Delphi "X" will come as a Windows hosted cross-platform development system, and I wonder what set of components and properties it will support. A Lazarus "X" version could provide the same just now, off the shelf, *and* with a native IDE on every platform. It would do no harm to remove some problematic features and components from an LCL "X", as long as there exists no compatibility pressure (vs. Delphi "X"). The IDE itself could become the proof of which components and features have to work, in order to qualify the according part of the LCL for "X". In a next step or branch all parts can be added to an LCL "X++", which are not fully supported on all platforms.

DoDi

I test the 5 major widgetsets with several packages of custom controls that I've ported from Delphi and the Qt widgetset appears to be the least stable: http://web.fastermac.net/~MacPgmr/OrphPort/OrphStatus.html#Status_Controls

Wow, great work :-)

DoDi

Why do you develop fpGUI and don't help to improve MSE :)?

I had a look at MSE, and I can not and will not provide anything, as long as all the names are unreadable (lower case). Otherwise both fpGUI and MSE are worth a look, because both have clearly restricted goals, reachable with limited resources.

DoDi

2009/11/29 Phil Hess :

http://web.fastermac.net/~MacPgmr/OrphPort/OrphStatus.html#Status_Controls

I'm curious... I once installed but never used TovcXXX controls (years ago and can't remember if it was Delphi or Lazarus).

What exactly does the TOvcController do? And do you have an example of how it is used? Is it something like TAction component?

Of course technology evolves and changes will need to be introduced over time... the problem is that better version control needs to start now so pure app coders won't have to be in the development loop on a daily basis to keep up.

In the current beta model, changes are added "on the fly" and anyone developing code has to follow the development track on an almost daily basis to keep their code working. This isn't realistic for a wider audience that just wants to use the tool to write apps and have confidence that they'll be able to compile them next year without having to review all the development threads and changes that took place in between.

Formalizing a 1.0 would establish a well defined baseline and make it possible to provide release notes that describe exactly what aspects of the 1.0 code would be impacted when moving to version 2, 3, 4, etc. On the other hand, if the project keeps wandering around in a beta state where changes continue to be introduced "on the fly", all the code that's currently out there will continue to become more and more broken with each passing day without a clear path for getting it fixed.

I would agree if I believed that Lazarus/FPC had any "serious users". Other then the core development team, their employers and people who closely follow the development track, who is using this toolchain for deploying serious public or commercial work?

That wasn't a frivolous question and if such a listing exists, I'd be very interested in seeing it and noting its length. Here in the US, doing a search on hotjobs.com for "Lazarus" returns "Sorry, we didn't find any Lazarus jobs". A search for "Delphi" returns a total of 17 nationwide whereas "Java" returns 2,817, "C#" 1,159 and "Linux" 1,817. Delphi is already a relic in the US, but with changes, I hope there's still a future for Lazarus/FPC as a serious commercial tool.

In another part of this thread someone pointed out that more developers are needed then users. I disagree. From my perspective, the Linux kernel again provides a useful model for a successful project that started with one guy. Once the kernel had achieved "critical mass" on a technical level (meaning it basically worked), Linus was able to "sell" a bunch of other people on trying it out... and some of those people were developers. What happened next is part of history.

Lazarus has had "critical mass" for a long time. Even in 2002 I found it to be a very capable and stable tool and I thoroughly enjoyed working with it. In it's current state it is nothing short of awesome! What is needed now is to get more people actually looking at it... and if we can achieve that higher visibility and enthusiasm within the larger community, some of those new users will be developers.

Where the days of Delphi are fading, the story of Lazarus is still evolving. At this point I see it as a developer's project that has been "almost ready" for wider use for far too many years. It's true that 1.0 is just a number... but it is the one that will clearly signal our "critical mass" and hopefully be the trigger that will start moving this great tool into the programming mainstream... and the job market.

Thanks,

-Tom

Hi Florian,

Given it's relatively brief life, there are actually quite a few well known applications, including Skype, TOAD, Altium Designer, The Bat!,...etc that were built with Delphi:

http://delphi.wikia.com/wiki/Good_Quality_Applications_Built_With_Delphi

Sourceforge currently hosts 3,170 Delphi/Kylix related projects while Torry's and DSP also list thousands of Delphi related applications and packages.

In contrast, the lazarus-ccr has 56 packages at last count and Sourceforge shows 124 Lazarus and 432 Pascal projects. These small numbers provide an alarming perspective on the total Lazarus/FPC mindshare as Sourceforge also hosts 20,313 projects for Java, 14,645 for php, 13,987 for C#/C++, 5,208 for Python and even 2,030 just for the Eclipse ide.

> source level past the version 1.0 release > that will hopefully be shared by the FPC team. When did FPC break source level stuff not being a bug fix?

During this time last year, I was working on a large project that I intended to deploy to several thousand users within my company. The compiler/ide was working great, but I was also tracking the compiler svn to make sure I didn't get into "creeping features" trouble that might break the project and cause maintenance issues downstream. Sure enough, sometime during the Nov/Dec 2008 timeframe I got a compile error with the new version. I don't remember the details but found a small posting explaining that this was due to a permanent change in the scoping of inherited class variables "in this and future compiler versions". I will have to un-archive the project to provide the specifics, but I remember having to move some variables out of either private or protected and exposing them more globally to get my application to compile.

Regardless of the specifics, this was a change to the language within 2.x that broke my code at the source level. Changing the scope of a variable in post production would have also triggered a QA review and unwanted visibility for using "beta software"... so I decided to put the idea on hold and wait another year to see if Lazarus and FPC would come and become a unified, non-experimental tool that I could rely on for production coding. That year has passed and here we are.

With all that I've said over the last few days, I sincerely hope that you and the other developers have not interpreted any of my comments as criticism. The accomplishments of the compiler and IDE teams have been both inspiring and spectacular! But at this point, I think it's time to revisit some prevailing attitudes and make a few adjustments. In short, after over a decade of brilliant, creative work, it's time to stop pushing back on the idea of a 1.0 for Lazarus/FPC and to rally behind the goals of production stability for application builders and promoting a wider utilization for this outstanding tool while the window of opportunity for it still exists.

Thanks,

-Tom

Selon Thierry Andriamirado :

This is a great idea. If we could start User groups for example, structured and organized, it could help a lot. Maybe we should be organized as the Germans are, if I understand correctly. We could start a User Group in France, using the French Law for not-for-profit associations (Loi 1901).

Best regards,
Thierry

hmm...qt doesn't look very stable here. Can you point to some bug inside qtlcl which can be fixed , so orph ctls can work ok with qt ? eg. I see that TOvcSpinner is marked as "Crashing" ...

zeljko

This is a very americanish view :) If I'd ever looked for job opportunities, I'd never started to waste my time developing FPC (or any other OSS) :)

Sure enough, sometime during the Nov/Dec 2008 timeframe I got a compile error with the new version.

svn trunk is supposed to change, the changes for release version are always documented like here: http://wiki.freepascal.org/User_Changes_2.4.0

I don't remember the details but found a small posting explaining that this was due to a permanent change in the scoping of inherited class variables "in this and future compiler versions".

So this proves the point that a version number 1.0 wouldn't change anything :) It was FPC which broke things apparently being at version 2.2.x.

Florian Klaempfl wrote

So this proves the point that a version number 1.0 wouldn't change anything :) It was FPC which broke things apparently being at version 2.2.x.

You're right, but you can say fpc-1.0 is there, we cannot say lazarus-1.0 is there, that's a *big* diff (in the heads of many users - especially for users which comes from windows).
Personally, I don't care if lazarus is v0.002 currently because it suits my needs (I'm unix/linux user for all my life - so perfectly understand what version number means), but for many users "0.9.28.XX beta" doesn't look nice. I think that Paul's proposal for 1.0rc instead of 0.9.30 is a good idea. Even fpc (2.2.X, 2.4.X, 2.5X) have "children's pain" like http://bugs.freepascal.org/view.php?id=13722 etc...

zeljko

Hi!

Ok, it isn't ready then. With Lazarus IDE those problems don't come up.

Do those components rely on LCL bindings only, or does it need some custom binding code?
I mean, if LCL bindings work perfectly then Orpheus comps would start to work automatically?

Juha

I wish I knew! I really don't have time (or patience) to do more than test Orpheus against each widgetset for the stable release of Lazarus.

A couple observations are in order:

(1) Although once in a while I stumble across something in the Orpheus code that allows me to fix a problem (as in the expression "Even a blind sow occasionally finds an acorn"), in general improvements in Orpheus are due to improvements in the LCL and widgetsets. Or in some cases, as happened with 0.9.28, Orpheus gets worse over time through no fault of its own.

(2) It's apparent that the LCL and widgetset maintainers never test their changes against the CCR packages. The attitude seems to be that package maintainers will test daily against SVN and notify of any breaks. Sorry, can't do that.

Thanks.

-Phil

Yes, all of the non-Windows widgetsets should behave the same with Orpheus. If not, then there's probably some difference or issue in the widgetset. I say "non-Windows" because with win32 you have access to the full Win API, so there are some things that have to be simulated on non-Windows platforms.

It's a little odd that with Orpheus, Carbon seems to be the most stable of all the non-Windows widgetsets. I would not expect that since it's the newest of the 4.

Another package that reveals some widgetset differences is this one:

http://wiki.lazarus.freepascal.org/THtmlPort

With THtmlPort, Carbon is actually the most stable, even more stable than Windows. GTK2 doesn't run at all and I didn't even bother to test Qt. You're welcome to see if you can get it to work on Qt though.

I'm not sure how good a test the IDE is. That's kind of like saying, "Well, it worked in the lab, why doesn't work in the field?"

Thanks.

-Phil

Generally yes, but if the component uses win32 specific code like manipulating bitmap pixels directly or depends of specific win32 behavior (like radio buttons, edit maxlength) it will not work even if the widgetset is supposed to be working correctly.

Luiz

I second that - 1.0rc is the best solution.

2009/11/30 zeljko

2009/11/30 Phil Hess :

I'm not sure how good a test the IDE is. That's kind of like saying, "Well, it worked in the lab, why doesn't work in the field?"

The ide is probably the most used lcl application. Either way, this is a pretty unproductive discussion. What would take a minimal amount of your time would be to provide backtraces for all the crashes, which would at least give the lazarus devs somewhere to start.

Henry

My fast observations & qt fixes from last night:
1.I've fixed crash in getRegionType function (qt) which happens when someone create region with negative width or height.

2.Orpheus spinner control (and maybe others) crashed under qt because of MyMisc.ptInRegion() implementation.

function PtInRegion(RGN: HRGN; X, Y: Integer) : Boolean;
{$IFDEF MSWINDOWS}
begin
  Result := Windows.PtInRegion(RGN, X, Y);
{$ELSE}
var
  ARect : TRect;
  APt   : TPoint;
begin
  GetRgnBox(RGN, @ARect);
  APt.X := X;
  APt.Y := Y;
  Result := LclIntf.PtInRect(ARect, APt);
{$ENDIF}
end;

Why is it implemented in such way when we have

  Result := LCLIntf.ptInRegion(RGN, X, Y);

which doesn't crash orpheus controls under qt even with buggy(was until last night) TQtRegion constructor. Anyway, it does not crash anymore.

Yes, they do that, but orpheus isn't often used seem so.I'm using virtualtrees and it work w/o problems. From my observations (eg. ptInRegion() implementation), some things need to be changed in orpheus , not in widgetsets or LCL.

zeljko

I'll check it today.

I'm not sure how good a test the IDE is. That's kind of like saying, "Well, it worked in the lab, why doesn't work in the field?"

hm..I don't agree with works ok, our commercial apps works ok (all ported from K3/D7) + 3rd party components (FastReports, TMS grids etc...) and we don't have such problems.When you say that something works ok on Carbon, but crashes under win32 or gtk2 then it doesn't deserve to blame LCL or widgeset for crashes without exact explanation why it crashes.

zeljko

The point is that the audience is different. Simplifying version nummbers is great for marketing to a dumb user crowd.

But open source project are primarily the property aiming at the more able, not the lowest grade of users (except maybe high profile stuff like linux distributions).

That's why a lot commercial software aimed at bulk user have yearnumber versioning, and open source projects not. Even the major distributions (only Mandrake and SUSE, that rely on selling versions have)

IOW If you change to it, you make it easy to understand for a group that is not the target audience, which makes no sense.

Marco van de Voort wrote

That's why a lot commercial software aimed at bulk user have yearnumber versioning, and open source projects not. Even the major distributions (only Mandrake and SUSE, that rely on selling versions have)

Hrm.. Have Ubuntu or Year based style versioning would make it easier to convince faculty to use it for teaching puposes.

IOW If you change to it, you make it easy to understand for a group that is not the target audience, which makes no sense.

Who is choosing the target audience?

We must realize that a college teacher/software engineer willing to use Lazarus at her classes/work is an ally. Sometimes she is having a hard time convincing her superiors that it's Ok to use Lazarus because, you know, version numbers are irrelevant. For the seasoned free software user, it makes no difference -- but for faculty staff or employees, it does.

2009/12/1 Michael Joyner

About the version numbering, I already discussed that a long time ago, and it had no effect back then.

In my opinion the current requirements are impossible to achieve, just look at the Qt (yes Qt, not lcl-qt) list of open bugs, its huge and they are a private company with many full-time developers and are in version 4.5 and their quality is very high. It's impossible to have a software without bugs.

Whenever a bug is fixed another is found, you can see Lazarus remains at almost constant 900 bug count. When a bug is fixed, more people use Lazarus and then they find new bugs. And also the easier to solve bugs are solved first, then you remain with harder bugs which take more time to solve. In my university we learn that 90% of the time of a project is necessary for the last 10% of the fixes.

But the proponents of the restrictive numbering do have a case that the gtk2 interface has an awful lot of bugs, which makes behavior between platforms inconsistent. You can't say that the change from gtk to gtk2 cause this, rather gtk was even much worse because of structural limits of gtk.

In the long run I expect that if gtk2 doesn't improve, then the Qt interface will improve beyond it and we will have a Lazarus 1.0 in 1 or 2 years with one of the two.

Florian Klaempfl wrote

As far as I understood, it's an axiom of the lazarus project to use the native widgetset ;)

Yes and no, we can use non-native widgets with lcl-qt, or futurely with lcl-fpgui.

Help me, please.

What is the purpose of a creating a 1.0 release:
A. Marketing, getting more people of the threshold to use Lazarus or
B. Forcing Lazarus developers to keep stable interfaces

Vincent

Vincent Snijders wrote

What is the purpose of a creating a 1.0 release: A. Marketing, getting more people of the threshold to use Lazarus

I started the thread due to option (a), so that is what I would like Lazarus to achieve.

Open Source software works different to commercial software, so there is normally no guarantee that stable interfaces will last. Also I would much rather have a design change (which might break the interfaces), than strictly keeping backward compatibility alive and having a nightmare of code to maintain years down the line. Plus, the development model of open source software is a lot more open, so you get much more warning of code breaking changes, so it is very easy to keep your code in a working state (and updated).

If you look at the released figures of Line of Code between Linux and various other "commercial" software, there is good reason why Linux line s of code count is by a margin of millions less than others. And it's not due to lack of features, but rather a cleaner design and more maintainable code.

Regards,
- Graeme -

Simple: the people doing the work decide.

(or of versioning policy in general)

A. Marketing, getting more people of the threshold to use Lazarus or B. Forcing Lazarus developers to keep stable interfaces

C. define ready as when developers would consider it ready, not as an marketing instrument.

Nothing stops the proponents from starting a good campaign advertising Lazarus as fit for purpose, and that would have way more impact then this bickering over the version number.

Yes. That's it.

B. Forcing Lazarus developers to keep stable interfaces

No. If you have 1.0 out and want to break an interface, release it as 2.0. No problem...

In a couple of years "Lazarus 7.5" looks a lot better than 0.9.54(beta).

Remember. Even a lot of dumb users can help because:
- They will attract more users and some of them might be not so dumb.
- Some of them will become less dumb.
- Some of them will will help testing, documenting and... ... some of them will become contributors.
- They will attract more contributors because it will make the project look more viable and highlight its strengths.

Paulo Costa

Good to know that PtInRegion is now part of LclIntf - it wasn't when I ported this and there's no way of knowing when new functions are added without monitoring closely every commit!

However, the current code works with other widgetsets. Do you know why it didn't work with Qt?

I'll look at this tonight.

Thanks for your investigation.

-Phil

Phil Hess wrote

However, the current code works with other widgetsets. Do you know why it didn't work with Qt?

Did you test Qt in Windows or Linux?

According to the code it seams that any non-win32 widgetset would fail to run in Windows because you use windows operating system ifdefs instead of LCLWin32 ifdef for the widgetset.

Using LCL-Qt in Windows doesn't make the handles become Windows handles, they are still Qt handles.

Good point, although if you recall the history of this port, it started with the only two widgetsets that worked back then: win32 and gtk1 - the others just came along for the ride. I'm not even sure that LCLWin32 was defined back when I started.

Does anyone use Qt on Windows though? That doesn't make sense to me. Why put another layer on top of Windows when win32 works quite well? And without any auxiliary libraries.

Nevertheless, the code probably needs to modernizing. Oh joy...

Thanks.

-Phil

Phil Hess wrote

Good point, although if you recall the history of this port, it started with the only two widgetsets that worked back then: win32 and gtk1 - the others just came along for the ride. I'm not even sure that LCLWin32 was defined back when I started.

I would bet they were already defined, they are extremely old.

Does anyone use Qt on Windows though? That doesn't make sense to me. Why put another layer on top of Windows when win32 works quite well? And without any auxiliary libraries.

Less work to port between LCL platforms. If you use LCL-Qt in all platforms your port effort between them is minimal (if necessary), both because you are using the same LCL-Qt codebase instead of multiple widgetset codes with various states of supported components and because Qt is not a native toolkit, it just looks native but has custom painting which helps it be very consistent across platforms.

I see that GTK/GTK2 doesn't appear to have PtInRegion implemented. That's probably why I didn't use it.

In some cases the compatibility functions still need to call the Win API regardless of widgetset if running on Windows, but you're right, if a handle is passed, that should only be passed on to Win API if LCLwin32 is defined. I'll review all the compat. functions when I have some time.

Thanks.

-Phil

Because, Qt doesn't like negative width & height in QRegion constructor and because LCLIntf.GetRgnBox() (qt implementation) was marked with warning that implemenation maybe sucks (now it's fixed also).
As Felipe already mentioned, there's too much wrong ifdefs, qt is pretty stable and it must work if you change code to be more LCL-ish.

zeljko

Phil Hess wrote

I see that GTK/GTK2 doesn't appear to have PtInRegion implemented. That's probably why I didn't use it.

So the best thing would be that you try to implement it :)

Dears all ,

In the following pages and the others some useful information may be found about software development and bugs :

http://en.wikipedia.org/wiki/Category:Programming_bugs http://en.wikipedia.org/wiki/Category:Software_anomalies http://en.wikipedia.org/wiki/Category:Computer_errors

http://en.wikipedia.org/wiki/Category:Maturity_models http://en.wikipedia.org/wiki/Capability_Maturity_Model

http://en.wikipedia.org/wiki/Category:Software_project_management http://en.wikipedia.org/wiki/Software_Peter_principle http://en.wikipedia.org/wiki/No_Silver_Bullet
http://en.wikipedia.org/wiki/Software_rot
http://en.wikipedia.org/wiki/Software_brittleness
http://en.wikipedia.org/wiki/Lehman%27s_laws_of_software_evolution http://en.wikipedia.org/wiki/Software_entropy
http://en.wikipedia.org/wiki/Software_quality
http://en.wikipedia.org/wiki/Computer_bug

Unfortunately , there is a concept < law of conservation of bugs > mentioned in the page

http://www.site.uottawa.ca:4321/oose/index.html#lawofconservationofbugs

and the another in page

http://en.wikipedia.org/wiki/Software_entropy
.

There is another law about relation between software size and number of bugs
but I could not find any proper reference about it which may be ( perhaps ) among papers about software metrics and software testing ( http://www.ece.cmu.edu/~koopman/des_s99/sw_testing/index.html ) .

As a result it may be said that it is impossible to produce a software without bugs when size exceeds a lower limit toward increase .

My opinion is that discussion about Lazarus version numbers is not converging to a solution .

My suggestions are as follows :

Move Lazarus Components Library into Free Pascal at the side of FCL . Renumber its version to Free Pascal Version .

Maintain Lazarus as only IDE , and use Free Pascal as compiler .

Remove Free Pascal from inside of Lazarus . It is physically unnecesary to keep it inside of Lazarus .
Instead of including Free Pascal into Lazarus , mention which Free Pascal lowest numbered version is able to compile it .

For the Free Pascal there are Language Reference Guide and Programmer?s Reference Guide .
These are related to documentation of respective Free Pascal version .

There is no ( with respect my knowledge ) a Free Pascal Language Design Specification .
My idea is that discussion should go on this Specification document . Free Pascal versions
will be implementation of this specification as much as possible .

In Lazarus wiki there are very good pages about which parts are implemented and which parts require further work ( To Do List ) . These works may be converted to a Lazarus Design Specicifation document and development may be pursued with respect to that document .

Assume that specifications are numbered as Version 1 . When Lazarus fully implements that specification its version will be at least the version of the specification . Without such specification version numbering will not be able to show any measurable entity .

When the following sites are studied one point may be noticed :

http://delphi.icm.edu.pl/
http://www.torry.net/

Nearly all of the presented sources contain information about which Delphi versions may compile the sources ( means that there is a very strong dependency of source syntax and sometimes semantics to Delphi version ) .

I think , later on , Lazarus and Free Pascal compilable sources will start to mention version dependency explicitly .

Now , it seems that most requested feature is to enlarge the Free Pascal and Lazarus but maintain exact backward compatibility . I consider such a possibility is an impossibility . My policy is to use a smallest possible subset of a language which this subset may not be changed over time or changes are so small that does not break my programs severely .

Thank you very much .

Mehmet Erol Sanliturk

Nice list. :)

Unfortunately , there is a concept < law of conservation of bugs > mentioned in the page http://www.site.uottawa.ca:4321/oose/index.html#lawofconservationofbugs

Well. What counts as bug?
The svn changes?

The FCL code and the LCL code is maintained by completely different people.

Maintain Lazarus as only IDE , and use Free Pascal as compiler .

Separating IDE, components and LCL would be possible (debian is going into this direction) and from marketing point of view an 1.0 IDE, some 1.0 components and a 0.9.28 LCL may sound better.
But:
- there are many developers asking for bigger bundles instead of smaller ones (see code typhoon and fppkg).
- In every release until now there were new features in the LCL that were supported in the IDE, so both had to be released in parallel. The next release will be no exception, because of resources and build modes.
- Using separate versions would increase confusion.

Remove Free Pascal from inside of Lazarus . It is physically unnecesary to keep it inside of Lazarus .

Free Pascal is only installed by the windows installer there. All other systems install Free Pascal as separate package at a separate location.

This topic should be discussed on the fpc-devel list.

True.
At the moment the bug tracker is used for this, which is not a good specification.

For example: eight years ago the specification for 1.0 would be something like this:
- half the debugger that we have now
- 30 controls on windows + linux with half the properties we have now
- some IDE features

In other words: Lazarus is already far beyond that. It would be possible using IFDEFs to create such a release.

I think this is different.
Delphians have no choice which version to use, they must live with the version they bought/can afford. For lazarus/free pascal components it makes no sense to support a five year old compiler or five year old lazarus.

Difficult.
Lazarus has to catch up with Delphi, with FPC, with several operating systems and with several widgetsets and with a few features of its own. The smallest stable subset is therefore very small - too small for many applications.

Mattias

Zeljko,

I'm not seeing the same problem with the Qt widgetset that you reported:

TApplication.HandleException Access violation
Stack trace:
$02345E7C
$0445EFB4
$00260568 TQTDEVICECONTEXT__QDRAWWINPANEL, line 1958 of qtobjects.pas $001C9574 TQTWIDGETSET__FRAME3D, line 1775 of qtwinapi.inc $000D6210 FRAME3D, line 222 of ./include/lclintf.inc $000EEA08 TCANVAS__FRAME3D, line 963 of ./include/canvas.inc $002A4CDC DRAWBUTTONFACE, line 984 of mymisc.pas $0028E954 TOVCSPINNER__SCDRAWNORMALBUTTON, line 1194 of ovcsc.pas $0028AD64 TOVCSPINNER__SCDRAWBUTTON, line 613 of ovcsc.pas $0028A2FC TOVCSPINNER__SCDOMOUSEUP, line 531 of ovcsc.pas $0029111C TOVCSPINNER__WMLBUTTONUP, line 1713 of ovcsc.pas $00011018
$0018D640 TCONTROL__WNDPROC, line 1593 of ./include/control.inc $00180C90 TWINCONTROL__WNDPROC, line 4920 of ./include/wincontrol.inc $00249D44 TQTWIDGET__DELIVERMESSAGE, line 3826 of qtwidgets.pas $00246548 TQTWIDGET__SLOTMOUSE, line 2413 of qtwidgets.pas $00245148 TQTWIDGET__EVENTFILTER, line 1819 of qtwidgets.pas

Could you test with 0.9.28.2? That's what I've got on my PowerPC Mac that I use for testing.

I'm running against Qt 4.5.2.

Thanks.

-Phil

Finally, one of the core Lazarus developer that agree with what I said!!

The 1.0 release is being pushed back more and more by new features (in my studies it was called "creeping requirements" and is the bane of all software projects). There never seems to be a feature freeze. And you agree too that Lazarus is far beyond the initial 1.0 release specification, so why then isn't yet?

I'm simply trying to help the Lazarus project, by preventing more and more bad press. Even if that means playing the "marketing game". Bad comments, bad press, FUD, etc.... they all scare developers away. I'm trying to do a good thing here, but it seems like all the core Lazarus developers have a mental block against anything I say. I simply don't get it! Why have a project that you don't want anybody else to use???

Regards,
- Graeme -

huh...0.9.28.2 ? no :) I'm using trunk all the time :), and haven't ppc but intel mac 10.4.XX. I'll do my best to test it (I have qt-4.5.1 on mac) There was some problems with qDrawWinPanel. Crash is fixed in 0.9.29 r 21876 http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/lcl/interfaces/qt/qtobjects.pas?root=lazarus&r1=21821&r2=21876 so again .... it works for me :). it is probably merged into 0.9.28.3.

zeljko

B makes A possible.

There is no point to releasing a 1.0 for publicity reasons if the publicity is going to end up being bad due to instability and code breakage. That would only make Lazarus/FPC a well publicized failure. Given that choice, I'd rather see the project continue to plod along in the obscure beta niche that it occupies now.

1.0 in a development tool means a production stable platform for application builders... B. If the 1.0 you release meets that requirement, you will have A... and probably fairly quickly. Delphi grew rapidly in the late 90's because developers liked RAD and felt confident that the tool was solid and their sources would continue to compile as they upgraded it. The company also didn't refer to it's customers as "users". They valued their developer base and a team was created to maintain the confidence and enthusiasm that the initial quality of the product inspired. When that relationship eventually faultered, so did the product and the company.

After 10 years of development, this project should have some of that same confidence and enthusiasm in it's developer base. At this point there's lots of enthusiasm and a production stable 1.0 would start building confidence. If there's no commitment to that goal, please don't release a 1.0, keep plodding along with the betas, have fun and don't worry about breaking "user" generated code that will frustrate anyone who tries to pick up and do anything serious with this toolchain. Next year we can always revisit this topic and see how well that strategy has worked by counting all the new Lazarus projects and apps along with the number of developers that have joined the project... or left it.

Thanks,

-Tom

Graeme Geldenhuys wrote

... I'm trying to do a good thing here, but it seems like all the core Lazarus developers have a mental block against anything I say. I simply don't get it! Why have a project that you don't want anybody else to use???

We don't have a mental block.

The idea of 1.0 rc1 was expressed before the 0.9.28 release. The proposal is the next:

For 1.0 rc1 we need to fix 1.0 win32 bugs. Maybe not all the bugs in the tracker with 1.0 target are really has 1.0 target. But at least we need to review all and decide about each of them.

For 1.0 rc2 we need to do the same but for the gtk2 widgetset. And here we need a help of community. We need to close all gtk1 bugs but we also need to check wether the bugs are present in our gtk2 interface. If they are present then first we need to change their widgetset to gtk2 and decide whether they are 1.0 bugs.

I think 1.0 rc3 will be the last rc release and to release it we need to review remain 1.0 IDE bugs.

This is my view of road to 1.0 and it can differ from ideas of other developers.

Best regards,
Paul Ishenin.

Why not both? If there was a stable version of Lazarus, when Borland thought to sell Delphi, would attract many Delphi developers. Delphi in 2011 will be on a Linux and Mac, and very rarely Delphi programmer will go to Lazarus. One of the main advantages of Lazarus would not have it!

If there is a stable form once a year, many companies will prefer to work with Lazarus. Will rarely find a company that gives money to produce software for clients through unstable (which they may be implied by the name beta) version of the software. Developers are in business. If Lazarus is not used by them, developers will use what they are working with companies! So many Delphi and Pascal programmers passed to Java, C + +, PHP, although they say they prefer Delphi. And companies will choose to buy a stable software instead of using unstable free! This also applies to Linux distributors. For example there was an openSUSE version, which was with Lazarus. Later versions had without it. Is there a Linux distribution, which includes in packages Lazarus? Why? Maybe because after so many years is still in beta? And most of the components makers will start making versions of Lazarus. This will help in Lazarus development.

Why use technology other than Object Pascal and not binding on Lazarus. As QT and gtk2! Looking for more developers to gtk2?!? WHY??? Can you create a stable version without gtk2 or QT??? If the development of gtk2 QT stops what will happen - will stop Lazarus?? Or will you keep both??? What a strange idea? So I will make programs of Pascal, but the aim should be to learn and gtk2 or QT, which is not clear whether they will continue to cooperate. What if the development of some of them take in another direction and become too inefficient to keep up with Lazarus? And what "advertising" - gtk2, QT or Lazarus? Or follow extremely erroneous policy of Borland to be bound by the technology of Microsoft? You know what happend after that. Why many developers prefer the Delphi 7 instead of Delphi .net? The only commitment must be with FPC! If there is something good in QT or gtk2 - get the idea. Or add them as components. In the next STABLE VERSIONS OF LAZARUS!

As far as I remember, one of the main objectives of Lazarus was to be free and cross-platform alternative to Delphi! Delphi was only for Windows! Now you says that there is little emphasis on the most popular OS!!! And no matter how uncomfortable about Linux community, this event still is and will be very long time! And why Windows is the most common? Because it is the most stable? No. Best! No! Free? No. Because Microsoft has one of the best marketing strategies! And is oriented towards consumers. And when people who have a little experience in this area offer something better to hear them. Because each product is aimed to users. Developers comes from user. Not vice versa! No users - not developers, not programmers - no Lazarus (after time).

Therefore, if you want Lazarus to have any chance against Delphi urgent need to release a stable version by the end of the year! And the next stable versions have each year to attract at least some of the companies and should not be delayed further development of Lazarus. Otherwise, time will come after the new technology will begin to deploy it, will pass the technology will appear new, however it will deploy and will never have a stable version! The goal is to have a stable version and to know approximately when will be the next! So in most major open source projects. Eg Linux distributions, Apache, Open Office ... I am sure that if you do not waste time to use Qt, gtk2 and removed many of unstable components Lazarus will be able quickly to run a stable version! Perhaps with fewer components, but it will have.

----------------------------------------------------------------- ?????? ??????? ?? ? ???? ??????! 50 ??. ???????????? ????? ?? bwin http://adserver.itsfogo.com/click.aspx?zoneid=71276

Rigel Rig wrote

Delphi in 2011 will be on a Linux and Mac, and very rarely Delphi programmer will go to Lazarus.

I very much agree! Lazarus v1.0 non-beta <wink> must be out before Delphi has cross-platform support. The advantage of Lazarus over Delphi will seriously diminish after that.

Regards,
- Graeme -

Graeme Geldenhuys wrote

comments, bad press, FUD, etc.... they all scare developers away. I'm trying to do a good thing here, but it seems like all the core Lazarus

you must mean some or most, not all

developers have a mental block against anything I say.

Maybe because of the tone of voice.

Vincent

Does that mean, we should stop fixing bugs, because you only get more?

Vincnt

Vincent Snijders wrote

Maybe because of the tone of voice.

Or my bad English. :-/

Regards,
- Graeme -

You can not do v.1 because constantly adding new things! Should be stopped at a certain stable level, to remove volatile components and to release a stable version.

Rigel

----------------------------------------------------------------- ????? ???????? ?????? ?? Vesti.bg!
http://www.vesti.bg

Rigel Rig wrote

Why not both? If there was a stable version of Lazarus, when Borland thought to sell Delphi, would attract many Delphi developers.

At that time we already saw an increase of ppl. The 0.9 version didn't scare them.
What I read in this thread is that Borland had no problem releasing buggy/limited versions and ppl accept that. But what most seem to forget is that those are already spoiled by Delphi and wil have a more critic look at Lazarus when it reaches 1.0. If it feels buggy, we've lost.

Delphi in 2011 will be on a Linux and Mac, and very rarely Delphi programmer will go to Lazarus.

I doubt. Professionally, maybe. Hobby no, delphi is too expensive for that (seen from the reactions on last weekends fair I was).

One of the main advantages of Lazarus would not have it! If there is a stable form once a year, many companies will prefer to work with Lazarus.

Do you realize the effort it takes to maintain 2 releases ?

Is there a Linux distribution, which includes in packages Lazarus?

yes

Why?

Since someone took te battle to get it added to some distro

Maybe because after so many years is still in beta?

Have a look of the packages in your distro, there will be a lot which have not reaches 1.0 and they are still used.

And most of the components makers will start making versions of Lazarus.

Some of them already do. Keep in mind that not being 1.0 is not the real issue for component companies, but the fact that you need the source to be able to compile it into the IDe is.

This will help in Lazarus development.

I see no relation.

Why use technology other than Object Pascal and not binding on Lazarus. As QT and gtk2!

??

Looking for more developers to gtk2?!? WHY??? Can you create a stable version without gtk2 or QT??? If the development of gtk2 QT stops what will happen - will stop Lazarus??

No, since ppl still need some widgetset. So at that time the alternative will be available to lazarus too.

I'm lost, what point are you making ?

Therefore, if you want Lazarus to have any chance against Delphi urgent need to release a stable version by the end of the year!

We are not battling delphi, and there will be no 1.0 in 2009, maybe end of 2010.

marc

It's nice view, but it takes only bugfixes into account. 1.0 should be interface freeze also. So eg. docking should be added to 1.0 rc1.
It's easier (not easy but easier !) to fix bugs when we have clear vision of interface look.There's enough diff between 1.0rc1 .. 1.0rc3 to make interface changes if needed by those bugs.

zeljko

Exactly, imo, Rcs should be only fixing issues encountered in the previous RC.

Therefore we still need a 0.9.30 (or a 0.10.0) first.

Marc

I think , it is not necessary to have so much fear because my expectation is that Delphi will not be able to compile any Windows application directly to Linux or Mac natively . Using Mono is not a cross platform development and it is not a new service because it is already possible to use it .

You may remember Kylix .

When I assumed that I would compile a Delphi program with Open Kylix , my biggest surprise was the error message about

< missing unit : Windows > .

Then , my suggestion : Do NOT worry on this subject .

Actually , the most severe problem of Lazarus is its dependence on external libraries for user interface . A native widget set is the most urgent problem to obtain stability . My idea is the necessity of dropping GTK and Windows dependency and switching to a manageable ( by the Lazarus developers team ) widget set such as fpGUI as default when it is usable in all platforms . Another step may be : Take GTK and all of its dependents and supply to these to users with new names to prevent confusion with other installed GTK libraries , and pursue user interface on this adopted and maintained ( by the Lazarus developers team ) GTK fork .

I am using 2008 May ( trunk ) FPC 2.3.1 and corresponding Lazarus on Windows XP .

When I tried FPC 2.2.4 with its corresponding Lazarus , it gave me an empty form without any component . Then I reverted to back . Later on , I read similar complaints in some messages by other users .

Thank you very much .

Mehmet Erol Sanliturk

Vincent Snijders escribi?:

Does that mean, we should stop fixing bugs, because you only get more?

No, that mean that a feature freezee is needed to order to achieve an stable release. No new features accepted until all blocking BUGS were solved. Lazarus is stable enough and mature enought to had been released as stable many years later.

I think that if a widgeset has not a mantainer/core developer/master or whatever you would name he or she, then that widgeset would not be officialy supported and should not block any stable release. For example, the gtk1 widgeset, if no one is interested in develop and mataining it, mark all gtk bugs as 'suspended' or 'non-blocking'. If gtk2 hasn't a mantainer, well that only shows up that nobody has enought interest to develop it ... so related bugs should not be blocking.

Also there are a thing that shock me out completly: ?why should Lazarus mantain backward compatibility with Delphi?
First of all, Delphi is not suited to compile anyother platform outside of windows. Delphi programs tend to use windows api extensively, that will not work for lazarus! Also, all components used by a delphi program need to be ported before trying to convert a Delphi project, and usually this is impossible due to lack of access to source code. Also is proved that any non-trivial Delphi project will need some type of workarround to work properly with Lazarus, and if you make that changes, it will not compile anymore with Delphi ... that's crazy for Lazarus development!

Provide a good Delphi->Lazarus converter if you want and drop Delphi specific issues. Be free to work with the most efficient way you can. Break compatiblity whenever you need to create a better ide. Users will increase and, eventually some of them will contribute to Lazarus development...

Sorry for my very-big-email and my painfull-english-skills

You are right if we say 0.9.30 is last interface changes version before rc1. If we want to release 1.0 in 12 months, it's time to re-discuss roadmap and necessary things todo.

zeljko

I agree, it's a nice to have feature, but it makes Lazarus development very difficult (causing many limitations, regression bugs etc.) - which it should not do, for a project that calls itself "cross-platform". VCL is simply too tightly tied to Windows and the Win32 API, even Borland, CodeGear and Embarcadero are struggling with that issue.

specific issues. Be free to work with the most efficient way you can. Break compatiblity whenever you need to create a better ide.

Those compatibility goals will apparently not change in the Lazarus project. I have had many people tell me that. But all is not lost - there are two other projects that tackled that problem in a different manner: fpGUI Toolkit and MSEide&MSEgui. Those two took a fresh start, not hindered by Delphi compatibility or limitations.

Regards,
- Graeme -

Mehmet Erol Sanliturk wrote

I think , it is not necessary to have so much fear because my expectation is that Delphi will not be able to compile any Windows application directly to Linux or Mac natively.

Very true, and considering that Delphi still includes the 'Windows' unit in every from it creates, it is a lovely nightmare waiting to happen. But I'm still curious to see what they are going to come up with, and what GUI toolkits they are going to support?

Regards,
- Graeme -

No , it says that fixing bugs will generate new bugs . Also , please , consider the law about relation between size of software and number of bugs .

Such concepts make fixing bugs a natural situation and this is not a fault of the developers : It is caused by complexity of software and capability level of human beings . The goal is to reduce number of bugs as much as possible in a level that they do not make unbearable damages .

Personally , I am encountering this situation sometimes .

Assume in a program there a three parts :

.
.
.
Part One
.
.
.
Part Two
.
.
.
Part Three
.
.
.

I am getting a bug in Part Two . I do not know that the cause is in Part One . I am fixing Part Two .
Part Three is using Part Two . Fixing Part Two is generating a bug in Part Three . I am Fixing the Part Three .

Everything is going well .

Later on I realize that there is a bug in Part One . I am fixing it . This is causing a bug in Part Two .

I am fixing Part Two .

This is causing a bug in Part Three .
I am fixing Part Three .

This is continuing in chain like the above steps .

The pages listed in my previous message is to emphasize this point :

In a complex software ( which its total comprehension is beyond human capability ) occurrence of bugs is natural and fixing those bugs is an unavoidable step . Then the main point is to eliminate damaging bugs as much as possible .

Another fact is that no one of any complex software is able to stay fixed over time because all of them are used in a dynamic environment . Changes in this environment is generating a bunch of new bugs to fix .

Then life is going in that way .

If we stop fixing bugs , we encounter < software rot > situation .

Thank you very much .

Mehmet Erol Sanliturk

Yes , because many of the subscribers of this mailing list do not have their English as a mother language and not experts on use of English . This is easily understood from their English usage style .

For that reason , we should be forgiving as much as possible when encounter a HIGH tone of voice and attribute this not to an action toward us but an erroneous English usage unless a rude and unacceptable language is used .

Thank you very much .

Mehmet Erol Sanliturk

Be free to work with the most efficient way you can. Break compatiblity whenever you need to create a better ide. Users will increase and, eventually some of them will contribute to Lazarus development...

This is a dream proven wrong by reality. 10 years ago there were fpGUI/fpIDE and Lazarus: fpGUI/fpIDE dropped Delphi compatibility for a better design being dead after 2 years till Graeme revived it two (?) years ago. Lazarus is now years ahead of fpGUI (fpIDE still being dead) and I don't see people joining Graeme's efforts.

If it feels buggy, we've lost.

So I wrote with less features and no major bugs. Minor bugs have any software.

I doubt. Professionally, maybe. Hobby no, delphi is too expensive for that (seen from the reactions on last weekends fair I was).

The boss of the company will buy it! Professional programmers will work for the company. Developer of the open source project will also chose to focus the project, rather than testing of Lazarus. And then help in the development of Lazarus. In this case the opposite occurs.

Do you realize the effort it takes to maintain 2 releases ?

Yes! But I do not mean very example the version of Lazarus works under Windows XP SP3 (until recently the most common). 2011 version will work under all versions of Windows from XP upwards. Similarly with Linux: works under openSUSE (or another distribution). In the next more distributions. In each stable version of Lazarus is appropriate to maintain the versions already supported.

Which?

Yes, but they are stable. If they are not stable are not included in the package by default. Unstable software is new one. Not on 10 years.

Lazarus can it work without them? Why not make a stable version without them and put them in the next?

Are you looking for users, developers who make applications of Lazarus. Most will prefer Delphi, because they prefer to make its software on a stable basis.

Rigel

----------------------------------------------------------------- ????? ???????? ?????? ?? Vesti.bg!
http://www.vesti.bg

Already have a version of Lazarus, which makes some importing from Delphi. Why not release first stable version with this opportunity? The following does not necessarily have it. The aim is to enable easier transfer of applications and components from Delphi.

Rigel

----------------------------------------------------------------- ????? ???????? ?????? ?? Vesti.bg!
http://www.vesti.bg

At the current state this discussion mixes orthogonal things into one dimension.
A thing a programmer never should do ... :-)

The following may sound funny, so at least you have something to laugh ....

My still limited mind sees at least the following dimensions:

A) Delphi vs Lazarus Competition
B) Developer concerns about stability and stable interfaces (Bug Fixing / Reintroducing / Breaking Features)
C) Users wanting a fancy "Release Tag"
D) Hope of getting more Users / Contributers / Developers E) Discussing version numbering schemes
F) Companies/Users dreaming of stable, out of the box usable software, fullfilling their needs.

The points are only loosely related and can't be mapped to a one dimensional version number/release discussion.

No ones expectations, hopes and wishes can be fullfilled with a version number.

Give it up. :-) We will never get there -> http://www.ntg.nl/maps/05/34.pdf

Lazarus will never be stable for all widgestsets on all os's, as the are not stable by themselves.

I am a "company" user developing software since 20 years. (But thinking about a second start as a gardener)

Here my viewpoint/experience:

I am using FreeBSD for network appliance (e.g. some sort of firmware) programming.
I am perfectly happy using a patched svn fpc (using FreeBSD 8.0) somewere near the fpc fixes 2.4 branch
I am perfectly happy using tagged svn Lazarus "releases" - There IS no release for "my" OS ...
I had problems with Lazarus, and mattias fixed it for (small) bounty/donations directly and ultrafast (<24h)
(I got f*cked by MS and Delphi and other companies at support questions for years, and counting ... -> 24h - lol, next release lololol ... ) I do make money using lazarus and fpc and I am happy with it.

"A wise man should see a diamond gem if it lies before him on the ground - At least he can decide if he wants to use funny arranged carbon atoms - or not.
The dumb one does have at least the possibility
if you (developers) want it and you put a giant red wrap around it ("Lazarus 2009/Q3/Christmas Edition")

*) OSS Developers will not and should not be forced to anything. (because they are idealists) -> A), B), E)
*) "Dumb" users will need C) and of 100 blind users maybe you get 5 good ones and 1 idealist contributing -> D)
*) To make a point at A) you need a "killer application" (VLC, Lazarus itself, uTorrent, Skype ...) and state that its made with Lazarus/FPC and a target audience
*) Thinking about B) -> MS broke the socket, the TAPI and the QoS API between every Release of 2000, XP, and Vista, forcing us to rerelease our "Delphi made" VoIP Softphones at every new OS release .... (Reality is here)
I think they have one or to more developers then the Lazteam ? (We have a deployed userbase of > 30.000 mixed over these OS's) *) Even companies have the possibillity to contribute, if contribution is welcome, and a company can see the gem ...

If you want to satisfy all needs you would need to compromise on some things. (Which should be easy, as no one gives guarantees for anything)

If my litte daughter wants a new blue lolly in favour of the red one
- I usually give it to her if no one gets hurt. :-)

Who gets hurt at doing what ? Maybe you get new (core) developers with a fancy brand at a little chance (better than nothing ?)

But what does the fancy Delphi User say ? (Future Forecast) "Lazarus 1.0 is 2009 releases behind Delphi 2010 and they have just released the 3rd HOTFIX !!)

I have all Delphi releases from 5 to 2009 bought ... (I does not give me a warm feeling in my stomach ...)

For me I want to switch my firm completely from Delphi to FPC: Which is hard because our GUI Clients uses many Components which needs to be ported ...
So we tried to "book" Mattias for a week crash/internal course workshop in Jan.2010 - He agreed.
That will help us evaluate possibilities and make progress ...

Maybe the "5000 year old principle" of giving something to get something is still applyable ?

greets
Helmut

__________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version 4654 (20091202) __________

E-Mail wurde gepr?ft mit ESET NOD32 Antivirus.

http://www.eset.com

I am trying to push Lazarus/FPC onto the CIS instructors at my school. Trying to get them to use something our very small IT department can actually support w/o installing GIGS of useless junk on our terminal servers. And... having it be cross-platform between Win and Ubuntu helps alot, our CIS is mainly using W32, but enough of our students are dumping Vista and Win7 for Ubuntu that this would be a great selling point.

Having a "version 9.12" X-Mas or "version 10.0 " Jan edition would definitely help the PSYCHOLOGY in this regard.
Who knows how many, if any, of people learning to program with Laz at my institution will eventually become contribs? But, I do know that if one does not go fishing, one will not catch any fish.

I also have a "killer app" in mind (to me), but not ready to share yet. :)

In the Ubuntu repositories, it has been available for some time. See attached screenshot. Though, looking at the versions, none of them are the latest releases of FPC or Lazarus.

So a simple 'sudo apt-get install' command will do the job.

PS:
I have no idea who maintains those packages though. If anybody knows, please let that person know they are outdated. I'm using Ubuntu 9.04 (x86-64)

Regards,
- Graeme -

Michael Joyner ?? wrote

But, I do know that if one does not go fishing, one will not catch any fish.

I have two quotes which can easily be applied in this case to Lazarus. ;-)

"If you can't imitate him, don't copy him." -- Yogi Berra

"If you come to a fork in the road, take it." -- Yogi Berra

Yogi Berra is a wise man!

Regards,
- Graeme -

open suse includes lazarus and fpc on DVD here the Version of open suse 11.1

Version:

2.2.2-0

Erstellt am:

Di 29 Jul 2008 22:38:09 CEST

Installiert am:

Mo 31 Aug 2009 11:55:25 CEST

Paketgruppe:

Development/Languages

Lizenz:

GPL and modified LGPL

Installierte Gr??e:

168.0 M

Downloadgr??e:

0 B

Distribution:

Hersteller:

Paketersteller:

Peter Vreman ()

Architektur:

x86_64

Erzeugt auf:

Adresse (URL):

http://www.freepascal.org/

Medium-Nr.:

0

Autoren:

p, li { white-space: pre-wrap; }

Version:

0.9.26-0

Erstellt am:

Do 09 Okt 2008 23:08:11 CEST

Installiert am:

Mo 31 Aug 2009 12:04:49 CEST

Paketgruppe:

Development/Languages

Lizenz:

GPL and modified LGPL

Installierte Gr??e:

189.6 M

Downloadgr??e:

0 B

Distribution:

Hersteller:

Paketersteller:

Mattias Gaertner

Architektur:

x86_64

Erzeugt auf:

Adresse (URL):

http://www.lazarus.freepascal.org/

Medium-Nr.:

Autoren:

Zeljko,

This is what my Qt "Crashes" for TOvcSpinner is based on. And also on testing with the current stable version.

If this is fixed, that's great, but doesn't help the user who has 0.9.28.2.

Also, I want to make sure there aren't any Mac-specific or even endian issues here. I think most of the endian things were wrung out of LCL years ago, but you never know.

Thanks.

-Phil

I found him not on DVD openSUSE 11.0. But it is certainly on the website for all versions:

lazarus
devel:languages:pascal/openSUSE_11.2
Lazarus is a free and open source Rapid Application Development tool for the FreePascal compiler using the Lazarus component library - LCL.
[more]
1-Click Install
Manual Package Download
Go to OBS Project i586 lazarus-0.9.28.2-1.1.i586.rpm src lazarus-0.9.28.2-1.1.src.rpm
x86_64 lazarus-0.9.28.2-1.1.x86_64.rpm

Thanks!

I'm using Ubuntu 9.04

> (x86-64) > > Regards, >

- Graeme -

----------------------------------------------------------------- ????? ???????? ?????? ?? Vesti.bg!
http://www.vesti.bg

But it could be in 0.9.28.3 then.

Also, I want to make sure there aren't any Mac-specific or even endian issues here. I think most of the endian things were wrung out of LCL years ago, but you never know.

Haven't any spare time to test in on my mac...so probably tomorrow.

No hurry. I'm actually kind of excited now again about the prospect of actually getting Orpheus and THtmlPort packages running reliably on all 4 major widgetsets (win32, carbon, gtk2, qt). The improvements in GTK2 / LCL in SVN are big, I think. And if Qt has improved too in SVN...

Of course one question would be how soon to get all these LCL/widgetset improvements into a stable release. That's critical. Otherwise, I can't really say to Delphi users that these packages are useable since that would mean they would have to start out with building from SVN and become a Lazarus aficianado instead of a Lazarus user.

Thanks.

-Phil

Yes, please. Very well spoken.

Bart

The point is that the audience is different. Simplifying version nummbers is great for marketing to a dumb user crowd.

Lazarus gets more dumb users, more people ask for help. Less time for people to work on Lazarus and more people getting upset about Lazarus = Bad PR.

By the way the word beta in the title is for the widget set and not the lcl. Miss leading I know.

A newer version were nice. I vaguely remember some issues with 0.9.26 on openSUSE, that made me immediatly use the 0.9.27 trunk.

DoDi

so, why not just, for the first and initial start, remove the word "beta" from the version?? that would remove some portion of the stigma that folk are seeing and shying away from...

Paul Ishenin wrote

This is my view of road to 1.0 and it can differ from ideas of other developers.

sounds like that needs to be published somewhere so that other Lazarus developers can read it and their ideas can be discussed and added to the point of saying, "that's it, let's do it" and then moving on with the plan...

Hello,

I'm sorry but I must agree. We released first version as 0.1.0. Program worked without crashes but had a few minor bugs. We released other 16 versions of our program and now we true is, we should started as version 1.0 not 0.1.0. Our program is the best in Linux world but a lot of people thing that it must be unstable development version. It isn't. We did a mistake, we really should release it as 1.0 not 0.1.0.

It is logging program for hamradio operators developed in Lazarus/fpc (www.cqrlog.com). I think, Lazarus is very good and next version could be 1.0.

Thank you for great work on Lazarus and fpc!

Petr

Paulo Costa p??e v ?t 01. 12. 2009 v 14:20 +0000:

I do not agree with that.
If there is a stable version that is tested on a OS, no problems with installation and detailed installation instructions, all working examples, many questions will be lifted! It is not hard to do, if once a year. Lazarus is already very stable. For example, when installed Lazarus 0.9.26 on Windows XP I had no probem. Next stable beta had a problem with the installation! From the forum helped me decide. Under Linux stable beta version of the search old package and did not want to go with a new one. From the forum helped me decide. These problems should not have them in a stable version. Similarly a large open source projects. Eg openoffice.

Novice users can use the forum. Maillist is usually for advanced users. Therefore, questions will be very small. Not necessarily all developers to answer questions. May determine to 1-2 and turning. Or to make an indoor maillist for developers. Decision can always be found if one wants.

Stable version without problems in instalation and compilation on given components, with a clear exit approximate period of the next stable version will help attract more IT companies, which employ professional programmers. This will be a great advantage.

Rigel

---------

----------------------------------------------------------------- ????? ???????? ?????? ?? Vesti.bg!
http://www.vesti.bg