Omnis Studio V8 niggles, and some general complaints

[Bryan Brodie]

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