Need some help on sf::Views and building UI stuff

[C with a C]

I just recently started dealing with SFML. and I'm getting a bit confused as I'm building some UI elements. I'm making this post to help myself think, as well as to ask a thing or two about this, and to see if anyone has any helpful suggestions.

I need lots of parts, some fixed and some scrollable. I decided to call them panels. As far as I can think, all the contents of each panels will only ever scroll up/down (except the world map, but that will probably have it's own screen for itself).

So I had to find a way to hide stuff outside each panel, and sf::View seems the way to go. But I wonder, is there's such a thing as too many sf::Views?

In the quick mockup below, the parts that are framed in red (1 and 2) are the main UI stuff, and are fixed and persistent. No sf::View needed there. They'll contain buttons with which I'll be able to navigate through several screens, each with different info about the game (panel 2 is just placeholder, and I probably won't need it).



This is essentially a resource management game, where you run an Inn, so I need various screens to show all the relevant data. This mockup shows just one of those screens, and I have at least six more of them planned.

This one lists all the NPCs that are currently in the house (3) and available for interaction through dialogue (6/7) and inspection (4 - info / 5 - portrait). I'll need lots of sf::Views on the whole, to make the rest of the screens for stock items, hired staff, sales, all the money stuff, perhaps even cooking recipes... Perhaps I should mimic a state-machine for that?

[Hapax]

There doesn't seem to be a logical reason not to use multiple sf::Views for ... multiple views

the parts that are framed in red (1 and 2) are the main UI stuff, and are fixed and persistent. No sf::View needed there.

Actually, you'll need an sf::View that matches the window to display fixed graphics. You 'can' get the view from the window but it might be better to store it for yourself. Just remember to switch to that 'fixed' view before drawing to the fixed panels.

[C with a C]

I was thinking that earlier today. But since those parts are persistent, much like a strategy game's HUD and minimap, I remain divided. Final Fantasy menus were all made of the same things, even the "main" fixed menu, even if they were hidden (not persistent) during gameplay.

I'm still keeping that notion in mind. It might be more convenient to implement, especially because I may still have better ideas that may force me to overhaul the whole thing.
Thanks.

[Hapax]

I was thinking that earlier today. But since those parts are persistent, much like a strategy game's HUD and minimap, I remain divided.

A view is needed to draw at all times, even when drawing 1:1 with the window. You can change the window's view to other, custom views to draw in different co-ordinate systems or to crop them into viewports but a view is always needed, as I mentioned above, even for persistent, fixed overlays.

[C with a C]

Indeed, you're right. I was forgetting the window has it's own default view...