Omnis Studio V8 niggles, and some general complaints

Sun Aug 18 16:56:58 EDT 2019

Hi Bryan:

> 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.

We are on that other side of things.   We barely made it through a studio 8.1.6 deployment just before Studip 10 was made available. 

Studio 8 had enough  broken things for us (compared to studio 5 where we came from) that got fixed in studio 10 — that we quickly abandoned studio 8.1.6 (or 8.1.7) as a platform that we wanted to support.

What has rock solid stable in studio 5 now seems to be there in studio 10 and I can’t wait for 10.0.1 as I know there are even more compatibility things addressed based on the bug list.  
 For us the key things that Studio 10 has;

- serial ports for max are back
- multiple page report printing now paginates properly (there were a few issues in the report tool in 8.1.6)
- I’m not losing objects in runtime. More anywhere near as often.   We have been hitting random issues finding data our of Postgres that we think are from omnis garbage collector cleaning up objects and object references before their time —  those issues are gone in studio 10.0.0.3/10.0.0.4

IN almost all cases where one of our customers has an issue with our 8.1.6 version, updating to Studio 10 makes the problems go away.   (In almost all cases)

And we can now deploy servers in linux.

So, my personal experience is that.  Studio 5.2.3.x for us was rock solid for 10+ years.     Studio 10.0.x is very close to similar reliability with the additional features of:

- git for a repository
- run time is faster
- 64 bit all round (Which is going to mean something next year on OSX)
- obrowser component 
- and I like the editor (the key new thing on Studio 10).
+++ it is more stable

Ad for your futures —  totally 100% agree that native on android and iOS platforms is a big thin I’m looking forward to.   I hope that is on the drawing board.        It is almost a must-do thing as I think Apple will start coming out with ARM laptops in the not to distant future.

Doug Easterbrook
Arts Management Systems Ltd.
mailto:doug at artsman.com
http://www.artsman.com
Phone (403) 650-1978

> On August 18, 2019, at 11:11 AM, Bryan Brodie <brb at appimatic.com> wrote:
> 
> 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 