Messing with userwindows

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

Messing with userwindows

Post by dicene » Mon Oct 10, 2016 9:07 am

Due to someone asking what options they had for dragable labels and the like, I started looking around at the code for userwindows to see how much work it would take to get support for moving and resizing userwindows added. Seems like a surprisingly small amount of work, so I'll probably poke around and see if I can't get it working over the next few days.

Question I had when looking through all this. Why are the following functions (lines 94-104 of TLuaInterpreter.cpp) getting assigned with signals/slots when the vast majority of the functions being provided to Lua don't need signal/slot assignment? In addition to that question, if I were to put together functions to show a hidden userwindow(so you don't have to rightclick the gui to re-enabled them), to move a userwindow, and to resize a userwindow, would I need to set up signals and stuff for those? Sorry if these are phrased less than eloquently, but I'm only very vaguely familiar with the concept of signals and slots in the first place.
Code: [show] | [select all] lua
    connect(this, SIGNAL(signalEchoMessage(int, QString)), this, SLOT(slotEchoMessage(int, QString)));
    connect(this, SIGNAL(signalNewCommand(int, QString)), this, SLOT(slotNewCommand(int, QString)));

    connect(this, SIGNAL(signalOpenUserWindow(int, QString)), this, SLOT(slotOpenUserWindow(int, QString)));
    connect(this, SIGNAL(signalEchoUserWindow(int, QString, QString)), this, SLOT(slotEchoUserWindow(int, QString, QString)));
    connect(this, SIGNAL(signalEnableTimer(int, QString)), this, SLOT(slotEnableTimer(int, QString)));
    connect(this, SIGNAL(signalDisableTimer(int, QString)), this, SLOT(slotDisableTimer(int, QString)));
    connect(this, SIGNAL(signalClearUserWindow(int, QString)), this, SLOT(slotClearUserWindow(int, QString)));

    connect(this, SIGNAL(signalTempTimer(int, double, QString, QString)), this, SLOT(slotTempTimer(int, double, QString, QString)));
    connect(this, SIGNAL(signalReplace(int, QString)), this, SLOT(slotReplace(int, QString)));

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

Re: Messing with userwindows

Post by SlySven » Mon Oct 10, 2016 6:47 pm

I think they are remnants of previous work where it looks as though the Lua interpreter was going to be a separate thread - and to pass information between different threads requires care as they operate independently of each other. Qt's signal/slot mechanism is an elegant(?) way to exchange data/events between different classes that may not even be running on the same thread - and on a multiple core/hyper-threaded processor even the same bit of hardware!

For your anticipated use you probably will need to go to signal/slots OR use the separate QEvent related things - fortunately the Qt objects/classes you will be interacting with will probably already have the required signals and slots or events you will need - you just have to "wire" them up appropriately. :geek:

Be aware that there could be issues with your proposed action - you want a label to react to a mouse over by the sounds of it - but that will possible require mouse-tracking if it is not to be accompanied with a mouse-click - and mouse-tracking is normally disabled on many "widgets" because it impacts on performance if it is not needed. E.g.:
In the [i]QMouseEvent[/i] Class documentation it was wrote:Detailed Description

The QMouseEvent class contains parameters that describe a mouse event.

Mouse events occur when a mouse button is pressed or released inside a widget, or when the mouse cursor is moved.

Mouse move events will occur only when a mouse button is pressed down, unless mouse tracking has been enabled with QWidget::setMouseTracking().

Qt automatically grabs the mouse when a mouse button is pressed inside a widget; the widget will continue to receive mouse events until the last mouse button is released.

User avatar
Vadi
Posts: 4648
Joined: Sat Mar 14, 2009 3:13 pm

Re: Messing with userwindows

Post by Vadi » Wed Oct 12, 2016 1:20 am

I'll second what SlySven said - userwindows are from very old code, and might not conform to the standards we've been following for newer code.

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

Re: Messing with userwindows

Post by dicene » Fri Oct 14, 2016 11:46 pm

Well, at this point it's more about the small things that would get Userwindows to a point where they were functional enough that I think people would actually use them. There is a little bit of simple functionality needed that would get it to the level that I would use it for at least a few things:

Initialize a userwindow with a custom size/position, rather than just starting them off docked to the right edge of main.
Show/Hide userwindows via functions so you don't have to enable/disable them via rightclick on the mudlet window.(note, it appears that closeUserWindow is broken, in that it's just killing the label in the userwindow(and I can't seem to get the label back) and not affecting the userwindow itself at all).
Move/resize a userwindow via function.

From looking at the userwindow code in TLuaInterpreter, it seems like that functionality would not be that hard for me to add in. If I added in those things, I'd be glad to move a few of my GUI elements to userwindows for the sake of letting the user move them themselves.

User avatar
Vadi
Posts: 4648
Joined: Sat Mar 14, 2009 3:13 pm

Re: Messing with userwindows

Post by Vadi » Sat Oct 15, 2016 12:18 am

I'd be happy to see those improvements.

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

Re: Messing with userwindows

Post by dicene » Sat Oct 15, 2016 1:16 am

So, since ultimately my point was making my labels dragable in some manner, I decided to try and make the change that I thought would make this possible with the least amount of messing around in the code.

About 6 lines of code later, I have a working getMousePosition function added to Mudlet that returns the cursor's position relative to the main window(so it matches the x, y coords for placement of GUI elements). (to clarify, this is necessary because the sysWindowMousePressEvent event does NOT get called when you click on labels.)

About 20 lines of code later, I have a label that allows me to move it by clicking it and then moving the mouse and clicking again when it's where you want it(since it appears there is no way to set a ClickRelease callback on labels?).

Is this something that would be desirable to add into a future release of Mudlet? If so, I can try and do the proper pull request stuff, although it'll be my first time actually contributing something via Git.


Regarding userwindows, I've got some things I'm trying to make sure I have a handle on. When a userwindow is being created, it's being automatically given a console(similar to the main scrollback and (I think) to miniconsoles)) with exactly the same name as the window itself? If that's correct, then I'll need to make sure there is a separate function for things like moveUserWindow, because at the moment using moveWindow on the userwindow's name is only moving the console in it relative to the userwindow itself, not the userwindow relative to the screen.

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

Re: Messing with userwindows

Post by SlySven » Sat Oct 15, 2016 1:38 am

Sounds promising! Are those labels for consoles only or is it applicable to map labels? The latter can be on top or underneath other map contents and there is some (IMHO) shortcomings in the current code for those, including the actions when multiple labels overlap (they all snap to the same TL corner IIRC and it gets very difficult to select a single one on it's own to move it out of the group; the selection logic is not brilliant)...

User avatar
Vadi
Posts: 4648
Joined: Sat Mar 14, 2009 3:13 pm

Re: Messing with userwindows

Post by Vadi » Sat Oct 15, 2016 2:07 am

I don't have it on hand right now, but people have made draggable labels using existing functionality - searching forums would turn it up.

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

Re: Messing with userwindows

Post by dicene » Sat Oct 15, 2016 7:35 pm

@SlySven I only added the getMousePosition function via source, the rest was a script in mudlet that drew a label and toggled the image-moving timer on click. No clue where Map Labels even are in the code? I've personally never really used the mapper much, generally staying away from images in my GUI's and using text whenever possible(like the built-in text map in IRE games), because I think that's a more appealing visual thing(or did). The image I ended up testing with is a knight from Final Fantasy Tactics that I'm using because I would like to display the people/mobs in the room using FFT sprites, so my shying away from images thing has kinda changed over time.

@Vadi The closest I could find were some things from Akaya. One was a window that moved when you hovered on past its borders(which I've made, but onMouseLeave events don't fire when a label moves away from them until you move the mouse again, and I can't think of any way around that issue). One was a a script that let you move the labels via clickable buttons(which is what I'm trying to avoid). And the last thing was something that let you build labels by dragging and dropping, but that only works if you have no labels or anything in the way, which conflicts with the goal of making drag-able labels.

User avatar
Vadi
Posts: 4648
Joined: Sat Mar 14, 2009 3:13 pm

Re: Messing with userwindows

Post by Vadi » Sat Oct 15, 2016 11:03 pm

I see, okay.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests