Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ MUSHclient ➜ Miniwindows ➜ Can't move miniwindow
Can't move miniwindow

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

Pages: 1 2  

Posted by Ragur   (2 posts)  Bio
Date Sat 26 Jul 2008 07:06 PM (UTC)
Message
Hi

I really like the new miniwindow function, I see lot of potential in it. I have been testing it a bit today but I have a problem.

I can't move my miniwindow. No matter what I put in the left and top properties, it does not move. I have tried different positions, both with and without the absolute position flag. And it doesn't matter if I try with WindowCreate() or WindowMove().

It would be awesome if you could move it easily with click and drag.

Another thing I would like is to have the miniwindow outside the output window.

And why is there no WindowResize function?
Top
Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #1 on Sat 26 Jul 2008 10:04 PM (UTC)
Message
Quote:

I really like the new miniwindow function, I see lot of potential in it.


Thank you very much!

Quote:

No matter what I put in the left and top properties, it does not move.


The short answer is that it isn't designed to.

I thought about making it possible to move them, and that may well appear in a later version, however for now my thinking was:


  • I wanted to get it out for testing, and making click-and-drag moveable windows was going to take time, if indeed it was a good idea.

  • In the World of Warcraft user interface, by way of comparison, none of the main windows that appear can be moved either. They have title bars and "look" like you should be able to move them around, but you can't. The client basically positions them in logical places. For example, your inventory is on the right, the minimap on the top RH corner, the main map takes the full screen when you activate it, your quest log appears on the left, and so on.

    However what *does* happen (like in MUSHclient) is that if you change window size (eg. change screen resolution) they will appear in the same relative spot - the inventory is still on the right, although the right is now closer to the left.

    So I thought, if it is good enough for them, it is good enough for me.

  • Just imagine you dragged the map around a bit, maybe down the screen a bit. Now what happens if you resize the window? Does it:


    • Go back to its original corner?

    • Stay exactly where you put it? (and possibly disappear if you make the window smaller)

    • Move relative to the window? If it moves relative to the window, to which side? The right side? The top side? Both?

    • If the window moves as you resize, what happens if it moves on top of another window?


    I don't think there is an obvious answer to these questions.

  • One of the reasons I liked the auto-moving miniwindows is, that it was tedious with the old system of dummy worlds, that if you made the main world window (with the MUD output in it) larger or smaller, you then had to spend the next 5 minutes repositioning the map window, the status window, the inventory window and so on. I was trying to automate that.

  • At present, what it does do, is fit as many miniwindows onto any side of the main world as it can. That is, if you specify one as being centered on the RH side, then it automatically positions that (and others) evenly apart (as in the screen shot on my introduction page). The intention was that manual positioning should not be necessary.


Quote:

I have tried different positions, both with and without the absolute position flag.


That flag is intended for scripted moves. I did think that with a large screen, a plugin could be written that moves the windows to fill available gaps (for example, two columns of them on the right side).

Quote:

I would like is to have the miniwindow outside the output window.


This opens up a bit of a can of worms - again, if you move the main window, does one outside the main window move with it, or stay stationery? Or if you resize it? Or close it? Or minimize it?

Quote:

And why is there no WindowResize function?


Calling WindowCreate resizes (although you lose the current contents).

I can see a certain amount of usefulness in allowing resizing of some windows (eg. chat windows). Let's see how the other stuff works, and then put things like moving and resizing onto the wish list. :-)



I should point out that I don't really consider the miniwindows totally finished. For example, I was thinking of drag-and-drop, so you might drag an inventory item onto a shop, or vice-versa.

For now, let's play with what is there, and start assembling a list of possible future enhancements.

There are a couple of other ideas I have too, but as I say, let's play with the current system and see if it needs tweaking before we start wanting to add another 10 things to it.


- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Ragur   (2 posts)  Bio
Date Reply #2 on Sun 27 Jul 2008 12:26 AM (UTC)
Message
I have to disagree on several of your points, like having to spend 5 minutes for repositioning some windows when you do it in seconds with click and drag. Even without a mouse it could be done easily with the suggestion I soon will give you. It also answers the question of what happends when you resize a miniwindow, and I find that obvious. :)

I was asking about a WindowResize function because there are a WindowMove function, while you can both resize and move with WindowCreate. WindowMove does not discard the content of the miniwindow as WindowCreate does. I think you should be able to resize also without loosing the content. Making the window bigger fills it out with the background color, and making it smaller crops the overflow.

---

Here are my suggestion for how the miniwindows should work:

- A miniwindow can have 2 states, "floating" or "docked"

- Both the output window and the miniwindow have 9 different "dockpoints": topleft, topmiddle, topright, middleleft, center, middleright, bottomleft, bottommiddle and bottomright.

- A docked miniwindows always have the same dockpoint as its parent.

- When a miniwindow is floating it can be anywhere within the MUSHclient and it always stay where it is even if you resize or move the output window.

- If you resize a miniwindow it uses its own dockpoint as a fixed point.

- All miniwindows is movable with the mouse. If you drop it within 10 pixels from a dockpoint it automatically docks to it. You should be able to turn off both mousemove and autodock when you create the miniwindow.

- When you first create a floating miniwindow you can position it relative a docked position with the left and top properties. Also negative numbers can be used.

- When you move a miniwindow it automaticlly gets floated. You should also have two different way of moving it, WindowMove moves it relative itself, while WindowPosition moves it relative a dockpoint of the output window. If both left and top properties in WindowPosition is 0 the miniwindow gets docked.

---

I hope I haven't missed something and that it won't be too much to code for you. While reading my own post I realize that the docked miniwindows already exist today as it is, it's the floating ones I would like to add.

Top
Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #3 on Sun 27 Jul 2008 02:17 AM (UTC)
Message
I will take your comments into consideration for the next version. Meanwhile, see what you can do with the current capabilities.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #4 on Sun 27 Jul 2008 06:43 PM (UTC)
Message
It should be noted however that most systems let you set transparency mini windows, both mouse over and when you are not in them. I.e., I could set the transparency of the map, or a quest list, to be 60% transparent normally, and 40% when clicked on/mouse over, so that I could better read them when I need to, but so I can still see what is going on behind them. Your minis appear to be overlapping the texts behind them, so something like that may be quite useful. Also, at least in EQ2, one can opt to make the background of the window completely transparent, leaving only the text floating over it. EQ2 has an option to "lock" the window, which has the same effect as WOW's, but prevents resizing "or" moving it. And in EQ2 you can also set it to be "click through", i.e., for a window that just shows info, like a map, you can have clicking within it actually effect what is "behind" it, instead.

As useful as such windows are, they are less so if/when they get in the way.
Top
Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #5 on Sun 27 Jul 2008 08:39 PM (UTC)
Message

Well I had thought about transparency, and I am interested in getting semi-transparency to work, once I get the mathematical model right. However bear in mind that in WoW the semi-transparent windows have text floating over a picture, like grass, or sky.

I can do full transparency right now, see below:

Not very readable is it? Because the MUD output is text too. Even semitransparent is only going to make it somewhat readable.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Darwin   USA  (125 posts)  Bio
Date Reply #6 on Mon 28 Jul 2008 12:01 AM (UTC)
Message
I would be interested in a function (or functionality) that would push the normal mud output text out from under the miniwindows so that the miniwindows do not obscure the output.

This would make it very useful in creating a graphical compass to the right of normal text and/or replacing a prompt with graphical percentage bars across the bottom of the output window, without obscuring any text that might appear underneath them. Or even placing some kind of display to the left of normal next, since I noticed that the options within MUSHclient only allow for that text to be "pushed over" 20 pixels at most.

Click and drag functionality would be nice, but I don't think it would be necessary at present.

I guess consider it a feature request.
Top
Posted by Guest1   USA  (256 posts)
Date Reply #7 on Tue 29 Jul 2008 01:36 AM (UTC)

Amended on Tue 29 Jul 2008 01:51 AM (UTC) by Guest1

Message
Let me start by saying I have not had an opportunity to play with this yet, and probably wont for a least a few weeks due to a busy schedule. Having said that,

AWESOME, THANKS NICK!!!!

I've been badgering for a multicolor status window for years!

Going on what I've read here, the main thing I'd like is full user control of where the miniwindows sit and what dimensions the miniwindows have, at least as an option. Perhaps this is currently do-able via script (much the same way as I open several notepad windows now and position them alongside my world window, which I use for tells, spell status, and various other bits of info), however I got the impression from this thread that the position is entirely automated and I have liitle control where the miniwindow appears, which to me just doesn't sound right.

The miniwindow create/move/resize info page ( http://www.gammon.com.au/mushclient/mw_creation.htm ) seems to say we can only choose which corner of the output window the miniwindow sits (or else centers at the right, top, left, or bottom side of the output window)..

Actually I might be wrong here.. I CAN specify the 'internal' dimensions of the miniwindow itself, so as long as the miniwindow itself is positioned in one of those 8 primary positions, I should be ok..

For example, when I open a world right now, I run a script 'world_open':

sub world_open
   MoveMainWindow 0, 0, 1050, 995
   world.SendToNotepad "STATUS", "status window generated.."
   NotepadFont "STATUS", "WhiteRabbit", 9, 0, 0
   NotepadColour "STATUS", "#FAEBD7", "#000000"
   MoveNotepadWindow "STATUS", 705, 0, 333, 675
   world.SendToNotepad "COMMS", "communications window generated.."
   NotepadFont "COMMS", "Verdana", 8, 0, 0
   NotepadColour "COMMS", "#FAEBD7", "#000000"
   MoveNotepadWindow "COMMS", 705, 675, 333, 245
   MoveWorldWindow 0, 0, 705, 920
   AddTimer "resize_my_world", 0, 0, 0.5, "MoveWorldWindow 0, 0, 705, 920", 5 + 32, ""
   SetTimerOption "resize_my_world", "send_to", 12
   world.ReplaceNotepad "STATUS",""
   world.ReplaceNotepad "COMMS",""
end sub

This resizes MUSHclient itself, creates the 2 notepad windows to the right of my output window which combined equal the full height of the output window, and repositions the output window if for some reason I had previously had it manually resized.. (there's some additional code there that is there for other reasons).

So I guess I just need to add the width of the notepad windows above onto my existing output window, then create miniwindows, one positioned top right, one positioned bottom right, with the internal dimensions that can be easily calculated taken from the above script..

Correct?
Top
Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #8 on Tue 29 Jul 2008 07:07 AM (UTC)
Message
You can do the following with miniwindows:


  • Put them absolutely wherever you want, by specifying an absolute coordinate.

  • Hide them altogether if they aren't wanted right now, however still update them in the background (eg. an inventory that is updating, but you are in a fight and don't want to see it)

  • Dock them to any of the 4 corners, or the 4 sides, or the middle, in which case they automatically track the window as you resize it.

  • If docked to the middle of a side, you can have multiple ones as they shift around to make room for newcomers.

  • You need to know its height and width, true, but you should know that. In some of the plugins I have been writing (like a quest tracker) I cache the items I need to display first - which I need to do anyway to avoid flicker. Then when all is received I know 2 things - 1) the number of items, which gives me the height, and 2) the maximum width of all the items, which gives me the window width.



So yes, I think you can do it with a minimum amount of fuss. I have released about 5 plugins so far that demonstrate the general idea, and I reworked all of those from ones that used dummy windows or notepad windows, with not a heap of effort.

However the end result looks much better.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Shadowfyr   USA  (1,788 posts)  Bio
Date Reply #9 on Tue 29 Jul 2008 06:52 PM (UTC)
Message
Hmm. Yeah. You have a point Nick. Even partial is going to be an issue with transparency. Mind, if/when you provide some means to display images in these, then a number of things, like the map, could be redone with that. In my case, its not likely a problem, because I have enough screen space to make the mushclient window full screen, then tack the minis to the right edge. However, since I can't "lock" the main window, I can't prevent accidentally sizing that to the full width, and messing myself up. :p Its still nice to have transparency, since it may be usable later, and some cases it may be usable now, the point isn't to make it 100% readable, necessarily, just possible to see what is behind it.

For example, in the case of click through, someone could set it to be 100% transparent when the mouse is "over" the window, and 80% opaque when not hovering over it. This would let them see it well enough to know what is there, while also letting them select text, or quickly "hide" the window, without well... actually hiding it, or closing it.
Top
Posted by Nick Gammon   Australia  (23,070 posts)  Bio   Forum Administrator
Date Reply #10 on Tue 29 Jul 2008 09:20 PM (UTC)

Amended on Tue 29 Jul 2008 09:22 PM (UTC) by Nick Gammon

Message
I'm taking a look at transparency, however I should point out that semi-transparent windows with text showing through other text involves quite a large processing overhead.

To simply copy an opaque window to the output area you can "blit" the pixels across, which is a single operating system call, and designed to be fast.

To have semi-transparent text, you need to pull in the existing text, go through pixel by pixel to reduce it to (say) 50%, then merge the new text on top of it, then put it all back.

For example, for a 400 x 400 pixel window, that is 400 x 400 x 3 bytes (RGB) that need to be processed, in other words 480,000 bytes - half a megabyte almost. To process 480,000 bytes every time a line arrives from the MUD might be regarded as a bit of an overhead.

On a fast PC, and a smallish window, this will probably work. But if you have a half a screenful of chats, on top of other text, and you try that, next I will be fielding complaints that MUSHclient is "too slow ever since you added that transparent window stuff".
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Worstje   Netherlands  (899 posts)  Bio
Date Reply #11 on Tue 29 Jul 2008 09:59 PM (UTC)
Message
Could always add a new global preference "Support alpha-blended drawing routines" or something, which would enable the more elaborate kind of drawing.

Which reminds me.. I haven't put too much attention into miniwindows yet, but does MUSH support PNG files? I'd love to use some PNG images with alphachannels (full and partial transparency) for my miniwindows. Of course it would only support such drawing with the above option on, but I think it could make an awesome addition.
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #12 on Tue 29 Jul 2008 10:06 PM (UTC)
Message
Drawing a translucent PNG onto a miniwindow shouldn't be expensive as long as you're not trying to draw it on top of something other than the background. Still, if the miniwindow is constructed as a pixel buffer, and then blitted in one go, it should be ok to draw on top of stuff already there -- where "there" is the miniwindow, not the main window behind it. Since that would use a different drawing buffer, retrieving pixels from it would be expensive, as Nick said.
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 #13 on Tue 29 Jul 2008 10:52 PM (UTC)
Message
Well, the idea was that it could have some non-rectangular forms. Think of the image of a half-unrolled scroll as background, with the actual mudcontent sliding behind it when it happens to overlap.

Maybe it would need two drawing styles for drawing PNGs then, then. ^_^ One to draw transparently while only regarding the current miniwindow, while the other would also take into account actual mud output.

But I'm not too sure on the implementation details, so yeah... >_>
Top
Posted by David Haley   USA  (3,881 posts)  Bio
Date Reply #14 on Tue 29 Jul 2008 10:55 PM (UTC)
Message
It is easier to draw things that have complete transparency than things that are in between. To draw something completely transparent, you just don't draw it. :-) So a .png with an alpha channel that is binary (0% or 100%) things should be (relatively) easy. It gets complicated (for the reasons Nick mentioned) when you need to blend two images together from different pixel buffers.
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
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.

70,700 views.

This is page 1, subject is 2 pages long: 1 2  [Next page]

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

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home