It seems the whole world is going "mobile computing" nuts!!

http://www.osnews.com/story/24713/Nokia_Announces_Qt_5_Plans

My thoughts on pushing those "mobile computing" UI interfaces into the desktop application space is rather negative. eg: Unity in Ubuntu, Gnome Shell in Gnome 3 - clearly all designs from the mobile touch screen devices - not so good on the desktop though. Lets hope that Qt 5's default graphics engine that requires OpenGL and forces developers to use Javascript instead for app development, doesn't affect desktop application developers too much. At least there is a mention of the QWidget-style API still hanging around for some time - but not there main focus any more.

Good news is that at least this time they are going to try and make the upgrade from Qt 4 to Qt 5 less painful (remember the move from Qt3 to Qt4?). So the Lazarus LCL-Qt developers should be happy with that.

BTW:
To those Lazarus LCL-Qt developers. Kudos for a job well done! I have recently compiled my Lazarus 0.9.30.x IDE with the LCL-Qt interface and it works and looks very good so far.

Regards,
- Graeme -

Very strange. Nokia already sold the business of offering service to Qt developers, and it fired most of the MeeGo department, so it doesn't use Qt in it's own products and doesn't sell services based on it. Why would it work in Qt 5? I'd rather have them stay far away from it, since I don't see anything good coming from Nokia these days.

Hmm,

The big thing is Android !!!

So doing Lazarus for Android would be essential.

I do know that there are several ways to do this, but IMHO, the most decent best integrated (though most painful) way would be not to use a second non-Android GUI-framework (such as QT) but somehow make the Android controls usable for Lazarus programs. I supposed this would ask for some kind of local "remote" GUI, i.e. serializing the GUI communication by some kind of byte stream and do a java based remote GUI handler application on the Android site.

-Michael

Michael Schnell wrote

Android controls usable for Lazarus programs. I supposed this would ask for some kind of local "remote" GUI, i.e. serializing the GUI communication by some kind of byte stream and do a java based remote GUI handler application on the Android site.

MSEgui has some "remote GUI via serializing" support, though I don't really know how it works as I don't use MSEgui for app development. But maybe that could give some ideas of how it could be implemented. Maybe one should ask Martin (MSEgui author) to explain the remote gui thing in more detail.

Regards,
- Graeme -

Felipe Monteiro de Carvalho wrote

it. Why would it work in Qt 5? I'd rather have them stay far away from it, since I don't see anything good coming from Nokia these days.

I don't have much faith in Nokia either these days. They don't even know what they really want. I guess that is why they also stated that Qt5 will be developed in a more open fashion than Qt4 was. Qt4 was more a Trolltech/Nokia internal developed library, then simply published the code when done. The whole JavaScript thing scares me too, but that is maybe just because I'm not very proficient in JavaScript.

Regards,
- Graeme -

Graeme Geldenhuys wrote

MSEgui has some "remote GUI via serializing" support,

Yep. This is originally an idea of Martin's and his name for it is "ifi" (nobody knows what this means :-) ). AFAIK, this is an unfinished open source project he once started and abandoned at some point of time.

Some years ago I tried to define a project that would need this and I wanted to use it with Lazarus and the LCL. I talked a lot with Martin about "ifi" that time and started an LCL implementation but this was too big a task for me, being an LCL-internals illiterate.

In fact, having an "ifi" Widget Type would be a really great feature of Lazarus'. There are lots of ways it could be used.

- a remote GUI via TCP/IP or a serial port could be done, using a standard Lazarus program providing all possible controls on the user site, for self-contained (embedded) server projects
- in same way a GUI-less Windows-Service could be created (Windows-Servers don't allow services with GUI binding as of 2008).
- an HTTP/HTML based remote browser GUI could be created (e.g. using extJS) for FCGI based server projects
- ...
- and the said Android Widget Type could be done, doing the local "remote" GUI in Java.

-Michael

I don't like some things in Qt too, but it's still better then gtk2/3, also Qt5 won't kill desktop and QWidget philosophy.
Upgrade from Qt4 to Qt5 won't be a PITA (like with Qt-2/3->Qt4), since there won't be huge changes with 2D graphics system (QPainter) and QWidget's. Only good thing in Qt5 is introducing of QAfterPaintEvent (if they implement it ... it was planned by trolltech devels).
Anyway, it will stay opensource so I'm not scared about it's future.

BTW: To those Lazarus LCL-Qt developers. Kudos for a job well done! I have recently compiled my Lazarus 0.9.30.x IDE with the LCL-Qt interface and it works and looks very good so far.

Thanks.

zeljko

Graeme Geldenhuys wrote

code when done. The whole JavaScript thing scares me too, but that is maybe just because I'm not very proficient in JavaScript.

Just what we need.. a program that you can publish that doesn't show any errors until user X does something which triggers some stupid uncaught runtime javascript type error or something.

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

Michael Schnell wrote

Hmm, The big thing is Android !!!

And if you want to capitalize on it, you need to be ready now, not only start.

Lazarus is not suitable for trying to follow fast moving trends. Iphone was just yesterday, and even that is not really ready.

Yep.

OTOH, I feel that Android is the more promising concept. In fact I don't like it's strong Java binding. I would prefer CIL, as same can provide Multi-Arch executables as well and seems the more advanced concept to me and is supported by a good count of programming languages, not just one. But very obviously Google's decision to use Java was a political one (against Microsoft). To allow for CIL on Android, there already is MonoDroid by Novell. Lets see where this goes after Novell having been bought. (Ugly theory: with Money coming from Microsoft, to be shut down ?!?!?!? :-) )

But other than then the iPhone OS+GUI, that seems quite different to the PC Mac OS+GUI, Android to me seems to be about to win at multiple targets:
- mobile (smart Phone and "Pad": anyway)
- Laptop
- Desktop (via the Laptop path)
- embedded (I already found the first embedded PCBs that come with Android <enhanced by API extensions for embedded hardware interfaces)
- Servers (it's not harm if the usual Linux server gets a - seldom used - Android GUI just for compatibility)

-Michael

Maybe, but only if some dominant vendor emerges that standarizes a certain set of features across its line. This is now chaos.

In fact I don't like it's strong Java binding.

I don't like that either, but usually such things will eventually be watered down by reality. (and I don't think it will be any different for the javascript bit)

(CIL vs JVM)

We have gone over the CIL rants before, so I'll not repeat it, except that I think it is a very coloured view, and I do not agree.

This demonstrates the problem what is "win". Widest range of devices? Most devices sold? Biggest turnover in the software market?

I think for the average developer it is the latter, and then corrected by subtracting turnover of the very large companies. (e.g. we won't compete with mp3 sales, and other very popular apps, we won't ever get that business, so it is no sense).

Note that is turnover for the devices I can reach in practice. Not the devices that run some form of android, but android in the right version on the right architecture with a device that has the required aux. hardware on board (think GPS,Tilt sensor etc), and sold separately or by a carrier that allows app install.

And of course the cost of development. How many versions of the app for different devices/archs/versions must I make? How many different periphal hardware will I have to support (different GPSes etc). How much does it cost to get them in the marketplace and promote them etc etc.

That is all more important than cil vs jvm, or even bytecode vs native.

But my personal opinion is that neither cil NOR jvm is a valid target for Lazarus/FPC (regardless of the fact if you think bytecode is the way to go or not).

I slightly turned last summer after some discussions on IRC and the lazarus day in the sense that if a JVM backend wouldn't complicate the compiler too much. (the JVM is standalone, and the rest of the compiler remains native), and has its own separate libraries, that would be a possibility.

But still I think it would be better served with an independant project long term.

Marco van de Voort wrote

Lazarus is not suitable for trying to follow fast moving trends. Iphone was just yesterday, and even that is not really ready.

I don't think that Lazarus is a bad choice for smartphone platforms, it would be a great tool for targetting Android and iPhone at the same time. The only issue is that we lack developers.

MonoTouch does the same thing Lazarus intends to do, but they are more successful because they have money.

Marco van de Voort wrote

Maybe, but only if some dominant vendor emerges that standarizes a certain set of features across its line. This is now chaos.

I don't think it is that bad. Software written for Android usually works out of the box if you stick to the Android API, as opposed to use your own custom-drawn widgetset.

The manufacturers add a lot of non-standard stuff, but they always test against the Android API, but they don't test against non-standard widgetsets, so if you are using your own non-standard widgetset, it won't work in half the devices.

And of course the cost of development. How many versions of the app for different devices/archs/versions must I make?

Only 1

?How many different periphal hardware will I have to support (different GPSes etc).

The Android API abstracts most hardware devices, so it is easy to support GPS, regardless of the specifics of the hardware. Accelerometer support is pretty standarized too. The Camera is a huge mess, on the other hand.

Marco van de Voort wrote

But my personal opinion is that neither cil NOR jvm is a valid target for Lazarus/FPC (regardless of the fact if you think bytecode is the way to go or not).

Agreed ! Lazarus/FPC is all about native code. It would be close to impossible to compile a decent Lazarus project to JVM or CIL.

That is why in my first post in this thread I mentioned "ifi": a Widget Type that separates the business code from the widget generation and introduces a stream interface between these parts. Thus a set of standard "widget generator"s could be provided together with the LCL to do a remote GUI based on the streaming interface . And this baby can be done in Java (e.g. for Android), in Java Script (e.g. for server applications with Browser based remote GUI) in FPC Code (for a remote GUI using a standard GUI-program attached to the "server" or "service" via TCP/IP, serial interface or some Windows message based transport, enabling WIN Server 2008 services) or perhaps in Delphi Prism (for enabling Silverlight/Moonlight stuff).

But I fear this is too much work to do for a small group of developers.

-Michael

Felipe Monteiro de Carvalho wrote

MonoTouch does the same thing Lazarus intends to do, but they are more successful because they have money.

... Up to yesterday. Now as Novell has been bought by Attachmate the future of Mono might be uncertain. (cui bono ? )

-Michael

Well, according to

http://techrights.org/2011/05/04/appeal-in-a-microsoft-case/

and

http://techrights.org/2011/05/03/mono-developers-laid-off/

Mono will be killed.

A good thing. Extended use of Mono in SuSE is one of the reasons I switched to Ubuntu.

Let .NET remain where it was: on Windows. :-)

Michael.

Mono will be killed.

Miguel de Icaza contradicts.

But as in fact Microsoft is part of the deal

http://www.zdnet.com/blog/microsoft/whats-microsofts-role-in-the-novell-attachmate-deal/8041

I suppose you are right.

I suppose Mono will be transformed in a community project. But as always Microsoft will try to use his legal staff against concurrent technologies. They could not do this to Novell, as they had an agreement about mutual respect with them.

-Michael

Michael Schnell wrote

Miguel de Icaza contradicts.

If you are talking about the tweet post referenced on the article you posted, then that is from November 2010, while the news of Mono getting killed are brand new.

Yes. And we have neither the interested developers nor fulltimers to be quick enough to track fastmoving targets, which was mostly my point.

A side concern is the walled garden concept of many mobile phones. They don't exactly encourage portable software, but want custom made apps for their phones, preferably with their recommended tools.

I wonder if they have to. They can simply outdevelop them, now that the funding is cut.

Hence the conclusion: a web application is probably the best way to go when developing business apps for the mobile.

(at least, that's what we concluded here at work).

Michael.

Depends. For me it would be absolutely useless, since for work I'm in too many places without decent signal. So I'd need data locally on the telephone as much as possible (roadwarrior scenario).

But worse, essentially that means for the the current playing field it is not worth the effort.

Do you mean: Using Android's browser as a GUI and have it connect to a server done with FPC and running as a daemon in the background and accessed as http://127.0.0.1:12345 ?

This is quite similar (but less powerful and maybe easier to do <for simple stuff>) than the "ifi" way.

-Michael

I would not do it locally.

In my line of work, there *always* is a central database.

So:
No access to the database (i.e. internet access) -> no functionality.

In such a scenario, a web app makes perfect sense. And it solves the "which device to support" question as well...

Michael.

IMO, better solution in such scenario would be to use web server than direct SQL database access, since link can be broken at anytime, and app will hang, but if it is web based product, web browser should say that web page is currently not available.
We are currently making one Android app with eclipse , which connects to pgsql via odbc and all I can say:
+ UI is pretty nice
- ODBC (jdbc) is bad way to connect to database, especially where many users are connected, since every connection takes an "idle in transaction", so > 100 users on an database takes > 100 transactions, even if they are idle. This is real pita.
- When link is down, app hangs .... yes you must wait until kernel timeouts or kill your app.
- Deployment.

Web application:
+ It's web application :)

So, I think that such concept of bussiness application on phone isn't good ... we are already moving to web concept.

zeljko

I would not do it locally.

I see. But supposedly, doing a local web server in fact is a way to use FPC to create a GUI enabled application for Android.

-Michael

That is exactly the design I am advocating ? (see 'Web app' ?) The web server is hosted by us (database resides on our servers as well), and the mobile just connects to the webserver.

So, I think that such concept of bussiness application on phone isn't good ... we are already moving to web concept.

My idea 100% !

Michael.

For one of our customers we have started to develop a mobile version of our application (around one and a half year ago) and there the restriction is: no online connection. So we're using a "synchronize scenario" with a LCL application (Windows Mobile 5 & 6).

Regards,
Sven

Sven Barth wrote

For one of our customers we have started to develop a mobile version of our application (around one and a half year ago) and there the restriction is: no online connection. So we're using a "synchronize scenario" with a LCL application (Windows Mobile 5 & 6).

Will they move the application to a newer platform? Which one?

Marco van de Voort wrote

Yes. And we have neither the interested developers nor fulltimers to be quick enough to track fastmoving targets, which was mostly my point.

At some point implementing a LCL widgetset based on that was on my plans, but then I found out that the Android API is really very different from the LCL. Doing the mappings is really a problem. It is filled with specifics which one can't just ignore, it really requires Android specific code for handling the life-cycle events, for example.

At least I managed to port the essential parts to allow writing FPC applications which run on Android. So at least one can reuse the non-GUI code across Android, iPhone and Windows CE.

A side concern is the walled garden concept of many mobile phones. They don't exactly encourage portable software, but want custom made apps for their phones, preferably with their recommended tools.

Indeed. Windows CE and Meego were the best platforms to develop for, the most standard compliant ones. WinCE being compliant with Win32 and Meego with Linux, but both are dead now.

No, they won't as they have business devices, not consumer devices. They contain a barcode scanner and are adjusted more to industrial environments.

Regards,
Sven

Marco van de Voort wrote

A side concern is the walled garden concept of many mobile phones. They don't exactly encourage portable software, but want custom made apps for their phones, preferably with their recommended tools.

A free (payed support offered) cross platform SDK, supporting iPhone, Windows Mobile, RIM, Symbian and Android:
http://rhomobile.com/products/rhodes/

-Michael

Felipe Monteiro de Carvalho wrote

Indeed. Windows CE and Meego were the best platforms to develop for, the most standard compliant ones. WinCE being compliant with Win32 and Meego with Linux, but both are dead now.

... and Android starting to become the "Standard" in the non-Mobile World :)

-Michael

Felipe Monteiro de Carvalho wrote

If you are talking about the tweet post referenced on the article you posted, then that is from November 2010, while the news of Mono getting killed are brand new.

Icaza founded _Xamarin_ <http://www.xamarin.com/> to go on with the Mono project.

see: http://www.linuxfordevices.com/c/a/News/Xamarin-launched/

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

I started a project like this about a year ago, but never finished due to client changing direction when Apple announced not including flash support which was the first basic UI framework that it worked with.

http://leebo.dreamhosters.com/pasria/

Basically it did the what you are describing I believe. The server basically instructed the (flash) GUI client to render textboxes, lists, grids, etc and bound the client events to the server so that a ComboBox in flex would signal it's selection to the server. A small framework on the client side was proxied for the server application and rendered the GUI as instructed and reported "interesting" events to the server.

Though this project was geared to more "remote" clients such as over the web or intranet, the speed/responsiveness was surprisingly good though I frequently would envision roadblocks whereas you cannot always get the fine grained control that you need of a gui from the server side.

Some events are easy and straight forward like a click event. Other events that you might need to capture and react to from the client, would be textbox change events. My thinking at the time though, for these kinds of events was that it was fast enough for google's "search as you type" Ajax implementation over the web so probably fast enough for local network and intranet as the prospective project was to be.

If I were to pick this project up again, I would probably go with Appcellerator or PhoneGap for the GUI front end.

Also, speaking of Appcelerator and PhoneGap, wouldn't it be nice to see a FPC version of the same? Basically, a fpc application that exposed webkit's WebView as PhoneGap does for the GUI (Appcelerator hooks native widgets by default I believe), but using object pascal to program it! Of course, that would require some kind of objectpascal to javascript translator unless the WebKit WebView exposes underlying DOM and events through an API...

All fun stuff to speculate on, but then again, I do make a good armchair quarterback :-)

Lee Jenkins wrote

If I were to pick this project up again, I would probably go with Appcellerator or PhoneGap for the GUI front end.

IMHO if such a project indeed would be (re-)started, it should be done without much considering the remote site, so that it is as universal as possible. So the first implementation should be completely done in Pascal ( (1) the server "Widget Type" implementation and (2) a client as a simple Lazarus Program) with a bidirectional Linux pipe as the streaming interface between the two. With that, just the well-known tools can be used. Of course the pipe easily can be replaced by a socket and we already would have a useful remoting tool.

In a next step creating different remote GUI clients (basted on Windows messages <for 2008 Server service>, HTTP/JavaScript <e.g. using "ExtJS">, Android/Java, Silverlight/Moonlight <e.g. using Delphi-Prism>, Flash <ActionScript>, etc.) could be started.

But before even starting anything, a major hurdle is, that there are several "Widget Types" available in Lazarus, but not a single one provides decent "Event Driven Programming" (such as "TTimer", "Synchronize" and "QueuAsyncCall") without requiring an external GUI framework. Such an "active NoGUI" Widget Type is needed as the basic building block for the GUI remoting "ifi" Widget Type. Obviously this needs to be done before any remote GUI implementation could be taken into serious consideration. I feel that a good way of doing this would be to work together with Greame to move his EventQueue code outside of the "fpGUI" Widget Type implementation to a location where it is usable by other Widget Types, as well.

Also, speaking of Appcelerator and PhoneGap, wouldn't it be nice to see a FPC version of the same?

I have no glimpse of those :(

But I feel that an "ifi" Widget set might be the base of a lot of inspiring stuff.

And I think that project could be initiated in a way that as well on the server as on the client site could start with just a few basic GUI elements done in a as GTK2 compatible way as possible to allow for switching a project between GTK2 and "ifi" Widget Sets at any point in time (as long as only these GUI elements are used). More elements can be added by combining existing elements (just on the server) or creating new ones with their own server- and client- implementation.

-Michael

[...]

Michael, why do you bother Lazarus people with all this if MSEide+MSEgui has all what you need already? Simply use MSEide+MSEgui, no?

Martin

Martin Schreiber wrote

Michael, why do you bother Lazarus people with all this if MSEide+MSEgui has all what you need already? Simply use MSEide+MSEgui, no?

Great to see the inventor of "ifi" here again :-) ! I would not have continued my research on this since years, unless you would have proven that it in fact is possible and viable.

Regarding my long-term goals:

In our company there is a "Firmware" department, that I am responsible for, and a "software" department, that my colleagues run.

Obviously, the firmware department creates software for embedded devices (right now moving from home-brew OSes to Linux).

Less obviously, also the "Software" department also mainly creates software for embedded thingies, only that these are not cheap small devices, but built on embedded PCs.

The main difference is that "Firmware" of course is done in C while "Software" according to the in-house definition is done in Delphi-Language using the Delphi IDE.

Right now, this requires that Windows is used on the embedded PCs.

To allow for running "software" on the upcoming Linux based "devices" (and to allow to pay less for software licenses, interesting regarding decreasing hardware cost and increasing sold numbers), they would need to compile their million-line projects for Linux (and maybe ARM) while continuing to be able to compile the with Delphi and maintain all this in a decent way.

That is why they need an as easy as possible migration path. I feel that Lazarus could provide this much better than MSEide and MSEgui, as it is done much more according to the lines of Delphi (which of course is not a plus in many other issues).

I feel that there is a (faint) chance to talk the "Software" people into trying Lazarus, but there is no chance in suggesting MSEgui :-( .

Thanks for asking ;-) .
-Micheal

Michael Schnell wrote

To allow for running "software" on the upcoming Linux based "devices"...

Not only those we build ourselves, but Android devices apply here, too.

-Michael