Board index FlightGear Development New features

Better readability of notifications

Discussion and requests for new features. Please note that FlightGear developers are volunteers and may or may not be able to consider these requests.

Better readability of notifications

Postby MariuszXC » Thu May 20, 2021 4:39 pm

So, honestly, I did not know whether to post this here or in the 'Nasal' section. Actually it is not a new feature per se, rather a slight tunng of an existing notification area to improve readability. Anyway, here is the rationale:

Notification area is located in upper center part of the screen. The usual background for this area is light blue sky, or white-greyish clouds. Together with bright colours of messages displayed there the combination is not easy on the eyes (see pictures, before and after modification).

Proposed change modifies default background alpha channel (transparency) of the notification area. This visibly (pun intended) :) improves messages readability during daytime flying, without having an impact on night flying.

The whole change is in attached diff. The main change is a one-liner in line 81. The other change around line 114 adds a small padding. Without this padding the transition between surrounding background and text was too abrupt.

Code: Select all
--- fgdata/Nasal/screen_nas_orig   2020-11-05 12:49:27.000000000 +0100
+++ fgdata/Nasal/screen.nas   2021-05-20 15:26:01.911317500 +0200
@@ -78,7 +78,7 @@
       m.autoscroll = autoscroll;   # display time in seconds
       m.sticky = 0;         # reopens on old place
       m.font = nil;
-      m.bg = [0, 0, 0, 0];      # background color
+      m.bg = [0, 0, 0, 0.65];      # background color, alpha
       m.fg = [0.9, 0.4, 0.2, 1];   # default foreground color
       m.align = "center";      # "left", "right", "center"
       #
@@ -108,9 +108,13 @@
       if (a == nil)
          a = me.fg[3];
       var lines = [];
+      var linepadded = "";
       foreach (var line; split("\n", string.trim(msg ~ ""))) {
          line = sanitize(string.trim(line));
-         append(lines, [line, r, g, b, a]);
+         linepadded  = " ";
+         linepadded ~= line;
+         linepadded ~= " ";
+         append(lines, [linepadded, r, g, b, a]);
       }
       if (size(me.writebuffer) == 0)
          settimer(func { me._write_(); } , 0, 1);


before:
Image
after:
Image

To test it is enough to add modifications to a local file fgdata/Nasal/screen.nas (make a backup copy of the original just in case) and restart FlightGear.

Hope you will like it.
Mariusz
INOP
MariuszXC
 
Posts: 1061
Joined: Tue May 18, 2021 5:38 pm
Location: Europe
Callsign: SP-MRM
Version: 2020.4
OS: Ubuntu 16.04

Re: Better readability of notifications

Postby Hooray » Thu May 20, 2021 4:58 pm

it's better to use the devel list/feature tracker for these sorts of discussions.

Anyway, there's currently ongoing work towards adopting the OpenGL Core profile: https://wiki.flightgear.org/OpenGL#Status

This entails removing/porting a bunch of legacy features/code (osgtext, PUI GUI, 2D panels, HUDs) and re-implementing those on top of the Canvas system, as in unifying the 2D rendering back-end via the Canvas: https://wiki.flightgear.org/Unifying_th ... via_canvas

Basically, the screen.nas stuff would be best ported to use a Canvas based back-end, analogous to the tooltips API: https://wiki.flightgear.org/Tooltips

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: Better readability of notifications

Postby MariuszXC » Thu May 20, 2021 9:38 pm

Hooray, thank you for your answer. Let me address a couple of points.

Hooray wrote in Thu May 20, 2021 4:58 pm:it's better to use the devel list/feature tracker for these sorts of discussions.

In principle I agree. The thing is, that in order to participate in the channels you mentioned it is necessary to register an account with SF, and then register to a project/list. Nothing wrong with that - technically - and I probably should try and check, whether my old SF account is still there after more than a decate of inactivity, but... there is a social side to this. I view the action of entering the channels you mentioned as a quite strong form of social commitment. In other words, should I try to be active in those channels I would feel obligated to provide useful input there and actually spend more time on development than I may have to offer at the moment.


Anyway, there's currently ongoing work towards adopting the OpenGL Core profile: https://wiki.flightgear.org/OpenGL#Status
[...]


I was vaguely aware of the change going on in those areas, but thank you for providing these pointers. I'll study them carefully.

In the meantime, may I ask a favour?
I am not an expert in Nasal. While the changes I made seem innocent enough to me, there may be side effects I am not aware of. Could you have a look and comment, if they are ok?

Lastly, what do you think about enhancing readability in the way I proposed?
INOP
MariuszXC
 
Posts: 1061
Joined: Tue May 18, 2021 5:38 pm
Location: Europe
Callsign: SP-MRM
Version: 2020.4
OS: Ubuntu 16.04

Re: Better readability of notifications

Postby Hooray » Thu May 20, 2021 9:53 pm

readability (well, usability in general) is kinda one of the pet peeves of the primary FG core developer (James Turner), so it seems your idea/patch would stand a pretty chance of being discussed/reviewed and applied there. If you don't want to subscribe to the devel list or if you don't want to use git or the tracker, you can still send your posting there, even without being subscribed to the list (pending review/approval by one of the moderators).

Other than that, the key people behind the effort(s) to modernize the FlightGear renderer currently are James, Stuart, Scott, Richard and most recently Fernando (via his compositor).
In addition, Jules has contributed a CompositeViewer integration, which is also touching the renderer.

All of these people are actively involved in the project (have commit access) and subscribed to the list, so there's a pretty good chance that you'll get a swift reply over there.

Don't be shy ... it's the appropriate place for such discussions and improvements.

(For the sake of completeness, there's also an ongoing effort to replace the built-in GUI engine (called PUI), by using a Qt5 based back-end - which is what the built-in launcher is using - using Qt5 for in-sim usability improvements is however unlikely to be well received as long as Qt5 as a dependency is required to remain optional by some core devs... so there's that too - which is why a Canvas back-end does make sense, and is in line with other efforts to help unify the 2D rendering back-end via the Canvas - admittedly, that may sound fancy, but the tooltips stuff is using a very simple back-end that simply uses osgtext via Canvas.Text, and the same approach would work here, while at the same time helping encapsulate things neatly, i.e. for a potential VSG future).


PS: Alternatively, you could also ask another contributor to file a corresponding feature request/patch on your behalf or have your postings forwarded to the list, some forum users have a reputation for interfacing between the devel list and the forum pretty regularly (for instance, wkitty42 tends to cross-post and share follow-up postings with both "places").
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: Better readability of notifications

Postby danielHL » Fri May 21, 2021 12:45 pm

Long story short: The fix you are proposing is in a GUI that is soon-ish going away and no new development on this GUI-Toolkit should be started. However, your fix is small and very relevant to day-to-day use of the sim, I would encourage you to post this to flightgear-devel@lists.sourceforge.net (no SF account required, as Hooray said).
danielHL / D-FMPW
danielHL
 
Posts: 280
Joined: Fri May 02, 2014 7:23 pm
Callsign: D-FMPW
Version: next
OS: Linux

Re: Better readability of notifications

Postby MariuszXC » Fri May 21, 2021 4:24 pm

danielHL wrote in Fri May 21, 2021 12:45 pm:[...]I would encourage you to post this to flightgear-devel@lists.sourceforge.net (no SF account required, as Hooray said).


OK, will do :-)
I am still trying to apply the same type of fix to the ATC text messages presented by 'Multiplayer' > 'Chat Menu <->' which have the same kind of readability issue (see image), but here I got somewhat lost tracing where the actual display of the messages takes place.

Will spend some more time on that, but if I don't find it, I'll simply mention this thread in my mail.

Standby...

Image
INOP
MariuszXC
 
Posts: 1061
Joined: Tue May 18, 2021 5:38 pm
Location: Europe
Callsign: SP-MRM
Version: 2020.4
OS: Ubuntu 16.04

Re: Better readability of notifications

Postby Hooray » Fri May 21, 2021 5:04 pm

danielHL wrote in Fri May 21, 2021 12:45 pm:Long story short: The fix you are proposing is in a GUI that is soon-ish going away and no new development on this GUI-Toolkit should be started.


To be honest, in a perfect world that would be true, but in reality that's a bit misleading unfortunately: The PUI GUI engine has been scheduled for removal/replacement for over half a decade meanwhile, with numerous public statements saying "it would be almost ready soon" over the course of several years now: https://wiki.flightgear.org/PUI#Replacement_status

Realistically, the Qt based replacement isn't going to be available to all end-users as long as Qt5 is required to remain an optional dependency because some core developers say so: https://wiki.flightgear.org/FlightGear_ ... Background

That is why some aircraft developers have begun using Canvas based aircraft specific dialogs, to shield themselves from any significant changes in the UI department (with others simply using Phi).

Specifically, a number of core devs stated explicitly that the integration:

the inner circle of core developers wrote:https://sourceforge.net/p/flightgear/ma ... /34532040/
it should be made clear that Qt will always remain an optional dependency.

https://sourceforge.net/p/flightgear/ma ... /34532040/
There is 100% agreement that FlightGear will never require Qt

https://sourceforge.net/p/flightgear/ma ... /34196458/
When the launcher was introduced, there were significant divergences of opinion regarding whether it was appropriate to require the dependency on Qt; the core developers concluded that it was undesirable, unless it had a specific benefit. Since, for the time being, Qt is only needed for the launcher, it has been made an optional dependency, and people can continue using other frontends should they wish so.


There also is the additional fact, that the PUI replacement is really only being worked on by single contributor - who happens to be the primary FlightGear core developer, too. In other words, that developer has plenty of stuff on his todo list. And the Qt5 based PUI replacement has never been shared, let alone completed, despite that developer being a professional Qt developer.
Behind the scenes, a number of folks have shared that the Qt5 replacement has been put on hold, since there are more urgent issues that need to be solved at the moment.

It's also been observed build issues (compilation problems) reported on the devel list are regularly related to Qt5 and dependency issues.

Also, if you look at the commit logs you will see, James himself has been committing stop-gap solutions by extending/fixing the PUI integration "for now" (well, for the last 5+ years). Thus, I wouldn't hold my breath - fgdata level improvements that get rid of PUI by using Canvas are almost certainly going to be welcomed - especially as long as it's unclear if/when the Qt5 replacement is going to be "ready".

For all the nitty gritty details and historical background, see: https://wiki.flightgear.org/Howto:Proce ... ing_Canvas

Furthermore a number of senior contributors are concerned about the fact that using Qt in conjunction with multi-threaded OSG apps is generally frowned upon, and at times even discouraged, on the osg-users list, e.g. by the OSG project lead himself (Robert Osfield):



Robert Osfield wrote:https://groups.google.com/d/msg/osg-use ... SD3DlPAAAJ
The threading models that the OSG
provides reflect this, enabling threading of the update, event and
cull traversals in parallel with the draw thread. This is all
possible with a Qt based viewer, but different versions of Qt add
their own caveates/problems. If you care a about full screen
real-time performance then Qt probably isn't the best tool to use,
native osgViewer based viewer will work much better, but if you need
the 2D GUI elements that Qt provides then you'll need to jump through
the extra hoops that Qt throws into the mix.


https://groups.google.com/d/msg/osg-use ... _2gPlZAwAJ
Unfortunately Qt has created a
series of problems on the threading front that we've had to try and
work around, Qt then goes and moves the goal posts though between
releases. it's been a real pain to try and keep osgQt working well
over the years. If you don't need a traditional 2D UI then it's
generally best to avoid Qt as it causes problems because it has it's
way of working that doesn't fit well with the needs of real-time
visualization.


(It's also worth noting that Robert has been making these statements despite KDAB (James himself) showing up on osg-users to help improve OSG/Qt5 integration)

If in doubt, check back with the developer's mailing list - but according to the most recent "release plan", the Qt5 based PUI replacement is no longer on the roadmap at all, despite it having been created/drafted by James himself: https://wiki.flightgear.org/2022.X_Release_plan

So it's probably best not to put too much additional pressure on the whole Qt5 effort by telling end-users it will be ready "soon" unless James explicitly says so himself; the PUI/Qt5 replacement is already approaching the HLA/RTI "pie in the sky" dilemma we've been watching for another decade - so, let's try to learn our lesson here, after all this is a volunteer-based project :wink:

PS: See gui.nas for additional PUI based helpers to write text to the screen, which too, could be wrapped by a Canvas helper using the same backend (as per tooltips.nas)
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: Better readability of notifications

Postby wkitty42 » Fri May 21, 2021 7:54 pm

Hooray wrote in Fri May 21, 2021 5:04 pm:That is why some aircraft developers have begun using Canvas based aircraft specific dialogs, to shield themselves from any significant changes in the UI department

i don't know if it is "shielding" or more of "hey, this is neat tech and we can use it for this and this and this so here we go giving it a try to see how well it works."...
"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: Better readability of notifications

Postby Hooray » Fri May 21, 2021 9:33 pm

Well, most people who started using/creating Canvas dialogs did so to address PUI shortcomings, i.e. to work around existing limitations. For the time being, Qt5/QtQuick is obviously not an option. And most aircraft developers tend to state explicitly that they don't exactly enjoy creating UI dialogs - thus, they also clearly state that they don't want to create dialogs for different front-ends (Qt5, Phi, PUI or Canvas) - especially because among these options only PUI and Canvas are actually available already.

Like you said, Thorsten belongs to the camp of people who enjoys the free form nature of Nasal/Canvas based dialogs, and has repeatedly shared his views - but he also said at the same time, that he would rather not have to recreate/update his dialogs once a new UI engine becomes available - which is why using the Canvas makes sense from an aircraft developer's perspective, because the Nasal/Canvas systems are a built-in technology stack that is readily available to all people able to run FlightGear.

And a number of folks have shared the same sentiment: no longer being restricted by PUI's archaic feature set, not being doomed to "wait" for some "soonish Qt5 based UI", while being able to proceed regardless of when or if a different UI engine is provided or not.
Even the core devs have acknowledged repeatedly that, for aircraft-specific dialogs, using the Canvas simply makes sense; and that includes James himself - who stated in that context that he's considering to provide a corresponding Canvas integration to render Canvas contents inside Qt5/QQ2 widgets.
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: Better readability of notifications

Postby danielHL » Sat May 22, 2021 2:03 pm

Hooray, once more - please let this pass! There is nothing -> nothing <- to gain for a new contributor by spamming him with this much information about the history and intricacies of the fgfs gui. Nearly everything you wrote is available somewhere else and if he is interested, he can ask. The rest of us, we are aware of these facts.

If I oversimplified with my initial statement about the state of gui devolopment, it was only meant to shorten the explanations and keep the thread on topic.
danielHL / D-FMPW
danielHL
 
Posts: 280
Joined: Fri May 02, 2014 7:23 pm
Callsign: D-FMPW
Version: next
OS: Linux

Re: Better readability of notifications

Postby Hooray » Sat May 22, 2021 4:45 pm

Ok, let's try to keep this constructive: telling others that their contribution is "in a GUI that is soon-ish going away and no new development on this GUI-Toolkit should be started" is not only extremely misleading given that this very development has been put on hold recently, but especially because it's taken over half a decade for anything to materialize, at a time during which a plethora of interim improvements have been made to the underlying GUI engine - by the very same person who's been working on the replacement.

Thus, I'd suggest to tread carefully at this point - we've already seen a handful of derailed attempts at replacing PUI that were killed by people like you, using the very same techniques :wink:

It should be up to James to announce/share with the community if/when the new GUI arrives (or not).

In other words: PLEASE DO NOT TRY TO KILL OFF PEOPLE's PROJECTS/IDEAS BY REFERRING TO SOME POTENTIAL FUTURE DEVELOPMENT THAT MAY OR MAY NOT HAPPEN/SUCCEED :lol:

Regardless of that PUI related improvements, especially at the fgdata level, remain entirely relevant to the majority of our end-users, for the simple reason that there's no holistic plan whatsoever, to deal with end-users who cannot afford a Qt5-enabled binary, so that they also cannot afford to rip out PUI as long as they want to have an in-sim UI experience.

Obviously, that needs to be addressed sooner or later, given that most core devs are actively working towards OpenGL core profile adoption - however, in the meantime, PUI is there to stay, and has been around for far too long to be simply ripped out by someone.

For reference, here's another "recent" forum posting suggesting to port/update PUI, and that topic, too, got killed off because the Qt5 port seemed to be available "soonish" (and that was 2 years ago):

GL2PUI
xcvb wrote:Since there are obviously no plans to get rid of PUI soon, I wondered if it would be a good idea to port PUI to OpenGL2. I'm not really an OpenGL expert, but at least I could get something working:

Image

Currently only the border is painted with OpenGL2 (I added pattern effect in the pixel shader).

Now I wonder which is the best solution to proceed:

1.) Stupid idea -> use Qt, PHI or canvas instead
2.) Write a wrapper around glBegin/glEnd functions and map them to OpenGL2 functions
3.) Complete PUI rewrite and make it look a bit more modern (e.g. https://github.com/shi-yan/AssortedWidgets)


PS: The forum is not the right place to discourage people referring to other potential developments that may or may not affect their ideas; we've seen this numerous times over the years, no matter if it's the PUI/Qt5 transition, HLA/RTI or people telling others that FlightGear would be a flight simulator, and not a "space simulator" - sometimes it's important to keep going, regardless of friction and opposition - or we would not have features like the shuttle, or the canvas system, or even the compositor (heck, even a scripted weather system implemented in Nasal instead of C++) - all of which started out as crazy ideas at some point :wink:
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: Better readability of notifications

Postby MariuszXC » Sat May 22, 2021 10:50 pm

Gentlemen,

I was not aware that I was touching upon a topic which, as it turns out, is quite sensitive. My intention was to improve upon something, that is available currently to most 'normal' users. Hence my original suggestion and patch. I had no intentions to 'stir the pot' whatsoever.

Later in this topic I also stated, that I would try to look for a similar improvement to multiplayer chat entries display, however this turned out to be more complicated than I hoped it would be. In theory this small change should be enough:

Code: Select all
--- fgdata/gui/dialogs/chat-menu.xml_orig   2021-05-22 22:28:32.655125303 +0200
+++ fgdata/gui/dialogs/chat-menu.xml   2021-05-22 22:51:22.485300609 +0200
@@ -14,7 +14,7 @@
     <red>0</red>
     <green>0</green>
     <blue>0</blue>
-    <alpha>0</alpha>
+    <alpha>0.7</alpha>
   </color>
   <text>
     <label>0. Back</label>


but it seems, that the underlying vbox does not respect the varying length of displayed menu entries (nor absence of text at some menu levels), resulting in displays as shown below.

Image
Image

I traced gui.popupTip() down to fgcommand() and _fgcommand(), at which point I gave up. This is currently beyond my knowledge of the code.

However, while wading through different files I found something, which to my eyes looks like a possible bug. The original code in multiplayer.nas seems to remove information about registered listeners before they are removed. If my understanding of the code is correct, this small patch should correct this.

Code: Select all
--- fgdata/Nasal/multiplayer_nas_orig   2021-05-22 20:08:42.893697025 +0200
+++ fgdata/Nasal/multiplayer.nas        2021-05-22 23:19:37.349188342 +0200
@@ -655,10 +655,12 @@
             io.write(log_file, "=====  DISCONNECT\n");
             io.flush(log_file);
             io.close(log_file);
-            log_listeners = [];
             log_file = nil;
             foreach (var l; log_listeners)
+            {
                 removelistener(l);
+            }
+            log_listeners = [];
         }
     }
 }


To sum it up, I think that at this point what is left is me mailing a reference to this thread to the devel list :-)
One final question - are emails sent to this list protected from spam bots?
INOP
MariuszXC
 
Posts: 1061
Joined: Tue May 18, 2021 5:38 pm
Location: Europe
Callsign: SP-MRM
Version: 2020.4
OS: Ubuntu 16.04

Re: Better readability of notifications

Postby wkitty42 » Sat May 22, 2021 11:11 pm

i've never received spam from SF scraping... i've been on SF for years and years...
"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: Better readability of notifications

Postby Johan G » Sun May 23, 2021 4:24 am

I do not think I have much of a say, but I would think that if changes are small and with low risk there is no need to discourage or even discard them while waiting for The Next Big Thing(TM), even if it at the moment looks like The Next Big Thing(TM) will happen. Who knows if The Next Big Thing(TM) will happen with the next major release, in half a decade or never. :P
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Some YouTube videos
Johan G
Moderator
 
Posts: 6629
Joined: Fri Aug 06, 2010 6:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 2020.3.4
OS: Windows 10, 64 bit

Re: Better readability of notifications

Postby Hooray » Sun May 23, 2021 8:55 am

I traced gui.popupTip() down to fgcommand() and _fgcommand(), at which point I gave up. This is currently beyond my knowledge of the code.


the way the text/screen handling works is that there are properties used to add new strings to the screen - currently, this is using a dynamic PUI dialog box.
However, using a canvas would be pretty straightforward - all you need to know can be found here:

https://wiki.flightgear.org/Canvas_snip ... t_Elements
Image

Again, it's best to first check back with the developers mailing list before spending time on this - but speaking in general, there's an ongoing trend to re-implement such legacy functionality on top of the Canvas system, this was initiated by James himself (HUD, 2D Panels). And James has still been encouraging contributors to help with that, despite some people disagreeing vehemently yelling from the backseats :lol:

The fact remains, there's ongoing work to unify the 2D rendering back-end by using the Canvas system, most recently James has been encouraging retargeting the 2D panels code to use the canvas as its back-end: https://wiki.flightgear.org/Post_Flight ... #2D_Panels


Once you have the demo stuff working (rendering a text string to the Canvas desktop placement), you can replace the PUI dialog with the corresponding routine.

At that point, you'll have all the flexibility you need.

PS: the tooltips API is using an fgcommand based wrapper. but under the hood, tooltips are still Canvas based using an osgText element (again, this was also all implemented by James originally, who was hoping to get rid of legacy 2D rendering code, while encapsulating the corresponding routines, so that the project can adopt a more recent OpenGL version, and hopefully OpenGL Core profile). With the exception of Canvas.Path (vector drawing via Shiva), all Canvas elements are compatible with OSG 3.6/OpenGL 4.xx/Core Profile - for the Canvas.Path/Shiva replacement, Scott menioned that he's contemplating to use a nanoVG based back-end instead of Shiva. At that point, all 2D drawing going through the canvas system, will be future-proof/safe - regardless of when or if alternate UIs become available or not. If in doubt, check back with the devel mailing list (primarily James, Scott, Stuart, Fernando)
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

Next

Return to New features

Who is online

Users browsing this forum: wlbragg and 5 guests