Hi,

[...If you are easily offended to what I normally write, stop reading now...]

This is a continuation of my issues regarding the tab-type components. Lazarus team doesn't have enough manpower or resources to maintain duplicate components, chase a moving target which has dedicated developers and corporate money backing (Delphi), and still implement it's own unique features and be a competitive product (or a project Delphi developers would want to switch too).

This worrying issues is more visible lately than ever before. I'm starting to worry that Lazarus team is trying so hard to catch a moving target (delphi) and trying to implement many fancy features, that nothing actually ends up becoming stable or compatible for long. The old English saying holds true here: "Jack of all trades, but master of none". Look how long GTK1 took to become stable, and just when it did, Lazarus switched to LCL-GTK2, which is still marked as beta quality, has slower performance than GTK1 - so here we start all over again. Not to mention that GTK1 is now often broken too, so we can't even switch back if we wanted too. :-(

I have also been seeing more and more developers complaining that their patches are not even being looked at - the core team seem to be preoccupied with other stuff. Yes I know we are all busy and have REAL jobs, but then give more developers write access and delicate work to those developers. The "fixes" branch has been totally unusable for months because the form designer is broken (you cannot move/resize components) and nothing is being done regarding that - even though it has been reported numerous times. Then there is the common known fact that if you port a component or implement your own component, it's guaranteed to not work or compile one or two Lazarus "minor.minor" versions later (I explicitly mention minor.minor because Lazarus doesn't increase major or minor versions - not it my lifetime at least). So this means developers (which are also busy) must keep fixing old/existing work.

Then developers like myself, which try and promote FPC and Lazarus IDE in the corporate environment, hoping to catch a break and get some corporate sponsorship for Lazarus, is having an endless battle. I personally have run out of options in what to recommend to such new clients/developers. The supposed to be stable "fixes" branch is broken. The "trunk" branch is changing to much for corporate on independent developers to use in commercial environment because it's often broken after a svn update or features are partially implement (expected from a trunk branch I supposed). But that leaves no real stable working version of Lazarus!

I just feel there seems to be no clear direction or goal in the Lazarus project any more. What was the initial goal? To be Delphi compatible? But to which version: Delphi 7, Delphi 2005, Delphi 2007, Delphi 2009, Delphi 2010? Seriously you guys don't think you can keep up with a commercial funded company and still implement your own unique features. Lazarus needs it's own set of goals, not the goals of Embarcadero. And things are just going to get worse when Embarcadero releases their cross-platform compiler and toolkit in a year or so.

Also, what's the state of Mantis bug reports? The statistics pages in Mantis is hidden from general users (we don't have access). What is the ratio of bugs being fixed to bugs being reported? What is the turn-around time of submitting a patch to having it integrated in the mainstream code? What was the turn-around time 2 years ago - has the Lazarus project improved? What is the year-on-year or even month-on-month count of outstanding bugs? What is the count of reported bugs not even being acknowledged? Why is all this information hidden? Can we please get this information in the public eye so we can have a clear idea if Lazarus project is getting worse or better. After all, Lazarus is meant to be a "open" source project - I would have hoped that relates to the bug tracker status too, but it doesn't.

Make no mistake, after all I have said, I still think Lazarus IDE is a great developer tool. It's just a bit harder to find a stable working build. We have resorted to to maintaining our own stable branch in our company by cherry-picking select commits as we need them, but this requires even more time. I just feel Lazarus project overall has NO goal! And a project with no overall goal has no future. It's not living up to what it could be. As a community member I thought it my duty to raise all these concerns. I want Lazarus to live up to it's full potential - only thing is, nobody knows what that is. :-(

Graeme Geldenhuys wrote

The "fixes" branch has been totally unusable for months because the form designer is broken (you cannot move/resize components) and nothing is being done regarding that - even though it has been reported numerous times.

Somebody with time can tell me what revisions to merge and it will be done. Did you find the revision to be cherry picked?

Vincent

Also, what's the state of Mantis bug reports? The statistics pages in Mantis is hidden from general users (we don't have access).

It causes a lot of load: it takes several seconds to load it. I've attached a summary graph for lazarus.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: summary_graph_cumulative_bydate.php.png
Type: image/png
Size: 9961 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100305/1ef3fcd5/attachment.png>

IMVHO the tab-type components issue is a non-issue.

I don't see Lazarus currently trying to catch up with Delphi, actually my impression is it's continuously diverging from this faith, and following it's own way.

Yeah, again. GTK2 is in itself much slower than GTK1, and I don't see a noticeable difference between LCL and native-C or gtk++ anymore. I for one wouldn't certainly develop for gtk1; it's simply a dead platform.

I guess Mattias fired three or four of his clones - didn't you, too? ;-) -, maybe this is being felt.
It's a bit frustrating waiting for your patches to be analyzed, yes, but rushing svn access for unexperienced developers or people not completely familiar with the project's mindset isn't going to help, on the contrary it's a sure recipe for the "downward spiral".

The "fixes" branch has been totally unusable for months because the form designer is broken (you cannot move/resize components) and nothing is being done regarding that - even though it has been reported numerous times.

No word on it.

It's a problem of the approach taken for the LCL: the widgetsets are the real moving targets here.
Maybe if we completed the fpgui bridge.. ;-)
I'd say Lazarus is almost as stable as it has ever been, but maybe it's still not stable enough for corporate tastes.

(...)

Best regards,
Fl?vio

06.03.2010 1:06, Vincent Snijders ?????:

Somebody with time can tell me what revisions to merge and it will be done. Did you find the revision to be cherry picked?

Consider merging the following revisions:

maybe 21839
maybe 21860
maybe 21863
maybe 21866
21875
21904
21927
21933
21934
maybe 22255
maybe 22260
maybe 22341
maybe 22487
maybe 22503
maybe 22515
maybe 22627
maybe 22628
maybe 22775
maybe 22795
maybe 22815
maybe 22817
maybe 22819
maybe 22829
maybe 22830
maybe 22833
maybe 22835
maybe 22841
maybe 22843
maybe 22844
maybe 22845
22846
maybe 22852
maybe 23023
23063
23082
23099
23100
maybe 23103
23133
23143
23173
maybe 23174
maybe 23177
maybe 23178
maybe 23234

I hope it will solve form designer issues and improve it.

Welcome to the world of software, our job is chasing moving targets :( You'd probably find that many people here don't really care about people switching, but it will help the community and have more people that can contribute patches (or probably just file more bug reports).

You need to forget about gtk1, I'd be surprised if you can actually find the libs on your distro. It's deprecated. Regarding the slower/faster thing, it's like comparing apples with pears, seriously.

One comment I can make about this is that a different development model would probably work better (with managers pulling trees). Then you can ask the manager to pull and have more real code and patches discussed (perhaps on a separate list). I have a suspicion that manpower is the real issue here, sadly.

Also, re compatibility of components, this is just the reality of any evolving system (see for example kernel drivers, if you don't maintain them, you lose them).

If we have people actively requesting patches to be picked and perhaps more discussion of this on list. But it all takes time. Release often, I guess, but that's hard for such a small team.

The initial goal was delphi 7, but lazarus is a lot more advanced in certain respects (imho). It is true that fpc will probably be playing catch up with language features, but a lot if it is sugar. Can you be a bit more specific about features you think lazarus is chasing that it shouldn't?

Henry

Graeme Geldenhuys wrote

This is a continuation of my issues regarding the tab-type components. Lazarus team doesn't have enough manpower or resources to maintain duplicate components,

Like what? TNotebook and TPageControl? They have the same internal (in the interfaces) implementation, it's not really so much duplicated code.

This worrying issues is more visible lately than ever before. I'm starting to worry that Lazarus team is trying so hard to catch a moving target (delphi) and trying to implement many fancy features, that nothing actually ends up becoming stable or compatible for long.

I see absolutely no connection. It's not like we are developing Mono with Microsoft releasing incompatible stuff every 6 months.

The old English saying holds true here: "Jack of all trades, but master of none". Look how long GTK1 took to become stable, and just

Gtk 2 has been around at least since 2002, that's 8 years now. Try asking anywhere else about gtk1 and will react like you want pierced card support in your kernel.

It's not the target that moves fast, it's just gtk that is exceptionally hard to program + our gtk2 interface is very old and mixed with gtk1 and thus has a somewhat spaguetti code. Just compare with how fast the Qt interface improved by using a better toolkit and a newer cleaner code.

Maybe they should become developers.

Ideally we would need someone payed by a company using Lazarus to developed Lazarus full-time or at least part-time, like lot's of open source projects have. Until that happens we will always face a lot of floating in the development based on the free time of the current developers.

But that leaves no real stable working version of Lazarus!

Sure there is a stable release, the latest one is 0.9.28.2 you should use that one to present Lazarus.

Seriously you guys don't think you can keep up with a commercial funded company and still implement your own unique features.

Do you really think they implemented so much useful stuff since Delphi 7?

Lazarus needs it's own set of goals, not the goals of Embarcadero.

Why do you think we are following Embarcadero blindly? Are we encoding our strings in UTF-16 and having a IDE with 1 window? Not really ...

And things are just going to get worse when Embarcadero releases their cross-platform compiler and toolkit in a year or so.

I have my doubts if this will happen so early. Anyway, if they really turn around it can only be good for Lazarus. They will attract newer Pascal developers and then some of those might become Lazarus developers.

Graeme Geldenhuys wrote

Yes I know we are all busy and have REAL jobs, but then give more developers write access and delicate work to those developers.

We constangly give write access to more and more developers. Since the year begin Luiz and Juha got an ability to commit their changes directly. We are trying to notice active contributers who write ideal patches. I have 2 candidates in mind who can get the write access.

We need someone who wants to maintain it. Who is willing to?

I just feel there seems to be no clear direction or goal in the Lazarus project any more.

I did not feel this direction from the start of working on Lazarus and I don't feel it now. My current goal is to stabilize what we have and to release 1.0. Probably at this moment we have most of features that delphi 7 has. Some of them still require much work (like visual form inheritance).

Also, what's the state of Mantis bug reports? The statistics pages in Mantis is hidden from general users (we don't have access). What is the ratio of bugs being fixed to bugs being reported?

I remember I have a trial to reduce bug reports. Every day bug amount decreased and after a month or two we had -200 bugs less. But bug amount raises too fast once you switch back to active feature development and forget about the tracker. So I believe we have +300 new bugs after that trial :) Someone just need to live in the tracker and fix/reject/update bug status.

I just feel Lazarus project overall has NO goal! And a project with no overall goal has no future.

Please help to formulate the Lazarus project goal.

Best regards,
Paul Ishenin.

[...If you are easily offended to what I normally write, stop reading now...]

I'll add some more possibly offending opinions :-]

This worrying issues is more visible lately than ever before. I'm starting to worry that Lazarus team is trying so hard to catch a moving target (delphi) and trying to implement many fancy features, that nothing actually ends up becoming stable or compatible for long.

ACK :-(

I've never tried to implement a "serious" project with Lazarus, only working on test applications for docking and related issues. So I don't know about its overall usability.

ACK. I'd say that the LCL should be compatible with D7. Until D2007 IMO there was nothing essentially new in the VCL, and later Unicode versions are not widely accepted, including new features like extended RTTI. So I see Lazarus as the follower of D7, for all people that are not willing or capable of paying so much for the Embarcadero products.

I also feel an urgent need for some consolidated version of both the LCL and the IDE. My dream were a fully specified and documented version of both parts (at least of the LCL), to which only "certified" components are added. The envisaged certification of a component will include full documentation and examples for the verification of the implementation, on all supported platforms/widgetsets. Not all platforms must be supported by a component, or the known issues must be documented in a way that allows every *user* to determine the usability of the component on his target(s). Only "stable" features of the components should be officially supported, i.e. problematic features should be excluded until their implementation reaches an stable state.

The platform/widgetset interfaces should be documented, in a form that allows skilled users to contribute to the development. The problems with specific targets should be documented, in a form that allows to find target-independent solutions, if ever possible.

Perhaps we should have two branches, one for a common GUI for multiple targets, and one with dedicated components (and designers?) for distinct targets. The latter approach would use thin wrappers around the native components, so that the components themselves will not be subject to development IMO will be the most attractive
solution for commercial developers, stable and with a clear goal. With proper separation between GUI and worker code it should be easy to implement multiple widgetset specific GUIs for every application, if desired. It also would use the widgetset-specific layout management in the first place, with only stable extensions as conforming to the widgetset-specific procedures.

The IDE also should come in a stable version, possibly configurable for easy in/exclusion of unstable or unwanted features (auto formatting...). It should be extended to support multiple form designers (for dedicated widgetsets), multiple editor windows and docking. The IDE should become platform independent in so far, as it also should allow for multiple GUIs, or it can be considered a test case for the multi-target LCL version.

The stable LCL and IDE versions should be implemented bottom-up, by removing critical/unstable features in the first place, and by adding them later in an easily configurable way, with stable interfaces. This will allow to diagnose trouble sources and to delegate the solution of problems to the maintainer(s) of the spotted trouble source.

While there exist areas that deserve really detailed knowledge about multiple involved items, a detailed documentation should allow to
1) find inconsistencies in the existing implementation, and
2) allow other developers to contribute to, or maintain, specific areas (components...).

Finally Lazarus is an open source project, that should allow *everybody* to contribute, not only a number of gurus with secret knowledge. I'm willing to do some kind of QC, when it comes to the integration of components, patches and features into the stable versions. Perhaps we can start with Grames's GIT version, to decouple a stable version from the Lazarus releases...

DoDi

Paul Ishenin wrote

My current goal is to stabilize what we have and to release 1.0.

For a project goal, it would be hard to top that one for conciseness and clarity of purpose... well said, Paul!

Thanks,

-Tom

Looking at the graph, you can see that the ratio unresolved/resolved is actually becoming smaller, thus countering Graeme's arguments.

Graeme has tunnel-view problems. I say this because I recognize the symptoms, I have them myself often. It's a matter of the glass being half-empty or half-full. Graeme currently sees a half-empty glass.

Instead of focusing on the open problems, you should see how much problems are actually closed. This is clearly visible in the graph.

I have only one critique on Graeme: I understand his reasons for starting fpGUI, but in fact in starting it, he has made the "lazarus problem" he now complains about, worse.

If Graeme had spent his time and effort on helping out in the LCL, instead of fpGUI, then the graph would have looked quite differently, I'm quite sure.

I know Graeme for a good coder, and therefor I regret that he decided to start fpGUI (this does not mean I consider fpGUI in itself bad), because I think the LCL could have used someone like him.

It's all a matter of available resources.

My conclusion: Graeme, stop focusing on what goes wrong, instead see what goes right (the Graph Florian posted clearly shows that there is progress). And I do suggest you make the jump to the LCL.

Michael.

Nevertheless, there are plans to start commercial support for Lazarus.

The people who are currently playing with this idea will announce this when the time is right for them, but I mention this now so that you can see that Lazarus is taken serious, and that corporate sponsorship is not an illusion.

I myself have recently also contracted development for Lazarus/FPC. I would not do this if I didn't consider Lazarus a viable option.

Michael.

Hello,
I don't think we are in a downward spiral. The number of people constributing to this project is increasing. The core-team get's more patches than it can handle at the moment.

I think the lazarus project needs more people which are allowed to apply patches. As already said by other's, this year for example Juha got the that level and as I recently noticed, the "Converting area" has improved drastically! Thanks juha.

I usually go through the open tickets on saturday and see a lot of tickets with assigned patches. Some of them are really simple (e.g. change of a string) but they are untouched for weeks/months.

I also see an increasing number of open tickets which are periodically reported and already adressed in bugtracker. As a reporter I can only comment this, but not close or link with existing reports.

About next release 0.9.30: Please address a feature-freeze. Move attached tickets which belong to new features to next release.

0012355: [IDE] Combine the Find dialog and Find in Files dialog to a single dialog

0012294: [IDE] "About Lazarus" menu item should be in the Application menu under Mac OS X

0012828: [IDE] there could be room for separate builds.

0013930: [Patch] New IDE Add-On Package: Opened File List Browser

0015096: [IDE] Search Box preconfiguration - acknowledged.

0015133: [IDE] CHM help integration in IDE fails

Happy coding to all ;-)

Sam

__________________________________________________ Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verf?gt ?ber einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100306/238b1813/attachment.html>

Samuel Herzog wrote

I also see an increasing number of open tickets which are periodically reported and already adressed in bugtracker. As a reporter I can only comment this, but not close or link with existing reports.

Thanks. It will be seen when somebody goes through this list and acknowledges new issues.

This was a patch. We want to handle patches asap, at least before the next release.

0012294 <http://bugs.freepascal.org/view.php?id=12294>: *[IDE]* "About Lazarus" menu item should be in the Application menu under Mac OS X

This was/is a regression, afaik.

0012828 <http://bugs.freepascal.org/view.php?id=12828>: *[IDE]* there could be room for separate builds.

This feature was actively developed

0013930 <http://bugs.freepascal.org/view.php?id=13930>: *[Patch]* New IDE Add-On Package: Opened File List Browser

Patch, see above.

0015096 <http://bugs.freepascal.org/view.php?id=15096>: *[IDE]* Search Box preconfiguration - acknowledged.

This seems to be a regression, we try to fix regressions asap.

0015133 <http://bugs.freepascal.org/view.php?id=15133>: *[IDE]* CHM help integration in IDE fails

Better help was/is one of the main targets of 0.9.30. It may be postponed, if we want to speedup the release cycle.

Vincent

Hi!

I have had the same ideas, this kind of cleared my thoughts.

*** Now, the future goals for Lazarus: ***

1. Stabilize the current features for 1.0 release. Nothing special here, I think everyone agrees.

2. Make different GUI-specific target modes for Lazarus! Three such modes would be:

a) LCL-mode, the current (more or less Delphi compatible) interface. It would have only (light?) native widget bindings like Windows and MacOS and a future *nix widget binding (maybe based on fpGui). GTK* and QT bindings would be dropped.

b) QT-mode. This would implement QT-lib classes, methods, properties and signals in a thin, one-to-one mapping. The programs would not be Delphi compatible but they would be more like QT compatible, just using pascal instead of C++. This mode would compete with dynamic language bindings for QT.

c) GTK2-mode. Again, a thin mapping for GTK2. However, it could improve the weird programming model of GTK2 and be fully object oriented.

-------------

Those modes would implement different component sets and also different (or modified) form designer. It is not a small task and so the target is Lazarus 2.0 (many years...).

However, this is a design change that must be done because the current binding design sucks, at least for big GTK2 and QT libraries. This is a known issue but nobody has suggested how to fix it except for hacking more and adding more spaghetti code.

I just tried to find a bug in QT combobox which occurs in my machine but not in QT-bindings maintainer's machine. See Lazarus-QT list for reference. The fact is that much of the control's behavior is re-implemented in the binding code to make it behave just like LCL has it (separate droplist and edit controls re-implemented).
And QT-bindings are in good shape, GTK2 is worse... This design is brain-dead! Please ask any SW-design expert if you don't agree.

Note: I am not criticising the binding maintainers. They have done a good job given the brain-dead design goals.

My experience with programming is that a design problem should be fixed as early as possible. If you build more features on a flawed base then you need to make more ugly hacks and the problems accumulate. You must change the design, refactor, change some more and refactor again... It may feel like waste of time at that moment but it pays off at the end. It makes the difference between a high quality SW and an "almost good" or "so-so" quality SW.

Regards,
Juha Manninen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100306/ff4e50ab/attachment.html>

Dear all,

I'm not an active developer of Lazarus (hope to use it in the future) but how it is about the following idea:

step 1: addition of a priority index in the list of open issues, e.g. high = necessary for version 1.0
middle = necessary for later versions
low = just nice to have also
step 2: freeze the status of all developments with middle and low priority and concentrate all effort for the actions with high priority step 3: soon release a version 1.0

This is transparent and brings lazarus in an upward spiral imho.

Thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100306/da59243f/attachment-0001.html>

Hi!

If Graeme had spent his time and effort on helping out in the LCL, instead of fpGUI, then the graph would have looked quite differently, I'm quite sure.

If fpGui is used as a base for a light native *nix widgetset for LCL, and if the design change I suggested (in my reply to DoDi) gets implemented, then Lazarus will be revived (again). :-)
The current bindings will never be good, because of inherent problems. That doesn't kill Lazarus but it will remain as a freak show case, instead of becoming a popular high quality application.

I see the quality of Lazarus code is now strictly divided between core features which is high quality, and the widget bindings which has problems.

What do you think?

Regards,
Juha Manninen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100306/290a702d/attachment.html>

It is a matter of resources. The design of the LCL is good. It's goal is
- to look and feel native on all platforms.
- At the same time it also aims to be Delphi compatible as much as feasible: porting a basic Delphi app to lazarus should be a fairly easy task.

In my opinion, it succeeds in these goals. More and more so.

Keeping the various widget-sets up-to-date is just a task that requires work and resources. And yes, there will be bugs in the process.

The same will be true if you use fpGUI under the hood.

With the added downside that it's far from certain that you'll ever be able to make fpGUI look native on all platforms: one of its explicit design goals was to look exactly the same on all platforms, which is contrary to the Lazarus design goal.

It may require a huge effort and maybe even a complete rework to make fpGUI able to do this: an uncertain path, which may well mean more work.

This time is IMHO better spent on improving the existing widgetsets. All that is left to do there is bugfixing.

There is also simply a strategic reason for not using fpGUI:

The GTK/Qt toolkits are tried and tested, because they a) Are used widely since years.
b) have a larger development group.
compare this to fpGUI which is essentially a one-man show. If Graeme for some reason drops out (gods forbid): bye-bye fpGUI.

None of this means that I think fpGUI is bad (I have used it), or that making a LCL widgetset for fpGUI (next to the others) is in itself a bad idea. But basing Lazarus' LCL on it: No, thank you.

Michael.

Hi,

Lots of bugs, yes, because it is complicated.
But, that is not the main problem unfortunately. Those libraries have their own message notification mechanisms and mapping them to LCL messages causes weird errors occurring only with certain clib or x-org or window manager versions (or whatever). The QT combobox bug is a good example, it happens only in my machine and we still couldn't find the reason.

If you look at the binding code (especially GTK2) and debug it, you soon start to question the sanity of its design.
The choice between widget libs is a nice idea, but I think the goal is too ambitious.

Please tell me why is it important to connect to many different MULTI-PLATFORM libraries from a system that already implements multi-platform support itself (LCL/Lazarus)? That makes multi-multi-platform. :-) There already are native Windows and Mac OS libraries for LCL. The missing piece is a native *nix library. (actully dedicated *nix library, there is no native one on *nix systems.)

[...] But basing Lazarus' LCL on [fpGUI]: No, thank you.

Yes, I understand the reasoning. Actually the new *nix library doesn't need to map any existing library but implement a new one, tailored for LCL only. The code would be copied shamelessly from fpGui, Fox Toolkit and other high quality libraries. They are open source after all. I would bet that the whole *nix widgetset could be implemented with the same amount of code that BINDINGS for GTK2 require now.

When such library works well and can be used for production code, then you could improve GTK- and such mappings. They would be more like a curiosity, to show people that "Hey, BTW, you can even map to these libraries if you want".

--------

What did you think of my idea of different GUI-specific target modes for Lazarus 2.0? I myself feel it is an extremely cool idea!

Regards,
Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100306/2166b441/attachment.html>

This is in the nature of bugs. I spent lots of time trying to figure out why in my Delphi application, the toolbar works on Windows 95-98-NT-2000, but fails on XP, Vista and Windows 7 with their 'native' theme. I also don't find it. And that is on a single OS coming from a single manufacturer, who tries very hard to be backwards compatible.

I appreciate that some bugs are hard to find. But you are wrong if you think that rolling your own widgetset will guarantee you less bugs.

And the more people go in different directions, the less people will be inclined to fix bugs.

Because they are standard libraries on a unix system, and you are guaranteed to have a native look and feel. an LCL library will never make it as a standard library for a very simple reason: it is written in Pascal.

Why do you think KDE/OpenOffice/Adobe Acrobat/Firefox developers do a lot of effort to make GTK apps look like Qt apps and vice versa ? Because they think - and rightly so - that the whole system should have a uniform look and feel.

Try and sell a Mac application that does not adhere to the conventions on Mac. Good luck to the person trying...

There already are native Windows and Mac OS libraries for LCL. The missing piece is a native *nix library. (actully dedicated *nix library, there is no native one on *nix systems.)

GTK and Qt de facto ARE the native linux libraries.

By all means, go ahead. Prove me wrong...

When such library works well and can be used for production code, then you could improve GTK- and such mappings. They would be more like a curiosity, to show people that "Hey, BTW, you can even map to these libraries if you want".

Maybe, but GTK works well NOW for production code. Yes, there is the odd bug here and there.

But your - as yet - imaginary system does not even exist yet. So I prefer to work on GTK rather than wait for your system, and fix the odd bug here and there.

I bet that Graeme - given a clear notion of the differences between the 3 components - could have fixed the notebook issue that vexes him so much, in the time we spend arguing...

-------- What did you think of my idea of different GUI-specific target modes for Lazarus 2.0? I myself feel it is an extremely cool idea!

It is already possible to do so.

Have a look at the examples/designnonlcl directory in Lazarus. It was created specially for such things.

Michael.

With the added downside that it's far from certain that you'll ever be able to make fpGUI look native on all platforms: one of its explicit design goals was to look exactly the same on all platforms, which is contrary to the Lazarus design goal.

There is nothing bad about an widgetset with the same look&feel on all platforms. IMO only its *use* is restricted to specific applications.

ACK. An fpGUI with *native* look&feel IMO runs into the same problems as any other multi-platform widgetset - hardly feasable and maintainable with evolving platforms and widgetsets.

None of this means that I think fpGUI is bad (I have used it), or that making a LCL widgetset for fpGUI (next to the others) is in itself a bad idea. But basing Lazarus' LCL on it: No, thank you.

IMO just the IDE were a good example for an application that *should* look&feel almost the same on multiple platforms, to multi-platform application developers. The IDE developers should be freed from widgetset/component specific problems.

DoDi

Many task based/worker bee applications fit this description. Point of Sale, banking, telemarketing/CSR, etc. IMO, these kinds of applications are perfect candidates for a uniform widget set like fpGUI or even Java or Adobe Flex, etc. Not only does the look and feel NOT matter per platform with these kinds of applications, but it probably helps to make the users who have used it on one platform, comfortable with it on another platform like going from Windows to Linux or Mac. I'm sure Graeme will confirm this as I think his company's main product fits into the category somewhat.

This of course takes into account user expectation. Business applications seem to receive much more tolerance in terms of native look and feel as opposed to more mainstream types of products like Graphics editors, etc.

On Sat, 06 Mar 2010 18:32:45 +0100, Hans-Peter Diettrich wrote about Re: [Lazarus] Is Lazarus project in a downward spiral?:

Do you mean like the original Mozilla? ... :-)

IMO only its *use* is restricted to specific applications.

When I use a specific desktop platform, I want any and all applications to integrate with the other applications. This means I want native look-and-feel everywhere.

[snip]

IMO just the IDE were a good example for an application that *should* look&feel almost the same on multiple platforms, to multi-platform application developers. The IDE developers should be freed from widgetset/component specific problems.

Well, when I use Lazarus under GNOME, I want it to look like any other Gtk application. Consequently, the current practice of using the Gtk widgets is just fine.

Graeme Geldenhuys wrote

...

As a user, I'm very happy the Lazarus team is providing an alternative to Delphi, on top of FPC. I'm starting to use Lazarus to make small utilities, where the GUI needs are not so great. The compiler and basic GUI are quite good now, I'm just waiting for the famous Lazarus 1.0 now.

I would gladly contribute 100 EUR to BUY such a product and help maintain the product.

As a user, I don't understand the team structure, now how can I report a bug or contribute to its correction? This should be clearer, in my opinion.

We absolutely need a stable 1.xx version to promote Lazarus in the corporate world, plus a team dedicated to its maintenance, somehow.

In any case, thank you all for this,

Best regards,
Thierry

06.03.2010 22:38, Thierry Coq ?????:

As a user, I don't understand the team structure, now how can I report a bug or contribute to its correction? This should be clearer, in my opinion.

That's really strange. Have a look at
http://wiki.lazarus.freepascal.org/How_do_I_create_a_bug_report

Isn't it clear enough?

Note that also you can attach patches to bugreports.

It's a matter of the glass being half-empty or half-full. Graeme currently sees a half-empty glass.

I think the point of these threads is not how one views a partially filled glass... but that it remains in a partial state year after year with no clear goal to ever make it full.

A Lazarus 1.0 would go a long way toward filling the glass, but it's only half of the equation. To provide a stable and production ready platform, the compiler developers must also commit to respecting developer codebases and not breaking them with frivolous language changes... otherwise even with a Lazarus 1.0, the glass will remain clouded and one that large scale and commercial developers will continue to avoid drinking from.

Tools are judged by what they have built... not on their potential. Frustration sometimes bubbles up on these threads because the potential is there... and the potential is great! No other open source tool of comparable power exists for generating light, fast, self contained and cross-platform graphical apps with an equally fast and full featured IDE. Given the bloated or proprietary alternatives, Lazarus/FPC should be the tool of choice for creating world class apps for all the major OS environments... but as Graeme accurately pointed out, what we have today is still "potential".

The only thing that is stopping Lazarus/FPC from become a stable, mainstream production tool is attitudes... and I'm hoping threads like these will cause a change of focus across the core teams from feature development to "stabilize what we have and to release 1.0" as Paul Ishenin suggested yesterday.

Thanks,

-Tom

2010/3/6 Florian Klaempfl :

It causes a lot of load: it takes several seconds to load it. I've attached a summary graph for lazarus.

Thanks for the graph Florian. Is it possible to create static versions of the various statistic pages (I don't know what is available), say once per month?

With a static page, the server will not be taxed with extra work. Even if the static page is just a list of numbers, then we can great our own graphs using OpenOffice Spreadsheet.

See also http:/msg05182.html
;-)

Michael Van Canneyt wrote

Looking at the graph, you can see that the ratio unresolved/resolved is actually becoming smaller, thus countering Graeme's arguments.

Well Michael, very few have access to statistics. So the rest of use must simply guess what's going one. Based on my experience with the Lazarus project and what I have read in the mailing list, I made an assumption.

I am very glad to see that the "resolved" line has followed the "unresolved" trend, though the gap between the too seem to larger now that it used to be. But that is probably due to Lazarus becoming a more popular project with more new users reporting issues.

If Graeme had spent his time and effort on helping out in the LCL, instead of fpGUI, then the graph would have looked quite differently, I'm quite sure.

Michael, that would have been the logical choice, and something we have tried when we moved from Delphi/Kylix. Many off the issues we had was marked as "will not fix" in LCL (there is a wiki page listing a few). So even if I joined the LCL development team, there was no way I could change it in LCL. This is unacceptable for our type of application - hence I started work on fpGUI giving us no limits at all.

The last think you want to hear is 'you may not do this, you may not do that etc.', and then having to explain that to the boss. The boss simply answers by saying: I hired a development team to create custom written software for our company, what I want, I want to get. I don't want to hear problems, just fix it!

But this is getting off-topic, we are supposed to talk about the Lazarus project.

My conclusion: Graeme, stop focusing on what goes wrong, instead see what goes right (the Graph Florian posted clearly shows that there is progress). And I do suggest you make the jump to the LCL.

Like I mentioned before, only a select few have access to the graphs. Everybody else has to guess how the Lazarus project is progressing. I asked Florian and will ask you too. Is there a way to save some of those statistics pages as static pages for the general public to view. Maybe the static pages can be updated once per month?

Don't you think time should be spended in fixing bugs instead of writing statistics scripts :)?

Michael Van Canneyt wrote

b) have a larger development group. compare this to fpGUI which is essentially a one-man show. If Graeme for some reason drops out (gods forbid): bye-bye fpGUI.

Qt started as a two-man band, so there is hope for fpGUI. ;-)

None of this means that I think fpGUI is bad (I have used it), or that making a LCL widgetset for fpGUI (next to the others) is in itself a bad idea. But basing Lazarus' LCL on it: No, thank you.

I looked at the LCL-fpGUI widgetset last night. I was shocked at how much Windows-ism is in the common widgetset interface layer of LCL. GDIObject types, many other Win32 API types, WinAPI unit itself, and lots and lots more Windows specific calls etc must all somehow be re-implemented for each widgetsets backend that the LCL supports. Such Windows-ism in a cross-platform product simply cannot be good. It is amazing LCL got as far as it did with this Windows paradigm forced onto all widgetset backend implementers.

Michael Van Canneyt wrote

I appreciate that some bugs are hard to find. But you are wrong if you think that rolling your own widgetset will guarantee you less bugs.

Martin (MSEgui) and myself having first hand experience in this will definitely tell you that there are much less bugs (simply because the code is simpler), easier to fix bugs too. And to fix a bug it's in one location for all supported platforms (99% of the time).

But it has been discussed a million times before and not to be repeated here again. Lazarus wanted to take a different approach, by having a native look and feel and using native components where possible. I know this.

I just think that LCL took the wrong approach in there implementation. Forcing Windows-ism on every widgetset the LCL supports - hence complicating implementations a lot. Take a look at Qt? No Windows-ism in it's design, no Win32 API types in it's design etc., yet it succeeds in the native look and feel on all large platforms.

... and the functionality is less: just one example: Drag and Drop between explorer and file dialogs does not work in MSEgui, neither the context menu works, so one can not create folders, rename files etc. quickly, no W7 favorite folder list (which I really like) etc.

People want delphi compatibility.

Forcing Windows-ism on every widgetset the LCL supports - hence complicating implementations a lot. Take a look at Qt? No Windows-ism in it's design, no Win32 API types in it's design etc., yet it succeeds in the native look and feel on all large platforms.

Due to the emulation, it usually still looks strange.

Can you guys refrain from making this a LCL vs fpGUI discussion. That was not my intent. My reason for this thread was my concern for the Lazarus project only. I only use the Lazarus IDE, and even there I was seeing issues that concerned me. Patches going unnoticed for long periods, known serious bugs not being addressed etc.

Yes the IDE has improved tremendously (feature wise) in the last few months, but it hasn't stability issue probably
goes down to the LCL layer too (I'm just guessing here). Currently there is no stable version of Lazarus - this is my major concern.

As I mentioned, we currently maintain our own "stable" version of Lazarus IDE, but this should come standard with the Lazarus project. It should not be the job of the end-users to make there own stable versions of the IDE.

Lee Jenkins wrote

have used it on one platform, comfortable with it on another platform like going from Windows to Linux or Mac. ?I'm sure Graeme will confirm this as I think his company's main product fits into the category somewhat.

100% correct.

Most in-house or custom written projects do not conform to the OS standards in regards to look and feel. Not even mainstream applications adhere to this. MS-Office, Windows Media Player, Adobe Lightroom, Apple's Safari on Windows, Apple's Quicktime player or Windows, Apple's iTunes for Windows any Accounting package on any platform etc.

Everybody keeps hammering the native look and feel issue, yet it seems very unimportant to the end-user (Mac OS users excluded). And then I haven't even mentioned the biggest product of them all, Web Apps! They run on all platforms, yet their look is consistent across all platforms and doesn't adhere to a single OS's look and feel. Funny that, no end-user has problems with that either.

I really dislike non native windows programs, specially GTK ones. Dia is about the only one I tolerate.

Thanks Tom. I'm glad somebody else understands the issue. At this point I'm not even worrying about a 1.0 release. I'm just looking for a stable release - whatever version number that might be. And then having a development model where stability is held. End-users can then choose to use the stable version or the unstable version.

At least that will give me something to recommend and promote to potential FPC & Lazarus users.

Florian Klaempfl wrote

... and the functionality is less: just one example: Drag and Drop between explorer and file dialogs does not work in MSEgui,

I'm sure that will be a quick fix for Martin, it if was brought to his attention. To be honest, no matter what platform, I have never even consider the action of drag-drop into a File Open dialog. Yes I have done drag-drop into a application window, but never into a File Dialog window. It's just amazing how each person works differently. :)

neither the context menu works, so one can not create folders, rename files etc.

I always smile when I see such comments - I guess it's a matter of oppinion. What is a "file open dialog"? Maybe the name will give you a hint? Yes, to select a file to open. If you want to manage files or folders, then user Windows Explorer, Total Commander, Double Commander, Nautilus etc... That's what the file manager applications were designed for.

quickly, no W7 favorite folder list (which I really like) etc.

A handy feature yes, and something fpGUI will have in the next week. It's been on my todo list for long enough. :)

> I just think that LCL took the wrong approach in there implementation. People want delphi compatibility.

I'm not arguing that, I'm simply stating the widgetset "interfaces" design is not idea, and that has nothing to do with Delphi compatibility.

Either GTK1, GTK2, Qt, Cocoa, Carbon, fpGUI or KOL has the notion of a GDIObject type? So why is it in the widgetset "interfaces" that must be implemented in each of the LCL backends?
That's Windows-ism forced down on every developer wanting to implement a new LCL backend.

Marco van de Voort wrote

I really dislike non native windows programs, specially GTK ones. Dia is about the only one I tolerate.

Then I guess you hate the internet as well? :) Gmail, Facebook, Twiter, etc. all those little web apps that nobody uses an doesn't adhere to a single OS interface. Do you now see how ridiculous the "native look and feel" argument sounds? Just the above three web apps have probably over a billion users and nobody complains that it doesn't look like there favourite OS.

It can be added if there is a sponsor. ;-)
It is possible to add platform specific functionality, components and widgets. I don't make it my self because my needs are identical behaviour of MSEgui on Linux and Windows. You are free to add the wanted widgets yourself. BTW there is tguiapplication.registersyseventhandler() in order to hook into Windows and X11 messages.

> easier to fix bugs too. And to fix a bug it's in one > location for all supported platforms (99% of the time). >

I second that. I used VCL for the pre-predecessor (Windows only) and CLX for the predecessor of MSEgui as base and decided that the goal of creating a high quality and productive platform independent framework based on platform specific widget libraries is too difficult for me. But I am a one man show only, Lazarus has probably better possibilities.

Delphi compatibility and crossplatform and especially using external widgetsets is a contradiction I fear. It is maybe imaginable to design a dedicated architecture in order to abstract the differences of the widgetset. I don't think VCL was designed for that purpose.

Martin

When saving a file I often realize that I would
- overwrite an old one so I rename the old one
- or that I want to have it in a new folder
- I'd like to see the SCM status
- see modification date or whatever
- ...
Why should I waste time and change to a different program while I could do this in the file open/save dialog?

I looked at the LCL-fpGUI widgetset last night. I was shocked at how much Windows-ism is in the common widgetset interface layer of LCL.

Can you suggest another interface, that better fits the various widgetset APIs?

DoDi

BTW there is tguiapplication.registersyseventhandler() in order to hook into Windows and X11 messages.

The unreadable names (all lowercase) make it impossible to me to have any closer

Then the file dialogs must use the platform specific file managers. On Windows, the dialogs expose functionality of file explorer, on Linux that of the installed or preferred Nautilus, Konqueror or whatsoever. Please note that the dialogs shall *use* the managers, *not emulate* them. I'm not sure how this is feasable. It also would mean that eventual dialog customization differs for every platform.

DoDi

Interresting.
I changed my Pascal conding style three times in the last 25 years, the last time about 10 years ago. It seems for me the optimum of productivity and readability is reached.
I write all lowercase exactly because all lowercase has the best readability for me. With camelcase style a symbol breaks into sub-symbols for me which can't be recognised and processed as fast by my brain.

Martin

The downside to this is: there is also a lot less functionality. A simpler product is by definition easier to maintain.

As you will introduce more components, you'll also introduce more bugs, this is inevitable.

And as soon as someone says 'I want native look and feel', you're in for a lot of work, and again extra bugs, by nature different per platform - and you're in the same situation Lazarus is in now.

I 100% agree with the critique about windows-isms.

I would also have preferred the LCL to be a VCL 'without the windows calls'

I think the VCL does a pretty good job of abstracting out the Windows API. You can program it pretty much without knowing anything about the windows API (some corner cases aside, such as keyboard key names).

It has always pained me to see lazarus' LCL re-introducing the Windows API to such an extent.

If I was planning Lazarus' future (for clarity: I am not), I would lay out for the LCL:

- 1.0 as being what is there now, minus the blatant bugs. No features/components added any more.
(I'm pretty condifent Vincent agrees on this goal)

- 2.0: Get rid of the windows-isms.
Add a set of controls/features deemed necessary, such as an internet browser.

The IDE itself is another story, there you are more free.

The problematic point is: no-one likes to do bugfixing only.

Michael.

For you, yes. I agree with Hans-Peter Diettrich...

I write all lowercase exactly because all lowercase has the best readability for me. With camelcase style a symbol breaks into sub-symbols for me which can't be recognised and processed as fast by my brain.

I don't think that you can credit the lowercase letters for your increased productivity. It's simply 25 years of programming experience.

If I look at code I wrote 12 years ago, I now see all the things I did wrong;
and I used CamelCase all the time. So the point is not in the casing.

Michael.

On Sun, 7 Mar 2010 10:55:59 +0200, Graeme Geldenhuys wrote about Re: [Lazarus] Is Lazarus project in a downward spiral?:

[snip]

I find that a little difficult to believe. Just using Xfce under Linux, I can see differences in a single Web application if it is rendered with a Gecko-based browser or with a Webkit-based browser. Moreover, I prefer the Webkit rendering, as it looks more native (Gtk+) and less Mozilla-ish.

Perhaps my eyesight is worse than I thought and/or I am hallucinating.

Hi!
I've not posted here before, but I've been reading this list for about six months, and I've gotta weigh in on this one.

By way of introduction, I'm the Sr. Software Engineer/Team Lead for a major consumer electronics company in the US. We've been using C++ Builder for several years as our PC compiler of choice. It's allowed us to develop robust applications in very short time spans with very limited resources.

However, it is (of course) Windows only. Last June the word came down that the market was changing, something we all knew, and that Mac's were gaining a significant enough share of the consumer market to warrant our support. I was charged with finding development tools that would allow us to move our existing programs to the Mac in the quickest and most reliable fashion.

My initial impulse was Java, but there were lots of issues, the biggest one being a native look and feel on Windows. Most of our PC products involve communication over USB, and that gets problematic with Java as well - we really need native code compilation. Deployment was also an issue. Ditto for Python, and the other platforms we looked at. Then I stumbled across Lazarus/FPC.

Native compilation - check. Native look and feel - check. Similar object structure to our existing code base - check. After about a month of having the team play around with the tool, we decided to go forward. Our entire PC software suite ( ~60 applications) is being moved to Lazarus, with the first release scheduled for mid May, on a new (for us) device category. The rest will be rolled out as updates warrant - all new development is being done in Lazarus.

A colleague moved a rather complex software update tool from C++ Builder to Lazarus in 4 days - and we now have a Mac version as well. That, my friends, is nothing short of incredible.

Following this "downward spiral" discussion has led me to believe that perhaps the Lazarus community doesn't really understand what it's managed to do here. AFAIK Lazarus is the ONLY tool in it's class that allows this kind of development - one code base, multiple targets, all native look and feel, all native code. That's just mind boggling.

My boss was initially very skeptical - "Pascal - that old fuddy-duddy language from the 80's?" He's a believer now, and happily relearning Pascal so he can throw in the odd module himself now and again. We're even looking as Lazarus for some of our device code (as some of our newer devices are Linux driven). There's a better than even chance that we'll officially get in touch with the developers at some point in the near future and offer resources to help move the project ahead. We were especially intrigued by the discussion of a multi-platform setup tool - right now we use Inno Setup on Windows and the awful Package Manager thing on Macs...

In summary, Lazarus is a fantastic product. It's usable TODAY for commercial development. We've found it (the IDE) more stable on Windows than it's commercial counterparts. RAD Studio will generally lock at least one of our development machines once a day - so far we've had only one issue with Lazarus, and that was on a Mac (and I reported the bug to Mantis, and it was fixed in three days - try that with you-know-who ....). These discussions are great, but please don't lose sight of what you've already got - a world class compiler and development tool that's being used right now to solve serious real world problems.

Thanks,
Dave Haxton
Sr. Software Engineer
Audiovox Electronics Corp.
Carmel,IN
USA

Hi!

- 2.0: Get rid of the windows-isms.

Would it be possible while retaining LCL support for existing code. No API changes?

Juha

Hi,

> What did you think of my idea of different GUI-specific target modes for

Lazarus 2.0? I myself feel it is an extremely cool idea!

Interesting. The framework is basically there.

Object oriented QT-pascal mapping would be rather easy to do. The existing code maps C++ classes and methods to flat functions, they just need to be mapped back to Object Pascal classes and methods. Clumsy but who cares.

Other part would be a QT aware form designer with a different layout manager. That would need some work and a more modular, refactored form designer interface in IDE.
Still, doable...

This is a fascinating idea actually. Combining the good parts of QT and pascal programming.

Regards,
Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100307/0efa0433/attachment.html>

Hello,

I'm taking the chance here to confirm that we can exactly agree on Daithi Haxton's posting. We had gone a similar way (had the same decision for a development language and tools) for our cross-platform data recovery software (http://grauonline.de/slides/lazarus.html). Before we made our decision for Lazarus, we developed cross-platform software in Java as well (with similar issues as in the posting before). Then we gave a good known wxWidgets-company the chance to develop a prototype using wxWidgets/C++. They needed 4 months. Finally, we found Lazarus and tried a prototype on our own. We needed 4 days and it worked even better. Lazarus is in fact the ONLY set of tools where you can develop native cross platform apps with the same RAD-IDE on all platforms using a fast compile-cycle. Guys, you really made something unique! Don't give it up. Sure, there are bugs - but the are the same amount in other frameworks, development tools etc. We already spend money on having FreePascal/Lazarus developers helping us to fix bugs. And we are considering spending more money into Lazarus in this way.

Best regards
Alexander Grau

Grau GbR
Hardware & Software Solutions
Huellhorst, Germany

Development company for LC Technology, Intl. (www.lc-tech.com)

We've been using C++ Builder ... [...] Native compilation - check. Native look and feel - check. Similar object structure to our existing code base - check.

and easier and clearer language syntax - check.

A colleague moved a rather complex software update tool from C++ Builder to Lazarus in 4 days - and we now have a Mac version as well. That, my friends, is nothing short of incredible.

Hmmm... how did he convert the source code?
Is simple find/replace enough or does it need lots of editing? By replace I mean :
'{' --> begin
'}' --> end
'->' --> '.'
&param --> var param
*param --> var param (I guess)
Remove '*'
etc. direct syntax changes.

If that works then it could be implemented in a future version of Delphi converter, making it "Delphi / C++ Builder converter".

Ok, it needs some parsing for sure. Like:

bool myclass::myfunc(otherclass *param)
must be changed to:

  function myclass.myfunc(param: otherclass): boolean;

which already needs a parser. But if it needs a full C++ parser then it becomes complicated and may not be worth the effort.

Regards,
Juha Manninen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100307/ea431dae/attachment.html>

A lot of the translation was done manually in this case. But a lot of it was as you describe - find and replace. Some of the direct Windows API calls were a bit problematic, but nothing that an experienced coder can't resolve quickly.

One interesting discovery he made was that it's possible to cut and paste controls from forms in Rad Studio into lazarus! That saved a lot of time ...

Another interesting issue was the fact that includes in C++ aren't exactly "uses" in Pascal - placement matters, and some things had to be manually fiddled to get them just right. Good unit design in C++ helped a lot, too.

It certainly wouldn't be impossible to get a C++ Builder to Lazarus converter going - you'd never get it perfect, but hey - that's what compiler errors are for, eh? ;>) And with some 50 programs yet to translate, we'll probably be doing something like that. If we do, I'll be sure to put the script/source up somewhere and let you folks know. If anybody else already has such a thing, by all means, feel free to share!

Be well,
Dave H.

Michael Van Canneyt wrote

I don't think that you can credit the lowercase letters for your increased productivity. It's simply 25 years of programming experience.

The switch camelcase->lowercase was the last step of the three after 15 years pascal programming experience...
But as you write, that's me, not all brains function the same way. :-)

Martin

Yes, I generally prefer real apps over webapps. The user experience (despite web2 propaganda) is poor.

But the difference is there that I spend relative little time in them.

Do you now see how ridiculous the "native look and feel" argument sounds? Just the above three web apps have probably over a billion users and nobody complains that it doesn't look like there favourite OS.

Pick one:

1. Millions of sheep don't mind doing nothing but grazing either.
2. Then, logically, those millions of users spend less time on the computer than me( and that is probably true)
3. Painlevels may vary between people and experience levels.

Thanks. This is helpful, I will

Most of the compiler is lowercase due to Martin's reason :)

Not forgetting the fact, that almost all lazarus and fpc development coordination is done through mailing list instead of web based forums.

For me not. The current level of windowisms doesn't disturb me, and makes porting of Delphi code to Lazarus so much easier.

As far as the planning goes, I think people should stop trying to manage version numbers, and just work.

I already made an C-to-Pascal converter
<http://sourceforge.net/projects/topas/>, but then got stuck in handling #defines, which deserve translation into either constants or functions, or must be expanded.

I never wanted it to handle C++ syntax, but if you have ideas how to make it usable for (partial) translation of C++ code, I'm willing to update it accordingly.

BTW, the other direction is much easier to go, see <http://www.texttransformer.com/Delphi2Cpp_en.html>.

DoDi

Hi,

Thinking it more carefully, a C++ parser is needed if you want to make the conversion even nearly automatic. The languages have different contructs. There are C++ features which can't be (easily) converted, like pointer arithmetic and templates.
VCL UI code may not have the most advanced C++ features but some other units may have them.

I didn't find any C++ to object pascal (or Delphi) converters from internet by google search. If nobody has made it then it must be a difficult task.

Regards,
Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100307/62ac662a/attachment.html>

Hello Lazarus-List,

Sunday, March 7, 2010, 10:17:56 AM, you wrote:

GG> Then I guess you hate the internet as well? :) Gmail, Facebook, GG> Twiter, etc. all those little web apps that nobody uses an doesn't GG> adhere to a single OS interface. Do you now see how ridiculous the GG> "native look and feel" argument sounds? Just the above three web apps GG> have probably over a billion users and nobody complains that it GG> doesn't look like there favourite OS.

Plase excuse my interference, but most web applications are windows feel and the look is native to the browser in some cases. The usual example is the combobox selection in HTML. Most browsers try to mimic its native look in the non special CSSd elements. Even default fonts are different across platforms. Even there are pages that are render completly different being browsed from Windows or MacOS, setting elements in different possitions.

I'm completly unable to understand this fight between native look and custom look. Special Windows application spend a lot of resources trying to look completly different that the native look (media player in example) and others spend resources trying to be as must native as possible. Each one of them is important in different context. It would be very difficult to explain to anybody why a notebook application in windows have big translucent buttons with a fancy glass effect, or why it is designed with a 12 or 13 pt font when in Windows most users have a 10 pt font.

Thanks ;-)

This doesn't solve the issue on when this bug will be corrected, what path will it take, who can correct or test the correction, etc. The casual (would-be) contributor such as myself seems excluded and not really wanted. This is a perception that I have, unwillingly.

For the moment, Lazarus is enough for my prototyping, and I'm waiting for a stable, 1.0 version. Until then, there is no chance as a professional developer that I could recommend this tool, although it shows great promise. In the meantime, I develop a few components, testing such issues such as COM/DCOM and dynamic loading of libraries, and hoping my code has as few dependencies as possible.

I just hope for the best, and that Lazarus 1.0, stable, will come out.

Best regards,
Thierry

Hans-Peter Diettrich wrote

Can you suggest another interface, that better fits the various widgetset APIs?

Maybe take a look at a widgetset that was designed from the start to be cross platform enabled. There are many to choose from. Don't base you interface on a very Windows specific widgetset like VCL or the Win32 API. And just to be clear, when I say "interface" I mean the glue code between the LCL and backend widgetset (gtk, qt, cocoa, fpgui).

As far as I understand, the initial Lazarus developers had all intention in designing a cross-platform LCL from the start, so common sense should have prevailed. So where did they go wrong and decided to re-implement the Win32 API and force that upon all other widgetsets?

Designing a cross-platform LCL from the start will take another long time, if we watch the Lazarus code you can feel it is changed to be as like we need, they deprecated the Handle of some objects for example.

But i will translate your message, you dislike to see emulation Windows API functions.

Thanks

Zaher Dirkey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100307/c80c2bcf/attachment.html>

Michael Van Canneyt wrote

The downside to this is: there is also a lot less functionality. A simpler product is by definition easier to maintain.

Being a one-man-band, things take a while to be implemented - especially if it's not the only thing you are working on. Looking at what v0.6 (last release of fpGUI) had and what v0.7 (soon to be released) will have, there is a huge amount of new components and features. v0.8 will have drag-n-drop, full clipboard support and MDI window type support, so fpGUI is becoming more feature complete.

To give you an example of what I meant by easier to maintain. For the last 6 months I have pretty much 99% of my time developing under Linux
- that included adding new features and components to fpGUI. Just the other day I though I better test my work under Windows. Fired up the VM session and even to my surprise, everything worked 100% like it did under Linux. That's the benefit I'm talking about - more common code reduces the amount of bugs and maintenance.

And as soon as someone says 'I want native look and feel', you're

That's what the themes are for. :) As for the "feel" - I haven't had a user complain yet. Most components (buttons, menus, comboboxes, grids etc.) all work like the users where used to under native Windows applications. So clearly it's just developers that have an issue with the "feel", not the common user.

If I was planning Lazarus' future (for clarity: I am not), I would lay out for the LCL:

See, now that is the type of thing I'm talking about. Have some goal for the LCL, and try and reach that goal. Currently, it's just from version to version, adding more features, introducing regression bugs and having no stable version of the IDE or LCL. Simply not ideal, and very hard to promote to others.

Michael Van Canneyt wrote

For you, yes. I agree with Hans-Peter Diettrich...

I thinking everybody (except for Martin) agrees with Hans-Peter. MSEgui code is very hard to read. :)

07.03.2010 20:46, Thierry Coq ?????:

This shouldn't be an issue for contributor. If he wants to have an influence on the path the fix will take he can always attach a patch or leave a comment in bugtracker.

The casual (would-be) contributor such as myself seems excluded and not really wanted. This is a perception that I have, unwillingly.

I don't see this problem and haven't ever had feelings like that.

Do you want to be the maintainer of the "stable" version?

Vincent

From?

COM is getting better, slowly (noticable in 2.5.1, but still not perfect, specially wrt exceptions. Will be in FPC 2.6 at the earliest).

I don't see any big development (or interest from _contributing_ users) in dynamic libraries. (and there are many pitfalls and multiplatform gotcha's here. There is not even a good inventorisation what should work how). So unless somebody is going to invest major amounts of times, I don't see this happening in say the coming two years _AT LEAST_.

More importantly though, most of this are FPC features, and not Lazarus so unrelated to Lazarus 1.0 or not.

Yes, but you disregard the native look and feel. As soon as you must introduce that, there will be less common code.

This is manifestly uncorrect. Show your product and a competing product with roughly similar features but using 'standard' windows controls, and you can be assured that the user will choose for the standard one.

I am not pulling this out of my hat, this is feedback from the sales manager after demos for potential clients.

I can only guess, but I think the reason you are getting away with your path is that you're in a situation where there simply is no competing product.

Personally, I don't have the impression that there are regressions, and I work with Lazarus daily. But that doesn't show much, it can be that I simply don't use the areas under development.

I can only regret that this happens to you, but it is up to the Lazarus devels to declare a complete feature stop and work to 1.0.

This is one of the benefits of commercial companies: there the pressure for a feature stop and enter a bug-fixing phase is simply larger. As a developer, one is paid for it, it is ones job. it probably shows in fpGUI. Lazarus is a hobby for most that work on it; so there is less pressure.

And for the record: none of what I write is meant to diminish the achievements of fpGUI. I think it is a hell of a job to create a widgetset. But I do believe that if the same time had been spent on the LCL, Lazarus might have already .

I know this, but my argument is that this is a personal preference, not an inherent benefit of lowercase code :-)

Michael.

[ snip ]

Oh well, for me Delphi is no longer usable as a debugger since years. So much for commercial products sometimes :/

Which is exactly why I think that the person who started this thread has tunnel-vision problems. The glass is half-full for me.

Thank you for this supportive comment !

Michael.

About Mantis graph of the issues (discussed in the beginning of the thread). There's CSV export available:
http://bugs.freepascal.org/csv_export.php for any user (login is not required).

So lnet (or synapse) + gui (lcl, msegui, fplib) or any image processing lib and one can get the graph image localy :)

thanks,
dmitry

Hello Lazarus-List,

Sunday, March 7, 2010, 5:51:33 PM, you wrote:

HPD> I already made an C-to-Pascal converter
HPD> <http://sourceforge.net/projects/topas/>, but then got stuck in handling HPD> #defines, which deserve translation into either constants or functions, HPD> or must be expanded.
HPD> I never wanted it to handle C++ syntax, but if you have ideas how to HPD> make it usable for (partial) translation of C++ code, I'm willing to HPD> update it accordingly.

I think that it would be great to have something that can sintax traslate from C++ to Pascal, but not a whole code with defines, macros, and other things, just a plain block syntax converter, that could simplify manual conversion, like creating the var block, handling the if {} conversion and always take the simple route, not trying to be smarter than the user ;)

Integrating this in the IDE could help to convert function by function, without too many changes.

This list, for example.

Yes, I'm very happy about that. It's already possible to work with COM, although the coding is a manual activity. I've done a COM interface to Excel which works quite nicely.

Yes, the effort is probably large. The Lazarus team has done the same multi-platform miracle for GUIs, so it could be done. I know for a fact dynamic loading can be done in some cases, as I have done preliminary testing on the subject and have demonstrated it can be done (manually) with the current environment. It could be possible at least to be able to load packages compiled with the same version (of FPC and Lazarus). The principle of one code, compiling for each platform could be applicable here, too.

I completely agree that loading packages built with other compilers than FPC would much more arduous. So maybe there is a staged path to add this feature.

So there would be limits and caveats, but it would still be a great feature of Lazarus in its effort to be compatible with Delphi.

More importantly though, most of this are FPC features, and not Lazarus so unrelated to Lazarus 1.0 or not.

No, I don't believe dynamic packages is only a FPC feature. Being able to dynamically load components in the IDE without recompiling would be a great improvement in FPC, as well as implementing one of the oldest features of Delphi. It would also allow people like me, users of Lazarus and builders of components to have a more external view away from the internals of Lazarus, and maybe create an ecosystem for lazarus components.

Also being able to load dynamically packages would be a great benefit for creating easily configurable or extensible applications.

Don't take my constructive wishes for Lazarus improvements for anything worse than what they are: I'm very happy that Lazarus exists, and I try to use it as much as possible. I wish to thank the core team for this great piece of work!

2010/3/7 Zaher Dirkey :

Designing a cross-platform LCL from the start will take another long time,

Obviously it's a bit late now for such a large design changes. As Michael suggested, maybe make it a v2.0 goal. But that will be decades away. :)

But i will translate your message, you dislike to see emulation Windows API functions.

YES, there is no need for it!

As far as I understand, there is/was two three goals for the Lazarus project.

1) Delphi compatible (we don't know which version though)

2) Cross platform

3) Native widgets to help the look and feel argument.

All of the above is possible without emulating the Windows API, so why pollute the LCL with such Windows-ism (I don't know a real word for this). As I said, I was looking last night at how much work it will be to implement LCL-fpGUI widgets. Immediately I see two units named fpguiwinapi.inc and fpguiwinapih.inc, and I think to my self - what the fuck?? Why does LCL require all other widgetsets to implement the API of a single platform? Just look at Qt, GTK2, fpGUI, MSEgui - all cross platform widgetsets without the need of re-implementing the Windows API, so why does LCL require it. Bad design?

Then take a look inside the XXXXwinapih.inc and see all the methods that must be implemented by each backend widgets. Those methods uses Win32 API types like HDC, WHND, HBITMAP, GDIObject, HGDIOBJ, HHOOK etc... All those types mean nothing to Qt, GTK1, GTK2, Cocoa, Carbon, fpGUI - yet we are expected to somehow make sense of those and translate them so something relevant in each of the other non-Windows toolkits. Absurd design.

And this probably contributes to the problems all other widgetset maintainers have and the cause of stability problems. Not only do they need to know their own widgetset, they need to have intricate knowledge of the Windows API before they can implement their widgetset backend (even though that backend has nothing to do with Windows). :-(

Vincent Snijders wrote

Do you want to be the maintainer of the "stable" version?

I wouldn't know how using SVN - we use Git remember. Our method of getting a stable version would also probably not be appropriate for others. On a serious note, below is what we do, and I honestly can't see how this would be done in SVN.

We try various revisions of Trunk until we hit a "sweet spot" revision that seems quite workable. This is a trial and error test. Once we found one, we tag that revision and create our stable branch off that tag. As soon as we hit a issue, we do a quick search through the newer trunk revisions to see if there was a fix, if so, we cherry-pick that into our own branch based on the Tag we choose before. If there was no fix, we create a feature branch off Trunk with the fix (and send the patch to Mantis). We that merge that fix branch into our stable branch. We also have various other "feature" branches that we can merge in with our stable branch to give us our added (personal) wishlist features. In my case I always merge in the "tabs on right"[1] and "file filters editor"[2] branches.

[1] hack to get editor tabs on right side of editor [2] http://bugs.freepascal.org/view.php?id=15679

o Fix A
/ o Fix B
/ /
---A---o---o---o---o Trunk
\ \
\ D Feature branch 1
\ \
B---C-------o---E

A = tagged the "sweet spot" revision
B, C = cherry-picked 'Fix A' and 'Fix B' into new branch created from A D = Some home grown feature branch like [1] or [2] above E = My personal branch which has stable C and merged in feature D branch

Then periodically we will revise the Trunk branch and tag a new "sweet spot" revision. We will then rebase our home grown feature branches ('git rebase' means it takes the patches in a feature branch and replays them on a new Trunk revision so they always stay up to date and can merge easily if needed because they are based on a newer trunk revision). We then start the whole process again.

Hello Lazarus-List,

Sunday, March 7, 2010, 10:20:33 PM, you wrote:

GG> Then take a look inside the XXXXwinapih.inc and see all the methods GG> that must be implemented by each backend widgets. Those methods uses GG> Win32 API types like HDC, WHND, HBITMAP, GDIObject, HGDIOBJ, HHOOK GG> etc... All those types mean nothing to Qt, GTK1, GTK2, Cocoa, Carbon, GG> fpGUI - yet we are expected to somehow make sense of those and GG> translate them so something relevant in each of the other non-Windows GG> toolkits. Absurd design.

That's just a bunch of names and defines, HANDLES in windows are GObject in GTK or any other identifier. The winapi names are IMHO to achieve two goals, one get a desired behavior compatible with delphi and a behavior well documented in MSDN, so FillRect is well defined in MSDN on how it should perform.

Do you really think that FillRectangleWithBrushAndPen function name is better than "FillRect" ? It is the Lazarus graphic abstraction which is more or less compatible with Windows abstraction.

People need those routines to port component packages mostly. The Windows API routines are not an end in themselves and they are also not to be removed (without generating a lot of trouble for people that need them). The solution is much simpler and elegant: simply provide as well a native LCL class or extension of existing classes to also implement the functionality natively in the LCL as well. This can internally refer to the WinAPI routines, so we don't need 2 implementations of the same thing while exposing 2 APIs for it.

I don't see why the mere existence of the WinAPI routines is an issue. While writing the book I used those APIs almost never, you can pretty much ignore them and if you find yourself in a situation where you can't ignore them it's just because we still miss some code to also implement them in LCL style.

Michael Van Canneyt wrote

Yes, but you disregard the native look and feel. As soon as you must introduce that, there will be less common code.

The benefits of a custom drawn toolkit - we can choose what features to support. :-)

This is manifestly uncorrect. Show your product and a competing product with roughly similar features but using 'standard' windows controls, and you can be assured that the user will choose for the standard one.

I can assure you that if I disable the gradient color selection, enable system color detection, then most common components are to the pixel accurate with Win2000 or WinXP un-themed look - default theme in fpGUI. I should probably mention that most of our clients are still running Win98 and Win2000, so this helps us too. I've spent many hours with 'xmag' observing Win98, Win2000 and WinXP screenshots so I can recreate the look - to the pixel.

This year I'll be enabling the same for WinXP, Vista, Motif and Clearlooks. WinXP and Motif are each about 90% complete. This should be sufficient to fool most common end-users.

I can only guess, but I think the reason you are getting away with your path is that you're in a situation where there simply is no competing product.

The benefit of being the best in the market. :-)

And for the record: none of what I write is meant to diminish the achievements of fpGUI.

I have not taken any offence either - you are simply speaking of what you know.

On Sun, Mar 7, 2010 at 6:20 PM, Graeme Geldenhuys
wrote

You would need to map all those widgetsets to something anyway, so mapping a part of them to WinAPI routines is not a big difference. The winapi is very well documented and their docs can be easily found with google.

While starting the qt widgetset these winapi routines weren't at all an obstacle, they were no problem for the port.

The greatest problem I had was lack of documentation about how each thing needs to be implemented, but I started a guide on that here: http://wiki.lazarus.freepascal.org/LCL_Internals

IMHO your objection to the design is based on a very superficial view.

Just to reinforce: As I explained the user shouldn't have to care about that, all features should have LCL-style API offered as well, so the WinAPI are only for interface developers and for people porting from Delphi, and I don't see them as a problem for widgetset developers as you would need to map to something alien to the widgetset anyway.

On Mon, Mar 8, 2010 at 12:12 AM, Felipe Monteiro de Carvalho <

But it can make spicial unit only for those porting components, and for who have more time can replace the function taht call API function to call LCL function

API FillRect(DC: HDC;....
to
LCL FillRect(Canvas: TCanvas;....
to
Object Canvas.FillRect(R:TR...)

Ok i am very slow writing in english :)

Michael Van Canneyt wrote

Which is exactly why I think that the person who started this thread has tunnel-vision problems. The glass is half-full for me.

I now understand what you meant with that statement, and I think you are right. ;-)
Lazarus is an impressive product, I'm not arguing that. And obviously, it is fantastic to hear stories like Daithi's one. This does make me take note of what Lazarus has already accomplished. I guess I have been too long around Lazarus and simply take the features for granted. :)

successful, goal oriented developer's toolbox. :)

Everyone agrees that Lazarus and FPC are unique, highly capable and excellent in their current releases and it's clear that the project is in a highly advanced state. Volunteers are needed now more then ever to fix bugs and clean up the howto's, code examples and obsolete wiki tutorials. Support funding would also be encouraging to the people that have worked so tirelessly on the IDE and compiler for over a decade.

Graeme started this thread with a question about plans for stability. It hasn't been answered, but is still relevant because the project is so close to being production ready. If it continues to be perceived as "almost stable", many potential volunteers will continue to hold back and "wait a little longer" until it is... and we've seen comments like that in this thread. After all, who wants to convert components, revise examples, rewrite tutorials and update webpages that will quickly become obsolete and need fixing over and over again?

The "almost stable" perception is real and frequently reinforced on this list. Recently one of the compiler devs said that "constant change" to the projects would typically require website and documentation revisions every 3 months. Hey, evolutionary changes are good and to be expected, but as this tool moves and more into the real world, minimizing their impact on existing, production code in the long term becomes a very real concern.

So how can the core team continue to enjoy working on new stuff while attracting developers and volunteers who want a "stable" tool that they can confidently promote to their employers and use for personal projects? For Lazarus, would it be possible to define a specific feature and bug set for 1.0? Can the critical path bugs be posted so "waiting volunteers" can see them as an obstacle to the stable version they're waiting for? On the compiler side, adding language features is to be expected, but if those changes are going to impact existing code, can they be made available via a switch that is off by default? Can any changes to the language be clearly separated from the detailed internals changelog so they'll be easily visible to developers?

There's been a considerable amount of time and energy invested by a lot smart people in this and previous threads, but no specifics have been suggested for addressing both the core team and community concerns about development freedom versus production stability. I'd like to see something tangible come out of all this effort rather then the thread concluding with everyone simply agreeing to disagree. :)

Thanks,

-Tom

I agree with everything Tom has said. I hope everyone takes it to heart.

I'm one of those who is lurking and waiting for a more stable project before jumping in and joining the team as a volunteer. I've tried both FPC and Lazarus and found them wanting for all the reasons that have already been mentioned. I have no immediate need to use them and therefore have the luxury of experimenting only but I would like to commit to using them full time. At the rate things are going I'll probably end up using Embarcadero's coming cross platform solution before using FPC/Lazarus. That would be a shame.

A couple of further specific comments:

I see a bunch of bugs reported and developers posting that those are fixed. But unless I wade in and install SVN and figure out how to use it to update my local source and figure out how to compile FPC and Lazarus I cannot make use of those bug fixes. So I'm stuck with the choice of installing a rather old stable version and living with the bugs it has (that I know have been "fixed") or waiting until a new stable version is packaged up. I choose to wait (again, because I have no compelling reason not to). But that, in turn, keeps me away from the project so that I cannot learn more about it and cannot help out because I'm forever "on the outside looking in".

I have avoided CVS, and so far successfully avoided SVN, because I see them as rather old technology. In contrast, Git is an amazingly powerful and fresh look at the problem. I'd rather start out using Git. But when Git was proposed to the FPC/Laz projects it was rather soundly brushed aside. Another reason for me to stay on the sidelines.

When 2.4.0 was released I thought, Ok, maybe I should start with that. So I went about installing and building and learning my way around. Then came to a crashing halt when I learned you could not build Lazarus using the 2.4.0 FPC. Huh? Made me wonder if these teams even talk to each other. Another reason to hold off diving in so I turned aside and got involved in other things.

I've been to the web sites and looked for installation instructions and tutorial help but things are scattered and not easy to find. When this is mentioned on the mailing lists people respond with direct links to the items being sought. Yes, that is helpful, but the larger point seems to be missed. These web sites need to be improved specifically with an eye toward the new convert. There is some talk of doing that but it is rather piecemeal. I think a larger initiative is called for.

I've read the testaments of those who have found FPC/Lazarus to be production ready. (In fact, those are the things that keep me interested!) But I get the impression that those testaments are being received by the core teams as evidence that all is well. If so, please re-read Tom's message and find some real answers to those questions because I think there are more people waiting for the big symbolic "1.0" than there are that have found a way to make the current code work for them. Reaching 1.0 is important not so much because a 1.0 release would contain major improvements to the code but more because it would mean the projects have matured organizationally. That is what I'd like to see.

Doug C.

I think Pavel Kanzelsberger did it quite nice in Pixel: his open/save dialogs show lots of info and fit nicely into the interface, but you can choose (in the options) to have system default open/save dialogs instead.

Just my two cents ...

Best Regards,
Andreas.

Am Montag 08 M?rz 2010 01:58:22 schrieb Doug Chamberlin: [....]

[...]

You don't have to build FPC. Just building Lazarus is enough. And not even that is required, thanks to daily snapshots: (with installers!) http://www.hu.freepascal.org/lazarus/

Best Regards,
Andreas.

You never used CVS and SVN, so you have a choice, which to learn to use. I rather spend my time bug fixing and general Lazarus support than learning yet another source control, especially since the SVN is doing its job reasonably well. Yet the community has provided alternatives for people who rather use git: http://wiki.lazarus.freepascal.org/git_mirrors

Vincent

Florian Klaempfl het geskryf:

... and the functionality is less: just one example: Drag and Drop between explorer and file dialogs does not work in MSEgui,

To my surprise, Gnome also supports drag&drop to the File Dialog. :) I never knew that.

neither the context menu works,

Gnome only allows "show hidden files" or "add to bookmarks/favourites list".

so one can not create folders, rename files etc.

Not allowed by Gnome either.

Regards,
- Graeme -

Felipe Monteiro de Carvalho het geskryf:

People need those routines to port component packages mostly. The Windows API routines are not an end in themselves and they are also

So do I understand this correctly. The xxxxwinapih.inc only needs to be implemented to help support for porting of Delphi components to Lazarus? So can I implement all the other interface classes and have a working LCL or better yet, a working Lazarus IDE (using LCL-fpGUI) without the need for implementing the fpguiwinapih.inc unit?

Regards,
- Graeme -

Zaher Dirkey het geskryf:

Then clearly you guys porting component to Lazarus are lazy. :-) I have ported numerous components from Delphi to fpGUI. During the port, I only use the functions available in fpGUI (no Win API calls). Porting does not take that long, and fpGUI isn't even as compatible with VCL as LCL is with VCL. The end result is guaranteed to be 100% cross platform.

This just highlights the point that the Win API cloning was a bad idea. If you want to make something truly cross platform, you implement it as such, using to top-level interface of the LCL classes. You don't use the "hack" idea of the Win API clone unit - that is inherently not cross platform.

Regards,
- Graeme -

Marco van de Voort het geskryf:

I really dislike non native windows programs, specially GTK ones. Dia is about the only one I tolerate.

[off-topic]

I gather you are using Dia for UML diagrams? If so, I urge you to take a small Java based UML diagram tool. It is really powerful, allows extensions by end-users, uses a text box design (so no popup dialogs) which results in really fast designing!

I am now using Umlet exclusively as my UML design tool under Windows and Linux. It is a brilliant open source product. Updates are also frequent and the developers are friendly people.

http://www.umlet.com

Regards,
- Graeme -

Replace rebase by merge and it works exactly the same with svn: you branch a new fixes branch and merge all needed feature branches. Though I think just merging new revision from trunk to the fixes branch is more svn style. However I consider not merging a feature branch into trunk but into a fixes branch as a rather chaotic development modell: trunk should imo contain all working stuff.

Doug Chamberlin het geskryf:

I have avoided CVS, and so far successfully avoided SVN, because I see them as rather old technology. In contrast, Git is an amazingly powerful and fresh look at the problem. I'd rather start out using Git. But when

Compiling from source code is really not that hard. It sounds more scary than it really is. :-) I'v setup several scripts on my system to compile for example FPC to different targets. As for Lazarus. I normally use the old executable to compile the new executable.

As for using Git. You are in luck. I maintain the Git mirrors for FPC and Lazarus projects. More information can be found here:

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

Here are some of the scripts I use. Not I use an old stable binary to compile the new binaries. Start a new thread if you need more information, or email me in private: graemeg at gmail dot com

------------[ stable32.sh ]--------------------------- #!/bin/bash
#make clean
git checkout fixes_2.4
make all CPU_TARGET=i386 PP=/opt/fpc_2.2.5/bin/ppc386 make install INSTALL_PREFIX=/opt/fpc_2.4.1/i386-linux/ CPU_TARGET=i386 PP=/opt/fpc_2.2.5/bin/ppc386
-------------------------------------------------------

---------------[ stable64.sh ]-------------------------- make clean
git checkout fixes_2.4
make all PP=/opt/fpc_2.2.5/bin/ppcx64 OPT=-gl
make install INSTALL_PREFIX=/opt/fpc_2.4.1/x86_64-linux/ PP=/opt/fpc_2.2.5/bin/ppcx64 OPT=-gl
--------------------------------------------------------

---------------[ trunk32.sh ]-------------------------- make clean
git checkout master
make all CPU_TARGET=i386 PP=/opt/fpc_2.2.5/bin/ppc386 make install INSTALL_PREFIX=/opt/fpc_2.5.1/i386-linux/ CPU_TARGET=i386 PP=/opt/fpc_2.2.5/bin/ppc386
--------------------------------------------------------

As you can see, they are all pretty similar. Converting them to Windows batch files will also be easy. Only the Linux style paths would need to changes to Windows style paths.

Regards,
- Graeme -

No, general overview diagram.

... which grew only in the last few years.

Felipe Monteiro de Carvalho het geskryf:

The difference would be you would map widget types to some abstract LCL type. Currently a Qt developer would now have to learn Win API to understand how to translate that to Qt. Same for GTK, fpGUI, KOL etc backends.

Having a abstract LCL type for the interfaces means the backend wigetset developers simply need to look at the LCL documentation. No need to learn some other platform API (which they have no interest in).

This overly complicates things when it wasn't needed in the first place.

Regards,
- Graeme -

I do not doubt this, but this is what I meant when I said that it is tailored to your needs, or better, the needs of your target audience.

I invite you to come and look here in Flanders. You'd realize that you have a lot of work ahead. More systems, many themes.

This year I'll be enabling the same for WinXP, Vista, Motif and Clearlooks. WinXP and Motif are each about 90% complete. This should be sufficient to fool most common end-users.

And theme changes are observed in your implementation ?

Because that is what 'native look' is all about.

Your app should look like a native app, no matter what version of windows/linux or one of the themes you are running on. it's much more than a matter of colors.

Michael.

I don't think MSEide+MSEgui has "a lot less functionality" than Lazarus. In many areas it has even more. Examples:
Database components, graphics (transparency, 100% flicker free), skinning (tframe, tface, tskincontroller), sophisticated key, shortcut and action handling, twidgetgrid and many editwidgets, a unicode capable postscript printer, sophisticated base widget component without the differentiation TGraphicControl/TWinControl and 100% working transparency, docking...

MSEide+MSEgui is on version 2.2 and reached production stability in 2006. Many of the MSEgui functions were impossible to achieve or need an enormous work with native widgetsets and MSEide+MSEgui surely had not production quality now. Lazarus too had not 100% production quality now if I invested my time into Lazarus instead to develop MSEide+MSEgui. Please don't underestimate the difficulty to reach 100% quality from 90% level if one can not modify the underlaying widget libraries. Although 90% is sufficient for most of the projects and the commercial concurrence is not better maybe. :-)

Martin

But KDE does.

So you see: there are some advantages to using native widgetsets. It's not because you (or me) don't use some (or a lot) of things, that other people don't. Using native widgetsets ensures that all these things that people have taken for granted still work.

Michael.

I was talking about fpGUI, not mseide.

and mseide does not run (to my knowledge) on Mac, didn't run till recently on 64-bit. It all depends on what you think is important.

Nonsense.

If you and Graeme had spent your time and effort on Lazarus, it would have reached that level a long time ago. The widgetset issue has very little to do with it, IMHO.

Michael.

Florian Klaempfl het geskryf:

Replace rebase by merge and it works exactly the same with svn: you

As I mentioned, rebase works slightly different to merge. As you rebase against a newer revision, the patches in that branch cat change slightly due to change new changes in the newer revision. Rebase is as if you used the latest revision and quickly implemented a new feature on top of that latest revision.

svn style. However I consider not merging a feature branch into trunk but into a fixes branch as a rather chaotic development modell: trunk should imo contain all working stuff.

Let me explain why. I implement a new feature in a feature branch. I submit that feature as a set of patches to Mantis. That patch set can sit in Mantis for months before it gets applied to Trunk. In the mean time I would like to use that feature, so I simply merge that feature into whatever branch I am working with daily.

Then if I get feedback in Mantis about my feature, and maybe need to make new changes, I do that in my feature branch. Merge that feature back into my daily working branch, and wait for more feedback from newest changes submitted to Mantis. That feature branch will exist locally until that feature is actually in Trunk. I can quickly run a 'git diff <feature_branch>..' command to see if that feature was added to Trunk too. Keeping it inside it's own branch has other benefits too. I can continue working on that feature, I can quickly reverse that feature out of my daily working branch etc..

Also some of our feature branches are not submitted to Mantis, simply because they are personal hacks or personal preference changes. Things we know Lazarus developers will not accept.

So as you can see, not chaotic at all, just better management of features and branches.

Regards,
- Graeme -

Marco van de Voort het geskryf:

Umlet can handle those too. I often use Umlet to design a diagram or two for my Toolbox articles (not necessarily a UML diagram). Anyway, just thought I would mention Umlet. Use it, don't use it, it doesn't matter to me. :)

Regards,
- Graeme -

Do you know it by your own experience? I know it because I made a VCL and a CLX based GUI toolkit as MSEgui predecessors. Both reached about 95% quality and much less than 50% functionality of MSEide+MSEgui with about the same effort.

Martin

It is not a technical question.

It is a question of available resources and well-defined targets.

Michael.

I know how rebase works ;)

Yes, this might apply to your local stuff, but not to an official fixes/stable branch we talked about.

Michael Van Canneyt het geskryf:

By default, using system colors are disable, but I am considering enabling it for Windows platforms. Once I implemented the Theme Builder application, any user (including graphics artists) can create themes for fpGUI - without needing to learn Object Pascal code.

At first, I'll implement the default look/theme of each Windows platform. These will come standard with fpGUI and will probably be implement in pure code.

Later I'll created a new theme that hooks into the uxtheme DLL of Windows, which means I'll ask Windows to paint each widget for me. This will automatically take into account all custom changes a end-user might have made to their Windows theme. This is not hard to do, just not a priority at this point.

The same goes for KDE and Gnome themes. I am considering adding support for reading the respective theme rc files and trying to match color and graphics. But first, I'll implement the standard looks in fpGUI, then expand theming to integration with existing desktops.

Theming to me is only a nice to have, I have more critical features I would like to implement in fpGUI first.

Regards,
- Graeme -

Florian Klaempfl het geskryf:

Yes, this might apply to your local stuff, but not to an official fixes/stable branch we talked about.

:-) And that is exactly why I said the following to Vincent: "Our method of getting a stable version would also probably not be appropriate for others."

Regards,
- Graeme -

Graeme Geldenhuys wrote

Theming to me is only a nice to have, I have more critical features I would like to implement in fpGUI first.

... and since the native look is a prominent feature in Lazarus, this is why they chose to use the native widgetsets, because then they don't have to do all this work. They already have the native look.

So it's a matter of what you think is important.

Michael.

Michael Van Canneyt het geskryf:

... and since the native look is a prominent feature in Lazarus, this is why they chose to use the native widgetsets, because then they don't have to do all this work. They already have the native look.

That applies to "look & feel" only. They have to reimplement widgets for each new platform they want to support, hunt for bugs in the common LCL code and each platform's backend code etc... All things a custom drawn widgetset doesn't need to worry about.

See, both options have there pros and cons. :-)

Anyway, we are totally off-topic here. ;-) This thread was meant to address the lack of a stable Lazarus (IDE and LCL).

Regards,
- Graeme -

This is (atleast) one of mu y plans.

I don't count you as the average lazarus user. And you clearly didn't pickup the numerous incompatibility complains here, or the bugtracker or on the forum.

This just highlights the point that the Win API cloning was a bad idea. If you want to make something truly cross platform, you implement it as such, using to top-level interface of the LCL classes. You don't use the "hack" idea of the Win API clone unit - that is inherently not cross platform.

Talking this after 10 years is easy. Implementing pieces of winapi gave an enormous boost to the development of the editor we use. It also made porting other delphi app a lot easier. So please shut up if you don't know where you talking about.

eod.

Graeme:

I wouldn't know how using SVN - we use Git remember. Our method of getting a stable version would also probably not be appropriate for others. On a serious note, below is what we do, and I honestly can't see how this would be done in SVN.

I copy here a part of my own mail to Lazarus-dev list, sent last month after I got subscribed there.
I followed instructions from "git-svn --help" (and hints you gave by e-mail) and got the svn link working. After that it is almost a non-issue. The same would be true for you. You get all the benefits of local git branches and commits and all.
"git-svn dcommit" takes little longer than "git push" or "git pull" but is not an issue either.

Maintaining a stable branch or version is challenging and needs much work but that is another thing.

--------- mail to Lazarus-dev list --------

I didn't know any revision control work flow well. Now I have learned git and configured the git-svn link for Lazarus SVN. My last commit was made using git-svn and it worked without problems.
If there are problems then I will learn svn more but until now it looks promising.
I have nothing against SVN but still wanted to learn Git because of the hype and controversy around it. (And because I am a schoolboy again and want to learn new things).
I must say I started to love its ability to split, join, delete and reorder commits before making them public.

Now, this could be a lesson for anybody who wants the whole project to change from SVN to git. You can easily use git with SVN repository and get all the benefits of working with a local git repo.
Yes, that is my experience.

Regards,
Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100308/ee57126f/attachment-0001.html>

Hi!

Sorry but that sounds like an excuse.
I learned both SVN and git usage mostly through this Lazarus project, as a side effect or extra bonus. :-)
Lazarus SVN repo is easy to copy and update. It works well for most things. Patches are easy to generate. I have done that.
If you want to use git, you can clone Graeme's Lazarus repo from GitHub any time and start to use it. I have done that, too.
I even forked his repo in GitHub to make my own public branch, before I got write access to SVN server.
If you would finally get write access to SVN server, you still could use git with git-svn link. Yes, I am doing that, too. Works well.

So, this revision control system war is nonsense, although workflow and policy would still need changes.

The biggest problem still is that good, valid patches get ignored. I notice the core developers try to improve this. There are now new maintainers for different areas with SVN write access. Maintainers for localization, bug tracker issues, even for Delphi converter (me).
But still, only the few and busy core devels check patches related to core features like IDE and LCL.
Like yesterday I found out QT bindings maintainer has a LCL related patch being ignored for months in bug tracker. He has proved his skills but can't write even to lcl directory. Ridiculous.
I had similar experiences with my patches before I got write access myself. And this is because of fear that some non-perfect patch may sneak in if more rights are given.

I propose two things to improve the situation.

1. Make a more stable "release branch" out of truck, or improve the "fixes branch" by applying more changes there. Actually fixes branch should be enough if maintained properly. So, a maintainer is needed. Graeme almost promised if he is allowed to use git, and I have told how well git-svn works so it shouldn't be a problem. :-)

2. Make the trunk less stable. That's what many other projects do, utilize the potential of trunk to let other developers and brave "on the edge" users test new code.
Now Lazarus trunk is too stable (Doug could well use it if he just knew :). At the same time patches in tracker are ignored because they may not be perfect... uhhh...
After letting patches in more easily, they would be checked by those who use trunk version, not by the few core devels (who are busy). It would be de-centralized instead of centralized. Remember what happened to Soviet Union because it was centralized? :-)
There could by an assigned "moderator" for all patches, who filters out some obviously poor and stupid patches but lets everything else in. Please remember that most patches are good after all.

What is the worst scenario that could happed? If there was a bad patch then it would be reverted using revision control (SVN, yes)! It is not like some evil person presses Delete-key and the whole Lazarus disappears.

Summa summarum: two more assignments are needed, "fixes branch" maintainer and a patch moderator maintainer!

Regards,
Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100308/56bae433/attachment.html>

Marc Weustink het geskryf:

I don't count you as the average lazarus user. And you clearly didn't pickup the numerous incompatibility complains here, or the bugtracker or on the forum.

Porting a component to a new development tool chain like Lazarus should mean making the component platform independent. With that comes the removal of Win API calls from the old component to the new - this should be quite logical. If the said developer wants to use Win API calls in a Linux or Mac apps, they have no business in developing cross-platform applications.

porting other delphi app a lot easier. So please shut up if you don't know where you talking about.

No idea where that came from... but very nice Marc.

Regards,
- Graeme -

Say YES, Graeme, and I'll be the first member of your team :-)

DoDi

I don't see any big development (or interest from _contributing_ users) in dynamic libraries. (and there are many pitfalls and multiplatform gotcha's here. There is not even a good inventorisation what should work how).

IMO a facility would be great, that allows to share code of other languages (C in the *nix world), and binary libraries (.DLL, .so).

The ability of dynamic linking/binding is important in the use of LGPL libraries, when an application should *not* become LGPL itself, only because it uses such libraries.

DoDi

As Florian said, most if not all can be done with SVN too. But besides that ...

Do you have this git repo in a public place?
The sweet spot revision is what people are looking for at pages like: http://wiki.lazarus.freepascal.org/Tested_Unstable_Revisions

And information about what are good fixes is valuable to other people who want to maintain a fixes branch efficiently (with as little time as possible).

Vincent

IMO you don't know enough about the real problems. Even a C parser must know about type names, so that proper detection and handling of all typedefs is vital, what means that the implementation of an preprocessor is inevitable.

Integrating this in the IDE could help to convert function by function, without too many changes.

This would be possible, but IMO a useful translator should be an interactive tool of its own. The source code could be analyzed and split into sections by such a tool, where some sections (declarations!) must be converted by the user, before the translator can do the stupid work of translating the code blocks inside subroutines. The user will have to spend much time in replacing the references to symbols in header files, and in writing stubs that call the RTL equivalents of the original C functions.

IMO the integration of an true C++ compiler, like CBuilder, would make FPC/Lazarus much more intersting and useful in real life, removing the need to translate existing (legacy or library[1]) C/C++ code. I don't know how far a mix of Pascal and C/C++ object code is already possible, based on the unified object file formats, but a direct interface to C code by using compiler-created library units were really great.

[1] The use of non-Pascal libraries would require another translation of the source code, after every bugfix or other changes. It's almost impossible to update *translated* code of other languages, instead the entire code must be translated into Pascal again, after every update of the external source code.

In an attempt to add compression modules to Abbrevia, I noticed an bug in the C code. When I reported that bug to the library maintainer, it turned out that just this bug had been fixed a few weeks ago, after the library existed and was used for many years! This was one of the reasons why I stopped my work on Abbrevia as a pure Delphi/Pascal-based project, in favor of 7zip, which uses the existing C libraries directly.

DoDi

It's not a matter of tools but a matter of identifing the good and mergable patches/changesets/revisions.

But in my eyes, one thing lazarus/lcl really lacks is a good automated testing system. I know this is not easy for a gui project but I still think a lot can be done e.g. by replaying recorded events.

Why not? The low-level API is *syntactically* different for every platform, but not so much in the (semantical) functionality.

Why invent another API, when this will have to be implemented again for *every* platform? You'll end up in the same number of fpXYZapi.inc files, regardless of which API you choose or design yourself.

There is nothing Window-ish about windows, handles, bitmaps etc. - every platform and widgetset implements the same, possibly with different names. IMO it's the same with C "struct" and "class", which translate into Record and Object in OPL.

The Windows API is documented, so that every developer can find all the required/related information. An equivalent documentation of a generic[1] FPC or LCL API would take years, including fixes of design flaws, and the same again for a reference implementation that would allow to test and compare the added widgetset-specific implementations.

[1] Did you ever find documentation for the LCL widgetset interface?

DoDi

Definitely. Hence my question for Graeme private stable branch change sets.

But in my eyes, one thing lazarus/lcl really lacks is a good automated testing system. I know this is not easy for a gui project but I still think a lot can be done e.g. by replaying recorded events.

I agree, maybe that is what I should be focusing on.

Vincent

Florian Klaempfl het geskryf:

But in my eyes, one thing lazarus/lcl really lacks is a good automated testing system. I know this is not easy for a gui project but I still think a lot can be done e.g. by replaying recorded events.

Definitely! I was just thinking about this same issue. If I implement LCL-fpGUI widgetset, how do I know it works? Other than me tinkering with a small test application. And more importantly, how do I know it works like the other non-beta widgetsets in LCL?

I remember years back where GTK1 differed from GTK2 and Win32, where events fired in different orders. This played havoc in our applications. I'm sure those are already fixed, but such issue could creep back in without anybody noticing. Some test suite will go a long way in detecting such issues and allow easier comparison between widgetsets too see at what level of stability each widgetset is.

Regards,
- Graeme -

IMO there is no requirement to use SVN for the stable version development. Final releases could be added to the Lazarus SVN, but I'm not sure whether this would make sense - I'd suggest snapshots instead.

DoDi

Vincent Snijders het geskryf:

Do you have this git repo in a public place?

Unfortunately no, I only push the SVN mirror to GitHub, and the release Tags.

The sweet spot revision is what people are looking for at pages like: http://wiki.lazarus.freepascal.org/Tested_Unstable_Revisions

I can push the sweet spot tags to GitHub. Only problem with this is that we only use the IDE, and not the rest of LCL. So we only test and note issues in the IDE and components used in the IDE. So saying that a revision works for us, might be a false positive to somebody else that builds applications based on LCL components (as we only tested the IDE).

If you want me to push the sweet spot tags anyway, I don't mind doing that.

And information about what are good fixes is valuable to other people who want to maintain a fixes branch efficiently (with as little time as possible).

Again, the fixes we apply will only be for the IDE part of the Lazarus project (whatever makes the IDE work for us), but I guess I can push those to a new branch on GitHub too if you want.

Regards,
- Graeme -

I see a bunch of bugs reported and developers posting that those are fixed. But unless I wade in and install SVN and figure out how to use it to update my local source and figure out how to compile FPC and Lazarus I cannot make use of those bug fixes.

Why don't you simply use an SVN client, to keep you working copy in sync with the project trunk? Compiling Lazarus requires not much more than a mouse click, and some time for the compilation itself.

When 2.4.0 was released I thought, Ok, maybe I should start with that. So I went about installing and building and learning my way around. Then came to a crashing halt when I learned you could not build Lazarus using the 2.4.0 FPC. Huh?

The required changes have been applied to the Lazarus code, long before it became *necessary* to use FPC 2.4 for a Lazarus build. IMO you better start with a Lazarus Release version, and install both the Lazarus and FPC of that version, instead of upgrading both independently.

I only wonder what happend to my openSUSE when I tried to upgrade to FPC 2.4. It looks to me as if the RPM handling was affected, somehow, because now I'm unable to install *any* RPM, with the always same (CPIO?) error: "invalid checksum for archive" :-(

DoDi

I'll have a look, though I meanwhile use some more specialized components of dia (specially the ones to make timeline of electronic TTL signals)

Hi,

Automated testing gives huge benefits. For my Windows development I use autohotkey (http://www.autohotkey.com/) to do this. Autohotkey is not only a macrorecorder but also a scripting language with the ability to send key-events to an application.

Some month ago I did some research, but there seems to be no cross-platform tool available so testing would be in windows only.

regards,

Stefan

Marco van de Voort het geskryf:

I'll have a look, though I meanwhile use some more specialized components of dia (specially the ones to make timeline of electronic TTL signals)

As I said, in Umlet you can implement your own custom symbols directly from inside the umlet program and it comes with a lot of predefined symbols already (though most based around UML). It's a pretty neat little tool.

Regards,
- Graeme -

het geskryf:

Some month ago I did some research, but there seems to be no cross-platform tool available so testing would be in windows only.

Mouse position/macro records have inherent problems and I don't think anything exist for platforms other than Windows.

Even though unit testing is generally used for non-gui code tests, it can also be used for gui code tests (with a bit more effort). I'm pretty sure FPCUnit or DUnit2 will be up to the task.

Regards,
- Graeme -

Hans-Peter Diettrich het geskryf:

Say YES, Graeme, and I'll be the first member of your team :-)

I think I should email you my current todo list, then you'll understand why I avoided answer that question. ;-)

Excluding fpGUI and company work, I would really like to start work on FPC's code-page enabled string types (branch: cpstrnew). I've already got some local changes for Linux which I still need to commit. I think Unicode support in FPC is quite important too.

...and Vincent was doing a really good job until he got stuck on the Form Designer bug in the fixes branch. Apparently that is fixed now (thanks). :-)

Regards,
- Graeme -

There are many ways how C code can cooperate wiht shared libs (even C with other C code), so you'll have to detail it a bit more I'm afraid.

Hans-Peter Diettrich het geskryf:

Why invent another API, when this will have to be implemented again for *every* platform? You'll end up in the same number of fpXYZapi.inc files, regardless of which API you choose or design yourself.

At least it will feel like it had cross platform support in mind. But I now understand that those Win API methods are only used by developers that don't port components correctly (lazy buggers). So I will not bother with those for the LCL-fpGUI widgetset, instead I'll only work on the higher LCL interface. Lets see how far I get. :)

[1] Did you ever find documentation for the LCL widgetset interface?

There are wiki pages on how to implement LCL backend widgetsets. Other than that, I often reference the LCL-qt implementation as that seems like the most modern implementation.

Regards,
- Graeme -

Hello Lazarus-List,

Monday, March 8, 2010, 12:59:53 PM, you wrote:

HPD> IMO you don't know enough about the real problems. Even a C parser must HPD> know about type names, so that proper detection and handling of all HPD> typedefs is vital, what means that the implementation of an preprocessor HPD> is inevitable.

I know the real problems, that's the reason I talk about a "simple" helper, that can perform trivial tasks, but keystroke repetitive, nothing fancy which would require a lot of parsing, preprocessing and even intuition.

I think it is not very complex to change:

"int a;" in "a: integer;" or something like:

int myf(char *a);
{
a[1]=\0;
return strlen(a);
}

in

function myf(a: pchar): integer;
begin
a[1]:=#0;
Result:=strlen(a);
end;

Of course there are much more complex examples that this easy ones, but I was not talking about a procedure that changes the strlen in a valid pascal function, simply convert the known plain syntax without type checking or alike habilities.

> Integrating this in the IDE could help to convert function by > function, without too many changes.

HPD> This would be possible, but IMO a useful translator should be an HPD> interactive tool of its own. The source code could be analyzed and split HPD> into sections by such a tool, where some sections (declarations!) must HPD> be converted by the user, before the translator can do the stupid work HPD> of translating the code blocks inside subroutines. The user will have to HPD> spend much time in replacing the references to symbols in header files, HPD> and in writing stubs that call the RTL equivalents of the original C HPD> functions.

I have some experience with full source translators and finally after some lines of well translated code something "unknown" is found, marked as such and after that or everything is marked as unknown or are completly wrong. Finally I end up making 95% of the work manually because the translator refuses to work in only a piece(s) of code :(

HPD> IMO the integration of an true C++ compiler, like CBuilder, would make HPD> FPC/Lazarus much more intersting and useful in real life, removing the HPD> need to translate existing (legacy or library[1]) C/C++ code. I don't HPD> know how far a mix of Pascal and C/C++ object code is already possible, HPD> based on the unified object file formats, but a direct interface to C HPD> code by using compiler-created library units were really great.

That sounds too complex to my skills :(

Thinking it more carefully, a C++ parser is needed if you want to make the conversion even nearly automatic. The languages have different contructs.

The main difference is the object model, including multiple inheritance and lifetime, and templates. C++ also has an ambiguous syntax.

There are C++ features which can't be (easily) converted, like pointer arithmetic and templates.

Pointer arithmetic is the same in C and Pascal, Free Pascal even supports some C-ish conventions (pointers are equivalent to arrays), and operator overloading.

I didn't find any C++ to object pascal (or Delphi) converters from internet by google search. If nobody has made it then it must be a difficult task.

It's not so difficult, but some constructs simply can not be translated, for language and object model design reasons. What's the use of an automated translator, that cannot translate everything?

DoDi

I have a little word here, in a encapsulation, user should avoid touching low level things.
But for M$ environment, they have many features that is correlate with winapi.

I am a wince widget user, and happy that LCL remain the window handle for winapi compatibility.
So I don't need to dig to underlay of LCL and uncover those low level things in order to use OS Specific features, like DirectDraw, D3D. I just reuse lcl and make some code around the handle and thing go smooth.

I have use undelphix years ago, and they just encap all D2D/D3D surface and make them untouchable on user level.
When I want to add some low level feather Like the Fixed pipeline line that it don't provide,
I have a hard time on digging the underlay code and uncover those D2D/D3D surface so I can add my feather for my propose.

May be for Mac/ Linux user, you just think the windows handle there is some thing useless, but it actually help people on other platform.

To make a decision of removing some OS specific feature, may be the best way to thing is what kind of user you are serving for. If the target is Delphi user, surely winapi specific thing is a must have. Because Delphi user most likely is windows user. And LCL add cross platform value on top of VCL.
Otherwise, there are Java, C they have much more nice library to use why use FPC/LCL?

This blurb is copied and paste for every message that asks for something.

It means nothing. No single feature, action or release ever brought in masses of new users, funding or code, despite they were always promised.

Today it is a 1.0 label , tomorrow it is GIT, yet the day after it is garbage collection, threaded for loops, dynamic linking etc.

And all this discussion and hurrying eats into the real work.

The trouble is it is hard to fight against perceptions. Once a 1.0 is rushed out, and some bad forum posts appear in some codegear forum, whipped up by some old faithfulls that it didn't work for their code and "Lazarus is almost htere, but not just yet", it all restarts again.

The only universal truth is that if people want feature X they should work on feature X, X beign stability, bugfixing dynamic libs and whatsoever, and not try to hinge their contribution on some magical state or feature Y.

that in this thread. After all, who wants to convert components, revise examples, rewrite tutorials and update webpages that will quickly become obsolete and need fixing over and over again?

Who wants to dedicate a next year to a rushed 1.0 that will solve nothing?

I don't really believe that the hordes will magically come after a rushed 1.0, and most experience FPC/Lazarus devels seem to agree. Yet we are having this same discussion over and over again, after every newbie from the Delphi world has the illusion he can manage the project better. (conveniently wrapped in a 1000 line summary, without any contribution).

The same is the GIT introduction. Several people that know the FPC/Lazarus workflow have played with GIT and said it was not ready yet.

Several GIT proponents have been asked again and again to come up with more details, study the workflow, and suggest how it might be adapted, and then start some pilot project. However, all we got was "what is good for Linus is good enough for you", and vague descriptions how to fix GIT problems with manual procedures (for stuff htat SVN does automatically like lineending correction), and a hurriedly set up mirror.

So how can the core team continue to enjoy working on new stuff while attracting developers and volunteers who want a "stable" tool that they can confidently promote to their employers and use for personal projects?

Because I'm now in about the 25th or already 30th likewise discussion in the years that I'm coremember, and they all turn out the same:

- a large thread in the maillist archives
- a lot of lost time.
- Changes initiated after the disucssion are mostly abandonned since the promised hordes don't come, and core is supposed to maintain it indefinitely again, yet another burden.
- A lot of time lost for core.

Yet, in this very thread it is clear that users are too lazy to read a 2 page SVN tutorial to get involved in development. This is crazy!

There's been a considerable amount of time and energy invested by a lot smart people in this and previous threads,

That is the exact problem. Much talk, much requirements to do something set, and nothing done.

[cut a long explanation, about the repeated appearance of this topic, and that it (at least in the past) usually leads to nothing....]

Thanks Marco. This post has my full backing. Exactly my opinion.

Martin

Thats why I said it's scriptable and can send keyboard events to the application. Since every app should be barrier-free these days it should be possible to avoid mouse-clicks-

Even though unit testing is generally used for non-gui code tests, it can also be used for gui code tests (with a bit more effort). I'm pretty sure FPCUnit or DUnit2 will be up to the task.

Sure, but for my applications I prefer test's implemented by another person that has no access to my codebase. I simply don't want to mix things up.

regards,

Stefan

Sure, but for my applications I prefer test's implemented by another person that has no access to my codebase. I simply don't want to mix things up.

I thought we are talking about Lazarus LCL here?

would the nightly build not work for this?

Sorry to hear about all your problems on the mailing list. ;-)

The reason for me starting this thread was not to bitch about this or that. I'm simply concerned that for a long time now there is no stable branch or working stable release of Lazarus. Luckily for this thread, Vincent got some ideas from somebody else, and the long standing broken "fixes" branch is actually fixed again.

So no I don't agree with you. Based simply on the above progress with the fixes branch, I regard this message thread as a success. A problem, no stable updated Lazarus, is now fixed.

As for people with too much email, git issues, too little time in the day, svn issues, can't fucken read the docs, etc..... that's their problem not mine, and was not the intended topic of this thread.

waldo kitty wrote

> forever "on the outside looking in". would the nightly build not work for this?

Don't know. If it does, let us know.

Then I wonder why you started this. This all has been discussed several times since you appeared on the list.

The lack is people that do things, not people that tell core what to do.

And it is not that core is static or so, even this week people received their commit bits.

Graeme Geldenhuys wrote

So no I don't agree with you. Based simply on the above progress with the fixes branch, I regard this message thread as a success. A problem, no stable updated Lazarus, is now fixed.

Try "fixes branch doesn't compile/work" as subject next time.

Sorry forget that, apparantly misread some context.

Hi,

would the nightly build not work for this?

Actually I wanted to ask this already before:
"Who are the nightly builds meant for?"

SVN copy is easy to make and requires much less time and network traffic after the initial copy, compared to the nightly build packages.

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100308/d4063c61/attachment-0001.html>

And you really thing it wasn't mentioned before?? Maybe you should start reading the mailing lists in more detail before getting your knickers in a twist. This fixes branch issue was report just after it was caused. Since then, it was reported by myself and many others - just nothing came from those reports. Hence this message thread. Also patches (available fixes that simply need to be applied) were lying in Mantis not being attended to for weeks or months. Hence this message thread.

So again, NO I wasn't simply complaining about nothing. I wasn't advising a new workflow, I wasn't advising a new repository system, I wasn't advising a new widgetset. I was concerned about know issues or available patches not being address. What more can we do than submit bug reports or supply patches to Mantis. It's up to you guys with write access to the repository to do the rest!!

Marco van de Voort wrote

The lack is people that do things, not people that tell core what to do.

So do you job, apply the patches available in Mantis! A few of you really need an attitude change - you guys have a serious god complex.

On 8 March 2010 23:43, Marco van de Voort wrote: > The lack is people that do things, not people that tell core what to do. So do you job, apply the patches available in Mantis!

I'am sure you can get svn write access to take care of them :)

I forgot ;) : obviously it means also to fix bugs caused by them.

Let me tell you this: it is not my job and you are not my boss to tell me to do my job.

Vincent

Patches usually linger in Mantis for a reason. There are downsides to it, unclear bits, or risks, versionwise.

So this argument is easy to bounce back, it is up to you guys to make it compelling to commit them !!

Marco van de Voort wrote

Patches usually linger in Mantis for a reason. There are downsides to it, unclear bits, or risks, versionwise.

Maybe I should have been more clear. Many of them sit with patches supplied, are not even acknowledged and there is no "feedback" status. So no, there is nothing further for use to do.

Vincent Snijders wrote

Let me tell you this: it is not my job and you are not my boss to tell me to do my job.

My beef is not with you!

Wow. You must have a deeply held belief in self-fulfilling prophesy, eh?

Doug C.

One way would be enough for me ;-)

My first idea were a library unit, that provides wrappers for DLL/so resident code. IMO this should be a FPC standard technique, but I don't know how to create according units.

DoDi

The lack is people that do things, not people that tell core what to do.

It's not so simple. Guess why it took me more than a year to implement usable docking - it's not a matter of implementation, but a matter of discussions what is *allowed* to change in a poor interface, and what additional LCL/Delphi incompatibilities already have been introduced and must be respected by all new code. It's almost impossible to replace an inappropriate implementation by a better model, because some existing code *could* be broken by such an change - unless such a suggestion comes from a core developer, who simply changes his existing code.

DoDi

I wholeheartedly agree with the above -- a purely theoretical backwards incompatibility
issue already prevented me from contributing to at least one Lazarus subsystem.

Any idea about how to make it compelling is very welcome. Should I
* use some tags to mark them,
* make thorough comments about implementation,
* clearly state that backwards compatibility is not broken by my patch,
* bump the issue from time to time on Mantis or on this mailing list,
* do wharever else?

Maybe there is a wiki page about how to make patches visible and compelling to commit?

I agree with Doug, Tom and Graeme. And I wait for a stable version of 5 years. Until then, do not be surprised why there are not many new programmers or users.

Regards,
Rigel

I wonder how such wishes can be reconciled with wishes from Tom Lisjac for example to have more stable lazarus, not changing compatibility every release (if that is what actually happens).

Vincent

It was a bit tongue-in-cheek of course, but there is a bit truth in it.

For FPC, easy and clear patches are often committed during work time, and the harder ones are left for the weekend or an evening with a lot of time.

But then something comes up at the weekend, it is postponed another week, etc etc, I think everybody can recognize how it goes.

I've been fixing and closing/triaging bugs, an handful a week on average, in the FPC project for about 10 years now (though I often take fairly easy ones, easier combinable with work):

The guidelines for patches are the same in nearly every project, and mostly logical:

- keep patches clean, strip unnecessary rearrangements etc, and focus on the Avoid forcing some own style or opinion on sources. Stick with the existing codeing style.
- If some bit is to be discussed, and the other parts can be committed without it, split the patch into multiple ones.
- Provide good descriptions, make clear you have reviewed the problem from several sides.
- If there is a multiplatform angle, please provide implementations for the big three (Windows/Linux/OS X). It is a considerable risk to commit an implementation for one, with only vague assurances (like a single remark about a call existing on Linux or so, without portability details) about the others.

Even then it is hard. Despite the "God complex" we are accused of, we don't instantantly overview all consequences either (but might see more than most submitters do, due to experience), something I assume real deities do. (which would be a great way to reduce bugs)

In general, during FPC commits I strangely find that both Delphi compatibility and multiplatform angle are often underestimated.

Until then, do not be surprised why there are not many new programmers

Luckily enough we heard the same for FPC and experience showed that 1.0 didn't change anything regarding contributors. So this argument is simply nonsense.

I don't remember suggesting that compatibility should never change between major releases. What we've been talking about in this thread is for stability issues to *start* being considered and to *begin* managing changes so version impacts on production developers and existing code would be minimized or at least well documented. Borland always did this with new version releases, so when they made changes, the community understood and was fully prepared for them.

The "stability issue" occurs when arbitrary changes are tossed in randomly and without regard for their impact existing code... and with no documentation. This doesn't mean that there has to be total compatibility between a version 1.0 and 2.0 if necessary changes and their impact on existing code are clearly documented.

It also won't be an easy or straightforward process managing codebreaking decisions because there will always be genuinely good reasons to make changes... but starting the process of managing code impacting changes is an essential next step if there's ever going to be a credible 1.0, 2.0, 3.0... etc for this project.

This thread was simply intended to flag a real world problem that developers are having when trying to create production code with this tool. Many of us were hoping to see a civil discussion of that topic that might have even lead to finding a mutually agreeable solution. I'm sorry that didn't happen but I'm hoping it will at a later time... and definitely before a serious effort is made to release a 1.0.

-Tom

Maybe people are tired of waiting for a stable version and left. 5-10 years is a long time.:)

Rigel Rig wrote

Maybe people are tired of waiting for a stable version and left. 5-10 years is a long time.:)

Without targeting anyone, but you have touched the root of the problem:

If they had helped out instead of waiting, the stable version might have been a reality earlier. There is a dramatic shortage of manpower for a project the size of FPC/Lazarus. It is open source, and it is still an unpaid hobby for the core developers.

Many people seem to forget that.

So can we please stop this thread and get back to work ? Do something we can enjoy, and bring 1.0 closer in the process ?

Michael.

Maybe people are tired of waiting for a stable version and left.

Indeed, things get moving if people just wait ...

5-10 years is a long time.:)

If it takes so long, it's a fault of all people interested in lazarus and definitively not a fault of people doing the work already.

When the 1.0 compiler came out, Delphi was cheap, worked well and dominated the market. At the time, mainstream Pascal developers had no reason to care about "that other compiler" or volunteer to support it.

... but how times have changed! :)

It's a totally different landscape now, Florian... and it's completely flawed to compare the lack of motivation for volunteers with the 1.0 compiler to the current situation with Lazarus.

-Tom

Everybody understands that it would be great if we can do that.

Would be great, no-one disputes that.

No-one is against that.

Only we don't need a thread to show us that all of this is missing. That only costs energy and adds nothing. What we need are people doing all this. Not people discussing it, or how it should be done. What we can really miss are mails to tell others (core) to do it.

The 'core' people are volunteers. No one can tell them what to do. They'll do what they like. Gladly some of them like it when more people can use Lazarus. Or they realize that attracting new developers can help them. So they invest their free time in documentation, stability, maintaining the fixes branch and such. But they have limited time.

Telling the 'core' team that if they'll do 'this' it will attract 'more developers', so that they'll have more time, is counter-effective. Most core-people are doing this for fun. So attracting more developers isn't their primary goal. If attracting new developers is reducing the fun they have while developing... It's all counter-productive, from their own point of view.

And don't forget: The 'core' people can leave the project too if they do not enjoy it anymore.

Maybe this all is shocking for some users. And maybe even more for the commercial ones. But eventually we'll find a way out of that. As Michael said there are plans to offer commercial support for Lazarus/fpc. And don't forget that this project has come this far that commercial parties are using it or want to use it. Even with all problems of the volunteer-driven development model of fpc and Lazarus. (I think it should even be 'due to' the development model)

And as a last comment: realize yourself that there are conflicting interest between different users. We all want all possible features, with the amount of bugs of a project without features. It should contain only a few lines of code. Which anyone can read. And it has to be stable, but we should be able to break compatibility for some new sideways features. This is easy-doable, as long as 'core' maintains a separate branch for each and every user. Not enough time? Make time by doing this, that'll attract new developers!

The 'core' team is trying to find the balance between all this. This is difficult. Really difficult.

Give them (us?) some credits.

Joost

Oh really? So why did people tell us then at FPC 0.9x.y times that things will change and FPC will get a lot of contributors when 1.0 is out?

When 1.0 came out, there was no Kylix, and the dotcom and Linux booms were raging.

It's a totally different landscape now, Florian... and it's completely flawed to compare the lack of motivation for volunteers with the 1.0 compiler to the current situation with Lazarus.

It's not. It has been the same ever since. Always the next visible milestone is supposed to bring in the hordes, if we just....

Personally I like the "packages" subject the most. This subject has been beaten to death over the last few years. Lazarus could never become somethign without it, commercial components wouldn't be possible, plugin architectures a mess etc.

To get everything rolling, I just kept tabs on it (like I did on e.g. the COM windows unit), and wrote a small doc how packages work ("packages" in the wiki).

The number of contributions, or even remarks or additions on how packages work is exactly... zero, in over 5 years.

So can we please stop this thread and get back to work ?

Who are you to tell me to work or not??? I agree with the opinions of some people. I do not want you to do or not do something. So do not tell me what I must do!

it's a fault of all people interested in lazarus

I agree!

Looks like this thread (and all it's sub-threads) are on a downwards spiral.

If it was on the forum I would close it.

The LCL could be simplified (and stabilized) in some areas. This could be done by removing unused or unusable parts, or by delegating other tasks to new classes. The scope of such refactoring varies, from almost local (docking) to an entire class tree (components, IDE interfaces). The latter changes are almost impossible, since just a proof of concept would require assistance by other developers, who had to implement the required changes in their area (e.g. components or widgetsets). Chances are very low that this ever will happen :-(

DoDi

I've no idea what you are talking about. Both projects (FPC and Lazarus) maintain stable branches, and regularly release from them.

Some examples (like the quite intrusive *.lrs ->*.res change that is coming) simply can't be avoided.

Likewise, probably heavy pain in the encoding/unicode department can't be entirely avoided (both because Codegear those to break compatibility there, secondly because the current solution is manual)

The "stability issue" occurs when arbitrary changes are tossed in randomly and without regard for their impact existing code

Examples please.

Hello Lazarus-List,

Tuesday, March 9, 2010, 4:25:43 AM, you wrote:

HPD> How should such a tool know that "int" or any other identifier is a type HPD> name? That's trivial for "int", but not for other type names.

I know, but a predefined usual types like base types. That's the reason I say "simple", "helper", not "solver" ;)

> Of course there are much more complex examples that this easy ones, > but I was not talking about a procedure that changes the strlen in a > valid pascal function, simply convert the known plain syntax without > type checking or alike habilities.

HPD> C syntax is ambigous, it only can be parsed when type names are HPD> separated from other identifiers. Such a separation requires a list of HPD> all type names, which has to be built by the parser.

OK. This is becoming a "you say / I say" which will not reach a good point for both, so I think is better to stop here. ;-)

HPD> You should give ToPas a try, it does not suffer from anything unknown. A HPD> few constructs can not be converted into OPL, but this does not normally HPD> affect the translation of the following code.

Hmmm... I think I had used it in the past, but anyway I'll give it a try again. Thank you.