Hi,

I just upgraded to revision 28712 of Lazarus, and really almost all message dialogs are messed up. Sometimes, the button captions make no sense whatsoever. Every message (or question) dialog I encountered seems affected by this.

Just one example, after execution:
Execution stopped: "Yes to all" "OK" ??

Where are the 'old' captions ? 'Do not close the IDE' instead of 'Abort' and so on ?

Michael.

What OS and widgetset?

Best regards,
Paul Ishenin

Linux 64-bit, GTK 2

But I would be very surprised if it was widget set dependent ?

Michael.

I can reproduce in gtk 2 / x86

I'll fix that.

zeljko

Linux 64-bit, GTK 2 But I would be very surprised if it was widget set dependent ?

Not long ago we rewrote QuestionDlg function to use native dialog function when possible (to make IDE and other LCL applications look more standard). Of course every widgetset uses own code because that native dialog functions are different.

Best regards,
Paul Ishenin

That explains a lot...

Michael.

Should be fixed in r28722. Please test.

zeljko

Still problems:

When project information file changes:

"Project changed on disk"
"The project information file "sopmefile" has changed on disk." "Ignore" "yes"

No question, and 'Ignore', 'yes'.

Michael.

ahhh....Buttons[].Caption should be used in AskUser(), not resource strings ... fixed in r 28723 :)
Please retest.

zeljko

Works perfect, thank you very much !

Michael.

I didn't pay attention on this the first time, but: the buttons no longer display the images associated with the modal results when a questiondialog is used:
- start ide
- Start new project
- Move main form
Close IDE.
-> 'Save changes to project project1'
With correct texts on the buttons, but no more images.

Michael.

Will be fixed, that's because buttons under gtk2 get image only if it's gtk's stock button caption eg. 'gtk-yes', 'gtk-no'.So must add stock id image to button by hand.

zeljko

Fixed, r28765.
Note: on some window managers gtk2 doesn't load stock images (but it's not lazarus problem, since all other gtk2 apps doesn't have images on message dialog buttons).
eg. On Fedora 14 i see images on buttons under KDE and XFCE , but not under Gnome :)

zeljko

Rats! Does it have to be Gnome! ;)

Stephano

To Vincent,

This is the exact thing I am talking about. Saying a "stable release" is a few weeks away, things like this should not be happening in Trunk. The mailing list is full of such reports.

Regards,
- Graeme -

When they shouldn't happen in trunk then where do you propose them to happen? And no, I won't take "the developer him-/herself should test it good enough" as an answer, because you can't think of every possibility a user might do.

Please Note: I'm talking about pure GUI related code here. In non visual code your statement might be considered more valid though, because there tests can be done more easily than with GUIs

Regards,
Sven

I can happily confirm that under Kubuntu, it works fine.

Michael.

2010/12/18 Graeme Geldenhuys :

I guess I am eager to release when it is ready. If it is ready, I don't want to wait for weeks to be sure it is stable.

Vincent

pls. tell that to Graeme ;)

zeljko

As far as I know, he uses ubuntu - so he uses GNOME.

Which, I'm sure, costs him some grey hairs when developing fpGUI, because I test his stuff on Kubuntu which produces some interesting effects :)

Michael.

Vincent,

That is a ridiculous statement and is one of the main reasons why this project is such a miserable failure. All formal releases should be stable. What is needed is a comprehensive test suit that covers all features of Lazarus. This test software should be used for regression testing and run on all platforms whenever new features are added. Also new tests should be added to the suit to test these new features. If this is done all that is required is to obtain a clean run of this test suit on all platforms before each formal release. As a bonus the test suit should be included with each release to provide clear examples of how to use Lazarus.

The other main reason why this project is going nowhere is because the stated goal to write once and compile everywhere is completely incompatible with the desire to follow the native interface and design guidelines of each operating system that is supported.

The project is further badly hindered by the stubborn refusal of the designers to implement Layout Managers.

Brian Prentice

On Sun 19/12/10 06:40 , Vincent Snijders sent:

2010/12/18 Graeme Geldenhuys :

I guess I am eager to release when it is ready. If it is ready, I don't want to wait for weeks to be sure it is stable.

Vincent

2010/12/19 Brian Prentice :

To be honest, I think this email didn't help the project either. As far as you are concerned you may consider this project a failure indeed.

Vincent

Brian, calm down, you have a moral right to have such emotional level if you contributed at a comparable level as all core developers of fpc/lazarus. I'm one of those who started using lazarus recently and sometimes I also can not be content at how the developers look at my ideas, but really, me and you are not ones who have the right to speak in such tone. Delphi is stable but CLOSED, it's much worse, believe me, you can find ten developers, take the current lazarus and create something amazing if you really see it differently, but you can not do the same with Delphi no matter how beautiful it is.

Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20101219/66c27ddc/attachment.html>

Hi Brian,

It's not my thing normally to reply to rants, but I simply could not resist. From time to time threads lead to discussions where people express their grief with Lazarus (to say it mildly). Perhaps we should create a FAQ on this ;) But to your remarks I can say only this;

If you have any issues with Lazarus then do something about it yourself, other than accusing others not to work on what you think is important. Please answer the following question for yourself: what have you constructively done to improve Lazarus?

Things that you could do, according to your expertise on the subject as
follows from your email;

- create a proposal to improve the release protocol for stable releases
- improve the comprehensive test suite for the GUI so it covers all features of Lazarus. Please don't forget also all combinations of all features.
- implement a basic layout manager. While you're at it could you also integrate it with the design editor? It will make our lives more easy.

Once you have done all this, and the quality is good enough I'm sure the core developers will grant you SVN access. Development of Lazarus will go faster for you and the future of Lazarus will look shiny again.

Please keep us informed of your progress.

Regards, Darius

Brian Prentice wrote

Vincent, That is a ridiculous statement and is one of the main reasons why this project is such a miserable failure. All formal releases should be stable. What is

In my opinion, at best this statement was out of context. It is not unawareness or unwillingness to do better. In fact many scenarios have been discussed. Including timely releases with appropriate pre-release branches and all.
Only this wasn't discussed in public, So for anyone reading this statement without the knowledge, it may seem a bit "questionable"

As for why then isn't all of it happening, please read after the next quote

needed is a comprehensive test suit that covers all features of Lazarus. This test software should be used for regression testing and run on all platforms whenever new features are added. Also new tests should be added to the suit to test these new features. If this is done all that is required is to obtain a clean run of this test suit on all platforms before each formal release. As a bonus the test suit should be included with each release to provide clear examples of how to use Lazarus.

All very good and very true indeed.
But all a question of man-power too.

We are looking for *good* contributors. And if someone is willing to take the job of a branch-manager, we are looking for that too. But anyone coming along declaring willingness, will need to prove that first. (Willingness, Ability, and Trustworthiness)

Anyone, who goes as far as: I provide you the tips and ideas, but I wont do a thing to help: Well thanks, we are all experienced developers, we know how thing can and should be done.

And as for telling the Team (or any of it's Members) what to do or how to do so:
How would anyone else (or you) feel, if I told you what to do in your free time, or how to do that?

Neither I nor anyone else can command anyone in the Team, nor can anyone command me. Why? I am not getting paid for this, I do not depend on this, I can walk away whenever I want, I am a free man. However, If anyone in the team ask me, and I have time, I usually will do what I can. And the same applies for anyone else.

So, if you want to contribute, be welcome. You can always start writing some testcase, and contribute them.

The other main reason why this project is going nowhere is because the stated goal to write once and compile everywhere is completely incompatible with the desire to follow the native interface and design guidelines of each operating system that is supported.

Well I beg to be allowed a different view on the issue

The project is further badly hindered by the stubborn refusal of the designers to implement Layout Managers.

You mean as in java? like grid, flow, etc?

See above. All is done on a voluntary base.
Anyone who wants, can implement them and offer them as components.

You can offer a bounty. If you place you offer high enough, it's most likely someone will take it.

Sven Barth wrote

When they shouldn't happen in trunk then where do you propose them to happen?

Exactly my point. Trunk is UNSTABLE - ALWAYS. So how can Vincent or any other developer think of cutting a "stable release" directly from Trunk. There is never a "developer/feature freeze" in the Lazarus project (well not in the last 5 years I have used Lazarus), so new and unstable changes always get introduced.

Vincent, how does a stable release process work in the Lazarus project? Do you create a new "feature freeze" branch off trunk, let it stablize for a few weeks or months with minor bugfix patches, and then eventually tag that as v0.9.30 release? I know the point releases work like that, but that is only after a 0.9.x.0 stable release has been made.

And no, I won't take "the developer him-/herself should test it good enough"

Excuse me, but that should happen without saying. If you don't, then
something major is wrong in your work process!

Please Note: I'm talking about pure GUI related code here. In non visual

I'm sorry, but I disagree. GUI code affects the Lazarus project just as much as non-GUI code in the Lazarus project. eg: Kill the GUI TTreeview component, and the whole LCL and Lazarus IDE is unusable. So I have no idea why you would even consider not testing GUI related code changes, and thinking it is less important than non-GUI code changes. GUI and non-GUI changes are equally important, and should always be test thoroughly by the developer making that change.

zeljko wrote

pls. tell that to Graeme ;)

You missed the point I was trying to make Zeljko.

2010/12/19 Graeme Geldenhuys :

See http://wiki.lazarus.freepascal.org/Lazarus_0.9.30_release_plan what we want to do to be able to release 0.9.30.

See http://wiki.lazarus.freepascal.org/Lazarus_Development_Process#Lazarus_branches_.2F_version_numbers_around_1.0 how 0.9.30 is in the big picture of other future Lazarus releases.

Vincent

Brian Prentice wrote

Vincent, That is a ridiculous statement and is one of the main reasons ?why this project is such a miserable failure.

You've failed to explain this premise. How have you come to the conclusion that this project is a failure?

The other main reason why this project is going nowhere

There we go again. Please explain this statement. Things don't magically become true because you say them.

The project is further badly hindered by the stubborn ?refusal of the designers to implement Layout Managers.

I seem to remember that most people thought that layout managers are a good idea, so I'm sure your patches would be gladly accepted.

Henry

I'm not saying that the developer should test nothing at all - that is indeed a given. But you can't think of every possibility. Also you can't test every combination. E.g. I personally can test on Linux i386, Linux x86_64, some Windows systems (2000, XP, 7) and some Windows CE systems (Windows Mobile 5.0 and 6.1). But I don't have a Mac OS X or an iPhone. Also I'd first need to build a libqtpas if I'd like to test the QT interface as well.

While you can indeed test things like (to keep your TTreeView example) "was that node added to the internal node list of the tree view", you can't (automatically) test whether a node is visually expanded or it only pretends to be expanded in its state (ok... it might not be impossible, but very hard to achieve).
But if it can't be tested automatically then at least manual test programs for such things could be written... but here the same problem applies as in every open source project: someone has to do it...

Regards,
Sven

Sven Barth wrote

programs for such things could be written... but here the same problem applies as in every open source project: someone has to do it...

+1

Brian Prentice wrote

That is a ridiculous statement and is one of the main reasons why this project is such a miserable failure. All formal releases should be stable.

I would label such first release a beta, but the whole lazarus formally still has beta status. The conclusion miserable failure is totally unfounded.

What is needed is a comprehensive test suit that covers all features of Lazarus.

Testsuites are the favourite knee-jerk solution for stability problems, but it is a lot harder if the project is visual, and/or the spec is constantly evolving.

I sometimes wonder how many people recommending regression testing actually did so on a non trivial scale.

before each formal release. As a bonus the test suit should be included with each release to provide clear examples of how to use Lazarus.

Tests and clean examples? In what universe? Usually tests are stuffed top till bottom with unit testing framework helpers, and not usable standalone at all.

The other main reason why this project is going nowhere is because the stated goal to write once and compile everywhere is completely incompatible with the desire to follow the native interface and design guidelines of each operating system that is supported.

There is tension there surely. But name me one major project that doesn't have tension betwee objectives. It's a sign of maturity, not of failure.

The project is further badly hindered by the stubborn refusal of the designers to implement Layout Managers.

I'm not too deep into the subject, but layout managers are more something of ownerdrawn environments, and as such that is not compatible with the projects stated goal of using native interface and guidelines as much as possible

Anyway Delphi can have layout managers, and afaik so can Lazarus. They don't have to be internal. SF.NET has one for Delphi iirc

Well, I do so, but never for visual stuff.

I consider that impossible in practice and probably even in theory.

Example: Write a unit test that tests that in a treeview, the selected node actually is displayed with the bitmap indicated by SelectedIndex property of the node.

Or:
Write a unit test that tests that in a MessageDialog, the correct image is displayed on the buttons.

I'd really like to see those tests :-)

Lazarus IMHO has the best testsuite ever:
An active community that points out bugs as soon as they pop up.

Michael.

Michael Van Canneyt wrote

Lazarus IMHO has the best testsuite ever: An active community that points out bugs as soon as they pop up.

And this is (for me, at least) a good sign that the project is not a miserable failure. There is a lot of activity in the bug tracker, and there is a team of developers, not just one person.

Henry

- implement a basic layout manager. While you're at it could you also integrate it with the design editor? It will make our lives more easy.

There exist already a couple of layout managers in the LCL, but they are totally isolated. It had been easy with the recent AutoSize rewrite to implement a general layout manager interface. Since ChildSizing is already a link to an external object, it could have been extended into a more general layout manager link as well.

There is nothing magic with layout managers, they have to do nothing but arrange their child controls, and to report the minimal and desired sizes to their parent (with AutoSize). Every docking manager already is a layout manager for its site, and its interface only lacks beforementioned AutoSize capabilities.

It's only the poor AutoSize hack that prevents the use of other layout managers. Give it a well documented API, and let the users add their own layout managers as e.g. TChildSizing descendants, as everybody already can add an docking manager. *Then* you can ask the users to implement their own layout managers, while asking them to implement a layout manager *interface* is the *wrong* way.

The same for the designer interface, which should be specified *before* you can ask the user to implement it. A published LayoutManagerClass and a LayoutData property in the control/form properties is the minimal requirement for such an interface. In the easiest case no extra designer support is required at all, when a layout manager works like a docking manager, where the location of the dropped control is sufficient to determine its final origin and extent. Further fine-tuning can use the already existing ChildSizing interface, and an generalized AnchorDocking (LayoutCustomization) dialog, if necessary.

Conclusion: The LCL already contains all required features and hooks for layout managers, only in a too specialized implementation. Make it more general and open to user supplied players, and the layout manager discussion can be closed forever, leaving more time for other issues to the core developers :-)

DoDi

Why should a layout manager ever require ownerdraw? It has to arrange and size its client controls, nothing else. In so far it's a simplified docking manager, with docking support required only at design time. At runtime no dock-headers are needed, so that no PaintSite method is required (or it does nothing).

DoDi

I also thought this. In theory, a layout manager only needs to manipulate some rectangles. Independent of a GUI, you could do it in the FCL. So I set about implementing one.

Mattias Gaertner quickly convinced me that this view is too simplistic. Under windows this may work; Under X, you have the window manager to take into account, the underlying widget set which doesn't listen, 'AutoSize' kicks in etc.

So I suggest you contact him about this prior to advocating your views.

Michael.

How can you guarantee any consistent positioning otherwise?

+1

I was very confused about Macro's statement as well.

Marco van de Voort wrote

> > Why should a layout manager ever require ownerdraw? How can you guarantee any consistent positioning otherwise?

Positioning a component and setting it's bounds (width, height) in definitely not ownerdrawn. As for as I know "ownerdrawn" in VCL and LCL means "component does custom painting". Layout managers have nothing to do with custom painting. eg: As far as I know Java's AWT used native widgets and they had/have layout managers. Swing is custom drawn, and it has layout managers too. wxWidgets also uses native widgets on each platform, and I believe they have layout managers as well.

Right :-(

The calculation of the positions and extents is quite easy, no special FCL support is needed. Problem is the conversation with the widgetsets.

Since the layouts work already, all problems with the widgetsets seem to be solved (as far as possible). At least remaining problems do not affect layout managers in a special way.

It's known that the placement of widgets frequently is delayed, with according features (intended position...) implemented in the LCL. A layout manager only has to use and update the intended position and size of the controls, and everything else will happen as usual.

DoDi