well actually i have install 10 testing apps on my android device.It is not part of the Lazarus or FreePascal project and the developers have no responsibility over it and no obligation to make it work.
the complains is all abou ie. try to install indy components...
try to open demo lamw projects and belive me NOTHING works...
in no way am I excusing being rude or a user not taking the time to read help documentation (including wiki).
The angle that I'm talking about has to deal with expectations, and arguably the Lazarus team should be aware of such. Ignoring that people would want to develop mobile applications for Android and iOS is strange. Delphi has positioned itself where it's not just for the desktop, but also for mobile. People who would be looking at Lazarus as a potential alternative, would obviously be considering this when making comparisons and decisions.
Probably the most glaring weakness or oversight of Lazarus is exactly that, creating mobile apps.
Oddly, nick1965's complaint about trying to use Lazarus for Android has a small bit of legitimacy. Don't get me wrong, in no way am I excusing being rude or a user not taking the time to read help documentation (including wiki). The angle that I'm talking about has to deal with expectations, and arguably the Lazarus team should be aware of such. Ignoring that people would want to develop mobile applications for Android and iOS is strange.First of all, the response anyone gets/got on this forum are responses from the community.
Probably the most glaring weakness or oversight of Lazarus is exactly that, creating mobile apps. That Lazarus is seen as not capable in that area, is arguably worrisome and problematic.Maybe, but that will only change if people volunteer. Answer questions, document, supply patches....
And other programming languages/open source IDEs, have been making themselves viable ways to create mobile applications. LAMW/Laz4Android is a fantastic effort, but them not being more thoroughly integrated into Lazarus, does appear to create a bit of awkwardness that would most obviously become a problem for newbies and beginners. And LAMW/Laz4Android is only a partial solution, as there isn't any equally viable Laz4iOS project. When people claim that Lazarus is an alternative, then the weakness in mobile development, can possibly lead to disappointment for some people coming from the Delphi world.All that may be true. But it is also chicken and egg...
QuoteProbably the most glaring weakness or oversight of Lazarus is exactly that, creating mobile apps.Detail here for people whose first language is not English. The traditional meaning of "oversight" is "omission, something overlooked". A more recent usage is equivalent to "supervision". It's a word I try to avoid in technical writing because of that ambiguity.
...a Pas2JS-Lazarus-Cordova pipeline to create allow for building cross plattform apps on the basis of web technology which works really well on both desktop and mobile
The thing about mobile development with Lazarus is that to be well integrated into Lazarus it needs to integrate into the LCL as a widgetset...
...A proper Lazarus integration, such that it is compatible with other platforms in the "write once compile anywhere" principle would require a custom android widgetset...
In contrast, Delphi is making mobile development easier and keeping it mainly within the confines of their IDE and Object Pascal. Among other languages that have open source projects that have kind of pulled off multi-OS development, in their own way, is Lua. Which comes along with the limitations of scripting languages (slower, security, etc...). It has interpreters on the major OSes, so didn't need to be coupled with JavaScript (HTML, CSS, or substituting friends).I think that a web-technology based approach, if integrated seamlessly, has many advantages over what Delphi is doing. Most importantly, HTML + CSS is actually really good for providing easiely stylable GUIs with little effort. Whenever I used Firemonkey, I found it pretty hard to make some decent looking styles, while with CSS and HTML I don't just think it is easier, but because it is the most widely used GUI technology around, you can find a lot more examples and/or royalty free code and styles online.
Debatably, this route would be the most preferable, though it appears more difficult or in need of developers to champion it. It would make Lazarus a more viable alternative, and do more to promote it as a tool for both desktop and mobile development.The thing about this is, that LAMW is an android solution through and through. And one thing is, when you develop a mobile app, you usually want the same app for both Android and iOS. This is why most apps are build on web technology and native apps are more of the exception. A solution for Lazarus should focus on unifying at least android and iOS, even if it is incompatible to Desktop. A widgetset would from a users point of view be the best solution, but of course this would also entail the largest development and maintainance overhead.
Even something like Laz4iOS (as a sister project to Laz4Android), where even though it's not fully supported or integrated into Lazarus, would still go a long way in the public perception of Lazarus in general because of the obvious comparison to Delphi.
.....
The thing about this is, that LAMW is an android solution through and through. And one thing is, when you develop a mobile app, you usually want the same app for both Android and iOS. This is why most apps are build on web technology and native apps are more of the exception. A solution for Lazarus should focus on unifying at least android and iOS, even if it is incompatible to Desktop. A widgetset would from a users point of view be the best solution, but of course this would also entail the largest development and maintainance overhead.
I think that a web-technology based approach, if integrated seamlessly, has many advantages over what Delphi is doing.
Whenever I used Firemonkey, I found it pretty hard to make some decent looking styles...
...Firemonkey never felt native...
...And one thing is, when you develop a mobile app, you usually want the same app for both Android and iOS...
What I was wondering, as QT5 supports Mobile, wouldn't it be possible to use the already existing widgetset for mobile...
I disagree about that point. This "integrated seamlessly", would likely have to be to make JavaScript, HTML, and CSS virtually invisible. It appears to me as something very difficult to pull off. Even in the case of Smart Pascal or pas2js, there will be conflicts between the desktop and web technologies or languages involved, where the user has to have web developer type knowledge to solve. It then creates a conflict of having to jump over one side of the fence or the other. Where the Delphi approach limits such issues. You are more focused on targeting the OS, and web technologies are not on the radar, unless that is what the user is focusing on.You also have the same conflict in Delphi. Firemonkey is a completely different framework that is completely incompatible with the VCL. If you come from the VCL things like layouting or styling of Firemonkey applications are completely different. A web technology based framework for GUI development would be similarly not compatible with the LCL as Firemonkey is not compatible with the VCL.
I think the web technology based approached works better with people who have advanced web development backgrounds, who are then targeting the desktop. Keep in mind that JavaScript is a "3 or more for 1" package deal, that includes HTML and CSS. Where the Delphi approach would arguably be better for those that are coming from desktop based or Pascal backgrounds. To include those that primarily interface or work with the desktop and desktop apps, such as IT professionals, workers at various businesses, etc...Not necessarily. You could easiely build a framework that hides all the HTML and CSS, the same way the LCL hides the underlying technology through the widgetset system
Well, part that is opinion, and another part is how Delphi has implemented it. Add to that, the FireMonkey framework is something that Delphi bought and then integrated, versus developed themselves. As with anything else, it can improve with each new version.Yes, the thing I think was the single bad design decision with Firemonkey was, to implement everything new from scratch. The advantage of using web technology is that already all of the hard stuff is made for you. HTML and CSS are already doing exactly what Firemonkey wants to do, they are a technology for building GUIs that are able to adept to any screen and resolution dynamically, utilize all the different forms of user input and allow for a high degree of configurability.
I very much agree with you. I think this is where a bit of uneasiness about LAMW comes in, despite it being such a great initiative and project. It's like solving one part of the equation, but not the other. But, it's what is out there. Better there is an Android solution, then none.Sure having LAMW is nice, and defenetly better than not having it. Back when I used it I was quite amazed that this rather hacky solution was easier to use than the official android studio :D
Preferably, there be a solution for both Android and iOS. Except to me, and acknowledging the present situation, even if Lazarus had two totally different solutions then that would be better. If there is Laz4Android, which is totally different from Laz4iOS, at least both exist. Though even in that scenario, I do think there would be a significant level of cross-over and concepts.
Some years back, it looked like Lazarus users/independent developers were making iPhone apps and did a significant amount of work towards an iOS solution. Oddly, whenever it looks like an iOS solution is about to come together (to a LAMW level), it seems to get abandoned. Example, from Simon Choi, https://blog.naver.com/simonsayz/221209784815 (https://blog.naver.com/simonsayz/221209784815).
@loaded
To prevent confusion and misunderstandings, letting you know that his thread wasn't created by me.
If I where that customer, I would simply ask why you would use this technology over the alternatives that don't require twice the effort. And most customers would probably then rather hire someone using the technology that doesn't cost them twice as much for the same work
Sure having LAMW is nice, and defenetly better than not having it. Back when I used it I was quite amazed that this rather hacky solution was easier to use than the official android studio :D
...But if I had to develop a mobile app, even if there was an Laz4iOS and both LAMW and Laz4IOS would both be of great quality, I would not chose lazarus, because even though I like it really, I would not want to do twice the effort for building the same app against two different frameworks, if there exist solutions out there which let me do it in one.
Imagine pitching this to a customer: "Yes, ok I am going to develop the Android and iOS app, but it will cost you twice as much because the technology I am using requires to build evrything from scratch for each system". If I where that customer, I would simply ask why you would use this technology over the alternatives that don't require twice the effort. And most customers would probably then rather hire someone using the technology that doesn't cost them twice as much for the same work
...You also have the same conflict in Delphi. Firemonkey is a completely different framework that is completely incompatible with the VCL. If you come from the VCL things like layouting or styling of Firemonkey applications are completely different. A web technology based framework for GUI development would be similarly not compatible with the LCL as Firemonkey is not compatible with the VCL...
I am seeking here for some oversight (supervision) in my efforts to find an oversight (omission to glean from the provided info). Could you help?
Maybe, but that will only change if people volunteer. Answer questions, document, supply patches....
Obviously there are already existing people, who supplied what is already there. Not sure if they are all still active and the Android stuff, or if they all read the forum. Maybe some of them are on the mail list. Maybe some are temporarily or permanently busy with other things. Again, all volunteers. Each decide for themself, when and how much...
...All that may be true. But it is also chicken and egg...
Without advertising what is there, no one will come, and no new volunteers. And without volunteers, it will not progress or maybe just ever so slowly.
But yes, if some wikipage promises to much, then it should be thought to be corrected.
Find out if the author of that page is still active. Leave a note on the wiki's talk page, ask here on the forum, and also ask on the maillist(s). If they are still there, speak to them.
A proper Lazarus integration, such that it is compatible with other platforms in the "write once compile anywhere" principle would require a custom android widgetset. There was the effort on making the "custom drawn" widgetset available for android: https://wiki.lazarus.freepascal.org/Custom_Drawn_Interface/Android
The custom drawn widgetset is from the idea pretty similar to Firemonkey, i.e. on how delphi supports cross compatibility. I don't know if this was continued and if so what the current state is.
The thing is, creating a native look and feel is actually quite hard, requires a lot of time and effort.
And the Lazarus/LCL project has enough problems trying to get to grips with things like gtk3.
There are some who would argue that Android and iOS are so overwhelmingly important that desktop OSes will shortly be eclipsed. I'm not one of them.
There are others who would argue that the important thing is being able to implement apps based on an HTML/CSS GUI which is an idea that's been around since Netscape proclaimed itself the Universal Desktop in about '95. I don't think I'm one of those either...
One possibility would be to completely decouple the Android-specific part of the LCL into a separate project, but there's already enough of a problem with occasional issues with LAMW being interpreted as a weakness in the main Lazarus IDE.
In short, I don't have an answer other than suggesting that the people who complain about deficiencies in any particular LCL variant should be encouraged to engage with the development and maintenance projects... and I have very little expectation that that would be productive.
What I was wondering, as QT5 supports Mobile, wouldn't it be possible to use the already existing widgetset for mobile. But I am simply not knowledgable enough about QT and the corresponding widgetsets for that matter
The thing is, creating a native look and feel is actually quite hard, requires a lot of time and effort. Oracles JavaFX, one of biggest custom drawn interface library out there, does not have this to this day. The main problem is, as soon as the underlying OS is updated, you need to update your skins for that version.
Especially on android you have the problem that different manufacturers (like Samsung) provide their own styles to their android versions, that look different to vanilla android.
Maintaining such a thing takes a lot of time and effort. This is basically the whole buisness model of frameworks like QT
IMHO when doing custom drawn, there is only one way to do it right, if you don't have the resources to make and maintain the native look and feel (which tbh I don't think Lazarus has), don't focus on making it look native, but on making it easiely customizable.
How much Android support would cost? Would be $10000 enough? :)
There are some who would argue that Android and iOS are so overwhelmingly important that desktop OSes will shortly be eclipsed. I'm not one of them.They already are, mobile makes up around 55% of the market share. There are a lot of people who have a mobile device but no desktop computer, or have a desktop but only use it for very specialized things (e.g. just for working). So just in raw numbers, mobile devices already eclipsed desktops.
There are others who would argue that the important thing is being able to implement apps based on an HTML/CSS GUI which is an idea that's been around since Netscape proclaimed itself the Universal Desktop in about '95. I don't think I'm one of those either, but it's possibly a bit more defensible when you take QML into account... however I've encountered problems on more than one occasion when I've come up against a large-scale program comprising multiple (Python) sub-projects held together by the Electron or Uranium frameworks... with nobody able to say how the ensemble should be debugged.Well back in the 90s web development was not really prevalent, today JavaScript one of the most widely used programming platforms, making up between 10%-20% of the market share (depending on which statistic you go by). The reason for this is simple, all modern systems provide browsers, some systems even exclusively (e.g. many Smart TV OS only allow webapps). So web development is the easiest way to target as many platforms as possible.
But, clearly Android applications can be built in a couple of different ways by Free Pascal/Lazarus.
There is a strong argument about whether mobile users always expect or demand a "native look". There are many cases and exceptions, where applications that didn't have a native look were embraced and successful. This could also depend a lot on the type of application that it is as well. It arguably comes down to how well that it's done.
Android could arguably replace Windows (check out https://www.android-x86.org/ (https://www.android-x86.org/) and others) and to a lesser degree macOS, for the desktop. A huge number of people already carry around Android phones and are very familiar with using them. It's not that big of a leap for people to use Android laptops or plug their Android device up to/WiFi into/use the cloud for large external storage and also connect the Android to their flat screen TV.Nah, Windows is here to stay, it could be in some areas overtaken by Android, but in many domains there is no chance. One huge advatage of windows is that it is backwards compatible to the stone ages, so if you look for example into the critical infrastructure sector: Hospitals, Powerplants, etc. they are still using software from multiple decades ago and this is only possible because of Windows. Android is based on Linux, which is famous (well more the GLIBC rather than linux itself) to switch up abis to make it not backwards compatible.
That Google hasn't made a stronger push to bring this about (Android on the desktop/laptop), has arguably to do with them fumbling around with the Chrome OS and Chromebooks (as if they don't already have access to enough personal information). Android is open-source, and a very short jump to the Linux world :o. Where with Chrome OS, that's totally under Google's control. But, Google may at some point change direction.I don't know what you are talking about, but Chrome OS is a massive success for google. Last year it overtook MacOS as the second most used OS for Desktops worldwide. Also it is kinda Open Source. The basic OS is Chromium OS, which is fully open source. Chrome OS is basically just Chromium with some addons and pre installed proprietary software (basically the integration into the google services is proprietary, but the whole OS is open source). It is like the difference between Chrome and Chromium.
That would be a terrible thing to do. Lazarus and the LCL has embraced Android for many years already, with many people already have built and are maintaining Android apps. We are really just talking about the other side of the mobile equation, more strongly embrace iOS too or that there would be an equivalent project like Laz4Android, thus Laz4iOS.As already mentioned earlier, Laz4Android with LAMW is specifically tailored towards android. The whole architecture is build around android. Trying to build now an Laz4iOS that behaves similarly will only make problems down the line.
Not everyone can be a developer. Usually, you are talking people who are exceptional and/or very experienced, that will walk that path. Most people aren't professional programmers, and a lot of people only engage in programming as a hobby. Climbing the ranks to become an advanced enough programmer, in addition to time and interest, is not the easiest thing for everyone. So, it might be a matter of trying to more actively find or encourage those with the needed abilities and interest.I completely disagree on every level. A programming platform should make programming as easy as possible. The Problems a programmer has to solve are already hard enough on it's own, formalizing real world problems, finding algorithms to solve them and applying these solutions to the real world are in it self extremely hard. If aside from this you make the act of programming also really hard, all you do is gatekeep people who could potentially write really good and useful programs, just because they might not have the time or the will to go through additional hoops.
I agree with your point about focusing on customizable. There is a strong argument about whether mobile users always expect or demand a "native look". There are many cases and exceptions, where applications that didn't have a native look were embraced and successful. This could also depend a lot on the type of application that it is as well. It arguably comes down to how well that it's done.I don't think that you need to have a native look, if you have the capabilities to make a good custom look. But many developers are neither good at developing great UIs and a good User Experience (it has a reason why these two areas are dedicated jobs with quite a good salary). The thing about native look is, that it is easy. If you make a windows application and just use windows form elements, it will generally look and behave fine. If you make a custom look, and aren't very good at it, it will look terrible.
In addition, by Lazarus already having LCL-CustomDrawn-Android, it then also creates the expectation to see LCL-CustomDrawn-iPhone. It could be said that it comes off a bit weird to somewhat embrace Android, but not iOS.
I completely disagree on every level. A programming platform should make programming as easy as possible. The Problems a programmer has to solve are already hard enough on it's own, formalizing real world problems, finding algorithms to solve them and applying these solutions to the real world are in it self extremely hard. If aside from this you make the act of programming also really hard, all you do is gatekeep people who could potentially write really good and useful programs, just because they might not have the time or the will to go through additional hoops.In short, I don't have an answer other than suggesting that the people who complain about deficiencies in any particular LCL variant should be encouraged to engage with the development and maintenance projects... and I have very little expectation that that would be productive.Not everyone can be a developer. Usually, you are talking people who are exceptional and/or very experienced, that will walk that path. Most people aren't professional programmers, and a lot of people only engage in programming as a hobby. Climbing the ranks to become an advanced enough programmer, in addition to time and interest, is not the easiest thing for everyone. So, it might be a matter of trying to more actively find or encourage those with the needed abilities and interest.
The best programming language would be one that takes an a specification or description of a program and turns it into a bug free fully fledged program. We won't have this any time soon, but we should at least try to come as close as possible to this ideal.
The encouraging thing is that it can be made slightly easier by the robust type checking etc. inherent in Pascal (and more recently Rust etc.). But in order to convince people of that they need to be able to develop for their chosen platform... and a console-based "Hello, World!" doesn't cut the mustard any more.I think the most important part isn't the language itself, it's the tooling. I think one of the great features of Javascript, and why it is so popular, is because, basically you can just open up any editor, write 3 lines, double click it and it works.
Ah ok so I misunderstood this, I thought this was about that the application of the LCL frameworks for android and/or ios should be targetet at experienced programmers. This makes sense
I think the most important part isn't the language itself, it's the tooling. I think one of the great features of Javascript, and why it is so popular, is because, basically you can just open up any editor, write 3 lines, double click it and it works.
e.g. WhatsApp the most widely used chat application is not available for Desktop
Also whatsapp still requires a phone
I think the most important part isn't the language itself, it's the tooling. I think one of the great features of Javascript, and why it is so popular, is because, basically you can just open up any editor, write 3 lines, double click it and it works.
Lazarus for Windows is also quite great, you just download the exe installer and everything works out of the box. But only if you develop on windows for windows. Even things like compiling for Linux on a Windows is pretty complicated
...but in practice the customers really want it, but consider it a nice to have that they don't want to pay for...
That said, I have some doubts about single source GUI for mobile and desktop. The form factors and UI culture are simply quite different.
What I was wondering, as QT5 supports Mobile, wouldn't it be possible to use the already existing widgetset for mobile. But I am simply not knowledgable enough about QT and the corresponding widgetsets for that matter
Android development seems to be progressing reasonably with jmpessoa and his LAMW addon, though it could do with better promotion and Wiki documentation.
iOS/iPadOS development seems all but dead: one forum thread in 2019, two in 2020 and one this year.
Whatsapp basically uses your telephone number as your login. Changing that for a desktop app would be massive, but also makes it an exception, and IMHO a bad model for comparison.It is highly dependent on the kind of app. For example Uber Eats, even though it has a website, requires you to create your account via their app. Gorillaz the grocery delivery service, is completely only on app. Another great example is Spotify, while it has a Desktop version, the App is much more used.
I tried to get mobile development to get rolling several times in the company I work for, but in practice the customers really want it, but consider it a nice to have that they don't want to pay for. IOW it faltered already before the divisive discussion about platforms :)
That said, I have some doubts about single source GUI for mobile and desktop. The form factors and UI culture are simply quite different.Yes and no. It is of course very different, but there are a lot of things that can be automated. Windows UWP apps, Angular webapps, Xamarin and even FireMonkey already support this quite good with a high degree of automization.
It's needed, but don't think JavaScript is all that wonderful. Let's not forget how widely popular that TypeScript has become, because of the perceived inadequacies of JavaScript. Then of course you are not usually dealing with just JavaScript, but 2 other "almost languages", CSS and HTML. Thus the dizzying array of constantly changing and new frameworks to try to tame the "3 headed monster".Javascript is a terrible language. It was created by one person in a week and afterwards always extended but could never be redesigned as it requires to be backwards compatible to the very first version. The new features are often actually quite nice, but that is the main problem with JS, it has a lot of terrible features and a lot of good features and as a developer you are responsible for only choosing the good features (what of course isn't that easy, especially for beginners). If you like to have a good laugh, watch the talk "Javascript the good, the bad and the ugly".
Could you elaborate about Qt5 mobile platform support, as it could possibly pertain to Lazarus mobile development?I don't know much about how QT is integrated into the LCL, but on Desktop you can basically the QT-Creator to create C++ GUI applications to run on mobile. The QT Creator form editor is a run of the middle WYSIWYG form editor and the applications work on both desktop and mobile. It is probably the closest to how an LCL integration would look like for the user.
I've always been torn between whether or not it's wise to have a single language like Object Pascal which is proficient at both application- and system-level programming, or if a split as with VB and VC++ was preferable. Now that so many people demand automatically-managed memory I think I'm moving towards the split approach: Rust (as a specific example) appears to succeed at doing both safely but the cost is having assignment semantics which are rather non-ALGOL.
We have reference counted strings and arrays, but classes need manual memory management, which is especially weird if you think about that classes already try to go the Javaesque way of hinding the fact that they are pointers in the first place.
What also makes this neat in C++ is that you can overload the dereferencing operator, so you can create classes that for the user behave exactly like a pointer, but internally do other stuff like reference counting.
If management operators would be working correctly this could also be implemented (even though we don't have a dereferencing operator).
In addition, by Lazarus already having LCL-CustomDrawn-Android, it then also creates the expectation to see LCL-CustomDrawn-iPhone. It could be said that it comes off a bit weird to somewhat embrace Android, but not iOS.
Developing for iOS is more involved than Android as not only you need a macOS computer, but also an iOS device (both of which aren't necessarily cheap). For someone like me for example that would be quite an investment (as I use Linux/Windows and Android) thus I prefer to do that investment somewhere else instead.
Thank you for entering the discussion. Much respect, as I realize it's a bit tricky from your perspective....but in practice the customers really want it, but consider it a nice to have that they don't want to pay for...
Maybe refer to the post by Chronos on the 2nd page. Clearly developers might want to PM him for clarification.
The problem is that more people use mobile and tablets now than desktops. The desktops are more suitable for real work but still most of the people simply have their smartphone with themselves all the time. So inability to target that audience by Lazarus is pretty huge deficiency. Sure, not every development environment support all modes like desktop, mobile, web and console. But with Lazarus we have that expectation "Build once, compile anywhere" which is simply not true for entire mobile segment.
QuoteThat said, I have some doubts about single source GUI for mobile and desktop. The form factors and UI culture are simply quite different.
I agree about the form factor and cultural elements involved, but would say there is possibly more at stake. Mobile is becoming increasingly more important, where more people are going to continue to notice Lazarus hasn't embraced it, and a lot of people would be looking to create applications on both.
I don't want to be so "look at them" about it, but other languages and IDEs seem to increasingly be providing both mobile and desktop development options.
Among what's out there is of course Delphi, and Lazarus is almost automatically going to be compared with it. Culture is definitely tricky, but at least when it comes to form factors and simulating mobile screens, it appears solvable. Various IDEs have solutions and even their own simulators for developing on Windows, for both Android and iOS.
Looking at Lazarus, many can already see the seeds of potential mobile development. Even if just only the custom drawn interface path, there is LCL-CustomDrawn-Android, so that there isn't LCL-CustomDrawn-iPhone seems a bit odd. Moving in only that direction would seem helpful.
When I retitled and split this thread off from the original, I should probably have added iPadOS to the title. A lot of acquaintances in my older age group have forsaken computers altogether and, while most have mobile phones, it is tablets that have been filling the gap.
How many have custom applications made by SMB on them other than maybe games?
Developing for iOS is more involved than Android as not only you need a macOS computer, but also an iOS device (both of which aren't necessarily cheap). For someone like me for example that would be quite an investment (as I use Linux/Windows and Android) thus I prefer to do that investment somewhere else instead.
Nah, Windows is here to stay, it could be in some areas overtaken by Android, but in many domains there is no chance. One huge advatage of windows is that it is backwards compatible to the stone ages, so if you look for example into the critical infrastructure sector: Hospitals, Powerplants, etc. they are still using software from multiple decades ago and this is only possible because of Windows. Android is based on Linux, which is famous (well more the GLIBC rather than linux itself) to switch up abis to make it not backwards compatible.
Which of those IDES provide that? IOW which also leverage their prime native desktop solution on mobile ?
You are begging for a single GUI library solution here. Which of those IDES provide that? IOW which also leverage their prime native desktop solution on mobile ? Does MS support MFC on mobile? Does Delphi support VCL ?Xamarin. Started of as a framework for supporting GUI applications using .Net Core for Windows, Linux and (I think) OSX, and later was expanded to also include mobile apps. Today it is part of Microsofts Visual Studio. And it is actually pretty successfull.
I didn't want to get into naming such, because don't want to promote others (and I prefer Object Pascal). Various game engines provide the ability to develop apps on the desktop for Android and iOS. An example is Solar2D (that has their own built-in simulator) in the Lua world (which comes with the limitations of scripting), which can be somewhat compared to the Castle Game Engine for Object Pascal. Solar2D does have the advantages of at one time being commercial, before becoming open source. Various game engines lend themselves towards also being useful for creating apps which are not just games. Of course the baggage of a game engine would not be ideal for many developers, but that's a depends type of thing. Another example is B4X, a Basic and Java hybrid, that somewhat compares to Delphi and Lazarus. They provide a solution for both desktop and mobile development, but both Delphi and Lazarus are superior for desktop app creation in comparison. They are a mix of freeware and payware. Arguably, another downside to their approach is it's more of a soft transition into the Java world, whether the user realizes it or not.
You are begging for a single GUI library solution here. Which of those IDES provide that? IOW which also leverage their prime native desktop solution on mobile ? Does MS support MFC on mobile? Does Delphi support VCL ?Xamarin. Started of as a framework for supporting GUI applications using .Net Core for Windows, Linux and (I think) OSX, and later was expanded to also include mobile apps. Today it is part of Microsofts Visual Studio. And it is actually pretty successfull.
Various game engines lend themselves towards also being useful for creating apps which are not just games.
As you are talking about game engines, another project on my never ending list of things I want to do somewhen when I have free time is to create a godot wrapper for pascal.
How many have custom applications made by SMB on them other than maybe games?
I think that's the really important thing, or possibly rephrased to include larger-scale corporates known to be using Delphi.
Finally the third truth is that even if you agree on the target(e.g. VCL apps on mobile), the route to it is a problem too. If it takes too long, the mobile world might already fundamentally changed before it is ready.
Xamarin is a rebranding of Monodevelop, it targeted Linux before Windows. One can discuss if it is a backport or not, but regardless of how you view it, Mono has had 15+ years of corporate stewardship (Suse/Novell and then Microsoft iirc).Not quite Monodevelop used GTK# for Forms. It then added the Xamarin GUI framework as an alternative to GTK#. This was the framework I was talking about, not the IDE. Later the IDE was rebranded Xamarin and later again it was bought my MS and incorporated into VS.
Finally the third truth is that even if you agree on the target(e.g. VCL apps on mobile), the route to it is a problem too. If it takes too long, the mobile world might already fundamentally changed before it is ready.
That's interesting- and scary. Slightly earlier in the thread somebody suggested that Windows had largely stagnated with stable APIs etc.
will the mobile APIs similarly stabilise, or are there quite simply too many people working on them with too many different approaches for that to ever happen?
In summary, I don't see a practical route to something like that. We can't develop fast enough, and the solution will require permanent heavy duty maintenance to keep up with the yearly iterations. Moreover we already have a shortage of interested developers for even the rock bottom solution (customdrawn/lamw, the latter which is the labour of love of one developer).
I can be wrong of course. Maybe one of you has a 10 person team in his pocket just chomping at the bits to contribute :-)
When I retitled and split this thread off from the original, I should probably have added iPadOS to the title. A lot of acquaintances in my older age group have forsaken computers altogether and, while most have mobile phones, it is tablets that have been filling the gap.
How many have custom applications made by SMB on them other than maybe games?
Everybody tried to tell to Elon Musk that it is impossible to start a new car company or to start new rocket factory. https://www.youtube.com/watch?v=k9zTr2MAFRgA bit off topic, but Musk didn't start any of these companies, he bought them.
If you make it delphi compatible, you repeat the same mistakes Delphi made. I already said why I think Firemonkey is not a good solution, but to reiterate just one point. Most modern frameworks use CSS for styling like QT, JavaFX or Xamarin. CSS is powerful, well designed (by an expert comittee) and refined over multiple decades, and it is well known. There are much more resources available than for Firemonkey. If you need a special style, chances are there already exist CSS style sheets for that somewhere on the web.
- Implement Delphi compatible FMX framework for FPC. After all, Delphi needed to solve the same problem. VCL was too Windows oriented and they could either break VCL compatibility to extended it to be usable across new platforms or to create(or buy) completely new more modern GUI framework. For sake of existing customers they decided to go with new framework. So in case of Lazarus and LCL this decision still needs to be done.
Then you can ask yourself the question, if I am already paying 150€/month to use delphi, why should I use Lazarus in the first place? One reason that I think is why many people use Lazarus is because they believe Delphi is not worth that money.
- Develop desktop app in Lazarus and mobile variant for Android and iOS in Delphi. How to sync GUI between those two environments? That is the tricky part. Perhaps one can create some Lazarus LCL to Delphi FMX converters. Or create LCL backend to target FMX as widgetset.
There is already Pas2JS which you can use with Cordova to create cross platform apps. Also LAMW works in a similar way, it basically auto-generates a Java GUI which communicates with a pascal backend. So all the GUI stuff is autogenerated Java.
- Another way to solve this would be to create some cross-compiler or better say transpiler to convert pascal code into code of other platforms which support Android/iOS. It may be Java, Kotlin, C++ or something else. This may not be just about language but also about GUI frameworks. That would be pretty complex and time consuming task but it is possible.
You misunderstand the problem the compiler (the FPC) already does fully support iOS and Android development. It's a library problem, that there is no GUI library available. There is absolutely no reason why a new compiler would be needed.
- Create complete new more modern Object Pascal/Delphi compiler to target multiple platforms. Indeed, not and easy task. But still one of way to achieve that. Over the years there were many Pascal compilers developed and new are still created to some degree. One example would be https://wiki.freepascal.org/Projects_using_Lazarus_-_Developer_utilities#PicPas which supports only limited pascal syntax and no GUI design support, but it is still pascal compiler. The list of other compilers https://pascal.fandom.com/wiki/List_of_compilers_and_interpreters
I actually used different Linux systems phones multiple times. I even bought used phones specifically for testing out different systems. They are completely unusable at the moment. I've found the best usability was to have another phone you can use to ssh into them to use the Linux phone.
- Use Linux phone instead of Android. Linux phones are still slow, not fully functional, not widely available and they are expensive. But this may change in future. https://www.pine64.org/pinephonepro/
Will you challenge to fight the Flutter created by Google?
If you make it delphi compatible, you repeat the same mistakes Delphi made. I already said why I think Firemonkey is not a good solution...
There is already Pas2JS which you can use with Cordova to create cross platform apps. Also LAMW works in a similar way, it basically auto-generates a Java GUI which communicates with a pascal backend. So all the GUI stuff is autogenerated Java.
...create an LCL widgetset based on a browser interface. Where the Pascal app connects to a javascript client in the browser via websockets and gets notified about events over this channel and can instruct the javascript to update the browser...
Oddly, nick1965's complaint about trying to use Lazarus for Android has a small bit of legitimacy. Don't get me wrong, in no way am I excusing being rude or a user not taking the time to read help documentation (including wiki). The angle that I'm talking about has to deal with expectations, and arguably the Lazarus team should be aware of such. Ignoring that people would want to develop mobile applications for Android and iOS is strange. Delphi has positioned itself where it's not just for the desktop, but also for mobile. People who would be looking at Lazarus as a potential alternative, would obviously be considering this when making comparisons and decisions.I don't want to blame anybody, but unfortunately this isn't about FPC/Lazarus only, but about whole open source. It's hobby for maintainers and they think about their own goals only - they don't accept requests from other people. And that's, what paid companies usually do - they want to satisfy as many clients, as possible. If you need something - you should do it yourself. I personally don't like it and also think, that it's real reason, why open source stagnates. Because it's obvious, that it would be much easier for maintainer, who already has lots of experience in developing this project, to implement required changes. And it would be counter-productive for me to learn everything about project from scratch to implement my own changes. Yeah, old version of Delphi has some limitations and even bugs. But it isn't worth it for me to start learning everything about FPC/Lazarus development in order to add several missing features to it. Not everybody, who needs to just hammer a nail, should know everything about making hammers.
Well then, perhaps you don't see it because you are blind to new approaches :)
Let's discuss how to overcome those obstacles and weight various strategies to solve the problem.
Let it be just open discussion with new ideas or revised old ideas. Everybody tried to tell to Elon Musk that it is impossible to start a new car company or to start new rocket factory. https://www.youtube.com/watch?v=k9zTr2MAFRg
Back to the topic. Mobile platform is used more than desktop now and your numbers may vary but that is the fact https://gs.statcounter.com/platform-market-share/desktop-mobile-tablet Sure it depends if one is interested in mobile "market" or not. As I use my Android device daily, I really want to use my own applications or other open source applications which are available for desktop also on my phone.
Sure, we can discuss many years about GUI differences between desktop, mobile and web. Every technology has own specifics and pros and cons. I even want to target Smart TV as a platform.
With Delphi FMX you can create mobile and desktop app with single code base. There will always be some platform specific things but normally it should be pretty easily possible. Delphi is kind of expensive and doesn't run on Linux so it is not an option for me.
And even it that would not be single application for those platforms, still Lazarus as IDE should offer ways to create mobile, desktop, web, console, tv, car, e.g. as separate applications. Just imagine an dialog window called "New project" where you can select needed GUI layout or possibly select generic dynamic layout. This ideal thinking is more like from top to bottom. That is the premise. To have development environment to allow develop an application/service/library/tool for any platform and GUI layout. That is where we can get in some distant future.
Back to reality. How can Android application be currently created? By quick check of existing Android related wiki pages https://wiki.freepascal.org/Portal:Android I can say that it is quite a mess. A lot of long and some outdated tutorials with many manual steps and auxiliary GUI tools to do a simple thing. To build GUI application. Can it be as simple as creation of a new project and hitting F9 to run in Android emulator? Or without emulator at least to simply compile and create Android package apk. Also you may need trunk FPC or Lazarus, anything can break and will probably break. Upgrade to newer Lazarus and FPC will probably break everything and one will need to do that again. Does it look like only to me as a big waste of time? Would it be better to start implementing partial Android/mobile support directly into IDE? Perhaps as an experimental feature which can be activated from somewhere. Sure, I can answer this by myself, this would take too much effort and there are no volunteers, so whatever.
Ok, Lazarus IDE can't support Android directly so what are other options apart from LAMW and other obscure ways described on wiki?
Implement Delphi compatible FMX framework for FPC. After all, Delphi needed to solve the same problem. VCL was too Windows oriented and they could either break VCL compatibility to extended it to be usable across new platforms or to create(or buy) completely new more modern GUI framework. For sake of existing customers they decided to go with new framework. So in case of Lazarus and LCL this decision still needs to be done.
Develop desktop app in Lazarus and mobile variant for Android and iOS in Delphi. How to sync GUI between those two environments? That is the tricky part. Perhaps one can create some Lazarus LCL to Delphi FMX converters. Or create LCL backend to target FMX as widgetset.
I don't really think language is that much of a problem. The problem is creating a layer over multiple very different systems. (iOS, Android and Desktop and then some various incarnations (TV/tablet/phone).
- Another way to solve this would be to create some cross-compiler or better say transpiler to convert pascal code into code of other platforms which support Android/iOS. It may be Java, Kotlin, C++ or something else. This may not be just about language but also about GUI frameworks. That would be pretty complex and time consuming task but it is possible.
- Create complete new more modern Object Pascal/Delphi compiler to target multiple platforms. Indeed, not and easy task. But still one of way to achieve that. Over the years there were many Pascal compilers developed and new are still created to some degree. One example would be https://wiki.freepascal.org/Projects_using_Lazarus_-_Developer_utilities#PicPas which supports only limited pascal syntax and no GUI design support, but it is still pascal compiler. The list of other compilers https://pascal.fandom.com/wiki/List_of_compilers_and_interpreters
- Stop using Pascal and use different better tool to create mobile/desktop application. One interesting open source project is Haxe https://haxe.org/use-cases/ which can also target desktop and mobile platforms. Although still not ideal. There are so many technologies which tries to solve that multi-platform problem. Mobile apps can be developed with C#/.NET, Python, JavaScript and many others. I am not aware of any what would fulfill all my needs. So I am still using Lazarus.
- Use Linux phone instead of Android. Linux phones are still slow, not fully functional, not widely available and they are expensive. But this may change in future. https://www.pine64.org/pinephonepro/
I understand that there are many other Lazarus weak areas like to this date not implemented single window docked IDE like Delphi has (AnchorDocking is just a poor guy alternative). Also Gtk3, Gtk4, Qt5 or whatever new toolkit version not fully supported. This is never ending effort to catch up with upcoming technologies and ever changing world. But this topic is about Mobile development and in this regard Lazarus is lacking.
n, if I am already paying 150€/month to use delphi,
(does that figure include the mobile option, or is that extra?)Windows macOS and Mobile. Only Linux requires the bigger package and its around 330€/month.
(does that figure include the mobile option, or is that extra?)Windows macOS and Mobile. Only Linux requires the bigger package and its around 330€/month.
The new version is still in beta and the old version is not a real app. It's a slim interface that connects to your phone. All the messaging functionality is performed by the App on the Phone and the Desktop client has no functionality on it's own. I don't count that as a real desktop version.
Also whatsapp still requires a phone, you can only use the desktop app in addition to an already existing mobile installation.
Well, maybe it's in beta, and it's old version, and it's not a real app, and it's a slim interface, and ... all the rest you've said.It isn't a desktop version. It's an interface to your smartphone. Sure it is useful, but whatsapp is still running on your phone. If you turn off your phone your desktop app stops working. You aren't using a desktop version of whatsapp, you are using your phone just through a remote control.
But you also said earlier that WhatsApp is not available on desktop, yet I use it and I found it very useful. And I don't know if it is a real desktop version or not, but it works (and it does that probably for millions of users).
It isn't a desktop version. It's an interface to your smartphone. Sure it is useful, but whatsapp is still running on your phone. If you turn off your phone your desktop app stops working. You aren't using a desktop version of whatsapp, you are using your phone just through a remote control.I'm not 100% sure, as I haven't checked it myself, but according to some recent news WhatsApp should have full desktop version.
It's like saying I have docker on my phone because I can SSH into my server to execute docker container
I'm not 100% sure, as I haven't checked it myself, but according to some recent news WhatsApp should have full desktop version.Yes there is one, but it is still in beta. The desktop client has the capabilities, but you need to opt in to the beta to use it (can be done from the whatsapp app).
Developing for iOS is more involved than Android as not only you need a macOS computer, but also an iOS device (both of which aren't necessarily cheap). For someone like me for example that would be quite an investment (as I use Linux/Windows and Android) thus I prefer to do that investment somewhere else instead.
Understand the situation. Difficult to develop for hardware that one doesn't possess. So, are you also saying that yourself or possibly other developers might need macOS and iOS devices provided or donated by the Lazarus community in order to actively support mobile development for iOS? It appeared that Chronos made an offer (page 2), that maybe should be discussed with him by PM.
While I agree that Windows will be with us for many years to come, a lot has to do with Microsoft's hold on being used in the business world (thanks to Microsoft Office). But, let's not forget that Microsoft Office is in the cloud and are apps that can run on Android and iOS. I do think the percentage of Windows OS dominance on the desktop and/or for general use will dwindle. When it comes to personal computing, a lot of people are relying on their phone and have become used to Android and iOS apps.
Ok, Lazarus IDE can't support Android directly so what are other options apart from LAMW and other obscure ways described on wiki?
- Implement Delphi compatible FMX framework for FPC. After all, Delphi needed to solve the same problem. VCL was too Windows oriented and they could either break VCL compatibility to extended it to be usable across new platforms or to create(or buy) completely new more modern GUI framework. For sake of existing customers they decided to go with new framework. So in case of Lazarus and LCL this decision still needs to be done.
- Develop desktop app in Lazarus and mobile variant for Android and iOS in Delphi. How to sync GUI between those two environments? That is the tricky part. Perhaps one can create some Lazarus LCL to Delphi FMX converters. Or create LCL backend to target FMX as widgetset.
- Another way to solve this would be to create some cross-compiler or better say transpiler to convert pascal code into code of other platforms which support Android/iOS. It may be Java, Kotlin, C++ or something else. This may not be just about language but also about GUI frameworks. That would be pretty complex and time consuming task but it is possible.
- Create complete new more modern Object Pascal/Delphi compiler to target multiple platforms. Indeed, not and easy task. But still one of way to achieve that. Over the years there were many Pascal compilers developed and new are still created to some degree. One example would be https://wiki.freepascal.org/Projects_using_Lazarus_-_Developer_utilities#PicPas which supports only limited pascal syntax and no GUI design support, but it is still pascal compiler. The list of other compilers https://pascal.fandom.com/wiki/List_of_compilers_and_interpreters
I understand that there are many other Lazarus weak areas like to this date not implemented single window docked IDE like Delphi has (AnchorDocking is just a poor guy alternative).
Also Gtk3, Gtk4, Qt5 or whatever new toolkit version not fully supported. This is never ending effort to catch up with upcoming technologies and ever changing world. But this topic is about Mobile development and in this regard Lazarus is lacking.
Generally, I think we should try to get a solution to this problem. I know that most people might not have the time or proficiency to do any development in these areas, but one solution might be to utilize the already existing Free Pascal and Lazarus foundation to collect donations for the implementation of such a project.
For example in your list above you mentioned using a transpiler. Well there is actually currently a project for integrating electron app development into Lazarus using pas2js: https://foundation.freepascal.org/projects/thread-pool-implementation
Electron works well on all major platforms, including mobile, so this is an effort theoretically anyone could support even without the corresponding skills and time.
FPC already supports multiple platforms including Android and iOS. So there is nothing that needs to be done regarding the compiler. It's library support that is missing (and in nearly all cases it's always library support that's the problem), in this case it's "LCL-Android" and "LCL-iOS" widgetsets.
As for Delphi's FireMonkey, have to strongly disagree with your assessment. FireMonkey has been arguably a success for Delphi or at least it can be acknowledged as a good move by them to use as a mobile solution. It put them very much into the mix of mobile app creation. Delphi's true issue with FireMonkey is they bought it from somebody else, versus creating it in-house, thus they had to shoehorn it into their existing product. The Lazarus team have the advantage of "20/20 hindsight", so can correct mistakes that FireMonkey has made, in addition to if they went that route then it would be their in-house solution that they developed. What they would create, would likely more smoothly fit the Lazarus IDE and ways of doing things.Yes it was a success for Delphi, but we must be realistic here, a success for Delphi is when people stop using it at a slightly slower rate. That doesn't mean that Firemonkey is a good solution. But what do you think how many people start learning Pascal just to use firemonkey? Well if you go by language popularity measures like the pypl index, Pascal doesn't even make it into the top 30 of most popular languages anymore so this number can't be that high.
Arguably, the JavaScript/HTML/CSS/browser route is best suited for web developers heavily involved and invested in that world. And, there is an avenue for creating HTML5 applications already, which is Pas2JS or Smart Pascal. That there is more that can be done with Pas2JS, I very much agree. Not against web technologies, just saying that it's a different perspective for a desktop programming language to specifically make use of it when adding to what they are doing, versus being a web developer of that world where JavaScript is the primary language and are seeking to extend it's reach from browsers to desktop and mobile.The usage of a widgetset is very different from how Pas2JS works. First Pas2JS is different from native objectpascal, simply due to the fact that it mapps onto javascript. For example the Pas2JS classes map onto Javascript classes. But Javascript classes are not classes but dynamic dictionairies so the Pas2JS classes also need to reflect this.
Well if you go by language popularity measures like the pypl index, Pascal doesn't even make it into the top 30 of most popular languages anymore so this number can't be that high.
So Firemonkey is a success for Delphi because it allows the existing Delphi developers to stick to Delphi (and probably a lot of already existing code) rather than having to switch to a new solution.
But if you are new to App development, the chances that you would choose Firemonkey over alternatives like React are basically 0.
...Pas2JS is it's own solution and not realy a part of the fpc-lazarus ecosystem. What I am talking about is a fpc-lazarus solution that uses the webbrowser simply as rendering engine...
...Such a solution would require as much knowledge by the developer about web technology like HTML or Javascript, as you need today knowledge of the QT framework to use Lazarus on Linux (which is absolutely none)
And I think there is just nearly no way in hell that Ada is ranked 17 and kicking the butt of Delphi, Free Pascal, and all the other dialects of Pascal combined (Oxygene, PascalABC, Smart Pascal, etc...).
I would trust the TIOBE index way more (where Object Pascal is ranked #16 this month and above Go, Kotlin, Rust...). Which is not saying much, because of how easy it is for the owners to "tip the scale" with their bias or agenda, while getting views. At least when the TIOBE index owner was confronted that Delphi was a dialect of Object Pascal, he did some grumbling about it, but reconsidered it and adjusted his Index. Even so, check out TIOBE's "Very Long Term History". Even though it has the top 15 languages since 1986, some how Pascal is not on there. Let's think deeply about that for a minute. He's showing Ada up there, which is not even presently ranked in his top 20, but not Delphi/Object Pascal. From the late 1970's to 1990's, Pascal was definitely on the map as a top 5 language. And Turbo Pascal and Delphi made a hell of run by themselves, where they didn't fall off until the early 2000's.Yes the PyPL index has some issues with respect to the definition of the languages, another example is combining C and C++ is a bit icky because these languages are, while related, rather different and see very different use cases. But the TIOBE index is much worse as a measurement, because it simply does not measure what it aims to measure. TIOBE only tracks searches for "XXX Programming Language", which is not representative with language usage at all. To give you one example, this month I googled "APL programming language", "ML Programming language" and "Go Programming language". But guess what, I don't use any of them, never have and probably never will be. I googled this exactly because I didn't know anything about them and wanted the most superficial introduction about the basic paradigms (i.e. the wikipedia article). What I haven't googled was "Python programming language", "C++ Programming Language" or "Pascal Programming Language" even though these three languages was what I was actually using this month, but still for the TIOBE index I count as an APL, ML and Go developer but not as a Python C++ or Pascal developer.
Yet TIOBE doesn't even acknowledge Pascal/Object Pascal in their "historical data", and probably because they messed up the language definitions so badly, where they don't know various compilers and IDEs were dialects of Pascal.
Why wouldn't this be true for Lazarus developers? You are talking about a similar issue of programmers that may have existing Pascal code and expertise, and want to leverage that for mobile app development. LAMW/Laz4Android is pretty much doing that, though taking a different route to get there.Because I think that this is not enough. We should strive for a solution that is actually good compared to other alternatives in different languages. Firemonkeys success is that it is good enough for keeping existing developers, but why be satisfied with this? Why not try to archive something that stands out and might attract new developers.
A person new to creating Apps would not automatically fall into using React. [...]I just used React as an example, but this can be exchanged for any of the other solutions, let it be QT5/QT6 (which today can be easiely used with not only C++ but also Python or Javascript), Xamarin, you name it.
The only realistic direction that I see would be to start something to just bridge Android/iOS based on some general FMX principles (without compatibility, too much hassle) or LCL customdrawn. (more headstart, but somewhat outdated). Or fully new with more CSS like approach, like Warfley advocates. (I'm no fan of that, but don't know enough about the praciticalities of such approach)
Pas2JS is it's own solution and not realy a part of the fpc-lazarus ecosystem. What I am talking about is a fpc-lazarus solution that uses the webbrowser simply as rendering engine.
Using Google Trends:Have you taken the time to also google for pascal? If I search for pascal in google, using an incognito tab, so it is unpersonalized (only considers my location in germany) I get on the first page 3 results regarding the physical unit of pressure, one page about german company called pascal, 3 pages about the mathematician Blaise Pascal, one page about the common german name Pascal, the general wikipedia article (where it links all articles that are tagged as pascal) and the wiktionary site.
https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F05y49,%2Fm%2F0n6y,%2Fm%2F019p2
It said BASIC > Pascal > Ada. BASIC (yellow line in the graph below) is slowly losing its popularity. Pascal (blue) is trying to keep its position. And Ada (red) is dying.
Ok, I've overlooked this. But this then basically is what the TIOBE index measures, and as already said, it is very flawed, because it can not distinquish between people searching for a language because they want to learn it, or if it is because they want to only know some superficial information about it. One reason why Basic and Pascal have such a high result there could be because their historical relevance. When you learn the history of programming languages, you will come into contact with them, the same way I've looked into Cobol and Fortran, even though I will never use these languages.
As already stated, the TIOBE index is inherently flawed and it's results can not be verified against any other metric of language popularity. It is simply not a useful measure for this
The users Seenkao and Skalogryz, have revived development and put it on GitHub (https://github.com/Seenkao/New-ZenGL (https://github.com/Seenkao/New-ZenGL), https://github.com/skalogryz/zengl (https://github.com/skalogryz/zengl)), but the effort appears a bit fractured when it comes to supporting iOS and Android equally.
Irrespective of the amount of visible mindshare that Pascal still commands, the fact that Embarcadero is still able to keep itself in business by milking its golden egg indicates that there are still enterprise-grade Pascal systems being maintained, whether or not they are being written ab initio. As such, it is in this community's interest to have a viable path for the people involved in that maintenance to "leverage" their talent onto Android and possibly iOS, which makes the subject of this topic worth pursuing: irrespective of the apparent statistics.
MarkMLl
Ok, I've overlooked this. But this then basically is what the TIOBE index measures, and as already said, it is very flawed, because it can not distinquish between people searching for a language because they want to learn it, or if it is because they want to only know some superficial information about it. One reason why Basic and Pascal have such a high result there could be because their historical relevance. When you learn the history of programming languages, you will come into contact with them, the same way I've looked into Cobol and Fortran, even though I will never use these languages.
As already stated, the TIOBE index is inherently flawed and it's results can not be verified against any other metric of language popularity. It is simply not a useful measure for this
At this time, I will not be able to recreate the iOS chain. Crawls out a lot of different problems and for different systems. At this time, I am aiming more at Android, as well as at replacing/avoiding external libraries or compiling them for Android64. I also intend to extend OpenGL to be fully usable. This does not mean that ZenGL will change. It's just that the ZenGL user will be able to fully use OpenGL up to 4.6, GLES up to version 3.2, without forcing the user to create the OpenGL window himself. ZenGL will do it for him.
I also try to document functions along the way, so that it is more convenient to use them and more understandable to use.
Only when I'm done with all the little things that creep out, I can look towards iOS. And I'll see what I can do in this direction.
Pas2JS is it's own solution and not realy a part of the fpc-lazarus ecosystem. What I am talking about is a fpc-lazarus solution that uses the webbrowser simply as rendering engine.
By all metrics that I have ever seen, Pascal/Object Pascal was a top 10 programming language from the late 1970s to the early 2000s. That Pascal/Object Pascal would presently be in the 15th to 20th range among programming language is logically consistent with its past. Contrary to the opposing view, Pascal/Object Pascal is not going to all of the sudden disappear. There is still a ton of code, websites, books, teaching materials, it being used in the schools of numerous countries throughout the world, and Delphi is still in existence and viable.I don't think pascal will disappear at all, if cobol has proven anything than that technologies never die. The question is what happens with a language that once was very popular, and is this what we want from pascal.