Get rid of default UI

[gajop]

btw, I also do "Clock 0" - not sure if needed
https://github.com/gajop/IngameLobby/bl ... by.lua#L14
Didn't have the fps one though

[8611]

For more crap about hiding stuff and minimap options see
viewtopic.php?f=10&t=33234

tl;dr:
"hideinterface" is most pro and how chili hides everything when the default GUI is turned off is imo 'bug/wrong/missing config option' and the other ideas simply seem like workarounds for that.

[8611]

A thread about long cats because there is no spoiler tag.
---

viewtopic.php?f=23&t=33190&p=567220#p567220

I see "hideinterface 1" similiar as other commands:
Common usage is to turn something off so that a widget can draw its own custom version.
/resbars 0 for resource displays.
/console 0 for chat widgets.
etc.
Sometimes one might want to turn off and custom-draw everything (for menus or game-over screens) and for such cases "hideinterface 1" is imo perfectly okay.
Also easier to reset everything to its previous state.

gl.ConfigMiniMap(0,0,0,0) will work but leave a small group of pixels

If in slave mode the pixels could be drawn manually;

Those pixels are the border of the minimap. It remains visible even when the minimap is "zero-sized." It is just a small unwanted artifact, why manually red-add it when goal was to get rid of the minimap.

"slaveMode" fixes that because it disables drawing the border (together with all other drawing)
Game/GUI/MiniMap.cpp

Code: Select all

void CMiniMap::Draw()
{
	if (!slaveDrawMode) {
...draw stuff here...
}

Is it basically a configuration that says the minimap appears in the rectangle (0,0), (0,0)?

No: first 2 numbers are coordinates and last 2 numbers are size.
https://springrts.com/wiki/Lua_OpenGL_Api#Spring

rts/Lua/OpenGL.cpp

Code: Select all

int LuaOpenGL::ConfigMiniMap(lua_State* L)
{
...	const int px = lua_toint(L, 1);
	const int py = lua_toint(L, 2);
	const int sx = lua_toint(L, 3);
	const int sy = lua_toint(L, 4);
	minimap->SetGeometry(px, py, sx, sy);

Game/GUI/MiniMap.cpp

Code: Select all

void CMiniMap::SetGeometry(int px, int py, int sx, int sy)
{
	xpos = px;
	ypos = py;
	width = sx;
	height = sy;

It seems one can set it to (-1,-1), (-1, -1)

Can even set it to (-1000,-666) but think it will not do much good?

Code: Select all

CMiniMap::UpdateGeometry() {
...
width = std::max(1, std::min(width, globalRendering->viewSizeX));
height = std::max(1, std::min(height, globalRendering->viewSizeY));

So smallest size seems actually to be (1,1) and not (0,0) but maybe that just to more clearly express: "I want this gone."

With position (0,0) minimap is not completly in lower left corner because it leaves space for buttons. (MiniMapButtonSize in springsettings)


There is more stuff like "endgraph 0" or the /sharedialog (H) and /quitmenu. (shift ESC)
Think those can not be hidden at all, can only block to open it.

Some commands like "info 0" save settings, that can change preference of user.

tl;dr
How chili hides everything when the default GUI is turned off is imo 'bug/wrong/missing config option' and the other ideas simply seem like workarounds for that.
Some things are not meant to be hideable but that should be decided by the widget, not by the framework...
(What use does it have if user can press F5 in a menu to make all the buttons disappear? So random!)

[Funkencool]

How chili hides everything when the default GUI is turned off is imo 'bug/wrong/missing config option' and the other ideas simply seem like workarounds for that.
Some things are not meant to be hideable but that should be decided by the widget, not by the framework...
(What use does it have if user can press F5 in a menu to make all the buttons disappear? So random!)

"hideinterface 1" does not "turn off the default GUI", it hides the interface(widget or engine); Because players sometimes like to hide the interface. It's a function that already has a purpose.

I agree that the workarounds aren't ideal but this would be better pursued as a request for "engineUI 0" or similar; Not re-purposing a long used function. That is just another workaround.

[gajop]

I'd be more interested to hear about this:

There is more stuff like "endgraph 0" or the /sharedialog (H) and /quitmenu. (shift ESC)
Think those can not be hidden at all, can only block to open it.

Some commands like "info 0" save settings, that can change preference of user.

What else is there? How can one block it being opened? What other commands set user preferences, and how can this be avoided?

[gajop]

Let's not have the same discussion in two threads. (Locking and merging..)

[gajop]

this would be better pursued as a request for "engineUI 0" or similar

Agreed, and actually would be cool to have a simple way (command or Lua function) that turns off (on) all engine UI.

[Funkencool]

I'd be more interested to hear about this:
What else is there? How can one block it being opened? What other commands set user preferences, and how can this be avoided?

From what I know; you simply disable the hotkey or "action". Then replace it with your own lua function.

Something like this

Code: Select all

function widget:Initialize()
  local openWidgets = function() 
    if window.visible then  window:Hide() else window:Show() end
  end

  -- unbind hotkey from default (or other widget?)
  Spring.SendCommands('unbindkeyset f11')

  -- create an action
  widgetHandler.actionHandler:AddAction(widget,'openWidgets', openWidgets, nil, 't')

  -- bind action to hotkey
  Spring.SendCommands('bind f11 openWidgets')
end

[8611]

this would be better pursued as a request for "engineUI 0" or similar

Agreed, and actually would be cool to have a simple way (command or Lua function) that turns off (on) all engine UI.

"hideinterface 1" is already excactly that and has always been used for that.

Imo only reasons it is not named "engineUI" are of historical nature:
"resbars 0" does not mention the engine either, but it is implied that it is "engine_resbars" and "engine_tooltip" and "engine_console" and so on.
In same way it is also "hide_engine_interface"
Not the first spring-things to have slightly bad naming.

Many widgets use isGUIHidden() to set their visibility.
But that is not nessecary to base that on an engine setting, it is just convenient. Could as well have some WG.showMyLuaInterface variable or use the Hide/Show functions of chiliUI.

Because players sometimes like to hide the interface.

So far that is the only arguement but it is pretty weak and only applies to things like build-menus that one might want to hide for screenshots or videos.
But for normal menus (Options etc) that does not apply because there simply is no use to open a menu and then disable its drawing by pressing a button on keyboard.
It makes no sense to do that or to allow that...
Instead to hide/close a menu the player should use the close-button of the menu.

I'd be more interested to hear about this:

One way to block sharedialog or other menus is by unbinding their hotkeys.
Spring.SendCommands("unbindkeyset Any+h sharedialog")
Or read the players hotkeys config and then block the Keyboard-event callin (KeyDown() or whatever)

Should it be possible to close the menu might also look at ways to save the settings so it is possible to return the GUI to playing state. Spring.GetMiniMapGeometry etc..

To put it different:
Which part of the engine's GUI would you NOT like to disable?

[Funkencool]

Make a pull request
https://github.com/jk3064/chiliui/blob/ ... _chili.lua
If a chili maintainer agrees with you he will accept it.

[gajop]

"hideinterface 1" is already excactly that and has always been used for that.

We obviously disagree here. The below discussion is therefor a moot point.

So far that is the only arguement but it is pretty weak and only applies to things like build-menus that one might want to hide for screenshots or videos.
But for normal menus (Options etc) that does not apply because there simply is no use to open a menu and then disable its drawing by pressing a button on keyboard.
It makes no sense to do that or to allow that...
Instead to hide/close a menu the player should use the close-button of the menu.

Hiding the interface for screenshots/videos is important and something we don't want to lose. While this option might be disabled for standalone lobbies (and maybe while in the options dialogue), it shouldn't be disabled for normal gameplay (which is where most of the interface is).

To put it different:
Which part of the engine's GUI would you NOT like to disable?

I'd say everything, or everything except the command interface (thingy that pops up when you press enter and allows you to enter commands).
The effect we want to achieve is probably similar to "hideinterface 1" internally with isGUIHidden() being false in Lua.

[8611]

The enter-text-thing stays functional with "hideinterface 1"
Just the console history/suggetions are ofc gone but if you already did "console 0" like in edited first post, then no change and can be Lua'ed.

Instead of changing engine (behaviour of Spring.isGUIHidden() or introducing new function) it seems more flexible to make your own isLuaGUIHidden() check.
Put it in global WG space thingy so all widgets can read it.
Or put it into chili as chili.isGUIHidden()

Hiding the interface for screenshots/videos is important and something we don't want to lose. While this option might be disabled for standalone lobbies (and maybe while in the options dialogue), it shouldn't be disabled for normal gameplay (which is where most of the interface is).

Each widget can still decide when to show or hide. A build-menu widget would hide itself if a screenshot is taken.
I can imagine some things where a game might want to clean the screen of all engineGUI but keep some small things always on screen. For example an always-visible "return to normal mode" or "Help" button in some corner.
Or a menu with animated action playing in background.
It is up to the widget or game to decide how to handle that but atm it is lost functionality.

Imo once the user enters certains menu the gameplay has stopped or paused, then there is no use in trying to take "pimped" screenshots.