Table and Query Classes good or unnecessary?
I Like endings because it is more obvious where things belong to. And even with endings, code folding or vertical indentation lines this can still be the hardest part of readability (structuring your code differently helps best when possible). The most common style used for lisp I find hard to read as well:
(if (= x 10)
I structure it differently:
(if (= x 10)
I really noticed I make fewer errors this way. I can see instantly where blocks of code belong to without having to put my cursor on the parentheses to see. Things become really unreadable when nesting, pretty quickly. So for me, some part of it is just getting used to, some part is not. I just find it nicer if I can see immediately where the block of code ends and that I don’t need to follow the flow of the code to find it.
> Which is why I used PyQt. That more closely approximates native widgets, certainly more accurately
> than Omnis. Omnis never looks quite native either and it’s understandable given that it paints its own
> widgets on a canvas.
You might be able to build software for windows with this, which feels like any other application, but does it have good RAD tools? How fast is it to build your screens? I bet it takes a lot more time than building (and changing) it with Omnis. And by no means am I calling Omnis a good native ui tool. The problem with Omnis is that it hasn’t progressed enough. Omnis never was _the_ tool to build great looking interfaces. It always has been a tool to build decent, not to complex, user interfaces, but build them really quickly. Same goes for Omnis, the language: This has always been the least feature complete language I know (no constants in 2018?!), and always has been strange, has quite a few strange edge cases, etc. But, because of its simplicity, you are forced to write more simple code, which is therefor easier to maintain. It is not suitable to build your complex hashing algorithm, but for business logic and basic platform structure it is very capable and _very fast to develop in
_. I can’t stress that enough. Being able to use other tools as well is not in question. But how fast can you build stuff with it. When comparing to Omnis, that is the most important question.
> Why bother with two completely different languages and two completely different codebases to target
> iOS and Android? Isn’t Xamarin good enough to target both? React Native and Flutter are two other
> frameworks that do a great job building native iOS and Android apps.
I am in a luxury position: We only use the software ourselves and we have standardized on iOS. So I can build the mobile client in Xamarin or Swift, it doesn’t matter, as long as it runs on iOS. I won’t be also creating an android one. And Flutter, really? I would not dare to build anything with it, which I intend to keep developing for a long time. It is still beta, and it is built by Google. How often do they really put their weight and vision behind a new thing? It might as well be abandoned in a few years for the next great thing. And even they (the web company) now envision building client UI not with the web tools, but with a tool specifically designed for building mobile apps instead of being designed in a ‘design by committee’ way as it is with the browser eco system (where it is really hard to make foundation changes, so many things are just added on top, like typescript). If the web-stack is so great for cross platform development, why have they created Flutter (what an awf
ul name b.t.w.)? I think the web tools will remain useful and used, but I don’t see it as _the_ future for building UI.
> As for transpilation being a bad idea, the facts don’t bear out that opinion. We transpile TypeScript to
> ES 5 so that it can run in a browser.
> By the way, we have received nothing but great reviews from our customers who are using the
> formerly Omnis fat-client window that we deliver as web forms via the Chromium Embedded
> Framework XCOMP that we’ve built. They actually prefer it to the legacy Omnis fat-client
> windows that the web forms are replacing. One of our design goals was to minimize the changes to
> the user interface while still freshening it up. The UI of the legacy fat-client application was hideous
> not just because Omnis widgets have a sort of Windows 95 look about them, at least in Studio 4.3,
> but because there were some strange design choices that were made at the time that the application
> was built, like pale green backgrounds on all dropdown lists.
> It doesn’t matter why that choice was made. That’s what the users are now used to. We faithfully
> reproduced those warts in the web application not because we’re not capable of changing but
> because we don’t want any user complaints about “Hey! You’ve changed everything!” We will evolve
> this application over time so that it looks better. It already looks much better by virtue of Bootstrap 3
> styling and Font Awesome icons. We took care to use iconography that is as close as possible to the
> Omnis icons except they don’t look like a SEGA game console graphics.
I sure hope they love it, otherwise it would be a waste of time:-). That omnis widget still look like windows 95 is because you are still using 4.3 If you don’t build a new iOS with the new toolset of Apple, your application still looks like iOS 5, with a iOS 5 keyboard for example. And SEGA game console graphics? Really? What icons are you using? Icons are just bitmaps. If you have ugly icons, it is your fault, not of omnis. Yes, you can build nicer user interfaces with web tools than current omnis (transparency, overlay, animation), but it takes a lot more effort.
An honest question: how long did it take your team to get where you are? (Building the middle tier in Python and building a web ui which can replace omnis?) How big was your Omnis application? (lines of code, how many windows, etc.)
I don’t have a team of developers. I build a complete ERP system, with cad integration, touch screen consoles in the factory, planning, crm, product configurator, document management, manufacturing chain integration, etc. All done by one developer. If it takes me double the amount of time to develop, it is not an option.
Also: I have never heard users complaining about changing a color. They only complain if they can’t find their stuff anymore or if you break their habits. You can only do that if it has great advantages for _them_. I can understand if you keep the new web-windows the same if your application still has some old Omnis screens, but I would probably (as I have never seen your application, I can’t really judge) change all main windows to all new designs, and just graphically update the remaining omnis windows to match the new design (colors, styling, etc.)
Four years back I did a big redesign of the application, which made the application look completely different (not like a normal windows 2000 application). With that I also completely changed how you find your stuff. This task is done a lot and became much easier and faster (interaction, not software). That single new feature prevented that users grumble. They only complained a little bit at some small, mostly fixable, interaction design bugs. They don’t mind changed colors. And they loved how much faster navigation was (and therefor accepted some of the small disadvantages).
Users only really complain if you didn’t do your job properly (can be interaction design, visual design, or communication). If you propose a downside (for example: needing to change your habits), you need a much bigger upside to compensate. As a developer it is easy to forget that, because by the time you have finished, you can’t see the downsides anymore.
>I think the resistance by developers to deploying their applications within a browser due to some
> imagined benefits of having a native look miss the mark if their customers want applications deployed
> within a browser. We fight our customers at our own peril. Whether there is actually any real benefit
> of running our application on an iPad or not, our customers were oohing and aahing over demos being
> done by our competitors who have web applications so if we don’t meet the expectations of our
> customers, our competitors will. I can see real benefits of running at least parts of our application on
> mobile devices. Initially, that will be via WebView and it will be like a web site running on a mobile
> device. We’ll eventually build native apps for iOS and Android. We’ve had that in mind from the outset
> which is why we implemented a REST API even though we control both the frontend and backend.
It actually surprises me that you don’t have a web based mobile client yet, if you have a functional web interface with a matching server.
How long ago was it that you heard customers requesting to run the application in a browser? The last time I heard anybody wanting a web interface is a long time ago. They want a mobile app now. Wanting it in a browser was only because of deployment (IT) or being able to just use a computer from somebody else to get to your stuff. But since everybody now has his own computer with them all the time they want to be able to access it there. Now, I just need a desktop interface and a mobile interface which should both work from anywhere. How it is built doesn’t matter as long as it works good. So I can choose how to make the best experience in the least amount of time, by picking the best tools, not just what is available for browser development.
I used to use a web mail client a lot in addition to outlook. But now it is just outlook and the mail app. I never touch a browser mail client anymore, because it is less convenient and doesn’t work as nice.
If web is the right tool for your job, good for you. But I know I cannot build the experience I need using those tools, with the resources I have. That is why I don’t look at the web-tools for any of my use cases. Because of the integrated experience of Omnis (instead of a big stack of separate tools) I was able to do a lot. Because Omnis wasn’t managed properly I am now hitting some limits I can’t have going into the future. They are really moving forward again, and I hope it is in the direction I need. If not I have to choose different tools for the long run, but my favourite future is with an enhanced Omnis.
Van: omnisdev-en [mailto:email@example.com] Namens Clifford Ilkay
Verzonden: zaterdag 17 maart 2018 0:23
Aan: OmnisDev List – English <firstname.lastname@example.org>
Onderwerp: Re: Table and Query Classes good or unnecessary?
On Fri, Mar 16, 2018 at 11:28 AM, Marten Verhoeven <email@example.com>
> Hi Clifford,
> The licensing can be a show-stopper, but doesn’t have to be. It
> depends on your application/business case. If you are building a
> (partially) free-to-use application (for example as an iOS app, which
> has a free version with in-app purchase to add functionality) it will
> probably a no-go with regards to licenses (you at least need to talk
> to Omnis about it). For us, we have a fixed amount of users. Adding a
> middle tier would require a bit more licenses, but not 2x. So the
> licensing cost is no issue at all for our situation.
> I agree with your first remark: single threaded is easier to develop
> for, and that is fine for Omnis in my opinion. I don’t need the
> multi-threading power of clojure for my business application. It is a
> no-go however to have to handle all client requests in a
> single-threaded environment. You have to be able to respond to
> separate request at the same time, otherwise you are lost even with 5
> users of your server. So in my opinion, multi-threading or multi
> process is required, even for small uses (and handling one request can be done in a single-threaded manor).
> And about python… Oh boy…:-)
> I am a novice, so I will probably be shot, but I will give it a try;-)
> I don’t like that the indentation is part of your application flow.
> You can get different flow of your code even if it looks visually the
> same (by mixing tabs and spaces in the wrong way). That however can be
> solved in practice by using the right tools,
“The right tools”… like any text editor or virtually any IDE. The amateur mistake of mixing tabs and spaces for indentation, you’ll only make once.
Once you’ve gotten over it, it’s really a no-brainer. If you were on my team, I’d even create a git hook, say “martenProofTheIndentation”, and let git handle any potential errors. 🙂
> and that is not why python currently is not my favourite language.
> Heck, I even really _love_ lisp and that notation is really awful. But
> somehow the dynamics and flexibility of that language make me love it.
> I have only used Python a little bit. And it _is_ on my list for a
> middle tier to investigate further. I don’t have the love for it,
> _yet_. For a small part this might be caused by not having a closing
> part of a code block (so no “end if” or something like that).
I love the indentation and the I love the removal of superfluous chatter, like “endif”. Every language has its peculiarities and once you’ve worked with it for a while, it just becomes second nature, like human languages.
(Who would ever spell the word “thought” the way it’s spelled if we were doing a “clean slate” design of English, for example?) Omnis has lots of these peculiarities. You’ve just become inured to them because you’re so used to. The $ signs all over the place – that’s ugly. The mish mash of procedural and object-oriented constructs in Omnis are weird to an outsider. It’s unnecessarily verbose. “Calculate foo as bar” How is that any more intuitive or expressive than “foo = bar”? You just get used to it and deal with it.
> But the biggest part, I think, was my inability to comprehend the
> standard modules. For example, I struggled a lot with calling command-line tools.
> Should I use os.spawnl, or os.popen, or one of the many other? I know
> I am a novice with python, but that made me search a lot and did not
> seem very nice. However, I believe a lot of the modules are cleaned up
> in Python 3, so it might be a lot different now. I just don’t know as
> I haven’t converted my (small) code-base.
There wasn’t a big problem with modules in Python 2x so I think this is just your inexperience with the language. The various ways of forking and interacting with the OS have to do with the fact that Python is portable across many operating systems. All that stuff is well-documented and it just takes a bit of patience and practice to sort it out.
> As for python to build UI: I know it is used on linux quite a lot, but
> on windows I have never seen anything based on it, and the only GTK
> applications I have seen on windows look just like linux applications
> on windows.
Which is why I used PyQt. That more closely approximates native widgets, certainly more accurately than Omnis. Omnis never looks quite native either and it’s understandable given that it paints its own widgets on a canvas.
> I will not be building a linux frontend anytime soon. The first new
> front-end will be mobile, and I can use c# and swift for that (and as
> far as I know I cannot use python for that).
Why bother with two completely different languages and two completely different codebases to target iOS and Android? Isn’t Xamarin good enough to target both? React Native and Flutter are two other frameworks that do a great job building native iOS and Android apps.
> I have no interest in making a web version of our application at all.
> That has been completely solved by ‘bringing your own device’.
> Installation and updating are not big issues anymore. I would prefer a
> cross-platform language and toolkit (like you can with c#) above a
> ‘webview in an app’ or ‘in a browser app’ anytime. So I definitely
> Clojure is not transpiled!
I didn’t say it was. I said that if you wanted to do client-side development with Clojure, Clojurescript could be an option. Transpilation is a problem that has been well sorted out. Source maps make it painless to debug your code in the original language, well, as painless as debugging anything can get.
> Clojure is compiled to run on the jave runtime. Clojurescript is
> something different. Heck, clojure is created for multi-threading, and
> clojurescript is intended to run on a single threaded runtime. So, if
> we would use clojure, I would have to write the client side in a
> different language (I don’t think building a java-ui with clojure (or
> basically building any java
> ui) a good idea).
> I mentioned protocol buffers. I don’t know ZeroMQ, but as far as I can
> see it is something different. Protocol buffers is a tool from google
> ( developers.google.com/protocol-buffers/). Basically you
> define the interaction of data between your applications in a configuration file.
> Based on this file code is generated to handle transferring the data.
> With one definition you can create modules in different languages. So,
> on the server you create data, the protocol buffer transforms it to
> binary data (or text when required for humans to read), you transfer
> the data and read it back in the other application. The data
> transferred is small (as it is in binary format, so not like JSON or
> XML), it can be converted very fast to usable data in your application
> and it is type-safe. I haven’t investigated it enough to know if you
> can also generically define the data, which you need when you want to
> be able to specify the columns of a select dynamically. You could do
> the same thing quite easily when server and client are both Omnis (you
> could transfer the binary data), but the advantage of a protocol
> buffer is that you can transfer data between different languages as
> well. It also takes version of the data definition into account (so a
> client with an older version of the code can still talk to the server with a newer version).
I’ve never encountered it. I wonder how popular this is. Looks interesting.
> other reason for it. And I don’t see our application as an application
> completely run in a webview. I don’t require it and I think it would
> take a lot more work to build something nice and the risks of it being
> not nice are much higher (I know a lot of crappy web applications,
> only a few reasonably good). I don’t believe in the ‘build once, run
> everywhere’ utopia;-)
As for transpilation being a bad idea, the facts don’t bear out that opinion. We transpile TypeScript to ES 5 so that it can run in a browser.
We’re not unique in this regard. Anyone who is writing ES 6 is transpiling.
The modern web would be nothing like it is today without transpiling being viable.
By the way, we have received nothing but great reviews from our customers who are using the formerly Omnis fat-client window that we deliver as web forms via the Chromium Embedded Framework XCOMP that we’ve built. They actually prefer it to the legacy Omnis fat-client windows that the web forms are replacing. One of our design goals was to minimize the changes to the user interface while still freshening it up. The UI of the legacy fat-client application was hideous not just because Omnis widgets have a sort of Windows 95 look about them, at least in Studio 4.3, but because there were some strange design choices that were made at the time that the application was built, like pale green backgrounds on all dropdown lists.
It doesn’t matter why that choice was made. That’s what the users are now used to. We faithfully reproduced those warts in the web application not because we’re not capable of changing but because we don’t want any user complaints about “Hey! You’ve changed everything!” We will evolve this application over time so that it looks better. It already looks much better by virtue of Bootstrap 3 styling and Font Awesome icons. We took care to use iconography that is as close as possible to the Omnis icons except they don’t look like a SEGA game console graphics.
I think the resistance by developers to deploying their applications within a browser due to some imagined benefits of having a native look miss the mark if their customers want applications deployed within a browser. We fight our customers at our own peril. Whether there is actually any real benefit of running our application on an iPad or not, our customers were oohing and aahing over demos being done by our competitors who have web applications so if we don’t meet the expectations of our customers, our competitors will. I can see real benefits of running at least parts of our application on mobile devices. Initially, that will be via WebView and it will be like a web site running on a mobile device. We’ll eventually build native apps for iOS and Android. We’ve had that in mind from the outset which is why we implemented a REST API even though we control both the frontend and backend.
+1 647-778-8696 <(647)%20778-8696>
Manage your list subscriptions at lists.omnis-dev.com Start a new message -> mailto:firstname.lastname@example.org
Manage your list subscriptions at lists.omnis-dev.com
Start a new message -> mailto:email@example.com