[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  MUSHclient
. -> [Folder]  Bug reports
. . -> [Subject]  WindowResize() doesn't set the background color.
Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?
(New message)
Subject: WindowResize() doesn't set the background color.
Name:
Your forum user name.
Register forum user name
Password:
Your forum password.
Forgotten password?
Message:
Message to be posted (in English, please)
Maximum of 6000 characters. Text only please, no HTML.
Forum codes:
Check this if your message uses 'forum codes' or templates (auto-detected for new posts).
Forum codes Templates

Save this message ...


Subject review (reverse sequence)

Pages: 1 2  

Posted by Nick Gammon   Australia  (19,495 posts)  [Biography] bio   Forum Administrator
Date Tue 24 Aug 2010 09:23 PM (UTC)  quote  ]
Message
Twisol said:

But there's literally no way to change the transparency color once you've created the window, without recreating the window.


I've added a new flag to WindowCreate that lets you keep the hotspots, as you seem to want, if I read it correctly, and also Fiendish suggested.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Tue 24 Aug 2010 09:11 PM (UTC)  quote  ]

Amended on Tue 24 Aug 2010 09:20 PM (UTC) by Twisol

Message
*sigh* Yes, I'm not arguing your logic. Clearly I just misunderstood, or thought the documentation was confusing/inspecific/<other>, or something. WindowPosition affects the flags, I figured WindowResize would affect the background color.

Lets not keep referring to the OP intent every step of the way, please. Things change over the course of a discussion. I posted to bring up an issue for discussion. It's extremely discouraging when my early remarks are held against me. My very second post agreed with your logic.

Nnngh. I'm going to stop here.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Nick Gammon   Australia  (19,495 posts)  [Biography] bio   Forum Administrator
Date Tue 24 Aug 2010 08:59 PM (UTC)  quote  ]
Message
Twisol said:

Ouch. It's a one-liner change, surely this can't be about the effort involved to do this. Did I say something wrong?


You filed as a bug report something that is behaving exactly as documented, and therefore is not a bug. From the documentation for WindowResize:

WindowResize docs said:

This resizes an existing miniwindow of the given name.

If the new size is larger than the existing size the BackgroundColour is used to fill any newly exposed area.

...

Any existing hotspots, images, and fonts are preserved. All other window parameters for this miniwindow are unchanged.


(my emphasis)

It is done exactly this way so that you can have a colour to fill any area that is larger than the original. The "background colour" of the original miniwindow may be being used for transparency purposes, and you may not want the new area to be transparent.

This was done with careful consideration, and not an omission of a "one line change" that would improve it.



- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Tue 24 Aug 2010 05:50 PM (UTC)  quote  ]
Message
David Haley said:
You can still keep your library's APIs simple while working around whatever you want to work around in MUSHclient's API. When asked for a concrete use case, I don't think it's really an answer to say that you're trying to keep some API simple; just push the feature to the API if you have to. Or keep it simple and don't handle certain cases (perhaps with a warning).

I don't understand why you think the underlying API affects your API. Even if the MUSHclient API were utterly nasty, you can still write a nice API on top of it, even if it goes through many contortions under the hood. A nasty core API would affect the implementation under the hood of your API, sure, but not the API itself.


Oh, sure, I agree. But there's literally no way to change the transparency color once you've created the window, without recreating the window. And recreating the window (and all the work it entails to keep everything else the same) is too much work just to remove one parameter from Window.new(). When the underlying API literally can't do something, you can't reasonably expect a wrapper API to do it.

Like I said, it's no skin off my back if nothing's done. I simply see a problem, and I thought we might be able to find a reasonable solution.


By the way, I -did- go through a lot of contortions with the miniwidget library project. There are very real barriers to making a nice wrapper API. Just like Nick said, this is all done for free, and there's a tipping point where so much effort is involved for not enough gain.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Tue 24 Aug 2010 04:22 PM (UTC)  quote  ]
Message
You can still keep your library's APIs simple while working around whatever you want to work around in MUSHclient's API. When asked for a concrete use case, I don't think it's really an answer to say that you're trying to keep some API simple; just push the feature to the API if you have to. Or keep it simple and don't handle certain cases (perhaps with a warning).

I don't understand why you think the underlying API affects your API. Even if the MUSHclient API were utterly nasty, you can still write a nice API on top of it, even if it goes through many contortions under the hood. A nasty core API would affect the implementation under the hood of your API, sure, but not the API itself.

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org
[Go to top] top

Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Tue 24 Aug 2010 03:41 PM (UTC)  quote  ]

Amended on Tue 24 Aug 2010 03:45 PM (UTC) by Twisol

Message
Nick Gammon said:

Twisol said:

Yeah, that wouldn't be a drop-in change. I suspect using DirectX instead of GDI might help a bit, though I don't know the details. If I remember right, though, the GDI API is a bit lacking in places, forcing you to use cumbersome per-pixel approaches.

Well I don't know how well it would work with Wine, or the Windows emulators under Mac, etc.

Just fine, most likely. Wine supports several rather graphically-intense games. Anyways, this is getting off-topic.

Nick Gammon said:
I mean, for showing the output of what is purely a text-based MUD (and MUDs are text, right?) then why do you really need to have alpha-channel fading in of miniwindows?

I'm not thinking of it so much for the end result, but for compositing windows together (using WindowImageFromWindow and such).

Nick Gammon said:
Look, I have seen plenty of APIs that handle every conceivable situation, but are unusably complex.

Give me a concrete example of where you need to use transparency, need to change the background colour, and need to keep hotspots (and not just for some generic library, but an actual real-world example) and I will be interested, maybe.

It's not about using them at the same time. I'm just writing an object-based wrapper API for miniwindows, and I'm trying to make it simple. The problem I have is that the MUSHclient API right now handles too many things within singular functions. This bug (now feature-request) stems primarily from me trying to make my Window.new function smaller, ideally to Window.new(width,height). Everything else can be managed afterwards.

Nick Gammon said:
Remember all this support is done for free.

Ouch. It's a one-liner change, surely this can't be about the effort involved to do this. Did I say something wrong?

I'm not doing any plugins right now. In fact, I haven't for months. All my MUSHclient time has been focused on libraries (some of which worked out, some of which didn't), and the source code. I don't, strictly speaking, need to work on this window API. But I want to make miniwindows approachable.

Is it any skin off my back if this isn't done? No. Unlike the sensi-hotspot thread, I'm not working on anything that would require this. It would just make my API that much cleaner.

Can I write this myself into the client? Sure I could. Is that useful to everyone else? Not really. I need to discuss it here, and if we decide it's good, then I have no problem providing a patch. But after all the other effort I've put into my fork - don't get me wrong, I understand your reasons - I'm not going to add any more new features until I know what their future will be.

Worstje said:
In Twisol's defence... I don't think his lowering his expectations has anything to do with you adding new features/functions, on the contrary. It has everything to do however with his failed former attempt that was a bit too idealistic in nature, thus making it hard to be finished in anything other than a disappointment.

So this time, he has set realistic expectations, and far more likely to be smiling when he finishes work on it. :)

(Why do I know all this? Been there, done that. That's all I'll say on the subject.)

You nailed it, Worstje. Thanks!

Nick, just to clarify, the recent functions actually spurred me to try again. I was (and am) sure that the new functions would let me simplify my API even more (WindowMoveHotspot for the WIN).

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Fiendish   USA  (1,007 posts)  [Biography] bio   Global Moderator
Date Tue 24 Aug 2010 02:39 PM (UTC)  quote  ]

Amended on Tue 24 Aug 2010 02:48 PM (UTC) by Fiendish

Message
Quote:
(and MUDs are text, right?)

Not in my universe. :)

Quote:
I can't see a huge use for semi-transparent text over other text. It would be kind-of unreadable.

Regardless of the content of the miniwindow (it may not contain text, after all), I think that window transparency is a stupid feature in any user interface for exactly that reason. Blending anything that you're meant to look at with anything else that you're meant to look at just makes everything hard to look at. Alpha blended drop shadows on the other hand are awesome, though significantly less delightful in a context that generally mandates black backgrounds and not putting things on top of each other.

http://aardwolfclientpackage.googlecode.com/
https://github.com/fiendish/aardwolfclientpackage
[Go to top] top

Posted by Worstje   Netherlands  (867 posts)  [Biography] bio
Date Tue 24 Aug 2010 01:27 PM (UTC)  quote  ]
Message
In Twisol's defence... I don't think his lowering his expectations has anything to do with you adding new features/functions, on the contrary. It has everything to do however with his failed former attempt that was a bit too idealistic in nature, thus making it hard to be finished in anything other than a disappointment.

So this time, he has set realistic expectations, and far more likely to be smiling when he finishes work on it. :)

(Why do I know all this? Been there, done that. That's all I'll say on the subject.)
[Go to top] top

Posted by Nick Gammon   Australia  (19,495 posts)  [Biography] bio   Forum Administrator
Date Tue 24 Aug 2010 10:10 AM (UTC)  quote  ]
Message
Twisol said:

I thought I'd try again at a generic miniwindow library, with my expectations set somewhat lower than before. :P


So the addition of a couple of new functions has lowered your expectations? Don't use them then.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Gammon   Australia  (19,495 posts)  [Biography] bio   Forum Administrator
Date Tue 24 Aug 2010 10:06 AM (UTC)  quote  ]
Message
Twisol said:

Nick Gammon said:
*What does it matter anyway? [...] Also it is used for the transparency.

Yes, exactly.


You are creating hypothetical problems here and then trying to solve them. You want to have a miniwindow that has hotspots that you want to keep (so you can't use WindowCreate) but a background colour you want to change *and* you are using transparency, so you have found a condition that the current API doesn't handle.

Look, I have seen plenty of APIs that handle every conceivable situation, but are unusably complex.

Give me a concrete example of where you need to use transparency, need to change the background colour, and need to keep hotspots (and not just for some generic library, but an actual real-world example) and I will be interested, maybe. Remember all this support is done for free.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Nick Gammon   Australia  (19,495 posts)  [Biography] bio   Forum Administrator
Date Tue 24 Aug 2010 10:01 AM (UTC)  quote  ]
Message
Twisol said:

Yeah, that wouldn't be a drop-in change. I suspect using DirectX instead of GDI might help a bit, though I don't know the details. If I remember right, though, the GDI API is a bit lacking in places, forcing you to use cumbersome per-pixel approaches.


Well I don't know how well it would work with Wine, or the Windows emulators under Mac, etc.

This is starting to take us into the realms of a graphical client, and I seem to recall some opposition to that in the mudstandards forum.

I mean, for showing the output of what is purely a text-based MUD (and MUDs are text, right?) then why do you really need to have alpha-channel fading in of miniwindows? WoW has that for chat channels, but the chat is transparent over a "picture" background (like, your 3D view of the world). I can't see a huge use for semi-transparent text over other text. It would be kind-of unreadable.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Tue 24 Aug 2010 08:54 AM (UTC)  quote  ]
Message
Nick Gammon said:

Twisol said:

As an aside, I've long disliked the odd color-keying transparency miniwindows employ, and I'd love to see true alpha-channel support in miniwindows.


As I think I mentioned elsewhere, that could be done, at a considerable hit for speed. Since to do that on a pixel-by-pixel alpha channel means that each each pixel has to be multiplied by the alpha channel amount, per pixel, based on the value of the original, the value of the alpha pixel, and the value of the miniwindow pixel. Multiply that by the thousands of pixels, even for a 100 x 100 pixel window, and that takes time.


Yeah, that wouldn't be a drop-in change. I suspect using DirectX instead of GDI might help a bit, though I don't know the details. If I remember right, though, the GDI API is a bit lacking in places, forcing you to use cumbersome per-pixel approaches.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Nick Gammon   Australia  (19,495 posts)  [Biography] bio   Forum Administrator
Date Tue 24 Aug 2010 08:49 AM (UTC)  quote  ]
Message
Twisol said:

As an aside, I've long disliked the odd color-keying transparency miniwindows employ, and I'd love to see true alpha-channel support in miniwindows.


As I think I mentioned elsewhere, that could be done, at a considerable hit for speed. Since to do that on a pixel-by-pixel alpha channel means that each each pixel has to be multiplied by the alpha channel amount, per pixel, based on the value of the original, the value of the alpha pixel, and the value of the miniwindow pixel. Multiply that by the thousands of pixels, even for a 100 x 100 pixel window, and that takes time.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
[Go to top] top

Posted by Twisol   USA  (2,230 posts)  [Biography] bio
Date Tue 24 Aug 2010 07:56 AM (UTC)  quote  ]

Amended on Tue 24 Aug 2010 07:57 AM (UTC) by Twisol

Message
Worstje said:
I can see situations where one might want to increase the size of their miniwindow, but not have the new area have the same shade as the background color configured for that window. On the other hand, two WindowRect() calls could fix any such color issue.

I'd love to hear an example. I don't doubt it could be useful, and hence it should definitely be "possible", but I don't think it's nearly so prominent that it needs something more than your suggested two WindowRectOp() calls.

Worstje said:
I guess I don't care either way, but I see the source of the confusion, and would tentatively support removing the transparency flag from here and using the one set in WindowCreate instead, as it only seems to clutter the API and add little functional meaning.

Transparency flag from where? WindowResize() doesn't have one.

[EDIT] As an aside, I've long disliked the odd color-keying transparency miniwindows employ, and I'd love to see true alpha-channel support in miniwindows.

'Soludra' on Achaea

Blog: http://jonathan.com/
GitHub: http://github.com/Twisol
[Go to top] top

Posted by Worstje   Netherlands  (867 posts)  [Biography] bio
Date Tue 24 Aug 2010 07:48 AM (UTC)  quote  ]
Message
Twisol said:

Nick Gammon said:
*Resizing a window should not necessarily change its background colour. In fact if you are using the "transparent" flag (4) then you may be surprised and disconcerted if resizing the window changes the transparency.

I'll grant you that, but then why can't WindowResize() use the background color provided to WindowCreate()? I -would- be happier if there was just a WindowBackground() function, anyway; you can see the hackiness in the original post to make sure I only change the pertinent parameters.

I can see situations where one might want to increase the size of their miniwindow, but not have the new area have the same shade as the background color configured for that window. On the other hand, two WindowRect() calls could fix any such color issue.

I guess I don't care either way, but I see the source of the confusion, and would tentatively support removing the transparency flag from here and using the one set in WindowCreate instead, as it only seems to clutter the API and add little functional meaning.

Twisol said:
Nick Gammon said:
*What does it matter anyway? [...] Also it is used for the transparency.

Yes, exactly.

Thanks for the chuckle. :)
[Go to top] 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.


7,150 views.

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

[New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

Quick links: MUSHclient. MUSHclient help. Forum shortcuts. Posting templates. Lua modules. Lua documentation.

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Web site powered by FutureQuest.Net]