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

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

[David Botton]

GNOGA v1.1 for Ada is now available from http://gnoga.com or via git from http://sourceforge.net/projects/gnoga

V1.1 in addition to bug fixes and vastly increased stability adds:

Completed multimedia bindings
Easier boot file creation by just including boot.js in any html file
Direct HTTPS and Secure Websockets
HTTP polling with Ajax including fallback support (using auto.html bootfile)

David Botton

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

[Shark8]

Good news / Congrats.

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

[slos]

Le mercredi 1 juillet 2015 16:43:51 UTC+2, David Botton a écrit :
> GNOGA v1.1 for Ada is now available from http://gnoga.com or via git from http://sourceforge.net/projects/gnoga
> 
> V1.1 in addition to bug fixes and vastly increased stability adds:
> 
> Completed multimedia bindings
> Easier boot file creation by just including boot.js in any html file
> Direct HTTPS and Secure Websockets
> HTTP polling with Ajax including fallback support (using auto.html bootfile)
> 
> David Botton

Dear Mister BOTTON,

Thank you very much for providing Gnoga.

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.

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.

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.

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.

Gnoga's market place would provide bindings to further libraries.

What about D3JS (http://d3js.org/) or Smoothie Charts (http://smoothiecharts.org/) ?

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.

Having the Ada application managing the UI seems to require too much overhead, doing DOM manipulation, when the data changes often.

I'd like to ear your opinion and thoughts on this please.

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

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

[David Botton]

> 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

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

[Vincent]

Le mercredi 1 juillet 2015 16:43:51 UTC+2, David Botton a écrit :
> GNOGA v1.1 for Ada is now available from http://gnoga.com or via git from http://sourceforge.net/projects/gnoga

Hello David,

Thank you for providing us Gnoga. I have a beginner's question upon it :
I would like to create a tool that allows us to draw technical diagrams made
of boxes and arrows (that represents exchanges of data between entities
according to an international standard) and export them as pdf and databases.

It is similar to what Ms-Visio does but much simpler. (In fact we use
Visio to create the diagrams but we are unable to extract the data to a
database, even with the XML files).

I have seen web apps for drawing, like : https://awwapp.com/
Is it possible or recommended to use Gnoga to do that in Ada ?

Kind regards,

Vincent



So would Gnoga allow us to create something similar (but simpler) to Visio ?
Create boxes and link them with arrows all in a web browser ?

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

[David Botton]

> I have seen web apps for drawing, like : https://awwapp.com/
> Is it possible or recommended to use Gnoga to do that in Ada ?

Tutorial 5 uses a drawing canvas for a whiteboard, so similar to this.

What you are asking about it more Vector drawing.

> So would Gnoga allow us to create something similar (but simpler) to Visio ?
> Create boxes and link them with arrows all in a web browser ?

Yes. You could do it from scratch using SVG (see test/svg_demo.adb) but it is probably better to leverage existing JS libraries and just bind them using Gnoga.

I will likely at some point soon create a binding to : 

http://jsplumbtoolkit.com

Which is very much in line with what you want.

That is the beauty of Gnoga, you are now able to leverage every existing JS library out there and so are always able to create far richer desktop or web apps than any existing UI framework such as Gtk, etc. (BTW, you can easily turn any Gnoga app in to a Gtk app or Mac OS X app using the webkit widget with a simple recompile see the docs dir for the native gtk doc :)

With Gnoga, I'm like Lady Ada in a candy store, I can pick from thousands of open source or even commercial JS components actively developed and instantly use them for my projects or bind them for even easier use in Ada and by others.

David Botton

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

[vincent.diemunsch]

Le jeudi 9 juillet 2015 17:53:10 UTC+2, David Botton a écrit :
> 

> Yes. You could do it from scratch using SVG (see test/svg_demo.adb)

Ok. I'll have a look on that.

> I will likely at some point soon create a binding to : 
> 
> http://jsplumbtoolkit.com
> 
> Which is very much in line with what you want.

Yes indeed. Sounds really cool. But I will have to learn how to bind to
Java Script !


> With Gnoga, I'm like Lady Ada in a candy store, I can pick from thousands of open source or even commercial JS components actively developed and instantly use them for my projects or bind them for even easier use in Ada and by others.

I like the image :-).

Thank you for your kind reply.
Regards,

Vincent

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

[David Botton]

> > I will likely at some point soon create a binding to : 
> > 
> > http://jsplumbtoolkit.com
> > 
> > Which is very much in line with what you want.
> 
> Yes indeed. Sounds really cool. But I will have to learn how to bind to
> Java Script !

Is not very difficult and depending on your timing I may have that bound by the time you are ready anyways.

David Botton

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

[Shark8]

On Wednesday, July 8, 2015 at 7:07:31 AM UTC-6, David Botton wrote:
> 
> 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)

Question: If there's a compiler taking .NET to ASM.js, then would the runtime encumbrance (or anything really) stick with if you processed it? After all, the output of that DOTNET-to-JS would be, at best, a "derivative work". And *IF* the runtime is encumbered, would it be feasible to use the pragma-restrictions to avoid it?

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

[David Botton]

> Question: If there's a compiler taking .NET to ASM.js, then would the runtime encumbrance (or anything really) stick with if you processed it? After all, the output of that DOTNET-to-JS would be, at best, a "derivative work".

That is what the license virus does, it makes your work a derivative work and so get the GPL even if you don't want it and even if the FSF never intended it.

> And *IF* the runtime is encumbered, would it be feasible to use the pragma-restrictions to avoid it?

Given the past record of ridiculous claims like "downloading from site X overrides stated licenses" prank or false IP scares, I highly doubt you won't here claim the generated binder file is GPL so that pragma may not be enough. (There is no FSF .NET version).

David Botton

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

[slos]

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