Board index FlightGear Development Canvas

Makeing a canvas window transparent?

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.

Makeing a canvas window transparent?

Postby jsb » Mon Jan 09, 2017 9:54 pm

Simple question: how can I make the canvas in a canvas window (semi-)transparent.
I played around with the var myCanvas = window.createCanvas().setColorBackground(0, 0, 0, 0.5); but it won't become transparent e.g. I cannot see the cockpit.
jsb
 
Posts: 285
Joined: Sat Oct 25, 2014 9:17 pm
Location: Hamburg, Germany
Callsign: D-JSB
Version: next
OS: Win7/Linux

Re: Makeing a canvas window transparent?

Postby Necolatis » Mon Jan 09, 2017 11:16 pm

Make the material the canvas is mounted on semi-transparent first.

Then probably also a good idea to apply a transparency shader to it, or just do like this, if you want to be able to see rain and such behind it:

<effect>
<inherits-from>Effects/model-transparent</inherits-from>
<object-name>canvasObject</object-name>
</effect>
"Airplane travel is nature's way of making you look like your passport photo."
— Al Gore
User avatar
Necolatis
 
Posts: 2233
Joined: Mon Oct 29, 2012 1:40 am
Location: EKOD
Callsign: Leto
IRC name: Neco
Version: 2020.3.19
OS: Windows 10

Re: Makeing a canvas window transparent?

Postby jsb » Tue Jan 10, 2017 8:23 am

Sorry, but I asked about a WINDOW (as in GUI) not about a canvas placed on a 3D object. But thanks for this interesting info :)

I am kind of frustrated by the bad documentation situation regarding canvas.
jsb
 
Posts: 285
Joined: Sat Oct 25, 2014 9:17 pm
Location: Hamburg, Germany
Callsign: D-JSB
Version: next
OS: Win7/Linux

Re: Makeing a canvas window transparent?

Postby zakalawe » Tue Jan 10, 2017 1:39 pm

The tooltip has transparency and it's a GUI / Window. I don't recall having to do anything special to make it transparent. (The background is a scale-9 PNG, with alpha transparency in the rounded corners)
zakalawe
 
Posts: 1259
Joined: Sat Jul 19, 2008 5:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: Makeing a canvas window transparent?

Postby jsb » Tue Jan 10, 2017 9:55 pm

Ok, I will have to look again for working examples, I guess I just oversee some little detail or did something stupid in my code... ;)
jsb
 
Posts: 285
Joined: Sat Oct 25, 2014 9:17 pm
Location: Hamburg, Germany
Callsign: D-JSB
Version: next
OS: Win7/Linux

Re: Makeing a canvas window transparent?

Postby Thorsten » Wed Jan 11, 2017 7:19 am

The canvas map window is even optionally transparent.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Makeing a canvas window transparent?

Postby wkitty42 » Wed Jan 11, 2017 11:13 pm

i wish more of them were... one of the first things i do when opening the map is to hit the transparent option ;)
"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: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: Makeing a canvas window transparent?

Postby Thorsten » Thu Jan 12, 2017 7:49 am

As usual, someone has to do some work. If Hooray's Pui2Canvas module develops further, we might get the ability in a native way because that would render all current dialogs as canvas, and then there could just be some 'common' area to adjust things like transparency and such.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Makeing a canvas window transparent?

Postby Hooray » Thu Jan 12, 2017 11:14 am

Thorsten wrote in Thu Jan 12, 2017 7:49 am:As usual, someone has to do some work. If Hooray's Pui2Canvas module develops further, we might get the ability in a native way because that would render all current dialogs as canvas, and then there could just be some 'common' area to adjust things like transparency and such.



Yeah, that is entirely correct - the "pui2Canvas" Nasal module started out as a simple 300 LOC proof-of-concept, and it merely looks at the XML/property tree hierarchy to look for supported tags/directives (widgets and layouting directives) and maps those to the corresponding equivalent (well, approximation) in Canvas space - so it doesn't strive to support a 1:1 mapping, but merely to approximate a sufficient degree of the existing pui/xml markup to support all legacy dialogs in FlightGear, without any of those having to be modified.

As such, it would be pretty straightforward to extend the module (probably using ~10-15 lines of added Nasal code) to add a generic "transparency control" (widget) to all PUI/XML dialogs created/rendered by the pui2/canvas translator.

Most of the code is comparatively straightforward, and it's still under 600 LOC, i.e. can be easily extended by people familiar with basic Nasal and Canvas concepts - the pui2canvas module mainly consists of a hash with embedded callbacks that use the PUI/XML tags as the lookup key to call the callback that "translates" a widget into the Canvas equivalent (think button, checkbox).

Thus, people will primarily need to be able to only understand how these callbacks works (which are usually ~20 LOC in size), without having to look at the whole module - for instance support for the <hrule> or <vrule> tags could be implemented by either adding a Canvas Image and resizing that accordingly, or by adding an OpenVG path using Canvas path drawing.

In general, the pui2canvas effort isn't intended to compete or conflict with the Qt5/Phi efforts, but it's a fasttrack solution to get rid of PUI without sacrificing tons of functionality, and without requiring tons of manual work (porting), which is especially important when it comes to dialogs that don't live in any of the repositories (think aircraft specific dialogs) but also any functionality that is implemented of top of procedurally created/updated dialogs that don't have a corresponding XML file, but which are dynamically assembled from Nasal space (think checklists, pilot list, joystick configuration, tutorials etc).

The pui2canvas module goes through the fgcommand() layer to extend/override the existing PUI commands, and as such will "just work", even for such procedural dialogs.

The current status is best summarized that it would benefit (but not necessarily require) from Canvas/UI additions like those that James mentioned on the devel list recently: http://wiki.flightgear.org/Canvas_News#Canvas_GUI

In summary, I don't think that the pui2canvas effort is "dead" - it seems it still is the only sane way to forward to have our cake and eat it, i.e. get rid of PUI without having to re-architectu much of FlightGear's GUI subsystem infrastructure from scratch (no matter if that means via Phi or Qt5), and as a matter of fact - even even/if Qt5 should ever become a mandatory build requirement, the pui2canvas approach could help pave the way for this, because it would allow us to get rid of problematic Nasal workarounds by unifying the GUI subsystem via the parser, e.g. by versioning PUI/XML files and introducing custom tags for some of the more common workarounds (hacks), such as having a proper "table" widget that can show arbitrary widgets, without having to resort to show/hide hacks using property switches.

For the time being, it's a rough prototype, but easy to extend, and all additions/improvements would automatically affect all existing UI resources, no matter if those live in any oof the official repositories or not - which really is one of the most striking advantages when it comes to updating the UI layer in a holistic fashion:

http://wiki.flightgear.org/Howto:Proces ... ing_Canvas
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Makeing a canvas window transparent?

Postby jsb » Thu Jan 12, 2017 9:38 pm

Frankly speaking, I am at a point where I am frustrated by the "bad" canvas documentation. As (if I recall correctly) T(h?)orsten wrote somewhere, tons of quotes are NOT a documentation. Those are hard to read, its like a puzzle, not a text with flow, costs time and nerves to extract information.

Personally, I am kind of annoyed by the many stubs in the wiki. Dont get me wrong, I really like the wiki as knowledgebase and way-of-documentation but empty stubs are not helpful but just drain attention.
I learned about many ideas some people obviously had in the past but that either did not get implemented or at least not documented - what a pitty :s - I would prefer to discard those "empty" pages and summ up the ideas on one page in a table.

What I miss: pages that gives me overview, structure, navigation - most of us just want to get their "project" done and a good documentation make things so much easier and raises motivation to work on things instead of reverse-engineer tons of code to find what API is avail etc.
A who-is-who would be also great, so you can get an idea how many people are working on flightgear in what area, maybe what motivation, what skill/background... that could make it easier to form teams to work on topics.
jsb
 
Posts: 285
Joined: Sat Oct 25, 2014 9:17 pm
Location: Hamburg, Germany
Callsign: D-JSB
Version: next
OS: Win7/Linux

Re: Makeing a canvas window transparent?

Postby Hooray » Thu Jan 12, 2017 10:35 pm

Yeah, we've had the same discussion before - so we're all aware of this, i.e. your point is well taken, and you made the exact same point previously in another topic...

In general, it would be good to have more, and especially better, documentation - in practice however, you are already stating why nobody is volunteering their time and expertise to help improve/create the corresponding documentation: because people want to get their own projects done. :D :D :D

Thus, without meaning to offend you, may I suggest that you simply take one step back and look at the situation as it really is ?

Really, nobody around here disagrees with your key message - but just like you, we're also just people interested in certain aspects of FlightGear, which usually means that we are not even the slightest bit interest in somebody's pet project - especially not if that doesn't translate into tangible results that flow back into the main project.

It goes without saying that unfinished and outdated wiki articles and unfortunate, and that also applies to articles consisting primarily of quotes.

Then again, I don't see anything suggesting that you are actually in a position to tell what entails good documentation and what should be "removed" - like I said earlier, I had the same discussion with Thorsten, and it was frustrating for both of us, for different reasons. I knew for a fact that I was providing exactly the answers to the question he posed, but it took him quite some time to follow up with some of the feedback I provided - it was only later on that he admitted that his priorities were very different, too - and that he also wasn't interested in helping clean up the wiki or re-write certain documentation.

Once you look up Thorsten's recent posting history, you will see that there is a handful of postings where he's specifically following up on advice that was previously provided here.

In addition, the wiki is maintained in a fashion not unlike to open source code: it evolves over time - e.g. some of the most useful articles mentioned by various contributors are the "Canvas Snippets" and "Canvas Reference" sections - yet, I ended up creating those specifically in response to certain discussions on the forum, and after tinkering with different forms of articles long before that.

Personally, I consider myself fairly familiar with the Nasal side of the Canvas system, and looking at your recent postings, I could have certainly posted answers to most of them (if not even all) - however, it's also a matter of spare time. And quite frankly, I also don't see anything suggesting that you actually looked at the underlying files - which is however something that Thorsten obviously started doing recently.

Please don't get me wrong, I am really not complaining at all - we all have real lives, day jobs and our own little pet projects - but even if you never look at the wiki, there is tons of good material in $FG_ROOT/Nasal. But you always need to keep in mind that it is unreasonable to just work through a few tutorials and understand all these concepts - people with a certain programming background will find it much easier to use Nasal and Canvas than people just starting out, which ironically is why the "Canvas Snippets" article is so appealing to folks who have no clue about programming or who are not that familiar with FG internals.

However, overall, the situation isn't that bad compared to other Nasal-space APIs and especially other subsystems in FlightGear.

Obviously, what is there can, and should be, improved - I would however appreciate it if you could start new articles (or new navbars) instead of outright deleting stuff that you may not yet fully understand - this is something that I also politely asked Thorsten to take into consideration before going crazy to delete everything that looks like gibberish to people less familiar with the whole thing.

Again, people with a strong background in JavaScript (functional programming, closures, OOP) don't seem to have much of a problem using the Canvas system, even just by referring to $FG_ROOT/Nasal/canvas/*.nas

However, if you are entirely new to some of the more advanced programming concepts the Canvas/Nasal bindings are using, it is certainly a bit far-fetched to directly use the whole shebang.

Besides, I have personally come to the conclusion that the way we're using the Canvas system, and especially its Nasal bindings, is hugely problematic, and that has little to do with the existing documentation - as a matter of fact, we would not be facing this dilemma if the documentation would be much worse or non-existing.

Nasal and Canvas are far too accessible at this point, and everybody and their dog is creating rendering related stuff that runs in the FlightGear main loop without people understanding the ramifications of coding that way, which is one of the reasons why I have stopped adding much to the docs, because I am firmly convinced that we need to fix/address some core level issues first; lest, the Canvas system is sooner or later going to become at least as problematic as the Nasal subsystem in FlightGear - which is not due to its inherent design, but due to the enormous flexibility it provides.

I've been trying to summarize the main issues in the wiki, feel free to take a look: http://wiki.flightgear.org/Canvas_Devel ... FlightGear

Finally, I really haven't been following the project much recently - but my general advice in these kinds of threads is usually that people should strive to be, and to embody, the change the want to see. In other words, feel free to fork whatever articles/templates you deem appropriate to compete with the status quo - if you manage to come up with something better, it will certainly be adopted sooner or later, that's the way open source works after all.

If however you end up arriving at the conclusion that your own little projects are more important than fixing the status quo WRT the wiki or the Canvas docs there, you can officially consider yourself to be part of the problem, and not part of the solution - which is to say, welcome to the club of people who are more interested in their own little pet projects than helping the project as a whole (in other words, things are certainly not as bad as some people make them sound).
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Makeing a canvas window transparent?

Postby Thorsten » Fri Jan 13, 2017 7:36 am

- this is something that I also politely asked Thorsten to take into consideration before going crazy to delete everything that looks like gibberish to people less familiar with the whole thing.


Actually, I said I would clean the wiki articles for features I maintain in FG (which I usually started) from quotes and I pretty much did that - I would argue they're fairly up to date and organized.

Frankly speaking, I am at a point where I am frustrated by the "bad" canvas documentation.


Actually, this

http://wiki.flightgear.org/Canvas_Nasal_API

is what I've been looking for, and after I've finally been pointed to it, I can actually work with the thing.

There's I guess (at least) three areas where canvas is perhaps difficult to grasp for a newcomer which require all different philosophy in documentation:

1) the concept as such - what are the elements we can draw? Which is to say, if I look at a screenshot of a glass cockpit MFD, how would I go segment that into things canvas understands? Or, if I parse an SVG file - what are the things that get returned (are they properties, vector images, raster images, classes,... - don't answer, I know this now...)? What am I supposed to do with them next? This is the thing that's sort of obvious for the canvas developers, which is why there's no explanation anywhere, but I only got it after reading through raw SVG code in an ascii editor and understanding what it does. It's similar to understanding 3d rendering - it's cool to admire, but you need to understand the relation of vertex, triangle, rasterizer, pixel to even halfway understand where to code something.

2) The OOP structure - that's where Hooray usually assumes people have trouble, but I actually don't think so. If you have some general Nasal background and have ever used props.nas, the way to talk to canvas is very familiar. At least I didn't ever have trouble with the structure (see rather 1) and 3) below), and it was vexing to frequently get this point explained, but not the others I had actually trouble with.

3) The actual API - it's nice to understand that your flight path marker symbol ends up as a canvas path element, and that you have to call methods to do something with it - but at some point you need to have a list of what methods are available for what and what parameters they need. And that's not at all apparent from the snippets - but solved by the API overview I linked above.

So in my view, what this needs is a general overview on what canvas is and does, followed by a handful of sample codes, followed by the API overview, and it's well documented.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Makeing a canvas window transparent?

Postby jsb » Fri Jan 13, 2017 5:01 pm

Thanks for your feedback. Please be assured as an engineer I am familiar with OOP and I understand nasal and the property tree. I also did read a lot of code (nasal and C++) and found out many interesting things but it costs a lot of time.
Thorsten and I seem to share some common understanding how we like documentation, e.g. the API doc and the sniplets.
I would be willing to improve the docs but I believe this should be coordinated otherwise people might be upset. I will not delete pages from wiki, I may follow your advice to create new pages as soon as I find the time.
jsb
 
Posts: 285
Joined: Sat Oct 25, 2014 9:17 pm
Location: Hamburg, Germany
Callsign: D-JSB
Version: next
OS: Win7/Linux

Re: Makeing a canvas window transparent?

Postby jsb » Sat Jan 14, 2017 10:06 am

Ok, I am I step forward, I finally found the property that controls the transparency of a canvas window (NOT a pui dialog!). I will read the cavas nasal files now to see if there is an API call I missed by now. Otherwise I guess I will implement it ;>
jsb
 
Posts: 285
Joined: Sat Oct 25, 2014 9:17 pm
Location: Hamburg, Germany
Callsign: D-JSB
Version: next
OS: Win7/Linux

Re: Makeing a canvas window transparent?

Postby jsb » Sat Jan 14, 2017 1:50 pm

I updated http://wiki.flightgear.org/Canvas_Nasal_API#Window created http://wiki.flightgear.org/Canvas_GUI_API with what I found in the nasal files.
I skiped the very internal things because I do not fully understand them yet. Unfortunatly i will have to touch more files than expected to make things work as I want.
To get a canvas window transparent, you have to manipulate ("hidden") canvas that represents the window frame/decoration - this should be done via an API of course and not in a reverse-engineering way that I describe now.

It appears that the title_bar element contains a path[0] that fills the window background area and that the hidden canvas itself has a background property.
Using the property browser one can manipulate the node /canvas/by-index/texture[x]/background (make sure /canvas/by-index/texture[x]/name == "window-decoration" and belongs to your window) which has the format "rgba(red, green, blue , alpha)" - just change the alpha to say 0.5 and it becomes half-transparent. Do the same to the "fill" node of the group/group/path element (id of groups: decoration and title_bar) .

There are other elements I did not look into detail but from the code I read I guess I will try to tweak the styleing system.

Of cource one has to make sure, that everything that is put into the (user) canvas of the window is also "set to transparent" in a adequate way.
jsb
 
Posts: 285
Joined: Sat Oct 25, 2014 9:17 pm
Location: Hamburg, Germany
Callsign: D-JSB
Version: next
OS: Win7/Linux

Next

Return to Canvas

Who is online

Users browsing this forum: No registered users and 4 guests