Re: GNOGA v1.1 Released - Ada Cloud Desktop and Mobile Development

[slos <new.stephane.los@gmail.com>]

Le mercredi 8 juillet 2015 15:07:31 UTC+2, David Botton a écrit :
> > In Gnoga features, one can read "Write complex web-apps or desktop apps with no HTML or JS" and I can't buy this since even if not writing HTML one has to know it to use Gnoga.
> 
> It is the case that you do not need to know HTML/JS the DOM etc with Gnoga, but knowledge is power. Just like knowing Win32 APIs helps but not needed if you use GWindows or CLAW for UIs on Windows.
> 
> 
> > I can hardly imagine a web designer writing the Ada code, compiling it, running it and refreshing the page in the browser. So I guess the workflow would rather be : design a web app with your favourite HTML / CSS / JavaScript editor, and embed in some Gnoga controls by querying the DOM and adding them to it.
> 
> Gnoga has many uses, while it can be used for "web", one of its target uses is for App UIs and embedded systems. For Web Gnoga excels with a workflow as you have described. For rapid prototyping of Apps that can also work well. I just posted to the Gnoga list a PDF on how to use an on-line simple HTML/Bootstrap form generator as a quick and easy GUI builder for Gnoga forms as an example.
> 
> In cases of using external design tools you do not have to constantly recompile your code. Simply attaching IDs at of the DOM as you point out is sufficient if you are working with designers and for Web sites that is often the best way to do it. For apps, it depends on your needs and how often the "design" will change.
> 
> 
> > It seems to me that Gnoga requires direct DOM manipulation to refresh data where AngularJS (http://angularjs.org/) or RactiveJS (http://ractivejs.org/) will provide simpler (user point of view) two-way data binding.
> 
> Only if you are using JavaScript do you have these concerns. From the Ada perspective you do not have to play around with the DOM or worry about data binding (a cludge for dealing client side only code in JS, I still prefer using JS directly there to "data biding" solutions.)
> 
> I prefer imperative event driven programming for UIs, respond to change event and make changes there to other controls, etc. I find that the "data binding" magic fails in practice once things become a bit more complicated then a total on spread sheet (and even then fails if you need that calculation to also notify the server of its change.
> 
> 
> > I am in no way a web specialist and I try to understand the philosophy of the many libraries / frameworks in the field and how Gnoga compares.
> 
> 
> The first thing is to compare it to Gtk and Cocoa not to Web tech which it uses.
> 
> Then once you've "got it" say, hey cool I can now program web sites in the same style as local desktop Apps like Visual Basic or Delphi.
> 
> Then.. You see how Gnoga is innovative and paradigm changing for web development on the cloud and UI development for mobile and desktop that is truly portable.
> 
> > Gnoga's market place would provide bindings to further libraries.
> > 
> > What about D3JS (http://d3js.org/)
> 
> No point to using that with Gnoga as far as I can tell at first glance. Same as Angular, etc.
> 
> > or Smoothie Charts (http://smoothiecharts.org/) ?
> 
> Looks like an easy and good addition.
> 
> The Core of Gnoga is extremely stable and working well at this point with 1.1. The majority of work ahead is in tools and bindings to complex widgets.
> 
> 
> > In fact, from my perspective, the application written in Ada should only serve the web page and provide the data using websocket to a JavaScript object managing the interaction with the browser / user.
> 
> That is because you are think like a web person not a UI developer for applications.
> 
> One can use Gnoga in that way and it is certainly superior to any solution in any language that way as well :)
> 
> 
> > Having the Ada application managing the UI seems to require too much overhead, doing DOM manipulation, when the data changes often.
> 
> No "human" interaction is not going to be an issue as calculations and data manipulation are done on the Ada side. The "html" page is just a rendering engine for the results.
> 
> However there are time where it makes sense to have things handled on the client side and if we ever have an llvm (unencumbered by GPL viruses) backend we can push the Ada to the client side as well. For example, until then something like the Ace code editor that I am using on the new IDE in Gnoga which is written in JS is bound to Gnoga but fine controls are handled by it on the client side and yes if was all Ada at this point could feel a little sluggish. Unfortunately until I have the time or someone else has the time to revive dragoneggs or an alternative those parts will need to remain in JS or language compiling to JS. (As a side note, if Ada.NET was not virused, I'd probably pursue updating that as there is a compiler freely available to compile .NET to ASM.js shame, I wonder if Martin realized the devastation GPL has on runtimes to kill future open source work not just closed source)
> 
> So instead think like this, "widgets" for the GUI if complex (at least for now) requiring a lot of interaction should be in JS, but everything else can be in Ada. If a lot of design work is being done (such as in a web page) then the design should be in HTML and CSS and Gnoga can just use View.Load_File and then View.Attach_With_Parent to the IDs set in those designs that require interaction or data.
> 
> 
> > I'd like to ear your opinion and thoughts on this please.
> 
> I appreciate the discussion, Gnoga takes some time to fully "get" for many. It is a far better solution then web servers for Ada for any web work, but it is also as good a solution (although not perfect yet since as pointed out complex widgets would need more client side Ada that is not possible yet) as GtkAda or GWindows for Ada GUIs.
> 
> David Botton

Thanks Mister BOTTON for the detailed answer.

I will take some time to digest all the provided information and study Gnoga further on to see how it compares or could use other libraries.

Best Regards,
Stéphane
http://slo-ist.fr/ada4autom