I am a big fan of the new framework. Not a fan of straddling two horses.
The problem IMO with the new framework is that it is too picky and more "computer sciencey" making it less approachable and less RAD than the old.
I think that putting more lipstick on a pig to cover the warts ultimately makes things more confusing. [quote]“Computer Sciencey”[/quote] is OK when its purposes is to deal with edge cases that actually arise.
4D, another language I use, has basically put the String/Text issues to rest. It has completed the migration, as it were. Life is better.
I spoke about that years ago…but if they did it, it would be a pro only feature as console is not included in desktop anymore (and IMO It should be as it used to have complete desktop functionality).
My console license expires next month (it came from the old licensing system that I renewed for many years) and I can’t justify the cost of Pro (or a separate console license) so these days IDE support for console apps makes little difference for me. (my desktop license expires in 2020)
Much of the new stuff over the last several years has not excited me and some has disappointed.
That said, I still use Xojo and am in the middle of using it for a major project right now.
[quote=370545:@Karen Atkocius]Much of the new stuff over the last several years has not excited me and some has disappointed.
That said, I still use Xojo and am in the middle of using it for a major project right now.[/quote]
I did the same thing… and for now cannot justify $300 (6x what I was paying), especially since now I am on a fixed income
Perhaps I will try to hit Xojo2019 next year…
[quote=370472:@Beatrix Willius]Interops might be interesting. But I’d rather have Christian figure out this stuff.
[/quote]
I am not sure what the future of the plugin SDK is. They have talked about allowing us to create plugins in Xojo itself and pre-compiled via LLVM. A major step up from what currently exists via encrypted classes. Combined with the new Interops feature and you should be able to access most OS level capabilities.
I do not believe they will provide a mobile plugin SDK ever which is disappointing. There is a lot of great Swift/Objective-C/Java code that could be used in our projects should an SDK exist.
Exactly. We are on the same page here. It could be a lot like XojoScript with limitations to the types you can pass (because behind the scenes it uses command line arguments and can only return output from the console app). I should be able to in 30 seconds create a method that will run on an external core via command line app and the IDE abstracts away all the details.
Except in 3+ years they have only released marginal table improvements to iOS. Sure there were some bug fixes, 64-bit support, iOS SDK backend changes, etc. (i.e. keeping the product functional) but for the most part it is challenging to produce anything like what is possible in the native environments. This is made worse that by your logic of 12+ releases since launch it has been crickets.
No need to get upset. What about “MobileTextField” and “WebTextField” that is cool. However, I actually have no problem with user interface controls being unique per target.
What hampers my productivity is all the senseless caveats of using the new framework and sharing code with iOS. The Desktop/Web/Console frameworks should have had new controls with Text equivalents within 12 months of iOS release.
As it stands I had to write the “GlueKit” package to bridge the gap which should have been provided or resolved in 12 months. Classes exist here but not there, data types used here but not there. We have hashed this discussion out several times and there is a general consensus…
[quote=370538:@Robert Livingston]I am a big fan of the new framework. Not a fan of straddling two horses.
[/quote]
Funny thing is I went all-in on new framework when I wrote GlueKit (https://www.github.com/1701software/GlueKit). I actually do not mind it either because I am computer science-y as Karen puts it.
The problem is under and poorly implemented across all targets making it mostly a pain to use.
My wish list at the moment includes just one thing: fix the 64-bit currency issue. We can’t move our server app to 64-bit until this happens, and we really, really want to do that.
(In 64-bit, 1.02 = 1.99 when both are defined as currency. You can see the problem in the XojoUnit project as it is now included as a test.)
[quote=370562:@Kem Tekinay]My wish list at the moment includes just one thing: fix the 64-bit currency issue. We can’t move our server app to 64-bit until this happens, and we really, really want to do that.
(In 64-bit, 1.02 = 1.99 when both are defined as currency. You can see the problem in the XojoUnit project as it is now included as a test.)[/quote]
Basic datatypes need to be rock solid.
If they arent then they are unusable. There are no two ways about it.
For 64 bit applications this is already supported today. We have no plans to provide 32 bit optimizations except for ARM which we support through LLVM.
Full PDF support. Generate, analyse, convert to png / html, get text …
HTMLviewer that’s worth this name with basic commands like selectall and copy and advanced commands to get source code and so on.
Canvas that refreshes as required on every platform
Respecting paying customers by changing the update system. Someone who pays for build 2017R3 should get updates even after the license is expired, but only fixes. So in paralell to 2017R4 thers should be something like 2017R3.rev2 containing all fixes but not the new features.
I’ve been trying to ship MacOS 64bit for over a year.
It keeps biting me with graphics bugs and random crashes, so I keep having to ship a ‘fix’ which is just a 32bit build.
What I want next is a Windows build I am not scared to upgrade to, where people start saying ‘wow - this Direct2D thing is a massive improvement, not yet another source of bugs’
