#Progression bar on gsx menu opening
1 messages · Page 1 of 1 (latest)
There would be a way, but GSX does not offer that in the menu.
I'm showing the progress of loading/fueling on my Streamdeck because GSX is updating SimVars that indicate the progress of it. And I do that for exactly the same reason - I don't want to have constant message popups to clutter my screen and ruin screenshots.
So if you have a Streamdeck, maybe that'd be something for you. But I agree that having these values shown in the menu would be nice (and probably not hard to implement as the data is there).
The progress bar that was added a few updates back is just for the initial loading progress, so that is not related to any service, it's just the loading screen showing some more details for people to be patient.
Having a progress updated in real time has a cost in performances, because the menu would need to subscribe to the html window refresh, which forces Coherent updates as if it was another extra instrument running, and the additional overhead of having to constantly poll all GSX progress LVars, which is not free of cost.
You're arguing against your own set up claim.
Noone asked to have a progress bar that is updated real time. It's totally sufficient to get the current state when opening the menu and showing it, the menu will close very quickly anyway, so no need for "real time" updates on the progress.
What "You're arguing against your own set up claim." even means ?
I haven't "claimed" anything, I just assumed the only progress bar that would be useful would be a dynamic one: what would be the point of having one that is not updated until you close and open the menu again ? And no, some menus like the main one have longer timeouts of 30-40 seconds.
If it's ok having a static update, we can do it easily, I just don't see much value in it but, of course, whatever... it doesn't cost much to add it.
I'm pretty sure you can make it work in some way just like the message popups in upper left corner do too. Those are also updating in some interval, should be possible the same way in the menu.
Reading a feature request, then building up the best possible solution and then immediately dismissing it because it won't work isn't constructive. If a user requests to see the progress in the menu, just think about how you could make it work even if there are limitations...
Users don't have the limitations in mind, but your first reply would mean that you won't implement anything and I don't think that's appropriate given there are other options than the one you drafted.
Those are also updating in some interval, should be possible the same way in the menu.
Completely different method, zero effect on performances. They are not refreshed constantly, they are only created and removed after a timeout notification, not through the javscript window refresh handlers.
Reading a feature request, then building up the best possible solution and then immediately dismissing it because it won't work isn't constructive.
And again, I just assumed with "progress bar", it meant what progress bars usually do: refresh constantly. I couldn't even think anybody would find useful a static progress bar that would require closing/opening the menu again JUST to see if it's "progressing". But of course, I guess that is better than nothing.
you can also just show numbers, no need for a bar, whatever works to show the progress at the time of menu opening to the user 🙂
The point is not to see if it is progressing but to see how far the progress is. Basically the same reason as you are showing popup messages on the boarding progress etc. just that it's up to the user when they want to check it instead of the constant message popups.
Let me draw something, brb
Of course I'll show numbers, a progress bar that doesn't progress doesn't make much sense anyway.
Something like this, just show the 3 status upon opening:
Certainly there's a nicer way but you'd make use of the space not making the menu vertically longer
Maybe even swap positions of progress and those dark gray buttons (left<->right) because the buttons are usually of less relevance if GSX runs fine and users have profiles installed.