Please allow spawning UserWindows as tabs

[jcsanady]

Currently you can drag and drop UserWindows onto one another to create a tabbed window, but there doesn't seem to be a way to spawn them like this.

Version 4.9.1

[itsTheFae]

This should be possible to implement via the use of QMainWindow::tabifyDockWidget

@Mudlet/lua-interface should this be implemented as an argument on the existing lua function or as a new lua function?

[vadi2]

I'd say existing.

[demonnic]

agree, existing

[SlySven]

Do we have a function to float/dock user windows already - (I believe there is - or there should be - an option for that in the current openUserWindow(...) - though that treats the dock area as an option whereas it ought to be compulsory {or default to right dockwindow area} because it would be needed if another function was available to dock a window created as floating) - I guess not! Therefore a new function should be considered that can not only dock a floating window but say whether it should be docked to the same space as an existing docked window. This will need some code checks to see that the conditions that are being requested are achievable:

:thinking: How about having a separate pair of functions to avoid complicating the existing creation function: setUserWindowDock((string) thisWindowName, (int)mode [, (string) otherWindowName]) where:

• mode = 0 or false - float - remove thisWindowName if it is docked and return true if that was achieved or nil + error message {e.g. user window not found / user window not docked)
• mode = 1/2/3/4 not sure about 2 dock a floating thisWindowName into the corresponding dock area - which I think corresponds to top/bottom/right/left {need to check the existing openUserWindow(...) options} - or move the docked window either if it is on its own or tabified with others into being individually docked in the specified area - and return true if that was achieved or nil + error message if not - including if it was already docked in THAT area on its own.
• mode = -1 or true - dock and tabify a floating or move an already docked thisWindowName into the same space as but AFTER the otherWindowName whether that is already tabified or not {though it itself does have to be docked} - and return true if that was achieved or nil + error message if not - including if it was already tabified with otherWindowName or otherWindowName doesn't exist or is not docked.

getUserWindowDock((string) thisWindowName) returning a table:

• {docked = true / false, group = {list of windows in tabGroup, including thisWindowName, in tab order}, current = luaIndexStartingFrom1} - group is an empty table if the window is floating or docked on it's own - it is only populated if the window is tabified - current is only present if the window is tabified and gives the index of the current tab in the list that is active.

I cannot recall but there is - or there is a desire for - functions to set the size and position of floating (undocked) user windows and if that functionality is separate from the creation code (it might not be) then that is likely to be wanted to be used after an existing window is undocked by the use of the above setter function. OTOH a function to get the SIZE of a user window in pixels NOT characters (as that is too font dependent) can be usable in both docked and floating states whereas one to get the POSITION of a user window only really works for a floating/undocked window...

[itsTheFae]

Mudlet already supports some dockingArea features in the openUserWindow function parameters. I think the acceptable values would need to be reworked to support this feature. While I like the idea of moving the more specific logic to their own functions, I don't know what the best method would be for creating a new function that both provides new functionality and backward compatible functionality with the existing openUserWindow function for sake of consistency of the functions and their parameters...

The values allowed for dockingArea parameter are: t b l r f top bottom left right floating according to the code and documentation.

I was initially thinking of using the existing dockingArea argument and passing in a prefix/suffix character (maybe upper-case T) to specify a desire to "tabify" spawned windows, if a docked window already exists in the area given. For the "floating" variants, it would be something like T thisWindowName to specify which existing window to "tabify" with, if the window exists.

I don't think my lazy idea is the best solution though.

[SlySven]

IIRC you will have to specify a profile name AND the user window name because the same window name from different profiles can be tabbed together (remember my disappointment about the loss of the profile name from the title-bar) so the window name is not enough to identify other user windows - so we may have to allow two string arguments for that. However if the window to be tabified with is identified and is docked then specifying the docking area is redundant. Also, it is easily possible to have separate groups of tabified windows in the same dock area...

Also, I repeat, floating windows still need to be assigned a docking area for the openUserWindow function! Even if they ARE floating - so the existing creation function needs a redesign - perhaps to assume a right docking area if f or floating is supplied but to be extended to take f/floating/d/docked as an optional further argument.

[itsTheFae]

Is there a way to identify another running host? How do users currently address UI elements from other profiles?

[vadi2]

How do users currently address UI elements from other profiles?

They don't and they shouldn't need to, this is not a usecase anyone has asked for... let's not get carried away with grand, complex designs here.

[itsTheFae]

The easiest route for me is to add a new function then. Something like tabifyUserWindows(name1, name2) which can simply live with the limitation of not being able to "tabify" with UserWindows from outside the calling profile.
This route avoids any extra complication to the already option-packed openUserWindow() function and keeps the new code additions in their own sections.

I've tested the suggested function already, under Windows 10, and can report that the QMainWindow::tabifyDockWidget method only seems to function on UserWindows which are already docked to the main window.

Sly's previous suggestion of additional functions setUserWindowDock and getUserWindowDock may be helpful to users wanting to make full use of the tabifyUserWindows function where windows already exist in an un-docked state. Alternatively we could add another argument to tabifyUserWindows to specify a dockArea value we can translate to a valid Qt::DockWidgetArea and just force the use of the specified or a default area.

[Edru2]

Since Mudlet 4.7 it is already possible to set the docking Area. See https://wiki.mudlet.org/w/Special:MyLanguage/Manual:Lua_Functions#openUserWindow and for Geyser UserWindows (setDockPosition) See https://wiki.mudlet.org/w/Manual:Geyser#Docked_UserWindow

For Geyser UserWindows it is also possible to get the DockPosition by reading the Variable in myUserWindow.dockPosition

Edit: I should have read the previous comments :facepalm: It's still early :wink:

[Edru2]

Also, I repeat, floating windows still need to be assigned a docking area for the openUserWindow function! Even if they ARE floating - so the existing creation function needs a redesign - perhaps to assume a right docking area if f or floating is supplied but to be extended to take f/floating/d/docked as an optional further argument.

That is already the case in the existing function, meaning the right docking area is the fallback if created in floating mode.