Pop-up Mini-Windows?

Post Reply
Tesagk
Posts: 13
Joined: Sat May 28, 2016 12:04 pm

Pop-up Mini-Windows?

Post by Tesagk » Mon Jan 23, 2017 12:02 am

I was talking to Jor'Mox about whether or not we could create mini-windows that were draggable and closeable with an "X" in the upper right-hand corner. Could even do a resize bit in the lower right-hand corner. There are Mudlet functions there to support it, but, when I mentioned using them as pop-up windows (from a trigger or event) it looked to be more difficult and the only code that might support it is in the dev branch.

It would be nice to see some sort of official support for this.

User avatar
SlySven
Posts: 920
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Pop-up Mini-Windows?

Post by SlySven » Mon Jan 23, 2017 5:09 am

It's not quite what you want but don't forget the dockable consoles you get from openUserWindow(<windowName>) - they can be docked or float free of the main Application window and can be hidden with the "X" button and shown/hidden by clicking on them in the (default) context menu (right mouse click on the title-bar of any "docked" dockable item (main menu, main toolbar, mapper in a dock widget, toolbar) - but showing/hiding them can't be done via a script-able command as far as I can tell...

dicene
Posts: 47
Joined: Thu Sep 25, 2014 7:36 am

Re: Pop-up Mini-Windows?

Post by dicene » Tue Jan 24, 2017 6:28 am

I introduced those features in Development for basically exactly that purpose. See: https://vimeo.com/197737882 for an example of the system I'm using now in my own profile I use on a dev build.

Userwindows are still a thing too. The functionality for them is a little lacking in some ways, and it's not documented very well. For instance, you can do most anything that works on miniconsoles to them because they make a miniconsole by the name you assign the userwindow itself, but attempting to move/hide them only moves/hides the console inside the window. No way to move the window itself, or hide/display it from scripts. You CAN hide them by right clicking on certain parts of Mudlet and clicking the unnamed option in the menu that corresponds to that userwindow, but then you can't show it again without doing the same process.

I've got a desire to work on improving userwindows at some point in the not too distant future, I just have a lot of other things that seem more important or more productive since I've got the features to make a better userwindow inside of scripts already put together and approved. Just a matter of how long it takes to make it down the pipeline to a real release.

User avatar
SlySven
Posts: 920
Joined: Mon Mar 04, 2013 3:40 pm
Location: Deepest Wiltshire, UK
Discord: SlySven#2703

Re: Pop-up Mini-Windows?

Post by SlySven » Tue Jan 24, 2017 6:28 pm

Those windows are unnamed (and show as checkboxes with no text on the context menu) because there is no pointerToWindow->setWindowTitle( QString ) in the current codebase. Personally I want to get names (and consistent ones at that) on ALL the dockable widgets (I think I've got them set for mapper ones) but we still need that string to be set on:
  • The main Mudlet tool bar (suggestion: tr( "Mudlet - Main Toolbar" ) )
  • The top and left Editor toolbars - FOR EACH profile if Multi-playing (suggestion: tr( "Toolbar - %1 - %2 ).arg( Host::getName() ).arg( "Editor Action Toolbar" (top) / "Editor Item Toolbar" (left) ) )
  • Miniconsoles ( suggestion: tr( "Console - %1 - %2" ).arg( Host::getName() ).arg( <console name> ) )
  • Floating Toolbars ( suggestion: tr( "Toolbar - %1 - %2" ).arg( Host::getName() ).arg( <toolbar name> ) )
There is some steps taken to suppress the title line on user Toolbars IIRC by specifying an empty QWidget() instance for that role but that was short-sighted IMHO because a toolbar in a module will mean identical toolbars that work on different profiles if that module is loaded into more than one profile active at the same time. Also the current user mini-consoles may have problems if present in a module because there is a global QMap kept that only tracks the mini-consoles in use by the given name and, unless the name given in the openUserWindow is generated to include something to make it different in each profile's instance of it the second and further profiles will fail to create such a window if the code in a module is of the form openUserWindow("Fixed string") rather than something like openUserWindow( getProfileName().." - Fixed string")...!

Of course a mini-console opened by one profile is not accessible by other profiles - they will have to use the (currently in prototype for the development branch) inter-event system to send text or other data to the owner profile of the mini-console should a scripter want to have a "shared" or common mini-console in a multi-playing set-up.

I agreed that the user window creation and control API is currently lacking - we need a way to specify where they are/can be docked (currently allowed anywhere and set to be docked in the right side docking area) and a boolean saying whether they are to be created "docked" or "floating" - of course for the latter we also need to provide setter/getter controls for size and position - and those will need to be desktop related NOT application. Of course using the global desktop size details is a bad thing to do as the desktop may be virtual and composed of multiple screens which is something we do not currently properly handle even for the limited window handling we do (for instance we save the editor size and position - but we use the values as a global setting so if you have multiple profile active the editors are created exactly on top of each other which is hardly ever the right option as far as I can see).

Anyhow I think perhaps I am going far too off-topic there so I'll better stop now...! :roll:

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest