Hi,

See http://delphimax.wordpress.com/2011/08/04/delphi-64bit-os-x-and-iphone-native/#comment-743 and http://delphimax.wordpress.com/2011/08/04/delphi-64bit-os-x-and-iphone-native/#comment-749 (Michael Swindell works for Embarcadero):

"Re FPC, we will be coming out with a Delphi ARM compiler at some point, but we're appreciative that FPC is available today for ARM/iOS and we were able to leverage to get FireMonkey to iOS."

So it's just a stopgap solution for them until they have time to build their own ARM compiler, but the fact that they will ship FPC definitely serves as a testament to its quality :) Very cool!

Jonas

jep her too:
http://www.andreanolanusse.com/en/video-delphi-xe2-and-firemonkey-app-on-windows-mac-and-ios/

in the comments:
Andreano Lanusse:
"yes, on this release we are using FreePascal to compile the iOS apps"

I can see the messages in the changelogs of Delphi:

"Reason: FPC compatibility"

There is a risk of an endless loop here, or a deadlock of some sort 8-)

Good news: the new Firemonkey framework is already 100% compatible with Freepascal by design.

Jonas Maebe wrote

... but the fact that they will ship FPC definitely serves as a testament to its quality :) Very cool!

This is very good indeed! 10/10 to the FPC developers. :)

+1

Marcos Douglas

Jonas Maebe wrote

...So it's just a stopgap solution for them until they have time to build their own ARM compiler...

wow! The former state of the art compiler vendor
(Borland/Inprise/Borland/Codegear/Emb...) is not able to produce a compiler of its own ;-)

Regards, Bernd.

Going from a completely i386-specific code generator to an ARM code generator is a lot of work, especially if you at the same time also have to create a 64 bit code generator. It also took FPC several years to migrate from it's i386-specific design to a more generic one, and to subsequently add x86-64 and ARM support.

Jonas

Jonas Maebe wrote

Going from a completely i386-specific code generator to an ARM code generator is a lot of work, especially if you at the same time also have to create a 64 bit code generator.

Maybe they should just call it quits on there compiler product, and at the same time save themselves a boat load of cash and time, and simply used FPC as their compiler, and then put their resources towards building a cross-platform developer tool chain around the FPC compiler (like IDE and GUI framework/bindings etc). Oh wait, they are already doing that for ARM. ;-)

Makes you wonder, will they start submitting patches for FPC too?

they could even save more time, it they would use Lazarus ;-)

Makes you wonder, will they start submitting patches for FPC too?

I had the same thought. What happens, if their customers report bugs concerning the code generation? Are they competent enough to fix them? (I don't think so)

Regards, Bernd.

Makes you wonder, will they start submitting patches for FPC too?

that was what I was wondering about as well. Why not participate in fpc/lazarus development and "add" the missing features (packages etc; some language features) or "update" the D7-isms to XE standards instead of doing it themselves? In exchange they would get the benefit of the x-platform bit.

and when they are at it, they could then deploy their own additional packages/components/libraries/helpfiles with their packaged product.

fpc might then even benefit from their x86 speedup knowledge and we could get rid of the comments "delphi compiler is x times faster than fpc" that pop up every once in a while. :-)

kind regards,
Dimitri Smits

Bernd Mueller wrote

What happens, if their customers report bugs concerning the code generation? Are they competent enough to fix them? (I don't think so)

I can't imagine why they wouldn't be able to do so. And I don't understand all this hostility towards Embarcadero. You can reword everything in just the same derogatory terms towards FPC developers when an LLVM backend or so is added ("are they competent enough to fix bugs in LLVM if they find one", "why don't they just drop FPC altogether and integrate everything into Clang", "Are they too stupid to implement all those analyses, optimizations and register allocators directly into FPC", ...).

Developers building on top of existing code to fill a gap they can't easily/immediately fill themselves is not a sign of incompetence. If anything, I consider it a sign of open mindedness.

Jonas

Graeme Geldenhuys wrote

Makes you wonder, will they start submitting patches for FPC too?

I hope so. The main problem I see with that is that they would become somewhat "tainted" by the FPC source code if they do so, which may make it harder to work on their own compiler later on. As long as they don't start blatantly copying code from FPC into their own compiler (like some people did in the past with Delphi RTL code into the FPC RTL) I don't think anyone who has contributed to the compiler would really care if they learned a bunch of stuff from our code base, but of course they have lawyers who almost certainly will care a lot.

This can of course be solved in various ways (have someone who normally does not work on their compiler work on ours, hire a someone temporarily to do that work, external contractor, ...).

Jonas

In our previous episode, Jonas Maebe said:

And keep in mind that for Embarcadero it is not just a codegenerator, but also (at least) assembler, linker and probably debugger. (see the remark about XCode)

In our previous episode, Jonas Maebe said:

I'm not sure that actually happened in all cases. It was a bubble, and internal frameworks in companies were quickly thrown together with whatever code available (and Delphi code being no problem since they had licenses), and later they were donated to FPC later.

That doesn't meant it wasn't wrong, both the donating as the accepting party should have checked and noticed it. But that is something else then knowingly copying it.

That being said, there is another bubble going on in Mobile, and we have to be very careful that such things don't happen again.

they could even save more time, it they would use Lazarus ;-)

That's the one part they - Embarcadero - are still miles ahead in productivity and reliability. Lazarus is workable - more than that - but still cannot compete with Delphi in productivity - but that of course is for Windows only. I use both, but I use an Delphi IDE for development. The second part might be their new framework.

Still, it is good news and I rather like the idea of Delphi as a development environment for the FreePascal toolchain.

I would not be surpised at all if they have done so. After all, they really appreciated the clean-room stuff done on FPC's RTL. This might sound strange after legal threads, but that is how California works. They are still very capable of destroying parts of the FreePascal community, especially Lazarus, in at least the USA and based on their strong patent portfolio if they would take up legal action. This is something that should not be forgotten: see the Sun->Oracle-> Sue you Google about Android.

Bernd Mueller wrote

they could even save more time, it they would use Lazarus ;-)

I wouldn't mind them building a workable debugger for FPC.

Florian, has anybody from Embarcadero approached you on this? I wonder if they know that any modifications they make to the FPC compiler must be made available as open-source? The compiler is GPL'ed after all.

Jonas Maebe wrote

> Makes you wonder, will they start submitting patches for FPC too? I hope so.

+1
At least for now FPC scored some bragging rights. :)

The main problem I see with that is that they would become somewhat "tainted"

A very valid point.

own compiler later on. As long as they don't start blatantly copying code from FPC into their own compiler

The problem is, how would we know? Nobody can see their compiler code.

Good news is that any modifications or bug fixes they make, they will have to share. But then comes the second question, how do you monitor something like that?

Graeme Geldenhuys wrote

Good news is that any modifications or bug fixes they make, they will have to share.

They only have to share them with their customers who get the binary (and even then only for nominal shipping and handling fees). Of course, those customers are then free to pass them along further, if they want to. And in practice, I can't imagine what advantage Embarcadero would have by not immediately publicly sharing any such changes rather than by going through such hoops.

But then comes the second question, how do you monitor something like that?

In general, you don't and just rely on the honour system. If you really suspect someone from copying code, you have to rely on reverse-engineering to figure things like that out. It would surprise me a lot if copy/pasting our compiler source code into their compiler and then adapting/debugging it would be much less work than immediately rewriting it though.

Jonas

contrary to popular belief, it is not so that if you GPL something, everyone gets your source (ie: the community; by way of "give back"). If you take a open source project ((L)GPL that is, not talking about MPL/MIT/BSD/...), and you modify it, then sell it, the licence does not require you to give away the source to everyone! Only to your customers(/competitors) who bought the program!

Likewise, when you take such a project with such a licence, maybe even straight GPL, and modify it, but only use it in-house, then you owe nobody anything. (since the source is handed over to the client, ie: yourself)

btw, I even believe that you can devise a licence that is GPL compatible (copyleft), but that disallows redistribution/resell. Like a bit of an NDA.

kind regards,
Dimitri Smits

In our previous episode, Dimitri Smits said:

As Jonas said, those can pass it on freely. And due to the scale of an Embarcadero launch (it is not 3 or 4 private customers Embarcadero sells too) that is nearly the same.

Likewise, when you take such a project with such a licence, maybe even straight GPL, and modify it, but only use it in-house, then you owe nobody anything. (since the source is handed over to the client, ie: yourself)

btw, I even believe that you can devise a licence that is GPL compatible (copyleft), but that disallows redistribution/resell. Like a bit of an NDA.

And what is that belief founded on? :-)

Anyway, there are more gotchas. They could e.g. have stuff like linkerscripts in a external files, and since they are not GPLed, not deliver them. (as in the case of Microchip gcc, where all linker scripts and all headers for the (many) individual parts were not included).

All being said, I wouldn't get my hope up. Most changes will probably be interoperability with their own toolchain. (e.g. I can imagine they change the cmdline module to be (more) dcc compat). And it is only a stopgap solution for an year. A handful of minor bugfixes is the best we can hope for.

Personally I think bugreports from users themselves will be a bigger treasure than what the GPL will deliver.

Marco van de Voort wrote

Anyway, there are more gotchas. They could e.g. have stuff like linkerscripts in a external files, and since they are not GPLed, not deliver them.

a) again, I have a really hard time imagining that the people at Embarcadero would go out of their way to share as little as possible as far as the compiler is concerned (which is what everyone here is theorizing about) b) at least the linker script example cannot happen, because Apple's linker simply does not support linker scripts

Personally I think bugreports from users themselves will be a bigger treasure than what the GPL will deliver.

I would not call bug reports "treasure". Patches, maybe, but bug reports not. Especially for the iOS platform, which Apples makes very painful to develop for at a low level if you don't go the jailbreak way.

Jonas

In our previous episode, Jonas Maebe said:

Honestly, I don't know. For good or worse. I haven't seen much open source spirit from them yet.

b) at least the linker script example cannot happen, because Apple's linker simply does not support linker scripts

I named that example because it is a GPL cirumvention case that actually happened . Not because I expect it to happen in this case.

Jonas Maebe wrote

And I don't understand all this hostility towards Embarcadero.

Indeed. People should be happy that there is a pretty large commercial vendor which provides an professional object pascal development environment. Even if one doesn't use it, one should be aware that it really helps to keep pascal (well, they call it Delphi ;)) a living language.

If someone gets access to the Embacadero supplied compiler(and some of the professional people probably will), they can run a differential test suite run for ARM and see if they fixed any of the remaining problems :)

Florian, as I suppose, when you started the compiler , it could not be possible to develop a compiler written in pascal without the turbo pascal? So not only the product inspired, it was also a tool to build all other things upon.

By the way, is it possible that when Delphi and fpc are now officially friends :) the some official inter-discussion possible before introducing some important things or before changing some things? Or you don't think that it will be useful?

Max

+1
-Michael

Jonas Maebe wrote

So it's just a stopgap solution for them until they have time to build their own ARM compiler,

They continue to use the product from RemObject as their .Net compiler :). So I suppose they are not in a hurry (in case that FPC works as expected, which nobody doubts.)

-Michael

AFAIU, the Windows 32 FPC has some disadvantages regarding the Delphi compiler (compiling speed, executable speed, executable size). (Obviously providing multiplatform does not come for free.)

-Michael

[joke] they could also shoot the lawyers and remove that particular problem... the world would be better for it, too ;) [/joke]

personally, i think it is a GoodThing<tm> that they are using FPC in some way and it would be nice if they would/could contribute code back to FPC... all in all, at this point in time, it appears to be +1's ;)

Marco van de Voort wrote

That being said, there is another bubble going on in Mobile, and we have to be very careful that such things don't happen again.

May I ask you to explain what you mean here? (Just curious)

Regards,
Sven

I better hope they continue to use RemObject's .NET compiler... Delphi.NET was a death-birth and that should not be repeated. At least Embarcadero has admitted that way that someone else has built a better compiler for that platform. It will be interesting to see whether they want to license Cooper, RemObject's upcoming Pascal compiler for Java, as well; their plans to support Android as well in the future could mean this.

Regards,
Sven

In our previous episode, Sven Barth said:

> That being said, there is another bubble going on in Mobile, and we have to > be very careful that such things don't happen again. May I ask you to explain what you mean here? (Just curious)

That donations of large pieces of code are not checked properly. Specially for parts (new units) that we don't know very well, and thus copyrighted code is more likely to go unnoticed.

Thanks for explaining, but could there really be such a problem as FPC is more or less the first Pascal compiler on such platforms? Or does converting copyrighted C(whatever) code count here as well? (Sorry, if I sound a bit naive, but I still have problems with all that copyright and license stuff...)

Regards,
Sven

It was not only the VCL. They included stuff in the assemblies that made them basically hard to use from other languages. Things like initialization and finalization sections just don't work that well in the CLR.

Regards,
Sven

Hans-Peter Diettrich wrote

IMO CodeGear stumbled with Delphi.NET over the same stone as with Kylix: the Win32 centric VCL :-(

Non-sense, if it was like that Gtk2 would be a huge failure, because it is totally X11-centric, but nevertheless it has a very big usage.

Plus, the LCL is much more compatible with the VCL then the CLX was and the LCL succeeded.

In our previous episode, Sven Barth said:

And mandatory destructors implemented by implementing idispose alway, iirc.

I knew there was something else :)

Regards,
Sven

I already explained that for a good reader. Google versus Oracle on specific issues about Android.
In this case: before Oreacle took over Sun, Sun was actively encouraging Google to develop Android and saw it as a strengthening of the Java platform.
After Oracle took over their point of view (b.en) or standpoint (usa.en) changed 180 degrees.........
But that is just a part of it on Mobile.

How can you be sure that it was the compiler? A compiler for .NET is not a big deal, adding an parser for the language is almost enough.

IMO CodeGear stumbled with Delphi.NET over the same stone as with Kylix: the Win32 centric VCL :-(

Now they try not to stumble across it for another time, and use an approved toolkit. Finishing the new library took precedence over an new compiler, so that they decided to use FPC, for the beta version.

Just my 0.02€

DoDi

Hans-Peter Diettrich wrote

IMO CodeGear stumbled with Delphi.NET over the same stone as with Kylix: the Win32 centric VCL :-(

I don't think that the VCL was the issue with Kylix. The issues were (a) uncertainty over the Linux community's acceptance of a non-free development environment and (b) the difficulty of having a binary release which was guaranteed to install on any distro or version.

In our previous episode, Mark Morgan Lloyd said:
[ Charset windows-1252 unsupported, converting... ]

c) betting on a desktop Linux revolution that never really came.

Mark Morgan Lloyd wrote

I don't think that the VCL was the issue with Kylix. The issues were (a) uncertainty over the Linux community's acceptance of a non-free development ....

Add to that list:
- CLX was buggy as hell because they didn't even write the Kylix IDE using CLX.
- Developers kept comparing VCL to CLX because Borland marketed it like that. They should
have done what EMB is doing with FireMonkey. Clearly state it is a different framework
that will have the RTL and other non-gui code in common.
- They priced Kylix way to high in the beginning.
- CLX was never updated to Qt 3 when it came out. CLX was based on Qt 2.2 or something like that.

I'm pretty sure Kylix and CLX would have worked if Borland just paid a bit more attention to quality and better marketing. Oh well, that's all done and dusted.

Sven Barth wrote

It will be interesting to see whether they want to license Cooper, RemObject's upcoming Pascal compiler for Java, as well; their plans to support Android as well in the future could mean this.

Of course Cooper would be a way to support Android for framework based apps. Additionally, KSD (the name of FireMonkey before Embarcadero bought it) supports ARM Linux and it should be possible to make it run as a native application on an ARM based Android (same for x86 based Androids).

-Michael

Graeme Geldenhuys wrote

I'm pretty sure Kylix and CLX would have worked if Borland just paid a bit more attention to quality and better marketing.

+1
-Michael

Even if KSD or now FireMonkey supports ARM Linux this does not mean anything for Android. While Android does support native Linux applications it does not have a X server. Currently the only possibility for this is to run a X server through a VNC viewer and thus you can not reproduce the usual feel of an Android application. For that you'd need to write a Java bridge.

Regards,
Sven

I read in several publications that there is QT for Android (e.g. by Bogdan Vatra (
http://www.osnews.com/story/23022/Qt_on_Android_the_Bogdan_Vatra_Interview/ ) or http://gitorious.org/~taipan/qt/android-lighthouse , http://gitorious.org/~taipan/qt-creator/android-qt-creator , http://www.androidpit.de/de/android/blog/391847/Qt-Portierung-fuer-Android-in-der-Entwicklung ). I don't know wheter same uses an X-server that is to be installed on the device, or some other means to do the Graphics etc, but it should be doable to use a similar way to provide an APIU for KSD to use.

-Michael

As far as I know VXScene is entirely userdrawn, so a native android application could just use OpenGL to draw the components. Android also has some support for a pixbuf object in native mode, which I guess could be used for the same

My guess would be that this is the way QT does it too

ra_Interview/
) or http://gitorious.org/~taipan/qt/android-lighthouse , http://gitorious.org/~taipan/qt-creator/android-qt-creator , http://www.androidpit.de/de/android/blog/391847/Qt-Portierung-fuer-Android-i n-der-Entwicklung
). I don't know wheter same uses an X-server that is to be installed on the device, or some other means to do the Graphics etc, but it should be doable to use a similar way to provide an APIU for KSD to use.

According to http://labs.qt.nokia.com/2011/02/28/necessitas/#comment-19682 the qt port uses the framebuffer driver. There is also a qt port for iOS in the making. No need to run after KSD...

Ludo

Bovine excrement, but I admit only partially, depending on version: There are X servers running on Android and there is qt running on Android. Except you need at least 2.3 or maybe a high 2.2.x, never had those.

I have qt code running myself on an very cheap Android 2.3 tab from a toyshop and it works a charm.
I also have Mono/.net code running on it.
Currently both under C and C#. The Freepascal examples run a bit strange (maybe ARM EABIv7 for Cortex 8, still palyimng with it) You definitely only need JNI before Android 2.3. So that part is correct.

Thaddy wrote

I have qt code running myself on an very cheap Android 2.3 tab from a toyshop and it works a charm.

What is the size of an app using Qt on Android counting the Qt libraries that it downloads?

I know about X servers running there (I have looked that up today morning, because I liked to know whether I somehow could run Wine on Android), but all I've found yet was the restriction to access the X screen through a VNC viewer. If you know more, I'd be glad to hear that. :)

And yes, I wasn't aware of QT.

I have qt code running myself on an very cheap Android 2.3 tab from a toyshop and it works a charm.

Does the QT app look and act like a "native" Android app? Did you (or someone else) test whether the LCL would work there using QT?

I also have Mono/.net code running on it. Currently both under C and C#. The Freepascal examples run a bit strange (maybe ARM EABIv7 for Cortex 8, still palyimng with it)

Doesn't .NET use a bridge to Dalvik? At least that's the last I know.

You definitely only need JNI before Android 2.3. So that part is correct.

Things definitely got better with 2.3. That far I'm aware of it ^^

Regards,
Sven

PS: Nice workaround with your "bovine excrement" :P

Felipe Monteiro de Carvalho wrote

toyshop and it works a charm. What is the size of an app using Qt on Android counting the Qt libraries that it downloads?

Just what you expect from any GNU compiled program and just what you expect the runtime libraries to be with any qt based program. Counting the libraries is not as relevant, the Android runtime is also several bytes...
Since you have access to a NDI native screenbuffer you can use opengl v 2 to render anything directly without qt if you want, so small is definitely possible.

You need a 8 or 16 G card though, for now, to use the "establishment" or a rooted device.

It works. There is a VNC server for Android for free.

Does the QT app look and act like a "native" Android app? Did you (or someone else) test whether the LCL would work there using QT?

Not really/ somewhat / close enough

I bought my tablet for €149 in a toystore (with amazing specs for the money) just to get FPC running on it, so I will keep you posted about my progress. As I implied: a shared library isn't the problem. Native rendering is, that's why I am exploring the Qt and Mono alternatives first. When I am satisfied that works I look into qt/fpc android.

I mean running on your Android machine and as an X-server..

IMO copyright and software patents are subject to U.S. lawyers only. In general only a concrete implementation of an algorithm is protected, not the algorithm itself. The same algorithm, implemented in a different language, can not really violate any rights, even if it results in the same binary code.

Of course judges may have different opinions on such issues, based on their interpretation of specific local law.

DoDi

That's what I've read as well.

Yes, keep me or better us updated on the progress. It will still take some weeks until I get my hands on an Android phone, till then I need to wait. :)

Regards,
Sven

Thaddy wrote

Since you have access to a NDI native  screenbuffer you can use opengl v 2 to render anything directly without qt if you want, so small is definitely possible.

Umm.. I'm getting more and more interested in the Android platform. Maybe it's time I officially start working on a OpenGL backend for fpGUI. fpGUI would at least guarantee a small executable - at least compared to LCL.

I'll be Google'ing some more tonight. :)

At least you can use the Android emulator even if you don't own an Android device ;)

I also already thought about using fpGUI, but as a LCL backend. The reason is that I have two Windows Mobile LCL applications that are tailored to my own needs that I'd like to use when I have a new Android phone. As far as I'm currently aware of the state of LCL-fpGUI (I never tested it yet) I'll need to implement TTreeView...

Regards,
Sven

Sven Barth wrote

I also already thought about using fpGUI, but as a LCL backend. The reason is that I have two Windows Mobile LCL applications that are tailored to my

I have created a few GPS related apps using fpGUI (directly) for my Garmin PDA. It was just to see if I could, and they work quite well. :) I'm planning on adding a WinCE theme to fpGUI soon, so then such apps should blend in a bit more - but I'm not to fussed about things looking different (hey, I work on Linux - where are no standards or native widgets).

I'm currently aware of the state of LCL-fpGUI (I never tested it yet) I'll need to implement TTreeView...

I really can't say. I simply make LCL-fpGUI compile every now and again with the latest fpGUI. I don't develop LCL-fpGUI, because I simply don't have the time to fight with LCL and fpGUI bugs, and implement new features in fpGUI.

I will offer fpGUI support to anybody that works on LCL-fpGUI though. So if you do go that route and get stuck with fpGUI concepts, don't hesitate to send me a mail.

Sven Barth wrote

I also already thought about using fpGUI, but as a LCL backend. The reason is that I have two Windows Mobile LCL applications that are tailored to my own needs that I'd like to use when I have a new Android phone.

The LCL-Android already has some basic components implemented. Button clicking works, for example.

But I already foresee a difficulty in porting existing apps because the controls and fonts in Android are much bigger then in desktop platforms. Fixed-size layouts will have a hard time being ported.

This could be fixed by introducing some phone-like layouts in the LCL, like the linear layouts from Android.

As far as I'm currently aware of the state of LCL-fpGUI (I never tested it yet) I'll need to implement TTreeView...

If you ever do, please implement it in the Custom Drawn Package from Lazarus, then we can use this TCDTreeView in both LCL-Android and LCL-fpgui =)

Since some time I've converted to a huge fan of LCL's autosize feature ^^

Also as my current phone has basically the same structure (portrait device, not much space) I wouldn't see a problem with those two applications of mine.

I thought more in the terms of using the treeview component provided by fpGUI (Graeme?)... especially as I only need it working for two apps and thus it's rather likely that I'll implement only the features needed.

Regards,
Sven

Ludo Brands wrote

According to http://labs.qt.nokia.com/2011/02/28/necessitas/#comment-19682 the qt port uses the framebuffer driver.

I don't know if this Frambuffer needs to have and/or already has the necessary support for OpenGL, that I understand to be what KSD (maybe more correctly to be called "KSDev/GLScene") sits on.

There is also a qt port for iOS in the making. No need to run after KSD...

Seemingly EMB things other (supposedly because they don't dare to implement QT or KDE support in the VLC (what the LCL already happily provides), they offer a completely new cross-platform GUI kit :( .

It might or might not be a good idea for Lazarus to offer "FireMonkey" support as well.

-Michael

I prefer other approach. My application have webapp with embedded http server, crosscompiled to ARM as Android library
Whole GUI act in webview
(http://developer.android.com/reference/android/webkit/WebView.html ) Only small Jni is needed to loadlibrary

For me browser has more capabilities than native widgets. With full css3 support i can use gradient background, rounded corners etc. HTML5 today is most powerful attempt to GUI : fast,full-featured, multiplaftorm, OS agnostic,

And more important for me: the same code I can use on several OS: Android, WebOs, Linux, Windows, .. iOs ( I hope that FPC will be able to crosscompile to iOs soon), server can be embedded or standalone

It work on toy tablet with android 2.1 and Samsung Galaxy , then same as on desktop computers.

Graeme Geldenhuys wrote

Umm.. I'm getting more and more interested in the Android platform. Maybe it's time I officially start working on a OpenGL backend for fpGUI. fpGUI would at least guarantee a small executable - at least compared to LCL. I'll be Google'ing some more tonight. :)

Remember to google on gingerbread and ndk, the i was a typo. This is a good starter link
http://developer.android.com/sdk/ndk/overview.html

Felipe Monteiro de Carvalho wrote

This could be fixed by introducing some phone-like layouts in the LCL, like the linear layouts from Android.

That's what I am currently experimenting with in opengl. I don't mean to turn it into a full widgetset, though.
Another way is maybe to use html5 browser rendering for a UI.

On 12-8-2011 10:52, Dariusz Mazur wrote:

My previous post crossed yours! Tnx for the good work.

Just one hint: Android is a *lot* more then just drawing some graphics. For example:

1> Virtual keyboard. There are dozens and dozens, even widespread devices like Galaxy Tab come with non-standard keyboards, some of them only for China, some only for Taiwan. The manufacturers always make sure the standard widgets work fine with those keyboards, but custom drawn toolkits have a really hard time keeping up. And you can't test this with the emulator, you need 100+ devices to make sure it works everywhere. I don't know what Qt did, but I bet it doesn't work with half of the virtual keyboards out there.

2> Action completion. In standard apps you can for example click on a video and complete the action with any installed video player, and this requires access to the SDK which is only availabla from the Java side or from the bindings which I built

3> Application lifecycle, also something different from other platforms

4> Orientation change, the app needs to respond to it. With standard widgets it automagically works

qt specifies Gingerbread (2.3) afaik. I may be wrong here.

Besides, it is a simple XML configuration file for the keyboard mapping and if you want to use it: JNI is inconvienient but NOT difficult. There is C++ code for IME softkeybord bindings available from the android developer website.

From the platform highlights 2.3:
"*Native input and sensor events*

Applications that use native code can now receive and process input and sensor events directly in their native code, which dramatically improves efficiency and responsiveness.

Native libraries exposed by the platform let applications handle the same types of input events as those available through the framework. Applications can receive events from all supported sensor types and can enable/disable specific sensors and manage event delivery rate and queueing."

2> Action completion. In standard apps you can for example click on a video and complete the action with any installed video player, and this requires access to the SDK which is only available from the Java side or from the bindings which I built

See the 2.3 platform highlights above.

3> Application lifecycle, also something different from other platforms

What do you mean? It isn't.( persé).
If your APK is packaged and signed correctly, an Android machine that isn't supported won't see your app in the market. If that is what you mean. I think this is rather neat/cute/wonderful and saves headaches.

4> Orientation change, the app needs to respond to it. With standard widgets it automagically works.

Also lower than 2.3 issue, but you have to provide for it in code or use a browser approach, that's true.

I must say I am still playing and can't say I have things working in a generic way. Just that some code that works in the emulator also works on my Android machine and in a predictable manner.

Jeppe Græsdal Johansen wrote

Android also has some support for a pixbuf object in native mode, which I guess could be used for the same

Having the processor write into the pixel array would be horribly slow. I am right now planning a hardware design using TI ARM processors that also very often are used in Android devices. Many of them do have hardware for creating 2D and 3D graphics (similar to PC graphics hardware and somehow Direct-X compatible.

So I do suppose that there are means in the Linux Kernel framebuffer driver to use this feature.

-Michael

Thaddy wrote

I have qt code running myself on an very cheap Android 2.3 tab from a toyshop and it works a charm.

GREAT !

Maybe you might be ablt to check if OpenGL is supported, too.

I also have Mono/.net code running on it.

Great ;)

Currently both under C and C#. The Freepascal examples run a bit strange (maybe ARM EABIv7 for Cortex 8, still palyimng with it)

We4 trust that you will get it going :).

You definitely only need JNI before Android 2.3. So that part is correct.

Sounds encouraging !

-Michael

Thaddy wrote

Since you have access to a NDI native screenbuffer

Does this mean, you can't use the hardware rendering (if the Chip provides it) ?

you can use opengl v 2 to render anything directly without qt if you want, so small is definitely possible.

That answers the question I asked before :) .

So FireMonkey aka KSDev/GLScene should be working out of the box.

Thus XE2 (using FPC) should be able to create GUI programs not only for iPhone/iPAD, but also for Android phones and Pads from the same source code.

Great for Delphi users and for FPC

-Michael

This might not be possible from non Apple targets, because of Apple's licence restrictions (the OS X users might be able to tell more regarding this). If you have a OS X and the iPhone SDK this is already possible...

Regards,
Sven

Graeme Geldenhuys wrote

Umm.. I'm getting more and more interested in the Android platform. Maybe it's time I officially start working on a OpenGL backend for fpGUI. fpGUI would at least guarantee a small executable - at least compared to LCL.

Great !!!!!!

Of course fpGUI / LCL would be a nice and easy way to have an application run on Android.

As you know I am working on a bare metal embedded ARM Linux system (no Android installed). I did install GTK so maybe an application with GTK Widget type could work, but for embedded stuff fpGUI makes more sense.

Right now I have a testing hardware with a processor that does not do hardware rendering and the GUI (I just tested some standard "Desktop"s) seem rather sluggish. In the end I supposedly will use a chip that has a hardware rendering unit, thus using fpGUI with openGL support seem a perfect choice.

Thanks for your work, (and let me know when I can of any help...) -Michael

Graeme Geldenhuys wrote

I will offer fpGUI support to anybody that works on LCL-fpGUI though. So if you do go that route and get stuck with fpGUI concepts, don't hesitate to send me a mail.

Great.

Sven: For me right now the biggest problem with fpGUI/LCL is that Application.QueuAsyncCall (and similar things) does not work.

Maybe we can work together on improving fpGUI/LCL.

-Michael

It is not slow at all, it is lightning fast.
As far as I suspect the framebuffer manipulation is indeed through the kernel. If you use openGL v2 there's of course just one abstraction layer extra.

I volunteer to be an easy target. Not good enough at Android and compiler stuff yet, although my stuff works. I am more than good enough at coding and review, though. And comparing different languages on the same platform. (C, C++, Java, Pascal)
At least my toolchain seems to be working ;-)

Course. Mail it when I am at home.

Thaddy wrote

Not really/ somewhat / close enough

Can you provide a photo ?

- Michael

Dariusz Mazur wrote

For me browser has more capabilities than native widgets.

But you can't use the Lazarus GUI designer. I feel that without same the development is far more stressful.

-Michael

Thaddy wrote

It is not slow at all, it is lightning fast.

So it obviously does use rendering hardware.

As far as I suspect the framebuffer manipulation is indeed through the kernel.

I did not take a look into the framebuffer driver API, but it's quite obvious that it does provide support for hardware rendering.

If you use openGL v2 there's of course just one abstraction layer extra.

Yep. I did understand wrong that not using GL would imply not using the rendering hardware and directly writing to the pixel array instead.

-Michael

Michael Schnell wrote

If you use openGL v2 there's of course just one abstraction layer extra. Yep. I did understand wrong that not using GL would imply not using the rendering hardware and directly writing to the pixel array instead.

Will not only provide screenshot but actual, dismal! - what-if kind of code link, scratchpad, code this weekend. That seems more useful for the forum.

I count on it. Purchase machine with OS X is not problem, when I come around than my source will work.

I remember people complaining that Android didn't do (IIRC) screen composition on the GPU, and this was even officially disclaimed. Unfortunately all I could find right now is this:
http://androidforums.com/android-lounge/29584-why-doesnt-androids-gui-use-gpu-acceleration.html Hmm, and this: http://android-developers.blogspot.com/2011/03/android-30-hardware-acceleration.html

-Flávio

On 12-8-2011 14:54, Flávio Etrusco wrote:
|
Look at the documentation, that is easier:
http://developer.android.com/sdk/ndk/index.html as a start. Almost ALL OpenGl calls are available under Android Gingerbread. In all my postings I am talking about Gingerbread or higher. But indeed, I am just experimenting. Wait until I post a link to my code. It works. And it is simple.

Jonas Maebe wrote

They only have to share them with their customers who get the binary (and even then only for nominal shipping and handling fees). Of course, those customers are then free to pass them along further, if they want to. And in practice, I can't imagine what advantage Embarcadero would have by not immediately publicly sharing any such changes rather than by going through such hoops.

From the horse's mouth: https://forums.embarcadero.com/message.jspa?messageID=379331#379331

"If there are any changes or fixes we would contribute them, happily. I don't believe that we made any but it's our policy to contribute back fixes/changes to any opensource project that we leverage."

Jonas

I suppose that concluding from this that FPC is bug-free would be one step too far ;-)

Michael.

Which presumably means they're using the standard command-line parameters, so potentially a different PPC could be used to generate code for some other target.

Mark Morgan Lloyd wrote

Which presumably means they're using the standard command-line parameters, so potentially a different PPC could be used to generate code for some other target.

They generate a project for Apple's Xcode IDE to compile everything. The project will be set up specifically to compile an iOS application, so I don't think that changing the FPC compiler called in that project will do much good.

Jonas

On 12 August 2011 07:33, Felipe Monteiro de Carvalho >> As far as

Oh, maybe I understood the original poster incorrectly. I thought he meant implement the TTreeview mapping to fpGUI's Treeview widget in the LCL-fpgui widgetset of Lazarus. Currently that mapping doesn't exist for LCL-fpGUI - on the basic components like Button, Label, Combobox etc are already mapped. I don't think there should be a need to completely implement a whole new TTreeview widget from scratch.

Michael Schnell wrote

But you can't use the Lazarus GUI designer. I feel that without same the development is far more stressful.

GUI designers are not always needed. Take MiGLayout manager for Java. It is extremely easy to create a GUI without the need for a GUI Designer. And yes, even complex UI's are a breeze to code up with MiGLayout.

No, you did understood me correctly, but Felipe misunderstood my plan :)

Regards,
Sven

Just curious: Do you still plan to port it to Pascal?

Regards,
Sven

Sven Barth wrote

Just curious: Do you still plan to port it to Pascal?

Definitely! I just keep getting other work that takes priority - damn bosses. :) I really should try and make time for it, because I can't wait to start using it. I've played around quite a bit with the original Java version, recreating some of our existing products GUI's, and it is so easy, and a lot more flexible.

Jonas Maebe wrote

From the horse's mouth: https://forums.embarcadero.com/message.jspa?messageID=379331#379331 "If there are any changes or fixes we would contribute them, happily. I don't believe that we made any but it's our policy to contribute back fixes/changes to any opensource project that we leverage."

+10000~

this is a GoodThing<tm>... especially coming from a commercial enterprise... much in the same way that other commercial enterprises have contributed to other FOSS projects...

i can't help but to look back to my dBaseIII/IV days and note that i never had a GUI designer for graphical or textual modes yet i churned out several hundred apps that were then manually massaged for numerous similar tasks... one of the most popular was a shipping management app which competed directly with one of the major shipping apps... i can't recall the name of the company but it started with a 'B' IIRC... anyway, the app started off as strictly shipping... then a warehouse management module was added... then a production module and finally there were billing and order entry modules... all of these were meshed into one of the premier dBase/Foxbase accounting apps available at that time... graphical stuffs were just barely starting to take hold at that time...

if i had had to do the dBase style forms stuff, it would have been a total nightmare... instead, we opted to go for "standard" drawn interface screens that had no clue what a "form" was... this was also back in the day when a database was what is now called a table and joining several databases into a relational setup was all the rage... tables and forms were totally alien concepts back then ;)

Graeme Geldenhuys wrote

And yes, even complex UI's are a breeze to code up with MiGLayout

I never tried this, but I feel that IDEs (integrating code editor, GUI designer, make process, and debugger) have been invented for a purpose.

-Michael

Graeme Geldenhuys wrote

On 14 August 2011 20:21, Sven Barth wrote: > Just curious: Do you still plan to port it to Pascal? Definitely!

Hmm, in the end giving us the choice between LCL/VCL, Firemonkey, fpGUI designer, and MiGLayout (and...).

Maybe too many alternatives ????

What is the main difference between the fpGUI designer and MiGLayout ?

Thanks,
-Michael

If I understand that correctly, than MiGLayout is just a layout manager and can be used above any GUI widgetset. So if we've had a Pascal implementation of it, we could use it for LCL/VCL, Firemonkey, fpGUI any every other possible widgetset set.

Regards,
Sven

Michael Schnell wrote

I never tried this, but I feel that IDEs (integrating code editor, GUI designer, make process, and debugger) have been invented for a purpose.

I agree with all except the "gui designer" part. Layout Managers are by far the better choice compared to something like Delphi or Lazarus or MSEgui and even fpGUI's UI Designer gives. Java hit the nail on the head. Why define a UI with co-ordinates, then sit with problems like overlapping components, components that don't scale, locked to a specific DPI etc. I have also seen to many developers "fight" with GUI Designers to try and get them to do what the developer actually wants. I think Lazarus improved a lot over Delphi here, but Lazarus's designer is still way to complicated and error prone for complex UI's. Look at all the settings in the Align/Anchor property editors, yet often you still have to code some UI rules irrespectively. With good layout managers everything is easy - no matter how complex the UI.

Michael Schnell wrote

What is the main difference between the fpGUI designer and MiGLayout ?

Like day and night. fpGUI's UI Designer is similar to Delphi or Lazarus's Form designers. Drop components, set some properties etc. The only difference there is that fpGUI's UI designer generates pascal code, and the other two generates some form object output separate from the code unit.

The best way to see what MiGLayout can do, is to download the demo jar file which has a lot of examples built-in, then play around with those examples. You can even right-click on each example to do "live editing", or enable the debug-mode to see how the layout manager does it's calculation and layout.

There was also a nice UI competition between layout managers. A UI Form was designed, and people could submit how to recreate that form using various layout managers available. MiGLayout had very little code compared to most alternatives, and the result was often more flexible too.

If you read the MiGLayout white paper, you will learn some more of the advanced features which are mind blowing! The author thought of everything. Automatically managed button orders per platform (OK, Cancel vs Cancel,OK etc), automatic style defaults per platform (border sizes around components, default sizes of buttons etc), layouts can be described in any units like pixels, mm, cm, inchs, dpi independent, alignment or anchoring or resizing can be described really simple or even by using complex expressions.

I can go on and on, but rather just download the demo and see for yourself.

+1

Unfortunately the added Lazarus layout options can not be removed any more, from TControl, TWinControl etc. I just wonder what will come next, in an attempt to add more layout "features" to the LCL :-(

Currently the only chance, to disable all layout features, seems to be the use of an DockManager - which is not much more than a layout manager. The LCL developers missed that simple fact, and continue to add layout features to every single control, instead of letting the user choose layout managers from an (extensible) set of predefined layout managers.

DoDi

On 15 August 2011 10:52, Michael Schnell wrote: > What is the main difference between the fpGUI designer and MiGLayout ?

[...]

If you read the MiGLayout white paper, you will learn some more of the advanced features which are mind blowing! The author thought of everything.

This is exactly the wrong approach, that also invaded the LCL layout management. Real life proves that there cannot exist one single solution for everything :-(

DoDi

For my projects in Delphi I did this with a control that was inspired by table layouts of HTML (I called it TControlAligner, it is a TGraphicControl descendant without own drawing, its bounds are used as a "container"). It has Controls property (TCollection descendant) and direction (vertical/horizontal). Every collection item has a reference to a control on the form (that can be simple control or another TControlAligner) and different properties. The main property of the item that affects the position is Cells which is either weight (equivalent of % of html tables) or pixels, and when all requirements is set and this TControlAligner is placed (or its bounds changed) it does the best it can do with all the requirements of the collections items (as with html tables where cells can require % of the width or exact pixels).

Adding new aligners and using it for items of another aligner can build very complex layouts not using direct like the port of this component works in Lazarus. If the concept is worth considering I can provide the source for further review by the developers.

Max

Max Vlasov > wrote

Adding new aligners and using it for items of another aligner can build

very complex layouts not using direct like the
port of this component works in Lazarus. If the concept is worth considering I can provide the source for further review by the developers.

MiGLayout went a step further. It is powerful enough to never need nested layout managers. Yet it's still possible to code complex forms with it. I once found a website where somebody took a popular app (I think firefox), and recreated all the forms using MiGLayout, just to show that it is possible and very simple to do, just with MiGLayout and no nesting. :-)

Graeme.

I glanced at the quick guide. Actually MiGLayout looks promising, but personally I'd use it if it's implemented with intuitiveness and visual sense in mind. Without doubt they should work and show rendered layout in design-time and all these "dock west", gaps etc should be available as a context menu items or maybe some tool buttons. Otherwise if one have to learn the string constraint language, he can fall into the same trap as with regular expressions, I mean if you don't use them on a regular (ironic coincidence) basic, you learn them every time from the start :)

Max

Graeme Geldenhuys wrote

Why define a UI with co-ordinates, then sit with problems like overlapping components, components that don't scale, locked to a specific DPI etc.

This is similar to HTML vs PDF.

PDF always looks the same _if_ it can be (hopefully) can be displayed everywhere but only in very rare cases really looks "right" (unless the designer imposed harsh restrictions). And printing HTML pages in fact is a nightmare.

So maybe it's not possible to definitely choose one vs the other.

-Michael

Max Vlasov wrote

I glanced at the quick guide. Actually MiGLayout looks promising, but personally I'd use it if it's implemented with intuitiveness and visual sense in mind.

"visual" doesn't always make things better. In fact, visual often posses more limitations. Think Linux vs Windows. I can backup our linux server's config files for all services. Install a new linux system, copying in the configs and be up and running in no time. Windows with all it's non-visual configuration dialogs, there is no way to backup configs and restore them on another Windows server. This is just one of many such examples.

If you do want to see what MiGLayout is doing, simply enable the "debug" option in Layout, Column or Row constraint. In then visualizes how things are laid out and calculated. Run the Swing Layout demo, and see the Debug section for more details. Right-click anywhere in the form see and change the constraint settings.

context menu items or maybe some tool buttons. Otherwise if one have to learn the string constraint language, he can fall into the same trap as with

If you look at all the constraint options, it does seem overwhelming at first glance. But in reality you only need very few options to start building usable UI's. Once you are familiar with those, you can revisit your UI designs to improve there behaviour with more advanced settings.

Anyway, this message thread has strayed way off topic now. :)