Board index FlightGear Development Canvas

New Canvas GUI

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: New Canvas GUI

Postby Hooray » Wed Oct 07, 2015 12:12 pm

Thorsten wrote:Sorry, I can't read that into the message. Why can't the in-sim triggered Qt launcher /not/ be optional like the rest of the launcher? It's not like the aircraft center would somehow be crucial functionality necessary to use the sim.


Of course, it already is optional - as is the AircraftCenter - but, please see the full discussion - the whole point was to expose package manager functionality via the GUI.

Originally, that is how the AircraftCenter got created - meanwhile, this is being re-implemented via the Qt5 GUI. And there's also been talk about possibly extending Torsten's web-based Phi UI accordingly.

But the main consensus was that people wanted to establish the package manager as the main mechanism for end-users to "manage" (=download/install, update, remove) aircraft using the notion of 3rd party hangars.

In other words, if the AircraftCenter stops being developed/maintained in favor of a Qt5 (or possibly HTML5)-based version, those people who cannot use a browser/qt5-based equivalent, would obviously be left out of the loop.

Obviously, you don't have to use any package manager functionality at all - and most of us (using git/svn) are unlikely to use it anyway. But it is a rather significant move still, because of the declared goal to establish the package manager as the main mechanism for aircraft deployment for end-users:

http://wiki.flightgear.org/FlightGear_Package_Manager

http://wiki.flightgear.org/FlightGear_P ... ite_note-2
James Turner wrote:Tthe goal here is to almost get rid of a centralised aircraft repo anyway, and have a decentralised development system with the only central point being the aircraft package manager for end users. Then 99% of people never care where the aircraft is stored while it’s developed

The goal is that no one except people working on an individual aircraft should care where it’s developed at all (on GitHub, in a private SVN repo, stored as sheets of paper in a filing cabinet). SCM systems are not distribution/release systems, we’ve simply been using them in that fashion by accident


Equally, reset/re-init functionality is primarily exposed via the AircraftCenter/launcher currently.
You may say, that it is us broken at the moment - but let's assume, it will get fixed, would you want it to be tied to a Qt5 dependency ?

All this is is obviously in stark contrast to Curt's original statement from Feb/2015:
http://sourceforge.net/p/flightgear/mai ... /33451055/
Curt wrote:As we move forward with FlightGear development and future versions, we will be expanding the "in app" aircraft center. This dialog inside flightgear lets you select, download, and switch to any of the aircraft in the library.
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: New Canvas GUI

Postby Thorsten » Wed Oct 07, 2015 12:35 pm

You may say, that it is us broken at the moment - but let's assume, it will get fixed, would you want it to be tied to a Qt5 dependency ?


I don't think the reset functionality will be (doesn't say anywhere at least).

In other words, if the AircraftCenter stops being developed/maintained in favor of a Qt5 (or possibly HTML5)-based version, those people who cannot use a browser/qt5-based equivalent, would obviously be left out of the loop.


Yes.

Which are all users which don't use the stable/nightly binaries or install from Linux distros but compile themselves and don't want Qt5. Unless I'm overlooking something, it's not a large group, and they should be able to manage aircraft packages manually.

I also suspect recent events have dampened the enthusiasm for a decentralized package manager somewhat and re-emphasized the importance of having a central project repository.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: New Canvas GUI

Postby Hooray » Wed Oct 07, 2015 12:50 pm

I don't think the reset functionality will be (doesn't say anywhere at least).

switching aircraft implicitly involves resetting - so that is why I (and others) mentioned it in this context, right now this is indeed only exposed via the AircraftCenter.


Let me re-iterate, I am absolutely not opposed to Qt5 - it's a step long overdue, had certain dependencies been accepted years, we would certainly be in a much better position now.

But right now, we are unfortunately seeing a chaotic situation, where some of the most senior, and most active, contributors regularly make contradicting, and even conflicting, statements with regard to future developments.

Getting rid of PLIB PUI would be good for FG - and it would also be possible to map Qt5 widgets to Canvas/Canvas elements, but right now the situation is pretty chaotic due to all those contradicting statements by core developers.

And like I mentioned, I am not even among those to be affected by the package manager - but what I care about is orthogonality of features added over time, and compatibility between them.

Right now, people developing Canvas based features (e.g. the space shuttle avionics) may not see the repercussions yet - but that is really only a matter of time. With Canvas, it is trivial to reuse features elsewhere - e.g. if you wanted to, your map drawing code could be trivially reused by the tutorial system to show a post-evaluation of the shuttle approach. Equally, the MFD logic could be trivially integrated with the tutorial system for learning/teaching purposes.
And it would even be possible to render GUI widgets on the MFD, or show the MFD in a GUI dialog.
All of this is possible right now, without requiring any modifications of the C++ code.

With a Qt5-based GUI there would be plenty of work ahead -and we should make damn sure that there are no regressions introduced, before phasing out functionality, and flexibility, offered by the existing system.

Your perspective also depends on your own roadmap, goals and priorities obviously - for instance, were you not developing a 70s era spacecraft, but the SpaceShip One (or even just the A380), you might actually want to ensure that the GUI toolkit can be easily used for creating MFDs - and that the underlying system can load/render 3D models, apply shaders/effects to the whole screen (or parts of it), or even just render external camera views to a camera (tail cam).

With Canvas, we have a well-understood mechanism in place to implement those changes using well-defined boundaries, building blocks and interfacing mechanisms.

If the Qt5 effort isn't consciously looking to support these uses-cases, before becoming an established standard, we are sacrificing tons of flexibility and functionality.
Last edited by Hooray on Wed Oct 07, 2015 1:30 pm, edited 1 time in total.
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: New Canvas GUI

Postby Thorsten » Wed Oct 07, 2015 1:05 pm

Somehow you have turned 'we discontinue support for the canvas-based aircraft center' into 'we discontinue support for canvas'. I don't think that's implied, and I don't think that's the plan.

Obviously the plan seems to be to confine Qt to the GUI/launcher - so I can't see how it has any relevance for MFD use cases.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: New Canvas GUI

Postby Hooray » Wed Oct 07, 2015 1:27 pm

You are misunderstanding: Modern MFD avionics do have the need to render modern GUIs, including stuff like buttons, checkboxes, labels etc - with the AircraftCenter (pure Canvas) approach that is straightforward to support, because we can trivially create a map (like you have done) and show that on a cockpit display, but we could also render the whole thing to a button widget, and display the button elsewhere, including a cockpit.

So there is a relationship that may not be obvious to you given your own focus/priorities (i.e. 70s style avionics on the space shuttle) - but other aircraft developers actually do need to be able to use/reuse Canvas-based functionality elsewhere, including the option to render a GUI on a Canvas MFD, or to dsplay a fully-functional Canvas MFD/layer on a GUI widget.

It is technically possible to integrate Qt5 with Canvas, i.e. to register Qt5 widgets with Canvas and map events accordingly, but also to allow a Canvas to be a Qt5 widget at the same time - but due to the way the integration is currently set up, this is not going to be an option anytime soon obviously.

The reason why I added the screen shot showing the airport/runway widget in the Qt5 launcher is that we already have such a Canvas-based feature, but there is zero code reuse taking place - which is primarily because of the technical challenges ahead involving the integration/interfacing between Qt5<->Canvas due to the way the Qt5 GUI is integrated for the time being, and due to the fact that Nasal (and thus its Canvas bindings) are currently unavailable when the Qt5 launcher is running.

So there is a very clear relationship here, even though it may admittedly only become obvious once you have looked at the underlying C++ code.

Thus my concern is not that we are discontinuing Canvas, but that we are sacrificing existing flexibility without also first making sure that existing use-cases can be satisfied using the new Qt5 launcher.

Like I said, you can only really understand the relationship here once you look at the repercussions of using Qt5 elsewhere, without it also having a way to 1) show Canvas widgets, and 2) allow Qt5 widgets to be instantiated/used via Canvas. Absent that, we are approaching exactly the situation/dilemma I outlined above.

the plan seems to be to confine Qt to the GUI/launcher - so I can't see how it has any relevance for MFD use cases.


again, in layman's terms: modern avionics (aka MFDs) need a way to use/display GUI widgets and respond to events. Right now, Canvas is the only way to accomplish this. Equally, people want to be able to reuse their MFDs and show them in dialogs - either for post-analysis (think you trajectory map being shown in a GUI dialog for flight analysis) - as soon as we begin using the Qt5 UI (with the declared goal of getting rid of PUI!), we are losing all the flexibility to make this happen.

Which is exactly the reason why the Qt5 GUI isn't using any Canvas functionality right now, but duplicating functionality existing elsewhere (namely the runways widget/layer).

With properly-integrated GUI solution accessible via Canvas, you could even support GUI-based editing/creation of MFDs and other displays without too much work (which doesn't exclude Qt5 at all, but just requires it to be exposed to Canvas and vice versa).

So there is going to be an increasing disparity between various GUI solutions and what is going to be "possible", because of all this chaos.

If you don't understand/share this standpoint now, feel free to quote me and revisit this discussion 5+ years from now 8)
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: New Canvas GUI

Postby Thorsten » Wed Oct 07, 2015 2:29 pm

Right now, Canvas is the only way to accomplish this


And, since the Qt functionality will be a platform independent replacement of fgrun, so it will remain.

as soon as we begin using the Qt5 UI (with the declared goal of getting rid of PUI!), we are losing all the flexibility to make this happen.


Methinks you're confusing the launcher with the in-sim functionality here. All statements I've seen talk about the launcher - so James' new idea is to create a button which brings the equivalent of FGRun on screen so that you can manage aircraft.

What that has to do with trajectory management, display etc. remains a mystery to me.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: New Canvas GUI

Postby Hooray » Wed Oct 07, 2015 3:05 pm

"new ideas" are all over the place, with many of those contradicting what other core developers have stated previously, including even the most recent trend/developments, and statements.

I can assure you that I am not confusing anything, I am familiar with the C++/Nasal code involving Canvas and I have looked at the Qt5 code.
I know exactly what it can do, and what it can't - which applies to both "modules".

And I am also familiar with the main use-cases of "a GUI" in FG, including the avionics use-case on modern airliners/MFDs.

But you only need to look at the history of these efforts to see how they got inspired and how they are very much overlapping, e.g.:

  • Core developers have been wanting to update/replace PUI for the better part of the last decade (see comments made by e.g. James and Stuart in the devel list archives with the "PUI" keyword)
  • Canvas got implemented to implement a consistent framework to satisfy all 2D drawing needs without requiring a recompilation of FG: http://wiki.flightgear.org/index.php?ti ... ldid=43497
  • Subsequently, Zakalawe and others agreed to establish/use this approach for also updating the existing legacy GUI: http://sourceforge.net/p/flightgear/mai ... /29588419/
  • The AircraftCenter got implemented to provide a GUI front-end for the package manager, but also to allow switching aircraft: http://wiki.flightgear.org/Aircraft_Center#Background
  • Curt announced that the AircraftCenter would be extended to also support switching aircraft at run-time: http://sourceforge.net/p/flightgear/mai ... /33451055/
  • F-JJTH started porting other PUI dialogs to Canvas to help get rid of PUI using the AicraftCenter as reference: http://wiki.flightgear.org/Aircraft_Cen ... _.28WIP.29
  • the Qt5 launcher got created to get rid of the plethora of 3rd party launchers and to provide an integrated launcher: http://wiki.flightgear.org/The_FlightGe ... _Situation
  • other core developers stated quite clearly that Qt5 would never going to be a build time dependency, that it would only be used for optional, non-critical, functionality.
  • subsequently, people announced that they also wanted investigate phasing out PUI (our legacy GUI engine, which is far from being optional) - using Qt5
  • F-JJTH got eMails and PMs from other core developers telling him to stop pursuing his "global Canvas UI" efforts, because a Canvas-based UI "would be a dead-end", and because there would be a Qt5 replacement for PUI in the works, to be released "soonish"
  • core developers announced that the consensus reached during a google hangout session was that creating a widget/UI toolkit from scratch (using Canvas) was deemed unnecessary and adopting Qt5 would be favored instead.
  • James begins adding/re-implementing functionality already existing in Canvas space to the Qt5 launcher (namely, an airport/runway layer)
  • Stuart posts a draft for an updated project roadmap, stating that PUI is to be replaced with Qt5: http://sourceforge.net/p/flightgear/mai ... /34183645/
  • 10/2015: the aircraft center is declared "an experiment" that is unlikely to be maintained and a new Qt5-based equivalent is announced, which -ironically- is also declared "experimental", but which will obviously require a fairly significant dependency.

So, yeah - there certainly is a "mystery" involved here, and it has more to do with what people (core developers) are agreeing on, and working towards, than specifically what I said.
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: New Canvas GUI

Postby Thorsten » Wed Oct 07, 2015 3:14 pm

As explained elsewhere, we don't even have the manpower to clean out obsolete shaders. Do you honestly think someone would be insane enough to implement something that renders airplanes defunct all over the place? And do you honestly think the rest of the developers would go along with that?

All I can see is James does what he stated he would do, i.e. create a QT5 launcher, and move functionality (aka aircraft switching) which belongs to a launcher and not to a sim to the launcher.

You can of course read more into this if you like, but I see no evidence.

And as usual, things go where the manpower is.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: New Canvas GUI

Postby Hooray » Wed Oct 07, 2015 4:01 pm

sorry to say that you are still not seeing the whole picture, and all the contradictions, unfortunately.

Given your last posting, I understand your perspective - but like I said, I am not the slightest bit opposed to Qt5 or modernizing dependencies (in fact, I'd claim that I would be up and running with a working build system faster than you'd be).

I never stated anywhere that this development would render airplanes "defunct all over the place", but there is something going on here that is completely eluding you, despite the surrounding context I posted above.

I guess you have to be into modern airliner/MFD development using GUI widgets to actually understand the repercussions of 1) telling Canvas contributors to stop coming up with their own widget set and to stop porting other PUI dialogs to Canvas, and 2) to see Qt5 being adopted for the launcher, and 3) to see discussions about phasing out the legacy GUI engine (PUI) in favor of Qt5.

Right now, we are approaching a situation where a tons of contradicting ideas and statements are made, including even in the "project roadmap" despite what is going on in reality, i.e. the git commit logs.

And this is not exactly a manpower issue as long as people consciously kill off competing efforts by sending out messages telling other contributors to stop "wasting their time" working on Canvas related features, due to other ongoing work - no matter if that means Qt5 or Phi-based additions.

If you were more involved in this, beyond shuttle avionics, you would realize that this is very much akin to someone (some core developers) stating that LW/AW is to be discontinued in favor of a new hard-coded system, at the cost of introducing a major external dependency - while contemplating to phase out support for certain key functionality (mutual compatibility) altogether, because the new system doesn't work too well with JSBSim for example.

Frankly, people should not expect for all this chaos to be embraced too well, given all these contradicting statements within such a short timespan. Given the quotes I pulled out from the archives, it is obvious that even core developers are confused themselves - I applaud you for seeing things differently, but then you are obviously among a minority of contributors - including even those with core commit access, and those involved in the Qt5/Canvas efforts.

Which is why I would politely suggest that you are missing the whole picture here, despite appreciating your comments, because they support the notion that even experienced contributors are very confused when it comes to the situation revolving around Qt5 and Canvas, and how things are unfolding in the time to come.

Thus, thanks for helping me make my case :wink:

(if you still think, your analysis is correct - it certainly doesn't match comments made on the devel list, commits made to the git repo or the updated project roadmap)
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: New Canvas GUI

Postby Thorsten » Wed Oct 07, 2015 5:30 pm

And this is not exactly a manpower issue as long as people consciously kill off competing efforts by sending out messages telling other contributors to stop "wasting their time" working on Canvas related features, due to other ongoing work - no matter if that means Qt5 or Phi-based additions.


Oh my - if I had gotten a $ every time someone told me to stop wasting my time be coding AW or ALS, I'd be rich by now. And look - they're both still there. Because I didn't care.

Consciously killing competing efforts takes quite a bit more.

If you were more involved in this, beyond shuttle avionics, you would realize that this is very much akin to someone (some core developers) stating that LW/AW is to be discontinued in favor of a new hard-coded system


I guess I've heard that one a few times as well. Um... AW still there.

Face it, people don't mince words, they say what they think - it doesn't mean it becomes gospel. Just because I think some things a waste of time doesn't mean they're not done.

I guess you have to be into modern airliner/MFD development using GUI widgets to actually understand the repercussions of 1) telling Canvas contributors to stop coming up with their own widget set and to stop porting other PUI dialogs to Canvas, and 2) to see Qt5 being adopted for the launcher, and 3) to see discussions about phasing out the legacy GUI engine (PUI) in favor of Qt5.


Maybe.

Or maybe I just basically trust that discussing with TorstenD, James or Stuart, reasonable results can be reached. Worked out so far.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: New Canvas GUI

Postby Hooray » Wed Oct 07, 2015 5:42 pm

Thorsten wrote in Wed Oct 07, 2015 5:30 pm:Or maybe I just basically trust that discussing with TorstenD, James or Stuart, reasonable results can be reached. Worked out so far.


yes, in theory, that sounds all great - while in practice, this is how we have arrived at the current stuation, despite having semi-regular "Google Hangouts", where the "consensus" is pretty well summed up by my list of postings/quotes with contradictory statements, referring even just to those made by core developers, including the ones you mentioned by the way.

In fact, we have had people, like TheTom, working on Canvas GUI support (e.g. via the Aircraft Center) specifically in response to those very discussions.

So maybe things are not quite as simple as you make them sound, given that even all those core developers tend to make contradicting postings despite talking about the same issue, i.e. Qt5 adoption in FG, and the future of the native FG GUI in FG, no matter if that involves PUI, Canvas, Qt5 or yet another GUI library.

I can see, and appreciate, what you are trying to do here, but frankly, you are missing tons of context, which is getting more and more obvious.

To be fair, even Stuart's and Curt's comments seem meanwhile outdated/obsolete, based on what's going on in the commit logs and the devel list. So you are certainly not alone. :)
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: New Canvas GUI

Postby Thorsten » Wed Oct 07, 2015 5:51 pm

Since I am too clueless to see the conspiracy and just a naive trusting fellow, I guess we leave it here.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: New Canvas GUI

Postby Hooray » Wed Oct 07, 2015 5:58 pm

thank you, good call - but I never said anything about a "conspiracy", which is why your line of reasoning isn't quite appropriate anyway. We do have a problem ahead of us, which involves updating the GUI engine in FlightGear.
This is overlapping with the effort to integrate Qt5 functionality through a launcher.

If, how and when this begins to overlap with Canvas/GUI support will only be obvious once you have seen a few use-cases where mutual support/integration of the built-in GUI, and the Canvas system, is a necessity.

Indeed, we kinda are at the cross-roads here - because people want to use a more modern UI in FG, but core developers have come to the conclusion that they only want to accept Qt5 as an optional dependency in a dedicated "FGGUI" module - which only leaves us with PUI and the Canvas system for modernizing the GUI, despite tons of conflicting statements, including even the updated project roadmap that is currently being drafted.

Once there really is an actual consensus, which materializes in the form of commits integrating "the new UI" with the Canvas system, and vice versa - the major impact that this will have on FG should become pretty obvious even to people not involved in the UI/Canvas efforts, especially in terms of modularity and code reuse, i.e. widgets being accessible to Canvas and Canvas textures being 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: New Canvas GUI

Postby wlbragg » Wed Oct 07, 2015 8:26 pm

Indeed, we kinda are at the cross-roads here - because people want to use a more modern UI in FG, but core developers have come to the conclusion that they only want to accept Qt5 as an optional dependency in a dedicated "FGGUI" module - which only leaves us with PUI and the Canvas system for modernizing the GUI, despite tons of conflicting statements, including even the updated project roadmap that is currently being drafted.


I think this is an accurate assessment.

Just look at the originating date of this thread. "I" am no more clear on exactly where we are heading, in fact it has flat-lined or even gone backward.

Not a conspiracy, just a bunch of competing and conflicting ideas by some core individuals.
Maybe it is nothing more that the people working on it being to slow, or they themselves decided the hurdles are to great.

I just hope someone, motivated enough, will step up and make it clear which way to go by doing it and then by enough people adopting it, just like everything else that has been implemented in this project has occurred.

This last thought was not meant to be a negative statement, but wishful thinking.
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: New Canvas GUI

Postby punkepanda » Wed Oct 07, 2015 9:33 pm

This is not the first time Thorsten labels other reasonable forum members as conspiracy theorists while they actually just try to say that the way of the core development at the moment does not work effective enough.
And if we think for how long this old PUI been the main GUI it is also reasonable to assume that someone is making an effort to win this GUI competition.

Remember that the word conspiracy(was invented by us media when investigating the WaterGate scandale(which turned out to be a "conspiracy")) is a quite new word from the word conspirator, which means two or more people agree to accomplish a goal against it competitors. So any reasonable person is therefor also allowed to even use the word in a discussion when they're meanings seems outnumbered by core/elite of this project!

Why not make a vote system! Then cooperate to make the best out of the sollution that get most votes and stop this childish competition / conspiracy discussion who will get anything but fustration and irritation in the whole community.

I vote for Canvas because it is proven to work inside the simulator. I hope there will be theme support for it too.
punkepanda
 
Posts: 234
Joined: Mon Nov 04, 2013 10:11 pm
Callsign: LostFlight
Version: 2.12
OS: Arch Linux

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 3 guests