Omnis Studio V8 niggles, and some general complaints

[Bastiaan Olij]

Hi Brian,


Definitely an interesting read. 


As someone who's moved to Studio 10 it's been a bumpy ride so far. A big part of this is the slow adoption of the product, it means we're on the bleeding edge and are often the first to find really gnarly problems. Omnis then has a tough time finding a solution, if more people ran into it, they have more to go on, things would get fixed sooner. That said, one of the absolute biggest positives that I can't be more happy about is the change you can see dealing with Omnis and tech support. In the past when we had problems like these it was like shooting them into a black hole.
Now they are on top of things, we get good feedback from the team, they get us involved, it is a major improvement. Yes we have issues that are proving difficult to fix and are causing us grief and frustration but it's not for lack of trying on their part, they are just hard to reproduce issues and as developers we know how difficult those are too fix. 


I've gotten used to the code editor, there are parts of it that I absolutely love, there are parts of it that annoy me, but seeing its new I have faith Omnis will improve it over time. TBH the advise here I have to everyone is to just swallow your pride and get on with the job. The more people adopt it, the more people that can give real feedback after they have gotten used to the interface and over the initial hurdles, the sooner Omnis can make the real improvements needed to make the new IDE work for everyone.  


The DF1 discussions doesn't interest me, I was lucky to be introduced to Omnis in the late 90ies at an employer that had already moved to Sybase (we had an older DF1 product but it was being phased out). When I joined Instinct Systems my SQL skills were a big part of that seeing they were moving from DF1 to SQL. A lengthy process that in the first pass made the application run badly because we were converting DF1 code straight up to SQL, but once we started rewriting parts to use SQL properly, wow, JobBag is now miles ahead of how far we could have taken it if we stuck with DF1. Seeing how much benefit we got through the move, yes after a lot of pain and suffering, it has been so worth it in the long run. Game changing I would even say, our product would no longer exist if it was still rocking the datafile. 
Frankly, I tip my hat off to Omnis that they've managed to keep such an old outdated technology running for as long as it has. The writing has been on the wall for wall over a decade maybe two and they are still keeping it going. But I can't blame them for trying to improve an exit path because there will come a time where the cost of maintaining the code base will far outweigh the benefit.


On the other parts, there is a lot you're saying that rhymes, some is indeed ranting, just kicking the tires so to speak, but there is also a lot I agree with. 


For me my biggest gripe is how outdated the GUI is and how much that has hurt us. Yes I would love a runtime for iOS but it has to be married up with the ability to create a GUI that looks the part. We've bend over backwards the last few years to make JobBag look modern and a lot of the gnarly issues I mentioned before stem from us doing things to get the GUI look somewhat more modern that are not working well with the Cocoa rewrite. We've really overstepped Omnis' boundaries in a few places.
oBrowser has been a blessing as it has started to allow us to create the more modern looking UIs we want but at the same time its slowly turning Omnis into a glorified browser.


It is here were things get very confusing for me. 


For our mobile/web development we've not gone down the Javascript client path, the model just doesn't work for us. Instead we're going down a more standard HTML5 road with the small twist that we use Rust to build our middleware in (and for those who are curious, Bootstrap.js for the front end framework, Rocket.rs for the middleware). 
Rust is a bit of a new player and an odd choice because the frameworks aren't as grown up as the ones available for Python but its consistently beating all the established players in benchmarks and the ability to compile and the deployment model that comes with it won us over and we'll grow along with the frameworks. 


At this time it is still all very anecdotal because it's an experienced Omnis team learning a new toolset so we're much much slower getting things done, but I would definitely say the old rule still applies, with Omnis I can develop an application in half the time it takes me developing the same functionality in this toolset (right now I'm at 3 - 4 times as much time due to lack of experience).


So for the foreseeable future our desktop development will remain in Omnis and as a developer I don't want to move away from it because I love it. But I can't escape the fact that the HTML5/Rust combination allows me to create interfaces that are currently impossible to recreate in Omnis, and often create those with very little effort.
 
If Omnis continues to grow and starts modernising its GUI I see no reason to ever move away from it. If it solves the mobile deployment issue it will capture back ground its lost. But if not, I don't know how big a role it will have. 


I know from talking to Doug that years ago they were faced with the same decision and eventually found out that using Omnis were it shines, and using HTML/Python (I believe) where that shines, has provided a worth while synergy. We may very well settle there as well as we're definitely going down a similar road. 

Kindest Regards,


Bastiaan Olij
Head of development - Instinct Systems: The JobBag People
Ground Floor, 48 Chandos Street
St Leonards NSW 2065
Australia


Phone: +61 2 8115 8000
Direct: +61 2 8115 8003
Mobile: +61 4 321 44833
bastiaan.olij at instinctsystems.com.au
http://www.jobbag.com



 From:   Bryan Brodie <brb at appimatic.com> 
 To:   OmnisDev List - English <omnisdev-en at lists.omnis-dev.com> 
 Sent:   8/19/2019 4:11 AM 
 Subject:   Omnis Studio V8 niggles, and some general complaints 

hey list, 
 
 
Now that I have been really digging into Omnis Studio V8 development over 
the last five weeks on a daily basis for hours at a time, a few things have 
gotten under my skin, therefore I have decided to vent here on the list. 
 
 
This is mostly a rant, so you might just want to skip this post altogether. 
You've been advised. ;-) 
 
 
- For scroll bars on debugger-displayed very wide lists (right-click field 
name- VARIABLE, window with list contents opens - nice!) there is no way to 
move through horizontally one column at a time - you HAVE to drag the 
slider, which is very imprecise. 
 
- For the traditional Omnis .DF, 'Set Main File' is (apparently) not 
reversible anymore. (Begin Reversible Block) - anyway it's not working for 
me. 
 
Apparently, 'Find' in Reversible Block mode also causes issues, at least 
for me in 8.17, it is blanking the CRB. 
 
- The code / method editing windows are too cramped / too small at the 
bottom left of the window. The area where you select & edit the command 
comments is tiny, not resizable, and the bottom of the entry field has no 
margin between it and the bottom of the window. The scrollable list of 
Omnis commands is small and cut off at the bottom of the window. 
 
- Oh and if you have a method / code block with more than 9999 lines, the 
line numbers in the listing mash into the code. Yeah I am doing it wrong if 
I have 25,000 line code blocks. But - those lines of code are computer 
generated, and it's a hacky workaround for what I need to accomplish which 
is the beauty of Omnis. In v8, that code block executes in under a second 
which is pretty cool. 
 
 
Ok the rant starts here, so stop reading now. 
 
I guess I should not complain, after all I only paid $199 to upgrade from 
V6 to V8. That is actually a really good deal. I tried out V10 and no 
thanks - I won't be migrating and I know a more than a few longtime Omnis 
developers who agree with me. 
 
Plus, .DF / Omnis native data files are going "away"', as is RAD command 
selection (to be replaced by mega-text editing with pseudo-nifty 
autocomplete). 
 
In my humble opinion, killing DF and RAD Omnis command editing sucks. I get 
that Tiger Logic nearly destroyed Omnis with non-benign neglect, and I 
respect that the current management is doing its level best to right the 
ship. 
 
But this still leaves two of the biggest lost opportunities in the history 
of Omnis: no code forward-compatible runtime for mobile (iOS and Android) 
and Linux, and a lack of imagination regarding the DF file format. 
 
My Omnis applications, transportable to new operating environments with 
minimal (if any) code changes, are what made me tons of moolah as Windows 
transitioned from Windows 2000 to XP to Vista to 10. 
 
And as MacOS transitioned from MacOS 7 to OS X 10.1-10.6, and beyond. 
 
Open, convert, bill the client. Easy peasy. Of course I am being a little 
simplistic / sarcastic here, but the transition path from one version to 
another was navigable and clear. Consistency over thirty years meant legacy 
code could be leveraged again and again. 
 
If there had been a real runtime at any point in the last ten years that 
would open traditional Omnis applications in mobile operating systems with 
minimal code changes, we would all be rich and so would Omnis Software. 
 
The market is still looking for that magic bullet of one code base, many 
platforms, but the currently available solutions are all lacking. 
 
And, what exactly do I mean by lack of imagination regarding the DF file 
format? Well, imagine that the multiuser DF file format had been made to 
work on Dropbox, Google Drive, OneDrive? Could you have made money with a 
serverless model like that? I certainly could. 
 
 
Working on mobile? Wow - imagine the possibilities... 
 
Nonsense! you say, those vendor APIs are opaque or locked down. 
 
Well, once upon a time, when Omnis was the #1 platform for multiuser 
database applications on microcomputers(!), the Omnis engine developers 
enjoyed an excellent relationship with Apple and Microsoft, and this made 
the multiuser DF file format simple to code and easy to deploy. 
 
I get that technology moves on and we all have to get with the program (pun 
intended), but rearranging developer UI interfaces on the Titanic isn't 
going to keep the ship from sinking. 
 
Over the last seven years, I have built a really cool RAD system for web 
systems application development that utilizes Omnis at its core. It is a 
tool for my personal use that allows me to leverage software design 
patterns to rapidly create workgroup oriented web applications (LAMP) that 
operate in the mode I used to build in native Omnis. As in weeks, not 
months. 
 
I have an interest in Omnis remaining viable, but if worse came to worst, I 
could always run my custom development engine in a VM until an army of 
contract code-monkeys are hired to convert my Omnis application to a 
full-on web application. 
 
Finally, this year's EurOmnis conference was abruptly cancelled with nary a 
peep from anyone on this list. That is an Omni-nous portent for the future 
of this amazing and versatile platform. 
 
I last attended 20 years ago when Fred Brinkman was still running it. It 
was amazing and fun and exhilarating. How times have changed. 
 
Rant over, we now return you to your programming already in progress. 
 
 
Bryan 
_____________________________________________________________ 
Manage your list subscriptions at http://lists.omnis-dev.com 
Start a new message -> mailto:omnisdev-en at lists.omnis-dev.com