Gammon Forum : MUSHclient : Miniwindows : Absolute positioning, a little pointer please?

Entire forum ➜ MUSHclient ➜ Miniwindows ➜ Absolute positioning, a little pointer please?

Absolute positioning, a little pointer please?

It is now over 60 days since the last post. This thread is closed. Refresh page

Posted by

Worstje Netherlands (899 posts) Bio

Date

Sun 24 Aug 2008 11:30 AM (UTC)

Amended on Sun 24 Aug 2008 11:52 AM (UTC) by Worstje

Message

I'm toying around a bit with absolute positioning, and getting a bit lost in the woods for a change.

1) The documentation says you can use WindowPosition() to change the position if you notice the output window has changed. How do I notice the output window changing? Is there a OnPluginWorldResized() or something like it? Edit: Wait, a OnPluginWorldOutputResized() would be more useful seeing how my commandline changes size every paragraph I type. ^^

2) Where can I get the current size of the output window? Can't seem to find the data in GetInfo(), and seeing how absolute positioning doesn't seem to like negative numbers (to position from the right edge or bottom edge), that information would be rather useful.

Top

Posted by Nick Gammon Australia (23,165 posts) Bio Forum Administrator

Date Reply #1 on Mon 25 Aug 2008 12:46 AM (UTC)

Message

Quote:

How do I notice the output window changing?

You set a timer and check every second or so (for example, testing GetWorldWindowPosition).

I deliberately didn't put in a callback when I get the Windows message about the window resize, because that would fire every pixel that you drag the window larger, which would probably cause a big slowdown if scripts tried to react to the intermediate positions. I thought about testing every second to see if the size had changed, and then thought "well the script can do that anyway".

Quote:

Where can I get the current size of the output window?

Unfortunately, although I put in lots of GetInfo fields related to window sizes, none seems to actually be the output window size. The code below is about the only way I can think of, as if you make a window, and draw it, it will return its exact location:


win = GetPluginID ()  -- get a unique name

-- find out where bottom RH corner is

WindowCreate (win, 0, 0, 1, 1, 8, 0, 0)
WindowShow (win,  true)
Repaint ()  -- force draw and therefore position calculation

local right = WindowInfo (win, 12)
local bottom = WindowInfo (win, 13)

-- recreate window in desired place

WindowCreate (win, right - 30, bottom - 30, 20, 20, 4, 2, ColourNameToRGB("red"))

Quote:

... absolute positioning doesn't seem to like negative numbers...

WindowCreate takes a width and height, and thus negative numbers won't apply.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Nick Gammon Australia (23,165 posts) Bio Forum Administrator

Date

Reply #2 on Mon 25 Aug 2008 01:13 AM (UTC)

Message

I have added new GetInfo selectors to version 4.36 which will directly return the output window width and height.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Worstje Netherlands (899 posts) Bio

Date

Reply #3 on Mon 25 Aug 2008 10:00 AM (UTC)

Message

Nick, I'd like to make an appeal to you to have that callback, since I do not agree with your reasons for not having it.

1) If people have smooth windowsdragging turned on (which is a setting in display properties somewhere), that means they want updates as the window is being resized. If they do not want those updates, they have it turned off.

2) Windows actually does quite a bit of optimalization, and sends a message for an amount of pixels moved if you move a bit faster than really really slow. I've also tested this in the past due to my having a similar concern.

3) Timers can be turned off, and people will wonder why the hell their graphics have stopped updating if they don't recall turning timers off.

4) Timers are, in my opinion, an even more cpu demanding way of redrawing. Timers fire every so often, no matter whether you are typing mud output, or whatever else. Even with the minimal did-size-change ifcheck, it is a matter of extra processing. In order to script as effectively as possible, one tries to make optimalizations (don't have triggers on that can't match now, don't have 500 timers, etc) and the use-a-timer approach is the exact opposite of it. I believe that people with slower computers benefit more from the direct windowmessagehook due to it only firing when it is actually being used.

5) There is more than one message for sizing (and moving for that matter). There's WM_SIZE and WM_WINDOWPOSCHANGED, but there is also WM_SIZING, WM_WINDOWPOSCHANGING and WM_EXITSIZEMOVE. I'm a bit unclear on what each did exactly, but the latter should only fire at the end of a movement operation - although I recall the actual message orders differing depending on whether one was using smooth resize/moving or borderoutline resize/moving. But one of them was sure to fire at the end of a resize, I'm positive.

6) Premature optimization is the devil of programming. ^_^ Sorry to put it as bluntly as that, but premature optimization tends to see problems where there are none, or make elephants out of mice. (I've been guilty of it myself so often...) So many programs react on those sizing/moving messages and redraw themselves based on it that it isn't funny anymore. The worst offender I can think of in my mind are all those programs with custom skins, alphablending and windowregions that need to be recalculated, MS' Messenger for example. Yet people put up with that crap, even on really slow computers. All a scripter would do is redraw a bunch of bitmaps, which would eventually get blitted back to the canvas of the outputwindow - which is really simple and fast in comparison.

7) If things actually did get too slow for someones computer (I have yet to see it, to be honest), there are two routes to take: a) optimize the code since probably whatever it does @resize can be optimized. I only see that happening when they end up going triggerhappy with all the filters you've added and rather large images. If worst comes to worst, people can implement their own redraw-delay with timers. Or b) they don't load the plugin that causes all the extra processing slowdowns. It might sound a bit crude to put it like that, but as long as I don't see/hear about the horrible delays, I'm going to assume they do not exist. Again, you can optimize later if it needs to be done.

8) OnPluginPacketReceived is also a very heavy callback. It gets to process tons of text, and I know plenty of plugins who use it, usually looping over every letter a number of times per replace operations or such. Then realize there's usually a number of plugins that use it for whatever reason (I have had 3 uses for it in one world so far) and it is a pretty heavy callback on its own... which is not limited by a user-induced resize operation.

Anyhow, I went a little bit offbounds. It's just that I kept finding new reasons to disagree after I started. :) I hope you'll reconsider, Nick.

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #4 on Mon 25 Aug 2008 03:44 PM (UTC)

Message

Would it really be that bad to fire an event every time the window size changed? I'm thinking about GUIs implemented in scripting languages, in which the logic does have to go into the scripting engine to figure out what to do with the window as it's being resized. If too many scripts at once started trying to do something with it, or if somebody tried to do something too intensive, it could cause trouble; but if somebody just wants to do something very quick it might be ok.

The approach that Java Swing takes, IIRC, that is kind of nice is to queue up these events and conflate them if necessary. So, if you drag the window around, and the callback doesn't see it until, say, the 20th pixel, it won't get the messages for pixels 1..19. This helps alleviate the load somewhat. Of course, it would be a lot of work to implement on top of a windowing system that doesn't already support this.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

Posted by

Worstje Netherlands (899 posts) Bio

Date

Reply #5 on Mon 25 Aug 2008 03:48 PM (UTC)

Message

Well, as I said above - Windows already has that built in. You don't get a message for every pixel moved - unless you move really really slowly.

Top

Posted by

David Haley USA (3,881 posts) Bio

Date

Reply #6 on Mon 25 Aug 2008 03:55 PM (UTC)

Message

Sorry; what I meant is that my impression was that Swing is a little more aggressive about it, due to its threading model.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org

Top

Posted by

Nick Gammon Australia (23,165 posts) Bio Forum Administrator

Date

Reply #7 on Mon 25 Aug 2008 11:33 PM (UTC)

Message

Well I can't argue with such a persuasive set of reasons. This is now in version 4.36.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

Posted by

Worstje Netherlands (899 posts) Bio

Date

Reply #8 on Tue 26 Aug 2008 12:38 AM (UTC)

Amended on Tue 26 Aug 2008 12:50 AM (UTC) by Worstje

Message

That is awesome, Nick. Thanks!

/me writes a note that says "Assault Nick with 10-point arguments for proper feature-adoptation in MUSHclient" and sticks it on the side of his screen.

Edit: Oh, just to make sure... does the new addition respond to the resizing of the output window or the world window? With the setting where the commandbox changes size depending on its content, that should also trigger the event... which might not happen in the case of it being the event of the world window.

Which reminds me of a bug I found a while ago in commandbox size-to-fit function. If you paste a text longer than the configured maximum amount of lines, it doesn't adjust the view at all.. leaving a single line to read through a dozen lines or whatever. The expected behaviour would be to have the box size to the maximum amount of lines it is allowed to be large.

Top

Posted by

Nick Gammon Australia (23,165 posts) Bio Forum Administrator

Date

Reply #9 on Tue 26 Aug 2008 03:17 AM (UTC)

Message

My testing indicates that it is indeed triggered by the command window resizing.

As for the pasting, I have reworked the code a bit so that if you attempt to put a large number of lines there, it will size itself to the maximum you specified, rather than do nothing.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

16,237 views.

It is now over 60 days since the last post. This thread is closed. Refresh page

Go to topic: Search the forum

top