Board index FlightGear Development Canvas

Nasal Browser :)  Topic is solved

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Re: Nasal Browser :)

Postby Hooray » Sat Jun 28, 2014 10:33 am

TheTom wrote in Thu Jun 26, 2014 4:14 pm:Code is all new^^


I think we can help create a few more widgets, even though a few more comments may be helpful whenever there's some required interface-wise, or if something is widget-specific. As long as a handful of widgets have a few comments, I can probably add some docs to the wiki to better document how new widgets can be created, which interfaces they should implement and how to handle events etc - that should also help anybody interested in custom widgets like the "weather editor" stuff people have been talking about.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Nasal Browser :)

Postby Hooray » Sat Jun 28, 2014 2:17 pm

Philosopher wrote in Thu Jun 26, 2014 3:55 am:Finding a way to reuse code between them sounds like a good idea as well, as it's still "spaghetti" code with copy/paste assistance there


For things like a "browser" (namespace, properties etc), we should probably really consider creating a typical listview, or even TreeView, widget - for starters, we could use ASCII art:
Image

Or even a combination of OpenVG paths and Canvas osgText:
Image

But using an existing SVG/TreeView should also allow us to animate it properly via Nasal.

These days, there are a handful GUI frameworks that internally use SVG images for their widgets, e.g.:
http://code.google.com/p/altcanvas/wiki/InkFace
http://www.dotuscomus.com/pergola/examples.html
Tom mentioned that he's reusing GNOME artwork for some of his recent work already. So we can probably do the same thing for more complex widgets like TreeViews, even though it's mainly a recursive widget, and not necessarily sophisticated aside from that.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Nasal Browser :)

Postby Alant » Fri Feb 09, 2018 9:55 pm

Is there any possibility that a version of this could be added to Fgdata?

PS what is the latest version?

Thanks

Alan
Alant
 
Posts: 904
Joined: Wed Jun 23, 2010 5:58 am
Location: Portugal
Callsign: Tarnish99
Version: from Git
OS: Windows 10

Re: Nasal Browser :)

Postby wkitty42 » Sat Feb 10, 2018 1:47 am

this is 3.5 years old, dude :/
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5574
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Nasal Browser :)

Postby Alant » Sat Feb 10, 2018 9:51 am

All the more reason to put it into the fdata menu. Otherwise it will get lost and undeveloped, just like fgplot was..

Alan
Alant
 
Posts: 904
Joined: Wed Jun 23, 2010 5:58 am
Location: Portugal
Callsign: Tarnish99
Version: from Git
OS: Windows 10

Re: Nasal Browser :)

Postby wkitty42 » Sat Feb 10, 2018 10:51 am

i don't see why we need it... we've already got file dialogs, right???
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5574
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Nasal Browser :)

Postby Hooray » Sat Feb 10, 2018 11:56 am

Sorry, but this has nothing to do with "file dialogs" - it's a Nasal namespace browser, it just happens to be using a pseudo-treeview.
Other than that, I do agree with Alan actually - the fgplot dilemma was unfortunate enough, we don't need to be making the same mistakes over and over again.
Despite this work dating back to ~3 years ago, I don't think there were any related changes that would "break" this.

Given the increasing trend among core developers to recognize that they cannot possibly stop all activity in the Nasal/Canvas department, and the recent work on the addon framework, I think that this could be added as an addon to FGAddon - that way, it will remain entirely optional, while being made available to people wanting to use it.

Nevertheless, it might make sense to consider adding support for "default addons" that are shipped as part of the base package, so that certain addons can be included in the base package/release builds, without people having to go the extra mile just to get something like the oscilloscope addon.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Nasal Browser :)

Postby wkitty42 » Sat Feb 10, 2018 12:51 pm

oh, it looked like files being displayed in a tree, to me :shrug:
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5574
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Nasal Browser :)

Postby Hooray » Sat Feb 10, 2018 12:55 pm

in layman's terms, it's doing the equivalent of the property browser vs. properties, but for Nasal vs. Nasal variables:

Image
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Nasal Browser :)

Postby wkitty42 » Sat Feb 10, 2018 1:02 pm

Hooray wrote in Sat Feb 10, 2018 12:55 pm:in layman's terms, it's doing the equivalent of the property browser vs. properties, but for Nasal vs. Nasal variables

OH! the topic name threw me off... i thought it was just a file browser written in nasal which just didn't make any sense to me... this makes a little more sense as it is, in essence, a nasal debugger... debugger as in the part of a debugger that shows you the variables and their values... not the debugger part which allows you to step through the code...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5574
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Nasal Browser :)

Postby Hooray » Sat Feb 10, 2018 1:06 pm

well, it's provides support for "browsing" Nasal variables and namespaces.
Yes, it can be used for inspecting/debugging Nasal scripts.
That being said, a Nasal/Canvas based file dialog implementation would not be such a ridiculous thing, given that the original implementation was using PUI, and got replaced with OS-specific versions, that stopped working properly a long time ago - which may not apply to people with access to Qt5 builds obviously, but we were seeing a number of bug reports due to such OS-specific "file load/save (open/close)" dialogs when the PUI based ones were replaced.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Nasal Browser :)

Postby wkitty42 » Sat Feb 10, 2018 1:11 pm

growing up and staying viable can be painful... excruciatingly painful at times... PUI is dead... Rembrandt is dead... AI traffic is dead... i mean, we're 20 years old and still wearing the clothes of a 5 or 10 year old... clothes that should have been replaced 5 or 10 years ago ;)
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5574
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Nasal Browser :)

Postby Hooray » Sat Feb 10, 2018 1:17 pm

yes, good point, there comes a time when it is cheaper to do away with legacy stuff/cruft - but it's probably not a good idea to do so without also providing a sane migration path and a migration period, and one that actually works - otherwise, this is likely to cause even more frustration than sticking with features/code for another decade:


making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Nasal Browser :)

Postby wkitty42 » Sat Feb 10, 2018 1:47 pm

yeah, i've been there and done that several times over the 35+ years i've been code jockey (aka software engineer)... sometimes, to remove the unwanted hair, you must bite the bullet and rip the tape strip off as quickly as possible instead of doing it slowly which may leave some hair behind as well as making the process take much too long and be all the more painful...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5574
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Nasal Browser :)

Postby Hooray » Sat Feb 10, 2018 2:08 pm

Like you said, the codebase/architecture could become really lean by getting rid of some of the features you mentioned - I am just not sure if it's going to be such a popular/successful step - these decisions must not be taken lightly, e.g. a few people have been wanting to get rid of Nasal, in favor of Python, Lua or JavaScript because of better "support" (maintenance, docs, examples, libraries etc) - without recognizing that the real bottleneck when it comes to FlightGear scripting is not Nasal the language (or its garbage collector), but the way the FlightGear main loop is structured, and the way Nasal code tends to be executed using the notion of timers and listeners - a different, more popular, scripting language like Python would make such problems even more prominent, within a few months time (release cycles) probably.

In theory, adopting Qt5 sounds great, and could help solve a bunch of long-standing issue, analogous to how adopting OSG has helped the project enormously - in practice however, a number of core developers have requested for all Qt5 related code to remain entirely optional and self-contained, i.e. encapsulated, using a corresponding Qt-module, so that theoretical benefits of adopting Qt5 would obviously also remain rather specific/encapsulated, i.e. unlikely to propagate to non-Qt5 areas of the codebase.

And as a matter of fact, we've had a number of people who pushed for wider adoption of boost or OpenSceneGraph, whereas the original person to actually initiate the OSG port (Mathias) has been encouraging people to encapsulate new depedencies properly, unrelated to the current popularity or maintenance status of the library in question - sounds like a lesson learnt, the hard way ;-)

https://sourceforge.net/p/flightgear/ma ... /22929621/
Mathias Fröhlich wrote:we definitely have parts in a
simulation that just do not need to know that they run on osg/OpenGL.

Imagine you want to change the viewer library. All the physics is still the
same. By mixing osg classes into everything without any type abstraction in
between, you need to rewrite the whole pile of code. Even for parts that do
not depend on any viewing crap at all.
I already did so when I started to switch to osg and plenty of that work was
almost only for that reason we have all the sg types directly spread around.
So please avoid having osg::whatever spread around in the whole application
...

Appart from that, having more separate code paths in general for the
simulation parts and the viewer/scene parts would help for plenty of our
scalability problems a lot. So just thinking about general software design ...
So nothing is set in stone here, but it makes sense IMO to head into that
separation where possible/sensible.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11326
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 3 guests