Hi,

I just found this very interesting video about Delphi XE7 (or AppMethod) and how the form designer can design for multiple device targets. Very clever usage of Visual Form Inheritance.

https://www.youtube.com/watch?v=fmA7KLlOR1U

How does Lazarus IDE (or LCL) handle this? Can you develop for multiple targets with a single source code base? Or is this beyond the scope of LCL (eg: LCL is only meant for desktop apps)?

Regards,
- Graeme -

I only use Lazarus for desktop apps. But I haven't checked most features it offers

On Wed, Feb 25, 2015 at 3:05 PM, Graeme Geldenhuys <

Of course you can use VFI to create custom views - for different platforms, devices, releases or whatever flavors.
XE7 took a common case - devices - and made that simpler by having only one unit and load a second resource automatically. Theoretically Lazarus could be extended to do the same (or more flexible), but the LCL will still use the native controls, so the "preview" is limited.

Mattias

While (AFAIK, not having watched, yet) in Delphi XE this is only possible with FireMonkey, and hence porting existing Desktop VCL-applications to other platforms is close to impossible, with Lazarus compiling for all supported platforms should be possible using the the LCL that is rather similar to the Delphi VCL.

So - disregarding technical details - Lazarus should be better regarding portability.

-Michael

Michael Schnell wrote

While (AFAIK, not having watched, yet) in Delphi XE this is only possible with FireMonkey

Correct, the Delphi video was just for the FireMonkey toolkit - hence my comment if LCL is only meant for desktop development (like VCL). I don't know what LCL is targeting these days... still only VCL compatibility, or slowly moving towards FMX compatibility.

Is the LCL-CustomDrawn widgetset maybe meant as the target for FMX compatibility?

Regards,
- Graeme -

Mattias Gaertner wrote

Of course you can use VFI to create custom views - for different platforms, devices, releases or whatever flavors.

But the difference between Delphi and Lazarus would be how you reference those forms. In Delphi FMX (as far as I understand) you would simply reference your form as SomeForm - regardless of the target device. FMX would resolve that automatically to the correct device specific implementation if one exists.

Whereas in Lazarus LCL's VFI you would have different units and different form names for each target. So you would have to wrap all those in IFDEF's. Is this correct?

flexible), but the LCL will still use the native controls, so the "preview" is limited.

Understood.

Regards,
- Graeme -

Graeme Geldenhuys wrote

Is the LCL-CustomDrawn widgetset maybe meant as the target for FMX compatibility?

Do you think it _should_ ?

Do you see a real advantage with FireMonkey ? (I did not even do a "hallo world" with same.)

In fact, AFAIK, the FM library once was a freely available library that should be usable with fpc. So FM on fpc should be just around the corner, if anybody like it.

-Michael

Am 25.02.2015 11:35 schrieb "Graeme Geldenhuys" <

Delphi's VCL was not portable to anything else than Windows, which is why Embarcadero added FireMonkey. The LCL however /is/ portable so we don't need FM and can instead improve the LCL to handle this better including native look and feel.

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150225/21e3071d/attachment.html>

Michael Schnell wrote

On 02/25/2015 11:35 AM, Graeme Geldenhuys wrote: > Is the LCL-CustomDrawn widgetset maybe meant as the target for FMX > compatibility? Do you think it _should_ ?

I honestly don't know what LCL-CustomDrawn is targeting. It also isn't in a usable state at the moment and still needs a lot of development before it is usable.

Do you see a real advantage with FireMonkey ?

Well, considering that VCL is _very_ Windows specific, Delphi needed something different to target other platforms. FireMonkey toolkit was their ticket. CLX could also have been their answer (as Qt runs on pretty much every platform out there), but Borland/CodeGear/EMB long forgot about CLX.

In fact, AFAIK, the FM library once was a freely available library that should be usable with fpc.

I'm pretty sure FMX now uses many Delphi specific features that wouldn't make it compilable with FPC any more. I also don't know (but would like to find out) if Delphi includes full source code of FMX - in case somebody wanted to try and do a personal port to FPC.

Regards,
- Graeme -

Sven Barth wrote

we don't need FM and can instead improve the LCL to handle this better including native look and feel.

Okay, so does that mean currently LCL can't target Android or iOS, but the possibility could exist in the future? The reason I say this is because to date there is no LCL-iOS or LCL-Android widgetset to choose as a target.

I haven't really tracked the progress of LCL over the last couple of years. So I'm just trying to compare Delphi and Lazarus to see how they compare for multi-platform and multi-device development. I'm trying to see if Lazarus is a viable option for a future project, or am I better off spending the small fortune and buy a copy of Delphi XE7 (or AppMethod). Maybe alternatives like Xamarin is an option too, but I would like to keep to the Object Pascal language if possible.

Regards,
- Graeme -

Check out LazAndroidModuleWizard. Quite promising for Android apps but not LCL compatible.

http://forum.lazarus.freepascal.org/index.php?topic=21919.0 https://github.com/jmpessoa/lazandroidmodulewizard

Stephano

Graeme Geldenhuys wrote

I honestly don't know what LCL-CustomDrawn is targeting. It also isn't in a usable state at the moment and still needs a lot of development before it is usable.

AFAIK, CustomDrawn is trying to restrict the necessary functionality of an external WidgetSet to as little objects as possible and build up all GUI elements from this in Delphi code.

> Do you see a real advantage with FireMonkey ? Well, considering that VCL is _very_ Windows specific,

IMHO the LCL proves that close to all VCL features can be done as good (or even better) with other Widgets sets than just "Windows".

Borland failed with trying to port the VCL with Kylix, but IMHO Lazarus does an excellent job with the same task.

I can't think of any language features that would make this necessary. Did they update the X86 compiler greatly making it decently incompatible to fpc ?

I also don't know (but would like to find out) if Delphi includes full source code of FMX - in case somebody wanted to try and do a personal port to FPC.

I once found the source code of the original library (before bought by Embarcadero). I'm not sure if I saved it. But of course they tried to remove it from the Internet after they changed the license.

-Michael

Michael Schnell wrote

I once found the source code of the original library...

"DXScene".

I do have some "DX" files fetched at that time. I did not ever open the ZIPs :-(

-Michael

Michael Schnell wrote

I once found the source code of the original library...

"GLScene".

I do have some "GL" files fetched at that time. I did not ever open the ZIPs

-Michael

Michael Schnell wrote

> Well, considering that VCL is _very_ Windows specific, IMHO the LCL proves that close to all VCL features can be done as good (or even better) with other Widgets sets than just "Windows".

I agree that the Lazarus team did a very good job, but I still consider the LCL design to Windows centric (by looking at what I had to implement to get LCL-fpGUI to work). And as you might guess, the reason I started fpGUI Toolkit is because LCL was (and still is - in my opinion) too limiting for some of the application I had to develop over the last 5 years. Your mileage my vary.

Borland failed with trying to port the VCL with Kylix,

No, they failed to market Kylix correctly, thus lost interest too quickly. To date there are still companies [though getting less] like Scooter Software that use Kylix and CLX. The Kylix IDE was a bigger problem than the actual CLX toolkit.

Either way, we are straying from the topic at hand.

I can't think of any language features that would make this necessary.

I guess the only way to find out is to buy a copy of XE7 and try to compile FMX with FPC.

Regards,
- Graeme -

Michael Schnell wrote

But of course they tried to remove it from the Internet after they changed the license.

Hmmm:

http://sourceforge.net/projects/glscene/ Last Update: 2015-01-27

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150225/2dfa3b89/attachment.html>

Michael Schnell wrote

On 02/25/2015 12:26 PM, Michael Schnell wrote: > I once found the source code of the original library... "GLScene".

You mean this... [http://sourceforge.net/projects/glscene/]

I think you got confused. FireMonkey originated from KSDev's product called VGScene. --- [http://en.wikipedia.org/wiki/FireMonkey]

Regards,
- Graeme -

I doubt that we can make the LCL FireMonkey compatible. For the features you saw in the video customdrawn controls are needed. So I guess LCL-Customdrawn could be used for that.

Mattias

I guess, but I only saw the promotion video, so maybe it is not that simple.

If someone wants the same in Lazarus:

For example the {$R *.iPhone4in.fmx IOS} directive can be replaced with
{$ifdef iphonesim}{$R *.iphone4in.lfm}{$endif}

The LCL (or msegui or whatever GUI lib) needs to be extended to search and load the second lfm resource. That needs only a few lines of code.

And finally the IDE needs to be extended to load/update the secondary lfm.

Whereas in Lazarus LCL's VFI you would have different units and different form names for each target. So you would have to wrap all those in IFDEF's. Is this correct?

Well, you could do it without IFDEFs, but then all resources are compiled into the binary. Or you can load the lfm files via another mechanism.
When programming multi platform the question is not *if* you need IFDEFs, but how many.

Mattias

Am 25.02.2015 12:02 schrieb "Graeme Geldenhuys" <

You cam do this with the CustomDrawn target. Please note that the widgetset for iOS is simply Cocoa and not "iOS" (though I don't know what's more usable: the Cocoa widgetset or the CustomDrawn-Cocoa widgets; I'd need to experiment with that on my Mac ^^ )

You could also try Oxygene which supports both iOS and Android, but you'll have to write platform and framework specific code for both... (so no abstraction like the LCL does for example)

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20150225/8847d4bb/attachment.html>

Well, a feature like this is something i suggested some years ago already... although not for supporting mobile devices (IIRC iStuff wasn't much of a thing then) but to properly support alternative layouts for different OSes. Even if Lazarus sticks to desktop only stuff, Windows, Linux and OS X (...especially OS X) have different conventions when it comes to layout, icons, spacing, etc and at the moment the only solution is either ignore them (and have your program look awful under OS X) or do manual modifications via code inside {$IFDEF} blocks to adjust things (which is painful, error prone and even that quite limiting - button order or using a different set of icons is impossible, unless you position the buttons manually and load the icons from the disk).

The form is already a separate file from the code and the IDE has functionality to unload and reload it, how hard would it be to switch between different form files? The hardest part would be to make sure all forms provide the same components (especially when adding a new component that might be under a different parent) but that could be left up to the programmer (since the IDE already does a check to see if the code matches the form so it can remove stuff like events or missing components, if you try to launch a program with a form file that doesn't match, the IDE might not allow you to run the program unless you add the missing components).

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

MSEi18n actually works with such an approach. It builds different resource-dll's/so's for different languages based on master form resource files (MSEgui counterpart of Lazarus *.lfm files) and a property table with a column for every language. The application loads the coresponding dll/so based on the language settings.
Several years ago MSEi18n already has been used to adapt the gui of an application for different display environments:
http://wiki.freepascal.org/MSEide_&_MSEgui#An_embedded_system

It is planned to extend MSEi18n with a form designer in order to edit the widget properties graphically.

Martin

Kostas Michalopoulos wrote

Even if Lazarus sticks to desktop only stuff, Windows, Linux and OS X (...especially OS X) have different conventions when it comes to layout, icons, spacing, etc and at the moment the only solution is either ignore them (and have your program look awful under OS X)

There is an alternative solution. In the fpGUI project we have ongoing efforts to port/implement a Object Pascal version of the java MIG Layout Manager. One of MIG's many features is support for OS specific conventions like spacing, button order etc.

http://www.miglayout.com/

If you can, run the Swing Demo to see what everything MIG can do. Part of the demo is the OS specific conventions.

Regards,
- Graeme -

I cannot run the demos since Java now blocks everything that hasn't submitted to the certificate mafia - apparently that was easier than Oracle sandboxing their VM, but i took a look on the PDF. And sadly this isn't a real solution.

This only solves issues like positioning, but doesn't solve issues like having the File -> Exit menu item being hidden in Mac builds, the "Apple" menu (where the Quit menu item should be in Mac) being hidden in Windows and Linux builds, using Cmd as a shortcut prefix instead of Ctrl, using different images for Windows, Linux and OS X (since all these three OSes have different design styles - ok Linux and Windows can share theirs, but OS X icons tends to be larger and usually the toolbars have less buttons), etc.

In fact personally i'd be against such "quick fix" solutions because they'll provide less incentive to do the right thing later.

On Thu, Feb 26, 2015 at 11:49 AM, Graeme Geldenhuys <

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