Discussion:
Release 1.0, part 2
(too old to reply)
Tom Lisjac
2009-11-29 04:14:52 UTC
Permalink
So what exactly is the Lazarus team afraid of in getting to v1.0?
Since we think it's not ready for 1.0.
Period.
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

--
Paul Ishenin
2009-11-29 05:52:56 UTC
Permalink
Post by Tom Lisjac
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.
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.

--
Hans-Peter Diettrich
2009-11-29 09:52:01 UTC
Permalink
Post by Paul Ishenin
- 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


--
Graeme Geldenhuys
2009-11-29 11:41:39 UTC
Permalink
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.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--
Graeme Geldenhuys
2009-11-29 10:35:29 UTC
Permalink
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 already at v4.3.x 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.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--
Florian Klaempfl
2009-11-29 10:38:44 UTC
Permalink
Post by Graeme Geldenhuys
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 already at v4.3.x and those issues in v4
release are long forgetten.
We switched all our simulation machines at work from kde to gnome.
Admitted, one reason is also that KDE4 looks terrible ugly :)

--
Juha Manninen
2009-11-29 11:36:06 UTC
Permalink
Post by Florian Klaempfl
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?
Post by Florian Klaempfl
From another message from Florian, about users looking at version
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

--
Graeme Geldenhuys
2009-11-29 14:04:16 UTC
Permalink
Post by 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 and at v0.9.x. It sure as hell
isn't as "new" as KDE v4.0 was, so the KDE issues will not apply to
Lazarus at all.
Post by Juha Manninen
 Usable for everyday work, no showstopper bugs and no missing features.
 Good for testing and experimenting, don't trust for serious work. Some
features still missing.
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!
Post by Juha Manninen
and then 1.0. Could happen quite soon. Early next year?
A agree! The next release should be 1.0 (release candidate)
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--
Thierry Andriamirado
2009-11-29 07:55:33 UTC
Permalink
Post by Tom Lisjac
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.
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
--
Le Site de Thierry : http://thierry.andriamirado.netsika.net [NEW]
Thierry sur Facebook : http://www.facebook.com/thierry.andriamirado
Le Twitter de Thierry : http://twitter.com/tandriamirado


--
t***@free.fr
2009-11-30 05:41:42 UTC
Permalink
Post by Thierry Andriamirado
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
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


--
Vincent Snijders
2009-11-29 07:59:40 UTC
Permalink
Post by Tom Lisjac
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.
Calling Lazarus 0.9.30 Lazarus 1.0 won't fix that problem.

Vincent

--
Martin
2009-11-29 08:28:31 UTC
Permalink
Post by Tom Lisjac
So what exactly is the Lazarus team afraid of in getting to v1.0?
Since we think it's not ready for 1.0.
Period.
...
Post by Tom Lisjac
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.
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.
Post by Tom Lisjac
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
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

--
Samuel Herzog
2009-11-29 09:05:33 UTC
Permalink
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 <***@gmail.com> schrieb am So, 29.11.2009:

Von: Tom Lisjac <***@gmail.com>
Betreff: [Lazarus] Release 1.0, part 2
An: ***@lists.lazarus.freepascal.org
Datum: Sonntag, 29. November 2009, 5:14
So what exactly is the Lazarus team afraid of in getting to v1.0?
Since we think it's not ready for 1.0.
Period.
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

--
_______________________________________________
Lazarus mailing list
***@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


__________________________________________________
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
http://mail.yahoo.com
Vincent Snijders
2009-11-29 18:19:54 UTC
Permalink
Post by Samuel Herzog
A) bugs without a simple test-project to reproduce the problem should be
moved to next version.
Which reports do you have in mind?
Post by Samuel Herzog
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.
Post by Samuel Herzog
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

--
Florian Klaempfl
2009-11-29 09:12:07 UTC
Permalink
Post by Tom Lisjac
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.
Post by Tom Lisjac
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?
Post by Tom Lisjac
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 ;)

--
Graeme Geldenhuys
2009-11-29 11:29:23 UTC
Permalink
Post by Florian Klaempfl
Post by Tom Lisjac
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 ;)
That would be sneaky, but clever! :-)
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--
Vincent Snijders
2009-11-29 13:05:41 UTC
Permalink
Post by Florian Klaempfl
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

--
Tom Lisjac
2009-11-30 05:15:18 UTC
Permalink
Hi Florian,

On Sun, Nov 29, 2009 at 2:12 AM, Florian Klaempfl
Post by Florian Klaempfl
Post by Tom Lisjac
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.
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.
Post by Florian Klaempfl
Post by Tom Lisjac
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 together at 1.0 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

--
Florian Klaempfl
2009-11-30 08:33:38 UTC
Permalink
Post by Tom Lisjac
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.
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) :)
Post by Tom Lisjac
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
Post by Tom Lisjac
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.


--
zeljko
2009-11-30 08:55:15 UTC
Permalink
Post by Florian Klaempfl
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

--
Alexsander Rosa
2009-11-30 19:30:03 UTC
Permalink
I second that - 1.0rc is the best solution.
Post by zeljko
Post by Florian Klaempfl
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
--
Atenciosamente,
Alexsander da Rosa
Linux User #113925

"Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude."
-- Barry Goldwater
zeljko
2009-11-29 09:20:16 UTC
Permalink
Post by Tom Lisjac
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.
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

--
Graeme Geldenhuys
2009-11-29 13:36:21 UTC
Permalink
Post by 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.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--
zeljko
2009-11-29 13:55:07 UTC
Permalink
Post by Graeme Geldenhuys
Post by 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.
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

--
Graeme Geldenhuys
2009-11-29 14:21:13 UTC
Permalink
Post by zeljko
You misunderstood my point.
My apologies then. :)
Post by zeljko
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.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--
zeljko
2009-11-29 15:09:22 UTC
Permalink
Post by Graeme Geldenhuys
Post by zeljko
You misunderstood my point.
My apologies then. :)
Post by zeljko
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.
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

--
Michael Joyner ᏩᏯ
2009-11-29 15:11:18 UTC
Permalink
Post by zeljko
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 :)
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.
--
LyX: http://www.lyx.org/ OpenOffice: http://www.openoffice.org/
Inkscape: http://www.inkscape.org/ Scribus: http://www.scribus.net/
GIMP: http://www.gimp.org/ PDF: http://www.pdfforge.org/
Graeme Geldenhuys
2009-11-29 17:48:52 UTC
Permalink
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.
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.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--
Graeme Geldenhuys
2009-11-29 17:43:17 UTC
Permalink
... 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
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--
Marco van de Voort
2009-11-29 09:28:05 UTC
Permalink
Post by Tom Lisjac
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.

--
Graeme Geldenhuys
2009-11-29 11:38:06 UTC
Permalink
Post by 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).
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--
Martin
2009-11-29 11:46:21 UTC
Permalink
Post by Graeme Geldenhuys
Post by 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.
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

--
Mattias Gaertner
2009-11-29 11:53:45 UTC
Permalink
On Sun, 29 Nov 2009 11:46:21 +0000
Post by Martin
Post by Graeme Geldenhuys
Post by 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.
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".
- 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)
And free updates for 1 year. :)

Mattias

--
Graeme Geldenhuys
2009-11-29 14:09:06 UTC
Permalink
Post by 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.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--
Vincent Snijders
2009-11-29 13:11:24 UTC
Permalink
Post by Graeme Geldenhuys
Post by 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).
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

--
Juha Manninen
2009-11-29 14:06:50 UTC
Permalink
Post by Vincent Snijders
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

--
Michael Joyner ᏩᏯ
2009-11-29 14:08:00 UTC
Permalink
Post by Juha Manninen
Post by Vincent Snijders
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.
Why not ship via getlaz off the wiki with both sets of bindings?
--
LyX: http://www.lyx.org/ OpenOffice: http://www.openoffice.org/
Inkscape: http://www.inkscape.org/ Scribus: http://www.scribus.net/
GIMP: http://www.gimp.org/ PDF: http://www.pdfforge.org/
Phil Hess
2009-11-29 18:49:25 UTC
Permalink
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
Post by Vincent Snijders
Post by Vincent Snijders
As Florian noted, Lazarus needs developers more than users. There
are
Post by Vincent Snijders
more gtk2 issues than win32 issues, so we need to focus our
martekting
Post by Vincent Snijders
(if any) more to the potential gtk2 developers (on linux) than on
the
Post by Vincent Snijders
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
--
_______________________________________________
Lazarus mailing list
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
Graeme Geldenhuys
2009-11-29 21:38:28 UTC
Permalink
Post by 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?
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--
Hans-Peter Diettrich
2009-11-29 21:11:18 UTC
Permalink
Post by Phil Hess
http://web.fastermac.net/~MacPgmr/OrphPort/OrphStatus.html#Status_Controls
Wow, great work :-)

DoDi


--
zeljko
2009-11-30 07:25:08 UTC
Permalink
Post by Phil Hess
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
http://web.fastermac.net/~MacPgmr/OrphPort/OrphStatus.html#Status_Controls
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

--
Phil Hess
2009-11-30 17:17:06 UTC
Permalink
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
Post by Phil Hess
Post by Phil Hess
Juha,
I test the 5 major widgetsets with several packages of custom
controls that
Post by Phil Hess
I've ported from Delphi and the Qt widgetset appears to be the
least
http://web.fastermac.net/~MacPgmr/OrphPort/OrphStatus.html#Status_Controls
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
--
_______________________________________________
Lazarus mailing list
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
zeljko
2009-12-01 07:27:03 UTC
Permalink
Post by Phil Hess
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.
(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.
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.
Post by Phil Hess
(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.
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

--
Phil Hess
2009-12-01 14:35:56 UTC
Permalink
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
Post by Phil Hess
Post by Phil Hess
I wish I knew! I really don't have time (or patience) to do more
than test
Post by Phil Hess
Orpheus against each widgetset for the stable release of Lazarus.
(1) Although once in a while I stumble across something in the
Orpheus code
Post by Phil Hess
that allows me to fix a problem (as in the expression "Even a blind
sow
Post by Phil Hess
occasionally finds an acorn"), in general improvements in Orpheus
are due
Post by Phil Hess
to improvements in the LCL and widgetsets. Or in some cases, as
happened
Post by Phil Hess
with 0.9.28, Orpheus gets worse over time through no fault of its
own.
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
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.
Post by Phil Hess
(2) It's apparent that the LCL and widgetset maintainers never test
their
Post by Phil Hess
changes against the CCR packages. The attitude seems to be that
package
Post by Phil Hess
maintainers will test daily against SVN and notify of any breaks.
Sorry,
Post by Phil Hess
can't do that.
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
--
_______________________________________________
Lazarus mailing list
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
Felipe Monteiro de Carvalho
2009-12-01 15:18:44 UTC
Permalink
Post by Phil Hess
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.
--
Felipe Monteiro de Carvalho

--
Phil Hess
2009-12-01 15:24:41 UTC
Permalink
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
Post by Phil Hess
Post by Phil Hess
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.
--
Felipe Monteiro de Carvalho
--
_______________________________________________
Lazarus mailing list
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
Felipe Monteiro de Carvalho
2009-12-01 15:34:30 UTC
Permalink
Post by Phil Hess
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.
Post by Phil Hess
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.
--
Felipe Monteiro de Carvalho

--
Phil Hess
2009-12-01 16:10:39 UTC
Permalink
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
Post by Phil Hess
Post by Phil Hess
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.
Post by Phil Hess
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.
--
Felipe Monteiro de Carvalho
--
_______________________________________________
Lazarus mailing list
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
zeljko
2009-12-01 17:33:28 UTC
Permalink
Post by Phil Hess
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 :)

--
zeljko
2009-12-01 16:22:45 UTC
Permalink
Post by Phil Hess
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?
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
Post by Phil Hess
I'll look at this tonight.
Thanks for your investigation.
-Phil
Post by Phil Hess
Post by Phil Hess
I wish I knew! I really don't have time (or patience) to do more
than test
Post by Phil Hess
Orpheus against each widgetset for the stable release of Lazarus.
(1) Although once in a while I stumble across something in the
Orpheus code
Post by Phil Hess
that allows me to fix a problem (as in the expression "Even a blind
sow
Post by Phil Hess
occasionally finds an acorn"), in general improvements in Orpheus
are due
Post by Phil Hess
to improvements in the LCL and widgetsets. Or in some cases, as
happened
Post by Phil Hess
with 0.9.28, Orpheus gets worse over time through no fault of its
own.
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
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.
Post by Phil Hess
(2) It's apparent that the LCL and widgetset maintainers never test
their
Post by Phil Hess
changes against the CCR packages. The attitude seems to be that
package
Post by Phil Hess
maintainers will test daily against SVN and notify of any breaks.
Sorry,
Post by Phil Hess
can't do that.
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
--
_______________________________________________
Lazarus mailing list
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
_______________________________________________
Lazarus mailing list
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
Juha Manninen
2009-11-30 13:36:55 UTC
Permalink
Post by Phil Hess
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
http://web.fastermac.net/~MacPgmr/OrphPort/OrphStatus.html#Status_Controls
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

--
Phil Hess
2009-11-30 17:25:58 UTC
Permalink
Post by Juha Manninen
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?
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

--
Henry Vermaak
2009-11-30 20:34:59 UTC
Permalink
Post by 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

--
zeljko
2009-12-01 07:31:47 UTC
Permalink
Post by Phil Hess
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.
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'll check it today.
Post by 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?"
hm..I don't agree with you at all.IDE 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

--
Luiz Americo Pereira Camara
2009-11-30 18:47:11 UTC
Permalink
Post by Juha Manninen
Post by Phil Hess
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
http://web.fastermac.net/~MacPgmr/OrphPort/OrphStatus.html#Status_Controls
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?
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

--
Michael Fuchs
2009-11-29 14:13:43 UTC
Permalink
Post by Vincent Snijders
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


--
Michael Joyner ᏩᏯ
2009-11-29 14:16:33 UTC
Permalink
Post by Michael Fuchs
Post by Vincent Snijders
As Florian noted, Lazarus needs developers more than users. There are
More users will also attract more developers.
"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!
--
LyX: http://www.lyx.org/ OpenOffice: http://www.openoffice.org/
Inkscape: http://www.inkscape.org/ Scribus: http://www.scribus.net/
GIMP: http://www.gimp.org/ PDF: http://www.pdfforge.org/
zeljko
2009-11-29 14:19:04 UTC
Permalink
Post by Michael Fuchs
Post by Vincent Snijders
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.
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 ? :)

--
Michael Joyner ᏩᏯ
2009-11-29 14:22:28 UTC
Permalink
Post by zeljko
Post by Michael Fuchs
Post by Vincent Snijders
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.
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 ? :)
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?
--
LyX: http://www.lyx.org/ OpenOffice: http://www.openoffice.org/
Inkscape: http://www.inkscape.org/ Scribus: http://www.scribus.net/
GIMP: http://www.gimp.org/ PDF: http://www.pdfforge.org/
zeljko
2009-11-29 15:10:29 UTC
Permalink
Post by Michael Joyner ᏩᏯ
Post by zeljko
Post by Michael Fuchs
Post by Vincent Snijders
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.
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 ? :)
What do you think the ratio is now? 100:1 1000:1 ?
Well, ratio is pretty high for ide, win32, some smaller for carbon,qt, but for
gtk2 there's no ratio :)
Post by Michael Joyner ᏩᏯ
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

--
Aleksa Todorovic
2009-11-29 15:10:23 UTC
Permalink
Post by zeljko
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 ;-)

--
Graeme Geldenhuys
2009-11-29 14:25:26 UTC
Permalink
Post by 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.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--
Graeme Geldenhuys
2009-11-29 14:14:24 UTC
Permalink
Post by 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.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--
Florian Klaempfl
2009-11-29 14:47:31 UTC
Permalink
Post by Graeme Geldenhuys
Post by 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.
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.

--
Vincent Snijders
2009-11-29 15:12:20 UTC
Permalink
Post by Graeme Geldenhuys
Post by 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.
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

--
Graeme Geldenhuys
2009-11-29 18:05:28 UTC
Permalink
Post by 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. ;-)
Post by Vincent Snijders
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.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--
Florian Klaempfl
2009-11-29 18:09:05 UTC
Permalink
Post by Graeme Geldenhuys
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.

--
Graeme Geldenhuys
2009-11-29 18:21:19 UTC
Permalink
Post by 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.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--
Florian Klaempfl
2009-11-29 19:03:11 UTC
Permalink
Post by Graeme Geldenhuys
Post by 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.
Guess why so many people work on Lazars/LCL ;)?
Post by Graeme Geldenhuys
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 :)?

--
Graeme Geldenhuys
2009-11-29 19:27:42 UTC
Permalink
Post by 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.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--
Hans-Peter Diettrich
2009-11-29 21:19:47 UTC
Permalink
Post by Florian Klaempfl
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


--
Hans-Peter Diettrich
2009-11-29 20:53:56 UTC
Permalink
Post by Florian Klaempfl
Post by Graeme Geldenhuys
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 ;)
...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


--
Felipe Monteiro de Carvalho
2009-12-01 11:29:30 UTC
Permalink
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.

On Sun, Nov t9, 2009 at 4:09 PM, Florian Klaempfl
Post by Florian Klaempfl
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.
--
Felipe Monteiro de Carvalho

--
Juha Manninen
2009-11-29 18:50:33 UTC
Permalink
Post by Graeme Geldenhuys
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.
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

--
Hans-Peter Diettrich
2009-11-29 17:56:43 UTC
Permalink
Post by Vincent Snijders
As Florian noted, Lazarus needs developers more than users.
Masturbation doesn't lead to propagation.

SCRN
DoDi


--
Marco van de Voort
2009-11-29 14:24:31 UTC
Permalink
Post by Graeme Geldenhuys
Post by 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.
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)

--
Marco van de Voort
2009-11-29 14:27:21 UTC
Permalink
Post by Marco van de Voort
- 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)
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 :-)

--
Hans-Peter Diettrich
2009-11-29 18:49:38 UTC
Permalink
Post by Marco van de Voort
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.
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


--
Michael Joyner ᏩᏯ
2009-11-29 14:28:40 UTC
Permalink
Post by Marco van de Voort
Post by Marco van de Voort
The serious users will consider the current restrained version policy as
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).
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.
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?
Post by Marco van de Voort
At least it will put this kind of nonsensical discussions to rest (which is
exactly why Patrick did this)
--
_______________________________________________
Lazarus mailing list
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
LyX: http://www.lyx.org/ OpenOffice: http://www.openoffice.org/
Inkscape: http://www.inkscape.org/ Scribus: http://www.scribus.net/
GIMP: http://www.gimp.org/ PDF: http://www.pdfforge.org/
Graeme Geldenhuys
2009-11-29 14:30:26 UTC
Permalink
Post by 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.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--
Michael Joyner ᏩᏯ
2009-11-29 14:40:50 UTC
Permalink
Post by Graeme Geldenhuys
Post by 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"
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.
--
LyX: http://www.lyx.org/ OpenOffice: http://www.openoffice.org/
Inkscape: http://www.inkscape.org/ Scribus: http://www.scribus.net/
GIMP: http://www.gimp.org/ PDF: http://www.pdfforge.org/
Aleksa Todorovic
2009-11-29 14:45:44 UTC
Permalink
Post by 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.

--
Marco van de Voort
2009-11-29 15:10:27 UTC
Permalink
Post by Michael Joyner ᏩᏯ
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.
The problem is that while this works for commercial projects (young/idiotic
users pay too), it doesn't work for open source projects.


--
Graeme Geldenhuys
2009-11-29 17:45:29 UTC
Permalink
Post by 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. ;-)
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--
Marco van de Voort
2009-12-01 10:26:08 UTC
Permalink
Post by Graeme Geldenhuys
Post by 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?
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.

--
Michael Joyner ᏩᏯ
2009-12-01 11:15:45 UTC
Permalink
Post by Marco van de Voort
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.
Post by Marco van de Voort
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?
Post by Marco van de Voort
--
_______________________________________________
Lazarus mailing list
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
LyX: http://www.lyx.org/ OpenOffice: http://www.openoffice.org/
Inkscape: http://www.inkscape.org/ Scribus: http://www.scribus.net/
GIMP: http://www.gimp.org/ PDF: http://www.pdfforge.org/


--
Alexsander Rosa
2009-12-01 11:26:12 UTC
Permalink
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.
Post by Michael Joyner ᏩᏯ
Post by Marco van de Voort
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
Post by Marco van de Voort
is
not the target audience, which makes no sense.
Who is choosing the target audience?
--
Atenciosamente,
Alexsander da Rosa
Linux User #113925

"Extremismo na defesa da liberdade não é defeito.
Moderação na busca por justiça não é virtude."
-- Barry Goldwater
Florian Klaempfl
2009-12-01 12:06:11 UTC
Permalink
Post by Michael Joyner ᏩᏯ
Post by Marco van de Voort
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.
Post by Marco van de Voort
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?
Simple: the people doing the work decide.

--
Vincent Snijders
2009-12-01 11:30:33 UTC
Permalink
Post by Marco van de Voort
Post by Graeme Geldenhuys
Post by 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?
The point is that the audience is different.
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

--
Graeme Geldenhuys
2009-12-01 12:03:19 UTC
Permalink
Post by Vincent Snijders
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 -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/


--
Marco van de Voort
2009-12-01 14:03:04 UTC
Permalink
Post by Vincent Snijders
Post by Marco van de Voort
Post by Graeme Geldenhuys
Why? Can you supply examples where simple versioning doesn't work in
open source projects?
The point is that the audience is different.
(or of versioning policy in general)
Post by Vincent Snijders
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.

--
Mehmet Erol Sanliturk
2009-12-01 20:58:30 UTC
Permalink
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





















--
Mattias Gaertner
2009-12-01 23:47:47 UTC
Permalink
On Tue, 01 Dec 2009 15:58:30 -0500
Post by Mehmet Erol Sanliturk
[...]
In the following pages and the others some useful information may be
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
Nice list. :)
Post by Mehmet Erol Sanliturk
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?
Post by Mehmet Erol Sanliturk
[...]
My opinion is that discussion about Lazarus version numbers is not
converging to a solution .
Move Lazarus Components Library into Free Pascal at the side of FCL .
Renumber its version to Free Pascal Version .
The FCL code and the LCL code is maintained by completely different
people.
Post by Mehmet Erol Sanliturk
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.
Post by Mehmet Erol Sanliturk
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.
Post by Mehmet Erol Sanliturk
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 .
This topic should be discussed on the fpc-devel list.
Post by Mehmet Erol Sanliturk
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 .
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.
Post by Mehmet Erol Sanliturk
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 .
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.
Post by Mehmet Erol Sanliturk
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 .
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

--

Paulo Costa
2009-12-01 14:20:57 UTC
Permalink
Post by Vincent Snijders
Help me, please.
A. Marketing, getting more people of the threshold to use Lazarus
Yes. That's it.
Post by Vincent Snijders
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

--
Hans-Peter Diettrich
2009-11-29 18:10:36 UTC
Permalink
Post by Marco van de Voort
- 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


--
Hans-Peter Diettrich
2009-11-29 17:39:46 UTC
Permalink
Post by Marco van de Voort
Post by Tom Lisjac
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.
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


--
Tom Lisjac
2009-11-29 23:14:45 UTC
Permalink
Post by Marco van de Voort
Post by Tom Lisjac
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.
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.
Post by Marco van de Voort
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.
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

--
Hans-Peter Diettrich
2009-11-29 09:32:35 UTC
Permalink
Post by Tom Lisjac
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?".
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


--
Graeme Geldenhuys
2009-11-29 10:36:35 UTC
Permalink
+1
I couldn't say it better myself. I'm glad to see that I'm not alone is
this thinking.
--
Regards,
- Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

--
Phil Hess
2009-12-01 16:20:12 UTC
Permalink
One of the points about Orpheus and other ported packages that I should probably make is that I've been in contact with Roman Kassebaum who maintains the Orpheus SourceForge projects and recently updated Orpheus for Unicode on Delphi 2009/2010. We've discussed possibly merging our codebases and also possibly trying to support DelphiX when/if it's released.

Fortunately since I maintained full Delphi compatibility in my port, that should make merging a bit easier. But I have to say that Roman was quite dismayed to learn that ports of many other packages that he uses were done as one-way ports to Lazarus, leaving Delphi compatibility behind. I could sense his interest in Lazarus quickly dissipating.

Roman's largest app is 2.3 million lines of code! I've been encouraging him to see how much of it he can get compiled with Lazarus, not so much to offer the app on other platforms, but as a way of further testing his code and expanding his world (in the U.S., engineers call this sort of effort a "skunkworks" project - historically lots of great original things come out of those). This would also be a good test of Lazarus. But if the other packages have changed significantly from their Delphi sources, then this might be difficult for him to do.

Thanks.

-Phil
Post by Phil Hess
Post by Phil Hess
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.
Post by Phil Hess
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.
--
Felipe Monteiro de Carvalho
--
_______________________________________________
Lazarus mailing list
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
--
Continue reading on narkive:
Loading...