Is this statement 'Lazarus and Free Pascal aim to be write once, compile anywhere' still a goal? If so can someone please provide me with the source code of a non trivial program which runs on Windows, Linux and OS X (Intel) using the current stable software available at

http://sourceforge.net/projects/lazarus/files/

Brian Prentice

here's list of the such programs:
http://wiki.lazarus.freepascal.org/Lazarus_Projects

and here's another one for all 3 OSe:
.http://sourceforge.net/projects/devwork (please compile from sources).

thanks,
dmitry

Brian Prentice wrote

Is this statement 'Lazarus and Free Pascal aim to be write once, compile anywhere' still a goal? If so can someone please provide me with the source code of a non trivial program which runs on Windows, Linux and OS X (Intel) using the current stable software available at

Yes it is. For an example, look at the Lazarus IDE. :)

Regards,
- Graeme -

2009/11/11 Brian Prentice :

One of the them is Lazarus, download the source from http://sourceforge.net/projects/lazarus/files/ :-)

Vincent

Vincent Snijders wrote

One of the them is Lazarus, download the source from http://sourceforge.net/projects/lazarus/files/ :-)

Great minds think alike. :-)

Regards,
- Graeme -

Which source file, the only one seems to be a linux rpm file which I can't use on my Mac.

Brian

Brian Prentice wrote

Which source file, the only one seems to be a linux rpm file which I can't use on my Mac.

http://sourceforge.net/projects/lazarus/files/Lazarus Zip _ GZip/Lazarus 0.9.28.2/

Vincent

Is this statement 'Lazarus and Free Pascal aim to be write once, compile anywhere' still a goal? If so can someone please provide me with the source code of a non trivial program which runs on Windows, Linux and OS X (Intel) using the current stable software available at

You must be a newcomer here. Welcome. :)

I've been using FPC and Lazarus (also Firebird) on Windows, Linux, and OSX and had created various applications using them since FPC v.2.2 and Laz v.9.24. Before that, I was using FPC and Lazarus on Windows and Linux. Oh, and I also had created some web applications as well. Of course, they're not just "hello world" kind of applications. ;)

If you came from Delphi, you may need some times to get used to them. But as time goes by, you'll be as productive as when you're using Delphi. Good luck! :)

On Nov 11, 2009, at 6:18 AM, Vincent Snijders wrote:

I don't believe that Lazarus is an example. Here is a program that Compiles and runs under Windows XP and compiles but does not run under OS X on an Intel Mac.

http://linuxenvy.com/bprentice/Lazarus/LazarusSquareCell.zip

I suspect that there are many more examples.

Brian

Looks cool, although I don't know what it's doing.

I'll take a look at it tonight on my Macs. Since you're [thankfully] not using the Win API anywhere, this app really should work. If not, then that likely means something not right in the underlying Carbon-based widgetset used on OS X. Note that it's still considered "beta". If we can track down what doesn't work, a bug report should be filed.

What exactly doesn't work on OS X?

The files look like they haven't been touched (or compiled?) in a while. Did you test with 0.9.28.2 on Mac?

Thanks.

-Phil

Brian Prentice wrote

On Nov 11, 2009, at 6:18 AM, Vincent Snijders wrote: I don't believe that Lazarus is an example.

Ah, Why not? (Well you do not need to believe it, or you don't need a reason for disbelief). But why is Lazarus not an example? Which part of your question does it not fulfil?

You did ask " If so can someone please provide me with the source code of a non trivial program which runs on Windows, Linux and OS X (Intel) "

- Lazarus has the source avail
- It is certainly not trivial.
- It runs on all of the named platforms

As for 'write once, compile anywhere'

- Lazarus does allow you to write apps that fall into this category
- Lazarus does not force you do to so. You are fre to write apps that run on selected OS only

That is:
- The LCL is aimed works on all platforms. And it does so in most cases. Some features are still under development. See here: http://wiki.lazarus.freepascal.org/Roadmap.
If you find a feature that is supposed to run, but does not, then you should report it as a bug.

- Additional Components: Some components are included in Lazarus, many others are provided by 3rd parties and can be downloaded. Included components should be in asimilar state as the LCL 3rd party components are not part of lazarus, no statement about them is possible

You should look here for more guides how Lazarus is to be used, if you aim for cross platform:
http://wiki.lazarus.freepascal.org/Multiplatform_Programming_Guide

Your attached example...
a) I do not have a Mac, but IIRC Mac OS limits paint to inside the paint event (Someone can probably confirm this). Which even if an OS does not force it, is a good practice.
b) I only had a very very brief glance at your code, but it looks like "DisplayPaint" is called all over the place.

If my Memory on a is right, and my assumption on b is right too, then
your code is written in a non cross platform way.

'write once, compile anywhere' does in no way mean, that every Windows feature (or every use/abuse of features possible in Windows) is available on all other platforms.
'write once, compile anywhere' means that the features provided by the LCL, if correctly used are available cross platform (or aimed to be).

Best Regards
Martin

Here is a program that Compiles and runs under Windows XP and compiles but does not run under OS X on an Intel Mac. http://linuxenvy.com/bprentice/Lazarus/LazarusSquareCell.zip

Phil,

I wrote the Lazarus version of SquareCell sometime ago. It is a stripped down version of this Delphi program:

http://linuxenvy.com/bprentice/SquareCell/Version%201/Square%20Cell.html

I did test the program with version 0.9.28.2 on my Mac. It seems that the mouse events and status bar don't work correctly. Since the menus on Widows XP and OS X behave differently, the program needs to be rewritten to use buttons rather than menus to control the simulation and use menus to simply open dialogs.

I needed a CA simulator for my Mac and my original plan was to use Lazarus and FPC, but since that didn't work I wrote this Java program:

http://linuxenvy.com/bprentice/Java%20Square%20Cell/

which I use daily.

Brian

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

I've managed to compile the program and launch it on OSX, so i guess "Write once, compile anywhere" works.

Too bad that OSes are too different, so some cross-platform style should be followed while writing the code.

thanks,
dmitry

I did find a list of compatibility issues on OS X, but it's very, very sketchy. Better than nothing I suppose but only that.

http://wiki.lazarus.freepascal.org/Carbon_interface_internals#Compatibility_issues

I don't mean to be critical of Brian's app, but having menu bar items that respond to clicks as though they are buttons is rather perculiar, certainly non-standard even on Windows. I think the only app I've ever seen that does that is Dave Baldwin's TFrameViewer demo app included with his HTML components package, where he has an About item on the menu bar that does not have a submenu. Very disconcerting when you click that and it doesn't drop down.

What Dimitry means is that in some cases you need to conditional-ize your code to conform to expectations and style guides on the target platform. So when I ported Dave's package, I inserted this code to take care of the whacky About item:

{$IFDEF LCLCarbon}
  AppMenu := TMenuItem.Create(Self);  //Application menu
  AppMenu.Caption := #$EF#$A3#$BF;  //Unicode Apple logo char
  MainMenu1.Items.Insert(0, AppMenu);
  MainMenu1.Items.Remove(About1);  //Remove About as separate menu
  AppMenu.Add(About1);  //Add About as item in application menu
{$ENDIF}

Not only does this eliminate About as a submenu, it also moves it to the correct place - and only on OS X too.

Thanks.

-Phil

Hi!

I compiled the program under Linux and it runs OK. I think the problems are some usability issues that could be fixed. One clear problem is that menu actions (OnClick events actually) are at top menu items, not at sub-menu items as usually.
You need to click the top menu item twice (separately, not double-click) to get the action. I don't know if it is a bug or a feature but it is an unusual way to use menus anyways.

Pity you wrote the Java version. I think this could have been fixed.

Juha Manninen

You abandoned the whole program that has been written in pascal just because UI issue that actually can be solved? Wow!

I needed a CA simulator for my Mac and my original plan was to use Lazarus and FPC, but since that didn't work I wrote this Java program:

Good for you then. Obviously you are not yet ready to join a free open source project driven by community. ;)

2009/11/12 Bee Jay :

Every issue can be solved, some of us just don't have days/weeks/months to wait for it to be solved and some of us can't solve it by ourselves. Especially if someone else solved it elsewhere already. I had to port some pascal code a while ago because it didn't work properly on a certain architecture. That's life.

Can you explain to me exactly how you came to this conclusion? You think java doesn't have a community?

Henry

2009/11/11 Brian Prentice :

Brian, i've took the liberty to make the sources friendlier to Carbon. Here's the fixed version:

http://havefunsoft.com/fpc/LazarusSquareCell_macfixed.zip

You can simply place squares around the field and run them with "Step" or "Start" menu.

I've added additional "Invalidate" calls in TDisplayForm and DisplayPaint for FormPaint event
It has been done to satisfy Mac OS X demand: "draw only inside OnPaint event".

thanks,
dmitry

Brian, i've took the liberty to make the sources friendlier to Carbon. Here's the fixed version:

http://havefunsoft.com/fpc/LazarusSquareCell_macfixed.zip

You can simply place squares around the field and run them with "Step" or "Start" menu.

I've added additional "Invalidate" calls in TDisplayForm and DisplayPaint for FormPaint event
It has been done to satisfy Mac OS X demand: "draw only inside OnPaint event".

thanks,
dmitry

Dmitry,

Thank you for looking at my code and modifying it. I modified FormPaint, added a call to Invalidate in DisplayPaint and removed the other Invalidate calls. Now the program is showing signs of life!

I've placed the code here:

http://linuxenvy.com/bprentice/Lazarus/LazarusSquareCell.zip

There are still some issues. Most are related to my unusual use of menus but some are not. I would like to discuss these with you either on this list, privately or not at all as you prefer. There is one issue which is pertinent to this topic though.

http://linuxenvy.com/bprentice/Lazarus/OSX.jpg

and

http://linuxenvy.com/bprentice/Lazarus/WindowsXP.jpg

show the Selection Control Dialog displayed on each operating system. I would be interested in your opinion on the differences.

Brian

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

2009/11/12 Brian Prentice :

http://linuxenvy.com/bprentice/Lazarus/WindowsXP.jpg

http://linuxenvy.com/bprentice/Lazarus/WindowXP.jpg

2009/11/12 Brian Prentice :

1. Most of OSX controls are using transperancy (i.e. panel or group box). These designer "double dots" are caused by this. The IDE designer always draw grid dots (based on controls client rectangle). Since control is transperent you can see dots drawn on its parent.

May be it looks strange, but It doesn't hurt the development. Tthe final application would not have this grid dots.

2. Font size is different for both system.
There's no proper "aligner" developed for the IDE or LCL, to align controls properly. So the inteface would look like a candy. In my apps i'm doing this re-aligment manually on the application start.

Is there anything else, i've missed in these screenshots?

Don't hesitate to ask any questions about Lazarus and LCL here or on the forum, especially regarding cross-platform issues. Other developers might find your experience useful.

thanks,
dmitry

The designer uses ExcludeClipRect to clip child controls. Maybe there is a bug in the carbon interface?

2. Font size is different for both system. There's no proper "aligner" developed for the IDE or LCL, to align controls properly. So the inteface would look like a candy. In my apps i'm doing this re-aligment manually on the application start.

There are various properties for auto sizing/aligning/anchoring.

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

Mattias

It can even differ within the same OS. Take Windows: users can set different dpi for their screen. Any hardcoded Size of any control that displays text is very likely to break.

There's no proper "aligner" developed for the IDE or LCL, to align controls properly. So the inteface would look like a candy. In my apps i'm doing this re-aligment manually on the application start.

You can get pretty good aligning in many cases by using autosize and anchors.

Martin

Mattias Gaertner wrote

The designer uses ExcludeClipRect to clip child controls. Maybe there is a bug in the carbon interface?

It can be. Needs testing.

My point about showing the differences in the dialogs, one acceptable and one clearly not acceptable, is that the solution seems to require the construction of two dialogs one for OS X and one for WindowsXP. Perhaps I'm wrong here but if I'm right this violates the Lazarus and FPC goal of write once. I don't want to start a war here but as you probably know Java has solved this problem nicely with layout managers. If layout managers were implemented in Lazarus the IDE would also be simpler, an additional advantage.

Earlier in this thread it was stated that when designing an application consideration should be given to the differences in the underlying operating systems. This might be true but if you do this you severly weaken the stated goal which would then read something like:

'Lazarus and Free Pascal aim to be write once, compile anywhere for those programs which only use the supported operating system features that share a common design'.

Surely a better approach for Lazarus and FPC is to hide operating system difference from users.

Brian

Lazarus solves this problem with autosizing and achors: http://wiki.lazarus.freepascal.org/Autosize_/_Layout http://wiki.lazarus.freepascal.org/Anchor_Sides
http://wiki.lazarus.freepascal.org/IDE_Window:_Anchor_Editor

Vincent

Mattias Gaertner wrote

The designer uses ExcludeClipRect to clip child controls. Maybe there is a bug in the carbon interface?

Fixed in r22551

thanks,
dmitry

2009/11/12 Brian Prentice :

This indeed violates that "goal", but please don't evaluate lazarus as a complete product. There is a bug tracker, with very friendly and responsive developers, as you have noticed.

solved this problem nicely with layout managers. ?If layout managers were implemented in Lazarus the IDE would also be simpler, an additional advantage.

Graeme has raised this point and it sounds very handy indeed. As Vincent pointed out, the layout mechanisms in place can already accomplish a lot, if not all of your needs.

The fact is that different operating systems and different widgetsets do things differently and fpc and lazarus does its best to abstract and hide this from users. Sometimes this is just not feasible and developers are forced to follow best practises. There will inevitably be some functionality that is not consistent or even present on all platforms. I've used lazarus with 4 different widgetsets under 4 platforms. There are very few systems that can do this with native code. It is an incredible feat in cross platform cross widgetset design. Note also that some sacrifices are obviously made to use widgetsets to give the "native" look and feel on a platform.

'Lazarus and Free Pascal aim to be write once, compile anywhere for those programs which only use the supported operating system features that share a common design'.

And I would've thought that this was obvious. There are just some things you cannot abstract/emulate.

Surely a better approach for Lazarus and FPC is to hide operating system difference from users.

This is the current approach, obviously. The job of the lcl is to abstract widgetset differences and the job of the fpc rtl is to abstract system functions. If this wasn't the case you'd have to use win api calls for windows and carbon for mac.

Henry

Brian,

Is there some reason why you haven't set the font in that dialog? Try Arial10.

Thanks.

-Phil

Answered inthe mean time by others => use anchors

Yes and no.

Lazarus aims to hide those differences. Examples:
- automatic placements of the about menu in different main menus (Mac vs Windows)
- automatic showing/hiding of Icons on buttons, depending on the OS default.

The difference to Java is. Lazarus offers both:
1) Functionality available on all OS
2) Functionality available on selected OS only.

Java only offers the first. And yes of course, that is easier for someone new to cross-OS develpment, because it protects you from errors.

Lazarus does not protect you from doing things that are not portable. On the other hand it offers additional features for people who only need one OS.

As far as components go, restrictions can be seen in the Object inspector. As far as source-code goes: Lazarus can not warn you. (This would require intelligent analysis of the source, something that only humans can do)

Conclusion:
Java forces you do do portable code
Lazarus offers this do you

Martin

This indeed violates that "goal", but please don't evaluate lazarus as a complete product. There is a bug tracker, with very friendly and responsive developers, as you have noticed.

That's why I said he's not ready to join an open source project _driven_ by community. I never mean to discourage him, but I think one who would jump to _native_ cross platfrom programming, s/he had to be ready to face the compatibility problem. It's the consequences. Even Java can't really solve the problem completely.

Exactly. Even those platforms don't have same thought about what is "common". What Java does is nothing more than standarized the "common" things within its own environment. But, whether it's common to the native platform, it's very much questionable. Obviously he can't see the obvious.

Well the understanding of cross platform is quite varying. The base obviously is that "one source code" can be executed on all of the supported platforms.

On top of this, there are at least 2 different understanding:
1) the application looks/feels like any application on that platform, it uses the platforms widgets, and the guidelines for the platform. This means that the qpplication will look and feel different on every platform

2) The application looks and ffels the same on all platforms. It completely ignores the guidelines and standards of the platform

1) is what the LCL aims for. It is more enduser friendly, but requires more work by the developper
2) is what Java and fpgui (and afaik msegui) aim for. It is easier for the developper. But the enduser will find an application that is different to any other app he runs on his PC (and therefore harder to use)

Martin

Well the understanding of cross platform is quite varying. The base obviously is that "one source code" can be executed on all of the supported platforms.

In my understanding, there are 3 kinds of cross platform implementation:

1. Cross platform is implemented within an virtual environment both the binary and the widgets. The application is run on top of it. The example is Java.
2. Cross platform is implemented in full native ways both in the binary and the widgets. The application is truly native application on each platform. The example is FPC/Lazarus.
3. Cross platform is implemented natively on the binary but not on the widgets. The application execute natively without any virtual environment but it losses its native look-and-feel (or at best, emulated). The example is fpGUI, mseGUI, Qt, etc.

Since FPC/Lazarus in on the second type of implementation, we (both the developers and users) should be aware (and understood) of consequences of the approach. Expecting FPC/Lazarus to act like the first type of implementation is ridiculous. This is what the thread starter didn't understand on the first place, and blaming it on approach taken by FPC/Lazarus.

1) is what the LCL aims for. It is more enduser friendly, but requires more work by the developper

Yes. Ideally, again I said ideally which mean it hardly can be achieved, we (developers) should fullfil anything our users want. Whether it's difficult or not, it should be our problems, not theirs, because the users who pay the bill. Sometimes we and our users make some compromises for whatever reasons. :)

Brian,

There are two problems with this dialog, one small, one bigger. The small problem, easily corrected, is that it's too small and you didn't leave space for possible differences in fonts between platforms or translated text that takes up more horizontal space than English. Consideration for both of those things are part of normal dialog box design. The horizontal space take up by the button is completely wasted. Why not widen the button and put the label on it as a caption the way buttons normally do? Then set the dialog's font to Arial 10 or 11 and everything will be fine on both Windows and OS X. Well, almost...

The bigger problem is that this dialog doesn't make much sense. At first glance I couldn't figure out what it was supposed to do until I realized that the little squares were buttons. But without captions. And a Save button in the list there too? Very odd and dare I say non-standard. Maybe a toolbar at the top would do better. Then standardize the menus and use the toolbar for all manipulation rather than a combination of menu bar items and popup dialog.

Thanks.

-Phil

Brian Prentice wrote

probably know Java has solved this problem nicely with layout managers. If layout managers were implemented in Lazarus the IDE

I fully agree, layout managers (or even only one layout manager) would solve this problem. LCL has Anchors (a lot more advanced compared to say Delphi 7's anchors), which goes some way to solve the problem, but it is still a hit and miss case - as Lazarus proves. Constantly Lazarus dialogs are broken, due to components overlapping, text being clipped etc... This gives the application a very unpolished look. A layout manager normally solves layout problems, preferred sizes, including handling size changes due to language selections etc..

I am working on a solution though, but unfortunately the work in progress is very slow at the moment due to day job (work) related deadlines. I started implementing the Java MiG Layout Manager - first to be used with fpGUI Toolkit. But the original design of MiG Layout allows for other GUI toolkits to plug in very easily with minimal code needed. I will try and duplicate that design, so that MiG Layout Manager can work with fpGUI and LCL.

MiG Layout is a very advanced layout manager, yet very easy to use. It can reproduce any GUI layout without the need for nested layout managers. All accomplished with just one single layout manager per form. There was actually a contest about this and MiG passed with flying colors in each test.

Mig Layout even manages platform preferred button orders, positioning can be specified in any units, not just pixels (eg: cm, inches, meters etc.) & it's dpi independent. You can even toggle a "debug mode" at runtime to see how MiG Layout manages the components.

For more information about MiG Layout, have a look at it's home page. I would also suggest you download the Swing Demo and try it out. It's a fantastic piece of engineering.

http://www.miglayout.com/

Regards,
- Graeme -

Martin wrote

2) is what Java and fpgui (and afaik msegui) aim for. It is easier for the developper. But the enduser will find an application that is different to any other app he runs on his PC (and therefore harder to use)

I guess we will have to agree to disagree on the part that it's harder to use. :-) Users are not as dumb and inflexible as most developers make them out to be. End-users can adapt quite easily.

Some quick examples were applications don't follow the "look & feel" rules of the platform, yet users have no problems in using them.

* Windows Media Player.
* latest Microsoft Office with it's new menu+toolbar design
* Pixel image editor. It fakes native look. But looking closer at it, it is quite different to native platforms, yet users don't seem to have any issue with using it.
* And the biggest one of them all. The INTERNET. Websites and Web Applications like Gmail, Facebook etc... It adheres to NO single platform, yet billions of users use the internet every day and don't have problems using it. If you can read the screen, you can use the interface.

Regards,
- Graeme -

I happen to know those users you do not name. Example: Learned IE, now struggling with firefox.

But the very best (and it is a true story, I happened to witness myself: A user who had only learned one (custom, none standard interface) only keyboard driven application (which was at his place of work). This users happened to accidentally touch the mouse, and click the desktop. After that the application he used no longer responded to keystrokes. He called tech support, reporting his PC had crashed.

Those users exist too.

But of course, user interface is more that just using a specific set of widgets. And of course a custom widget set, with a well thought through command hierachy, offering the propper commonds at the right time, is a hundred times better than using the default widgets, but throwing all available commands into one or 2 unsorted menus.

Martin

I suspect these are the exceptions, rather than the rule. The vast majority of the time I am presented with a non-standard interface, I find it to be awkward and difficult to use, and it doesn't usually get any better from there. A few examples that come to mind:

* anything by hp (printer/scanner software in particular)
* non-standard installer programs (thinking of hp again)
* vi
* emacs
* the earthlink totalaccess toolbar
* almost any antivirus / antispyware program

...there are many others, but it's hard for me to think of them because I don't use them!

The best broad example I can think of that may be in agreement with what you're suggesting is SymphonyOS and the Mezzo ui. I thought it was very cool when I first learned about it in 2006, but it looks like the project has been abandoned. I've got this "MezzoGreyPaper.pdf" here, but I can't find a working link to it. It's almost like it disappeared off the internet... very strange.

Cheers,
David

David Emerson wrote

* almost any antivirus / antispyware program

:-) Now that's a good example of awful UI design! I wonder if they actually employee UI designers to purposefully screw the living crap out of their products UI to make cleaning your Windows PC from viruses any harder.

The best broad example I can think of that may be in agreement with what you're suggesting is SymphonyOS and the Mezzo ui.

OK, based on your examples, I probably had to be a lot more clearer about what I meant. I did not mean, radical changes to UI, I simply meant the idea of having a Button or ComboBox in a UI that maybe doesn' look 100% like the native one, but for all intense purposes does the same think as the native Button or Combobox. Even thought it might look slightly different (or un-themed).

This is what we are doing with fpGUI in our products. The look and feel of our applications are consistent on each platform. But it might not look identical to the native widgets of that platform. But clicking a button or selecting a menu item from the main menu back is exactly the same process in fpGUI applications as they are with native applications.

So in such a case, the average user has no problem in using our fpGUI based applications.

Regards,
- Graeme -

Really? How does it solve that on different widgetsets dialogs should have a different layout?

Not me ;) E.g. I really hate systems which have switched Ok/Cancel buttons.

Florian Klaempfl wrote

Not me ;) E.g. I really hate systems which have switched Ok/Cancel buttons.

Ah, so you are one of "those" users... that don't read the screen and only rely on muscle memory. :-)

Hopefully once I have completed to port of MiG layout, that issue would be a thing of the past as well - in ,
- Graeme -

Graeme Geldenhuys wrote

So in such a case, the average user has no problem in using our fpGUI based applications.

ok, in my original post I did not mean to impugn fpGUI or anything like this (I haven't event tested it yet). And even lazarus allows you to modify, colors, sizes and fonts to the point of unrecognisably.

A button as long as graphically well presented, is probably always easy to find. A form close button that resides in the lower, left corner (instead of upper right) is probably not even the menu layout between a mac, and a windows PC may be confusing to some people (I don't have a Mac but apparently some entries are differently placed (like about) and at least on older Macs (in the 80ties or 90ties) Menus, where always on the top of the screen (like a toolbar), even if the window was not maximized (menus where not part of the window).
Sure most people will find out quickly, and learn, but even then it is a habit breaker. You first move the mouse to where you expect the menu, not to where it is. (That is exactly why emacs is such a problem, every single key-shortcut is different, even copy and paste; oh yes I do use emacs but it took time)

If it is only looks that differ (color, maybe slight differences in size or border width) it will probably not be a it is more, like layout it becomes irritating. A gtk user may be very used to have a dropdown that allocates the full height of the screen (given it has enough entry), this gtk user will be highly irritated, if only 8 entries at a time are displayed, and he has to scroll all the time . He will be able do to it. But he may miss the comfort (comfort = what he is used too)...

And so on....

Martin

2009/11/13 Graeme Geldenhuys :

Reflex is orders of a magnitude quicker than reading and thinking. And reading and thinking wastes a lot of brain power (which I already have very little of). I still hit <Esc>/something or <Esc>* before I can think "crap, I'm in Lazarus now, not vi".

Henry

Yes, because it's quicker. Or do you look at each key before you press it :)?

Florian Klaempfl wrote

Or do you look at each key before you press it :)?

OK, you got me on that one. :-)

My co-workers hate touching my computer, because I have my keyboard set to Dvorak, but the actual keyboard keys-caps are still in QWERTY. They say I have the best password protection system installed. Even if I tell them my password, they can't type it (not without HUGE effort). :)

Regards,
- Graeme -

In my development of an docking manager I came across the idea to separate the docking related methods from the layout of the dock site. Using that separation, a GUI designer could work like a DockManager, with added features for rearranging the layout, while the layout manager part would handle the container component in a
layout (currently all TWinControls, later every DockZone) could have its own layout manager, not restricted to one single (tree) layout for an entire site (form, panel...). This approach would allow to implement the traditional (Java...) layout managers without additional cost, and most probably also would fit the MiG layout.

The "dock" zones (here better: layout zones) could be used for an additional structure of a GUI, invisible at runtime, establishing points of reference for the control placement (similar to anchor docking). The anchor docking approach looks to me too unsystematic, with too many degrees of freedom that make it hard to implement and use; otherwise it's just another layout management system, that can be used in any layout zone.

The technical implementation could look like this:

The TWinControl.DockManager is used as a layout manager (when assigned), in the following referred to as LayoutManager. When no special manager is installed, a reference to an default manager object could be returned, so that all docking and layout related functionality can be moved out of TControl and TWinControl, into the default manager class.

The layout and docking control methods of TControl and TWinControl simply defer to the new LayoutManager. This allows to replace the Delphi docking model by any other one, that is more appropriate to non-Windows platforms and widgetsets, without breaking Delphi compatibility.

TWinControl.DockSite only activates the docking related methods of the LayoutManager.

TWinControl.UseDockManager is quite obsolete then. It could indicate that a special LayoutManager has been installed, otherwise the default manager (doing almost nothing) is used.

The anchor docking related fields are removed from TWinControl and become part of the LayoutManager. Persistence and property editing must be handled somehow, just like for every other docking/layout manager.

Splitters can be removed as standalone components, and can become part of the layout management of every layout zone (kind of combination of a TPanel with an TSplitter, where the splitter position and visibility is determined from a single property of the combined component).

The form designers cooperate with the installed layout managers, using their virtual methods. The managers can use the inherited designtime methods, implemented in their base class, in csDesigning state. The designers can use the existing docking capabilities of the managers, no need to reinvent the wheel.

DoDi

Some quick examples were applications don't follow the "look & feel" rules of the platform, yet users have no problems in using them. * Windows Media Player.

I cannot use the media player or media center, due to its aberration from any application look&feel. Somebody else may be happy to use his computer like an CD/DVD player, but I had to buy an DVD player first, so that I could read how to use it :-(

* latest Microsoft Office with it's new menu+toolbar design * Pixel image editor. It fakes native look. But looking closer at it, it is quite different to native platforms, yet users don't seem to have any issue with using it.

Dunno what you mean, never used newer versions of such tools.

This is an argument for a Web (Delphi IntraWeb?) layout, portable across platforms, because it doesn't rely on any platform specific conventions
- except for the framework and interaction between multiple pages (application forms). We might have to rethink the entire application GUI, so that e.g. the placement of menus or other panes can be changed by a simple exchange of a CSS, on every platform, by every user. The same for themes, now also configurable by CSS.

DoDi

My co-workers hate touching my computer, because I have my keyboard set to Dvorak, but the actual keyboard keys-caps are still in QWERTY.

That is geeky, I must say. Wow!

Juha

Correct and it is a good tool.

But the layouting in ExtJs (and hence ExtPascal) leaves to be desired :(

Michael.

I thought the default look of Ext JS was an improvement over the qooxdoo JavaScript widgets used by Delphi for PHP.

Thanks.

-Phil

Phil Hess wrote

I thought the default look of Ext JS was an improvement over the qooxdoo JavaScript widgets used by Delphi for PHP.

Looks: yes, absolutely - it looks fresh and modern.

Layout: Not so good.
The toolkits behaviour when adding html and resizing the browser window is not so good :(

Michael.