“Easier to get out of Omnis” (Formerly Studio – Github)

Andrew, we wrote our own HTML code generator to inspect the window classes
in our Studio 4x library to give us a starting point in our migration to
AngularJS. At the time, there was no JSON export option. If we had it
available, we may have used it.

David, your comments about tools making it easy for developers to get in or
out are right on. As for your comments about not being sold entirely on the
idea of web apps running on the desktop and citing Slack as one of the
examples of native applications you like, Slack is not a native
application. It’s a web application that is packaged and distributed using
Electron <electron.atom.io/>. You also mention Spotify. That is
also not a native application. See < www.quora.com/What-is-the-technology-stack-behind-the-Spotify-web-client>.
That’s how good web applications are these days that even someone as
knowledgeable as you would think that you’re running a native application.
How cool is that?

Regards,

Clifford Ilkay

+ 1 647-778-8696

On Fri, Oct 6, 2017 at 1:07 PM, Alex Clay <aclay@mac.com> wrote:

> Hi David,
>
> +1 up-vote for everything you said.
>
> Alex
>
> > On Oct 6, 2017, at 12:51, David McKeone <david@artsman.com> wrote:
> >
> > Hi All,
> >
> > I’ve been heads down on things for a quite a bit, but I just wanted to
> chime in this to say that the JSON library export is a great feature and it
> means that will all soon be able to share with each other much more easily.
> >
> > On Clifford’s comment that we could “generate Omnis libraries without
> the use of the Omnis IDE”
> >
> > So ya, you can generate Omnis code without the use of the Omnis IDE, but
> you could always do that before and then just use a little Omnis code to
> inject that plain text into a real library if you wanted to get clever. It
> certainly gives us a different avenue to generate code outside of Omnis,
> but I don’t feel that it gives us anything we didn’t already have through
> other means.
> >
> >
> > On Andrew’s interpretation of “it could make it easier to get out of
> Omnis”:
> >
> > (I’m potentially reading into this, but i’m gonna hop on the soap box
> anyway)
> >
> > Yes, it does, and that’s the point. Being easy to leave should be a
> goal for Omnis, because being easy should be a goal for Omnis. What makes
> me program in Javascript or Python or C++ should not be because I am locked
> in. Useful tools allow you to leave just as easily as they allow you to
> come back in to the fold — they’re easy, by definition, so all things
> become easier. The paradox is that the harder it is to leave Omnis, the
> more likely I would be to actually leave. The thing is that I don’t want
> to leave now. All the features they’ve put in Studio 8.1+ (OW3 C++
> TCP/HTTP/FTP workers, JSON, oBrowser, JSON library export) make Omnis a
> really useful RAD tool for the modern web-based desktop app.
> >
> > We can now share code more easily on common tools, we can talk to the
> plethora of REST APIs with threaded background workers, with Alex Clay’s
> contributions we can do automated testing, and we don’t have to be
> Javascript/HTML/CSS or C++ experts to do it. Omnis has always let
> non-professional programmers write useful apps for their business niches,
> and now they can do it in the modern software world.
> >
> > There are so many REST/HTTP APIs out there now and Omnis is, I think,
> pretty uniquely positioned to take advantage of them by offering an
> approachable native desktop app feel combined with oBrowser HTML/CSS/JS
> flashiness where needed. Web apps (which I’m guessing are the proposed
> Omnis alternative) are certainly encroaching on the business space, but I’m
> not entirely convinced they’re going to win. Responsive/Progressive web is
> *hard* and while it may be one size fits all for the devices out there, not
> a lot of companies can put in that kind of time and resource commitment.
> Even without that, native apps on phones seem to be doing pretty well, and
> while businesses are still moving to a lot SaSS solutions, the browser, by
> itself, does not need to be a foregone conclusion as an application
> delivery mechanism on the desktop. I know I certainly appreciate my
> Spotify native app, my PgAdmin native app, my Slack native app, my Mail
> native app, etc, etc… Many of those apps still use HTML/CSS/JS content as
> _part_ of the app, but it’s not always, and doesn’t have to be, the whole
> thing.
> >
> > Omnis is in a great position to integrate with other languages and other
> tools now, so I look forward to the future where we all start to do that.
> Open the window and let the air in, but I don’t think there is a need to
> walk out the door.
> >
> > Anyway, off the soap box.
> >
> > These conversations are great to have over drinks and food at EurOmnis.
> See you soon 😉
> >
> > __________________________________
> > David McKeone
> > Arts Management Systems Ltd.
> > mailto:david@artsman.com <mailto:support@artsman.com>
> > www.artsman.com <www.artsman.com/>
> >
> >> On Oct 6, 2017, at 9:18 AM, Andrew Stolarz <stolarz@gmail.com> wrote:
> >>
> >> Alex and Doug, thats for the detailed examples. I will have to take a
> dive
> >> and see it in action to get a better understanding.
> >>
> >> In case anyone else is interested, I noticed Studio posted a small post
> on
> >> this topic few days ago too.
> >>
> >> developer.omnis.net/blog/json-components-and-omnis-on-github
> >>
> >>
> >>
> >>
> >> Clifford,
> >>
> >> your comment “It could also make it easier to get out of Omnis”….
> please
> >> elaborate!
> >>
> >>
> >>
> >>
> >> Andrew
> >>
> >>
> >>
> >> On Thu, Oct 5, 2017 at 1:56 PM, Alex Clay <aclay@mac.com> wrote:
> >>
> >>> Hi Clifford,
> >>>
> >>> No, it’s not specific to git. The key is that the source is exposed as
> >>> plain text which git, mercurial, subversion, perforce, or even CVS can
> >>> handle much better than a binary lbs file.
> >>>
> >>> Alex
> >>>
> >>>> On Oct 5, 2017, at 13:22, Clifford Ilkay <cilkay@gmail.com> wrote:
> >>>>
> >>>> Is it really “git export” or just JSON export? I didn’t see anything
> in
> >>> the
> >>>> source code of the OmnisTAP repo that Alex shared that would make it
> >>>> git-specific. I could store that source code in any revision control
> >>>> system, e.g. Mercurial.
> >>>>
> >>>> Regards,
> >>>>
> >>>> Clifford Ilkay
> >>>>
> >>>> + 1 647-778-8696
> >>>>
> >>>> On Thu, Oct 5, 2017 at 10:50 AM, Doug Easterbrook <doug@artsman.com>
> >>> wrote:
> >>>>
> >>>>> by the way of history on git export — it was a topic of conversation
> at
> >>>>> the last Euromnis.
> >>>>>
> >>>>>
> >>>>> a case was made for the need to work in distributed teams and how git
> >>>>> would support that very effectively (or any external version control
> of
> >>>>> preference, is you are subversion fan).
> >>>>>
> >>>>> plus the need for automatic builds and testing using the likes of
> >>> jenkins,
> >>>>> etc.
> >>>>>
> >>>>>
> >>>>> Bob & Bob listened .. as did the new owners, and to their vast
> credit,
> >>>>> they understood why this was needed and how it could help Studio
> within
> >>> the
> >>>>> enterprise.
> >>>>>
> >>>>> It positions Studio to play even better in the enterprise space where
> >>>>> there are lots of ancillary tools that are free/ope nsource that are
> in
> >>>>> widespread use.
> >>>>>
> >>>>> plus .. an open repository tool like git will help the studio
> community
> >>>>> share minor libraries if they wish. eg, we have a built a
> >>> performance
> >>>>> analyzer that we know some people use. its a separate library, self
> >>>>> enclosed. now we can put it into git and others can get it, and/or
> >>>>> submit enhancements.
> >>>>>
> >>>>>
> >>>>> it is an excellent example of how the core studio development are
> able
> >>> to
> >>>>> respond to the changing need of the developer community
> >>>>>
> >>>>>
> >>>>> great Kudo’s to Omnis for implanting git export. it truly opens a
> lot
> >>>>> of doors to a lot of supporting toolsets to automate parts of
> >>> application
> >>>>> development process
> >>>>>
> >>>>>
> >>>>>
> >>>>> Doug Easterbrook
> >>>>> Arts Management Systems Ltd.
> >>>>> mailto:doug@artsman.com
> >>>>> www.artsman.com
> >>>>> Phone (403) 650-1978
> >>>>>
> >>>>>> On Oct 5, 2017, at 8:37 AM, Doug Easterbrook <doug@artsman.com>
> wrote:
> >>>>>>
> >>>>>> as alex says… the files are spread out.
> >>>>>>
> >>>>>>
> >>>>>> essentially there is a folder for each object (a window, or object,
> or
> >>>>> file, or table class)
> >>>>>>
> >>>>>> in that folder, there is a file for the variables and one file for
> each
> >>>>> method.
> >>>>>>
> >>>>>> they are all pretty-printed for proper indentation, etc .. which is
> >>>>> exactly the way git likes it.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Doug Easterbrook
> >>>>>> Arts Management Systems Ltd.
> >>>>>> mailto:doug@artsman.com
> >>>>>> www.artsman.com
> >>>>>> Phone (403) 650-1978
> >>>>>>
> >>>>>>> On Oct 5, 2017, at 8:21 AM, Clifford Ilkay <cilkay@gmail.com>
> wrote:
> >>>>>>>
> >>>>>>> Hi Alex,
> >>>>>>>
> >>>>>>> That should make it feasible to generate Omnis libraries without
> the
> >>>>> use of
> >>>>>>> the Omnis IDE. (It could also make it easier to get out of Omnis.)
> >>>>>>>
> >>>>>>> Is the export one big JSON file, one JSON file per class, or
> something
> >>>>> else?
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>>
> >>>>>>> Clifford Ilkay
> >>>>>>>
> >>>>>>> + 1 647-778-8696
> >>>>>>>
> >>>>>>> On Thu, Oct 5, 2017 at 10:00 AM, Alex Clay <aclay@mac.com> wrote:
> >>>>>>>
> >>>>>>>> Hi Clifford,
> >>>>>>>>
> >>>>>>>> Absolutely yes. The only tricky part is managing multiple
> libraries
> >>>>> that
> >>>>>>>> share superclasses, design tasks, or external file classes. In
> those
> >>>>>>>> instances, you need a copy of the remote library open for the
> import
> >>> to
> >>>>>>>> successfully build a .lbs from the JSON export.
> >>>>>>>>
> >>>>>>>> Alex
> >>>>>>>>
> >>>>>>>>> On Oct 5, 2017, at 09:57, Clifford Ilkay <cilkay@gmail.com>
> wrote:
> >>>>>>>>>
> >>>>>>>>> The JSON that is exported from a library, is it a complete
> >>>>> representation
> >>>>>>>>> of the library with all classes, methods, and attributes of those
> >>>>>>>> classes?
> >>>>>>>>> In other words, can I take a fresh library, import that JSON, and
> >>>>> have a
> >>>>>>>>> fully-functioning library that works exactly the same as the
> >>> original
> >>>>>>>>> library from which the export was done?
> >>>>>>>>>
> >>>>>>>>> Regards,
> >>>>>>>>>
> >>>>>>>>> Clifford Ilkay
> >>>>>>>>>
> >>>>>>>>> +1 647-778-8696
> >>>>>>>>>
> >>>>>>>>> On Thu, Oct 5, 2017 at 9:22 AM, Doug Easterbrook < > doug@artsman.com>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> hi Andrea:
> >>>>>>>>>>
> >>>>>>>>>> Alex is right — two people can be working on the same class and
> its
> >>>>> not
> >>>>>>>> a
> >>>>>>>>>> problem.
> >>>>>>>>>>
> >>>>>>>>>> you have to look at the mindset of traditional version control
> >>>>> systems
> >>>>>>>>>> (the Omnis VCS is modelled after them). You are familiar with
> it
> >>> ..
> >>>>>>>>>> — they are in a central repository
> >>>>>>>>>> — you take the classes you want
> >>>>>>>>>> — you prevent others from change them
> >>>>>>>>>> — you fix
> >>>>>>>>>> — you put them back
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> often you take mote classes than you need, in case you have to
> fix
> >>>>>>>>>> something up the inheritance tree.and then you have to figure
> out
> >>>>> what
> >>>>>>>> has
> >>>>>>>>>> changed before you put it back.
> >>>>>>>>>>
> >>>>>>>>>> and the reason you do that is that the problem/solution is never
> >>>>> where
> >>>>>>>> you
> >>>>>>>>>> think it is going to be. What that does is lock others in a
> >>> team
> >>>>>>>> out of
> >>>>>>>>>> changing something in the same class.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> with git, the mindset is a free-for-all.. Everybody changes
> what
> >>>>> they
> >>>>>>>>>> need, when they need.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> While it may seem like anarchy, it is really isn’t. there is a
> >>> day
> >>>>> of
> >>>>>>>>>> reckoning AT TIME OF CHECKIN as follows:
> >>>>>>>>>>
> >>>>>>>>>> I change class A, you change class B. we can both push up the
> >>>>> changes
> >>>>>>>> and
> >>>>>>>>>> there is no conflict. git likes that. not much different
> than
> >>>>> using
> >>>>>>>> a
> >>>>>>>>>> traditional VCS, except you didn’t check out.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> we both change Class A, I change method 1 (eg build a list)
> and
> >>>>> you
> >>>>>>>>>> change method 2 (sort a list). There is still no conflict,
> git
> >>>>> likes
> >>>>>>>>>> it. both of us can check in. VCS would not like it.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> we both change class A and we both change the same method.
> Git
> >>>>> says
> >>>>>>>> ..
> >>>>>>>>>> first check in wins and the second person to check in is faces
> with
> >>>>>>>>>> comparing the difference in that one method .. to decide how to
> >>>>> merge in
> >>>>>>>>>> their changes.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> We’ve used git ofr other projects for a number of years — (to
> >>> manage
> >>>>> C
> >>>>>>>>>> code, html pages, python, config files for setup of our
> >>> application —
> >>>>>>>> lots
> >>>>>>>>>> of things), and I’d far rather use it that a centralized VCS.
> >>>>>>>>>>
> >>>>>>>>>> developers are far more productive — they see a problem and fix
> it.
> >>>>>>>>>> and the funny part, is that there is rarely a conflict.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> as soon as we can get everything to studio 8, we are gonig to
> use
> >>>>> git..
> >>>>>>>>>> it has realy great
> >>>>>>>>>> — diff features (comparing the changes)
> >>>>>>>>>> — blame features (who exactly is responsible for each line of
> code
> >>> in
> >>>>>>>> each
> >>>>>>>>>> method – eg I did line 1, you did lines 3 to 5, I did line 6)
> >>>>>>>>>> — versioning features (so you can be working on many different
> >>> things
> >>>>>>>> and
> >>>>>>>>>> then build a release that is only of finished stuff)
> >>>>>>>>>> — and you can automate it with code building and testing tools.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I really can’t wait.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> On Oct 5, 2017, at 1:34 AM, Andrea Zen <a.zen@athesiavr.it>
> >>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> How is simultaneous development managed? I mean what now is the
> >>>>> locking
> >>>>>>>>>> of classes in the VCS, when you “check out to modify”, that
> >>> prevents
> >>>>>>>>>> developers to work both on the same class.
> >>>>>>>>>>>
> >>>>>>>>>>> Andrea Zen
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> —–Original Message—–
> >>>>>>>>>>>> From: omnisdev-en [mailto:omnisdev-en-bounces@
> >>> lists.omnis-dev.com]
> >>>>> On
> >>>>>>>>>>>> Behalf Of Alex Clay
> >>>>>>>>>>>> Sent: Wednesday, October 4, 2017 8:40 PM
> >>>>>>>>>>>> To: OmnisDev List – English <omnisdev-en@lists.omnis-dev.com>
> >>>>>>>>>>>> Subject: Re: Studio – Github
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi Andrew,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Instead of checking out classes, you simply make the changes
> you
> >>>>> need.
> >>>>>>>>>>>> When ready, export the library to JSON. You then commit it
> like
> >>> any
> >>>>>>>>>> other
> >>>>>>>>>>>> code – add new files, remove deleted ones, and commit and push
> >>> when
> >>>>>>>>>>>> ready. When you need to integrate with another developer’s
> work,
> >>>>> pull
> >>>>>>>>>> the
> >>>>>>>>>>>> remote repository into your local copy. In Studio, import the
> >>> JSON
> >>>>>>>> code
> >>>>>>>>>> into a
> >>>>>>>>>>>> new library and voila, you have the latest copy!
> >>>>>>>>>>>>
> >>>>>>>>>>>> Mix this with feature branching and you have a slick setup for
> >>>>>>>> multiple
> >>>>>>>>>>>> developers…and it’s handy for single devs, too.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I’m covering how to do this at EurOmnis in 10 days or so in
> case
> >>>>>>>> you’ll
> >>>>>>>>>> be
> >>>>>>>>>>>> there. 🙂
> >>>>>>>>>>>>
> >>>>>>>>>>>> Alex
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Oct 4, 2017, at 14:35, Andrew Stolarz <stolarz@gmail.com>
> >>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Hi Alex,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks I will look into it.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Im used to the old school omnis VCS process, check in – check
> >>> out
> >>>>>>>>>>>>> within Omnis.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> How does this work for you using GitHub and JSON exports? ie.
> >>>>> what is
> >>>>>>>>>>>>> the process like to “check in / check out” components?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Andrew
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Wed, Oct 4, 2017 at 2:26 PM, Alex Clay <aclay@mac.com>
> >>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi Andrew,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Your best bet is to jump to Studio 8.1 so you can export
> your
> >>>>>>>>>>>>>> libraries as JSON. We have a couple projects on GitHub that
> >>> host
> >>>>>>>> both
> >>>>>>>>>>>>>> this JSON source and then compiled .lbs files:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> github.com/suransys/omnistap
> >>>>>>>>>>>>>> <github.com/suransys/omnistap
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> github.com/suransys/omniscli
> >>>>>>>>>>>>>> <github.com/suransys/omniscli
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Alex
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Oct 4, 2017, at 14:21, Andrew Stolarz < > stolarz@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Just curious if anyone is using Omnis libraries with
> Github?
> >>> if
> >>>>> so,
> >>>>>>>>>> how?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> or we locked into using the Omnis VCS?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Andrew
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>> __________________________________________________________
> >>>>>>>>>>>> ___
> >>>>>>>>>>>>>>> Manage your list subscriptions at
> lists.omnis-dev.com
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>> __________________________________________________________
> >>>>>>>>>>>> ___
> >>>>>>>>>>>>>> Manage your list subscriptions at
> lists.omnis-dev.com
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>> __________________________________________________________
> >>>>>>>>>>>> ___
> >>>>>>>>>>>>> Manage your list subscriptions at lists.omnis-dev.com
> >>>>>>>>>>>>
> >>>>>>>>>>>> __________________________________________________________
> >>>>>>>>>>>> ___
> >>>>>>>>>>>> Manage your list subscriptions at lists.omnis-dev.com
> >>>>>>>>>>> _____________________________________________________________
> >>>>>>>>>>> Manage your list subscriptions at lists.omnis-dev.com
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Doug Easterbrook
> >>>>>>>>>> Arts Management Systems Ltd.
> >>>>>>>>>> mailto:doug@artsman.com
> >>>>>>>>>> www.artsman.com
> >>>>>>>>>> Phone (403) 650-1978
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> _____________________________________________________________
> >>>>>>>>>> Manage your list subscriptions at lists.omnis-dev.com
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>> _____________________________________________________________
> >>>>>>>>> Manage your list subscriptions at lists.omnis-dev.com
> >>>>>>>>
> >>>>>>>> _____________________________________________________________
> >>>>>>>> Manage your list subscriptions at lists.omnis-dev.com
> >>>>>>>>
> >>>>>>> _____________________________________________________________
> >>>>>>> Manage your list subscriptions at lists.omnis-dev.com
> >>>>>>
> >>>>>> _____________________________________________________________
> >>>>>> Manage your list subscriptions at lists.omnis-dev.com
> >>>>>
> >>>>>
> >>>>> _____________________________________________________________
> >>>>> Manage your list subscriptions at lists.omnis-dev.com
> >>>>>
> >>>>>
> >>>> _____________________________________________________________
> >>>> Manage your list subscriptions at lists.omnis-dev.com
> >>>
> >>> _____________________________________________________________
> >>> Manage your list subscriptions at lists.omnis-dev.com
> >>>
> >> _____________________________________________________________
> >> Manage your list subscriptions at lists.omnis-dev.com
> >
> > _____________________________________________________________
> > Manage your list subscriptions at lists.omnis-dev.com
>
> _____________________________________________________________
> Manage your list subscriptions at lists.omnis-dev.com
>
_____________________________________________________________
Manage your list subscriptions at lists.omnis-dev.com