Hi,

I have just found this link
http://www.pro-linux.de/news/1/16733/necessitas-suite-qt-fuer-android-vorgestellt.html(German) speaking about this announcement
http://groups.google.com/group/android-qt/browse_thread/thread/209edef7c5ceec8afor a unofficial community port of QT to Android.
I'm not sure how FPC and Lazarus use QT (is a C wrapper still required) but i think this would be a lot less work than doing all this stuff with FPC/Lazarus.

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

Yes, C wrapper is needed, Qt is C++ lib.

zeljko

zeljko wrote

Yes, C wrapper is needed, Qt is C++ lib.

Could Lazarus use the same C wrapper it now uses on Linux since Android is mostly a Linux distro with different GUI ?

Razvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110226/07b32c81/attachment-0001.html>

Razvan Adrian Bogdan wrote

Could Lazarus use the same C wrapper it now uses on Linux since Android is mostly a Linux distro with different GUI ?

Most probably. But w/o an Android I have not tried yet. Can you check out if you can already make a small app in Qt c++ (just a window and a button hooked to quit).
I do not know the state of android-lighthouse

Then you can see how much of the fpc binding compiles. Compiling the binding has very similar requirements as to compiling a Qt c++ library (which is what it is)

regards,

Den Jean

Razvan Adrian Bogdan wrote

Android is mostly a Linux distro with different GUI ?

I could not resist:

Linux does not have a GUI. Same always is an add-on, so Android is Linux Plus some GUI plus some other add-ons.

-Michael

Michael Schnell wrote

Linux does not have a GUI. Same always is an add-on, so Android is Linux Plus some GUI plus some other add-ons.

The nasty surprise here is that Android implemented their GUI library in Java, and users cannot run native executables.

I haven't checked how Qt works, but probably it writes their GUI with OpenGL, which will make it badly integrated and bring all kinds of problems.

On Tue, Mar 1, 2011 at 12:35 PM, Felipe Monteiro de Carvalho <

Yes Linux the Kernel is just core stuff and of course non visual but most people refer to GNU/Linux+Qt/Gtk+Gnome/Kde/Lxde/Xpde/AnyWm, X11 itself is not mandatory but a good GUI framework is required for normal tasks such as reading a complex document or watching a movie. I'm not sure but last time i checked the graphics drivers used kernel modules but i could be wrong about this and we could consider graphics as part of the kernel but not an essential part, many people (including myself) just say Linux when they really mean their favorite distro
Ubuntu/Fedora/Suse/Mandriva/Gentoo/Mint/....

They implemented QT using a service application that provides access to the GUI framework, it doesn't say anything about OpenGL and people seem to be happy about it.
It is important that it uses the same look and feel and is well integrated. I'm not sure how they wrote the Java GUI stuff, is it all written in Java or there are some C/C++ wrappers for Java that we could use ? I know that there is a port of QT to NaCl and being Google technology it might get adopted faster i'm not really sure why NaCl isn't already on the Android platform because it was proposed for Chromium OS and the browser.

The problems Google and Oracle have could boost the adoption of other technologies such as C/C++, Python and Google Go (which is similar to Pascal and Ada but more C'ish, with support for clusters and multi-cpu).

Razvan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110301/3e32622f/attachment.html>

-

This might be of interest to all LAZARUS developers/users. Take look at the LiMO foundation (consortium of companies for next generation of hand held devices)
http://www.limofoundation.org/en/what-is-the-platform.html http://www.limofoundation.org/

The takeaway message from this is that EFL (enlightenment foundation libs) are the main libs proposed by the foundation to develop the next generation of hand held devices. What is disturbing is that lasarus/fpc has no bindings for these super fast libs. Samsung is using these libs and have devoted 4 full time developers and 2 part timers to use EFL libs for all of their electronic devices.

http://www.enlightenment.org/

Ubuntu is also using them for the notebook remix. And many others will follow and use the EFL in their projects. they have to be tried ? Try them and than make a critical analysis.(the EFL libs provide fast efficient (better design) optimised reusable code that other libs (GTK2 and QT) suffer from.

the EFL (e17) and very stable.

bodhi linux is using E17 as their desktop shell (fast memmory efficient)

http://www.bodhilinux.com/

Fast, maybe. But also primitive.
There are very few widgets available in elementary (no surprise, given the name ;) ). It looks like it is indeed geared towards PDA/Mobiles. Lazarus would have to develop most other widgets by itself. What also comes as a surprise is the very long list of dependencies. Compare with fpGUI, which only needs X11.

In each case, we'll certainly welcome header translations.

Michael.

-

Interesting?
Yes elementary has a limited number of widgets (at the moment). ELF is not "elementary"
roadmap for Elementary.
http://trac.enlightenment.org/e/wiki/Elementary

Some EFL features:
Each Can be installed independently
Each library can be used by itself

FpGUI (true - has low dependancies on other libs) has no future in the embedded market and has some design flaws (graham is happy and that all it mattaers). lcl-fpgui is not happening?

Felipe Monteiro de Carvalho wrote

The nasty surprise here is that Android implemented their GUI library in Java, and users cannot run native executables.

(re-phrased previous mail)

AFAIK, at the beginning native application have been strictly discouraged, but with a more recent version, they seem to be acceptable. They seem to need some Java wrapper to be startable from the Android user interface. I suppose to do a GUI for a native code Android application there are several alternatives

- do some callbacks to the Java environment that started the native code to use the Java based GUI library

- directly use the Framebuffer API (in Lazarus this would hopefully be possible some day using the fpGUI Widget Type, as <AFAIK> Graeme is planning to implement a Fframebuffer interface for same, additionally to the already existing X interface

- install QT (as the OP in this thread suggested).

-Michael

Razvan Adrian Bogdan wrote

Yes Linux the Kernel is just core stuff and of course non visual but most people refer to GNU/Linux+Qt/Gtk+Gnome/Kde/Lxde/Xpde/AnyWm, X11 itself is not mandatory but a good GUI framework is required for normal tasks such as reading a complex document or watching a movie.

I don't need to have X11 or and GUI framework running to watch a movie... mplayer and a framebuffer are sufficient. :D

Regards,
Sven

On 2/03/2011 5:01 AM, Razvan Adrian Bogdan wrote: > we could consider graphics as part of the kernel but not an > essential part,

IMHO this is a (quite common) miss-conception. There are millions of embedded devices that run Linux without any graphics, (here, the hardware does not provide graphics at all, and often not even a character based display). With servers there is no need to activate the graphic stuff - even if running on a PC that does have graphics hardware. So you can free a lot RAM for more useful stuff.

By definition "Linux" is just the Kernel. The graphics hardware of course is accessed by a dedicated Kernel-mode driver (usually a loadable module), providing a "frame buffer" interface to the userland software. AFAIK, the X-Server (if used) is just a user land program, accessed by some kind of byte stream (pipe) by the user land programs that want to create a GUI.

-Michael

This is what fpGUI is about.

What also comes as a surprise is the very long list of dependencies. Compare with fpGUI, which only needs X11.

Hopefully a future fpGUI will be able to use the framebuffer API if X11 is not available.

-Michael

Op 2011-03-02 02:07, alex kovacic het geskryf:

FpGUI (true - has low dependancies on other libs) has no future in the embedded market and has some design flaws

What design flaws?

NOTE: I'm not referring to lcl-fpgui, but rather the real fpGUI Toolkit.

Regards,
- Graeme -

Op 2011-03-02 11:07, Michael Schnell het geskryf:

> It looks like it is indeed geared towards PDA/Mobiles. Lazarus would > have to develop most other widgets by itself. This is what fpGUI is about.

Yes, that is one of its uses. There are quite a few developers I know of that use fpGUI successfully on Embedded Linux devices, and on some Windows CE devices.

Hopefully a future fpGUI will be able to use the framebuffer API if X11 is not available.

You can count on that! With my frustration ever growing over the bad X11 performance, the Linux Framebuffer support will come sooner rather than later. I'm playing around with Haiku too. My 7 year old laptop only uses the VESA driver in Haiku, yet it has mindblowing fast graphics and mouse cursor-to-window edge lag while resizing is near zero (same for Windows and MacOS). Linux desktop graphics on that same system (and any other system) is appalling! Compiz and wobble windows etc are just trying to detract user from that fact.

Regards,
- Graeme -

2011/3/1 Razvan Adrian Bogdan :

They implemented QT using a service application that provides access to the GUI framework, it doesn't say anything about OpenGL and people seem to be happy about it.

If you search more deeply, Qt for Android depends on OpenGL.

It is important that it uses the same look and feel and is well integrated.

Exactly what Qt won't be. Qt is a custom drawn toolkit. It could never use the native widgets because it doesn't match it's internal architecture.

I'm not sure how they wrote the Java GUI stuff, is it all written in Java or there are some C/C++ wrappers for Java that we could use ?

There are no such generic wrappers, you have to write them yourself for each program.

For Pascal I am writing generic wrappers to communicate with Java.

Razvan Adrian Bogdan wrote

I was looking at this: "The ONLY problem this plugin has, is that ?it doesn't support hardware acceleration so no OpenGL. For OpenGL I need to resurrect "mw" plugins, I'll do it after sw plugin will be production stable. "

Maybe they use the new Surface API, but that only appeared in Android 2.3. It offers a raw surface, no widgets.

I too like Qt and fpGUI, so maybe my mails were sounding like if I think it is a bad idea to invest in checking how they can work in Android, it's not the case.

The thing is that I work with Android Programming so I know that custom drawn programs suffer from major integration issues in android which can be solved if you have a company with dozens of developers working full time on that and people testing all of the 50+ most important smartphones, tablets, etc, but a small team (or just 1 guy alone) will have a very hard time keeping up. Every new phone that comes in might bream custom drawn apps or their integration to the OS in general and so many things are configurable. And everything is tested against the standard Java widgets, not against custom drawn apps.

But, despite these issues, Qt or fpGUI might be the only viable solutions for porting Lazarus to Android.

My bindings which connect Pascal to the Android API (which I am calling Android4Pascal) are more viable for standalone programs then for the LCL.

The problems appear when trying to mimic the way native widgets work on each platform such as pulsing buttons and things like that but if browsers can do it, so can FPGui.

Actually, many browsers use native widgets. Desktop browsers use native widgets more often then mobile browsers, for the reason that we already know: Lack of trust in the stability and durability of mobile APIs. Many mobile OSes have died over the years.

I was thinking how did Google do it, did they write the GUI core in C/C++ and created wrappers so that Java may use them or did they write the GUI in Java and now people have to find ways to make Java respond to native calls through indirect wrappers and service applications.

Ah, I see. I don't know, but I think that the widget drawing and handling code is in Java, otherwise they would have made the API public.

-

Linux desktop graphics on that same system (and any other system) is appalling! Compiz and wobble windows etc are just trying to detract user from that fact.

Use e17 desktop environment you might change your mind about linux desktop performances?