What is the possibility of setting Muschclient as skinnable or at the very least transaprent? This came up when I found out that I tend to like to watch DVD's while running Mush Client and that's about it. With a transparent setting this would give more of the screen available?
Skins or Transparency
Posted by Tricuspa on Mon 20 Aug 2001 05:27 AM — 25 posts, 114,863 views.
Interesting idea. I have added that as suggestedion #402.
Hmmmm - seeing this suggestion got me deciding to try out a bunch of my programs (since I run with a lot of transparent stuff on my Win2k box). I don't know if you've tried any third party programs or not Tricuspa - but like I said, I went ahead and did.
WindowFX...er - it doesn't like MUSHclient a whole lot - it sets the transparency of the main window okay, but then all of the dialogs display... weirdly to say the least. There is a little utility out there though (I'll see if I can dig up the URL in a moment) which sets transparency by individual window IDs, and so would ignore things like the config dialog. There's a few problems though: 1. If I remember correctly, it determines the window ID from the title bar caption - so you'd have to set it for each world you open. 2. You need to change your window backgrounds from black - black isn't transparent. ^_^ 3. The little utility (naturally) requires 2K or XP - and if your video driver doesn't support hardware level alpha blending it's going to be SLOW. If you want to try it though, the URL is: http://vitiy.boom.ru/progs.htm
WindowFX...er - it doesn't like MUSHclient a whole lot - it sets the transparency of the main window okay, but then all of the dialogs display... weirdly to say the least. There is a little utility out there though (I'll see if I can dig up the URL in a moment) which sets transparency by individual window IDs, and so would ignore things like the config dialog. There's a few problems though: 1. If I remember correctly, it determines the window ID from the title bar caption - so you'd have to set it for each world you open. 2. You need to change your window backgrounds from black - black isn't transparent. ^_^ 3. The little utility (naturally) requires 2K or XP - and if your video driver doesn't support hardware level alpha blending it's going to be SLOW. If you want to try it though, the URL is: http://vitiy.boom.ru/progs.htm
I'm not using Win2K if that is what you are referring to, so that will have to wait. :)
Hmm... I would really like to see a Windows client with transparent windows as well. Especially if only the background is clear, but the text is still solid ( like on a Macintosh or Linux ). Hopefully, a response to this post like 2 years later will revitalize the effort or something.
Well Darren. Guess what! Mushclient provides a GetFrame command that lets you pass the window handle for the main window to any program you can call from a script. Using GetChildWindow or the like to step through and enumerate each Mushclient window, you could use a simple program you make yourself to set the background of any or all windows to be transparent. The only control/window type this doesn't 100% work with is the VB Tab/Property Sheet, but from in C++ you can tell the primary container to become transparent, even if the control doesn't provide the attribute. The only real anoyance is that anything below XP has no *native* support for alpha channel, so you are stuck with full transparency on parts/all of the background or a solid background and image. :(
To handle Alpha channel Nick would have to literally rewrite all the Draw functions built into the stardard MFC libraries to capture and blend the stuff behind the window using the alpha channel information in the image. And since PNG is the only decent format supporting Alpha channel, he would also have to add libpng.dll to the client. Would be so much cooler though... Sigh!
To handle Alpha channel Nick would have to literally rewrite all the Draw functions built into the stardard MFC libraries to capture and blend the stuff behind the window using the alpha channel information in the image. And since PNG is the only decent format supporting Alpha channel, he would also have to add libpng.dll to the client. Would be so much cooler though... Sigh!
I don't have XP and don't intend to install it for the forseeable future. You have heard of the definition of an "upgrade" ...
"Swap your existing bugs for new ones".
However I would qualify that a bit, based on my experience with Windows:
"Swap your existing bugs for new ones, and watch your PC run much more slowly.".
Shadowfyr, do you want to do an example of the transparent window thing, if you can make it work?
"Swap your existing bugs for new ones".
However I would qualify that a bit, based on my experience with Windows:
"Swap your existing bugs for new ones, and watch your PC run much more slowly.".
Shadowfyr, do you want to do an example of the transparent window thing, if you can make it work?
Hmm. Not really.. I don't know C++ very well. I would know how to make something skinnable in VB, but not C++.
In general... You are going to be dealing with Device Contexts. Basically something like:
temp = GetCompatibleDC(self.DC);
...do blending/transparency masking here...
self.DC = temp;
Or something more or less like that. There may be some special command you actually need use to copy one DC to another. The brief attempt I made to try to use this resulted in my simply turning the "Auto-redraw" option off and using a Firework.Refresh command instead after everything was redrawn. :(
So, in the blending/masking step you either draw the image into the DC completely, mask out one color (say 255) as 'transparent' and not copy it at all. I think Windows can and will do this automatically, just not sure how. To blend things though, you would need to get the stuff 'under' your window somehow from Windows then average 'your' background onto that based on the percent of transparency you want. This obviously is more complicated. Unfortunately I would have to go hunting for examples of how this works the same as you.
One possibility though is OpenGL, which may already supply functions that can do some of this automatically and even properly support alpha channel. It would have the advantage of being a free library (unlike Direct3D) and compatible with Linux when ever you port the client over. The draw back is that if the card says it can do alpha channel or bitmap scaling, etc., but doesn't impliment it properly, there is no way to force OpenGL to use its own software emulation instead of the defective implimentation on the card. Direct3D would have the same problems. Coding it yourself is 100% certain to work, but far more complicated.
I may nose around a bit and see if I can find some usable example of doing any of this in C++, but most people are bound to take the simple way out and use stuff like OpenGL, even if it doesn't work 100% of the time on every system.
In general... You are going to be dealing with Device Contexts. Basically something like:
temp = GetCompatibleDC(self.DC);
...do blending/transparency masking here...
self.DC = temp;
Or something more or less like that. There may be some special command you actually need use to copy one DC to another. The brief attempt I made to try to use this resulted in my simply turning the "Auto-redraw" option off and using a Firework.Refresh command instead after everything was redrawn. :(
So, in the blending/masking step you either draw the image into the DC completely, mask out one color (say 255) as 'transparent' and not copy it at all. I think Windows can and will do this automatically, just not sure how. To blend things though, you would need to get the stuff 'under' your window somehow from Windows then average 'your' background onto that based on the percent of transparency you want. This obviously is more complicated. Unfortunately I would have to go hunting for examples of how this works the same as you.
One possibility though is OpenGL, which may already supply functions that can do some of this automatically and even properly support alpha channel. It would have the advantage of being a free library (unlike Direct3D) and compatible with Linux when ever you port the client over. The draw back is that if the card says it can do alpha channel or bitmap scaling, etc., but doesn't impliment it properly, there is no way to force OpenGL to use its own software emulation instead of the defective implimentation on the card. Direct3D would have the same problems. Coding it yourself is 100% certain to work, but far more complicated.
I may nose around a bit and see if I can find some usable example of doing any of this in C++, but most people are bound to take the simple way out and use stuff like OpenGL, even if it doesn't work 100% of the time on every system.
Hmm. Ok.. A preliminary search reveals:
http://msdn.microsoft.com/library/en-us/vclib/html/vcrefCImageDraw.asp
Which may or may not be .NET related. If so, then there is:
http://www.bridgespublishing.com/articles/issues/0109/Drawing_transparent_images.htm
Which basically explains how to do it without necessarilly having CImage.Draw to work with. However, BMP is only able to store a single transparency mask color, so you still have to have support of GIF (which only allows 256 colors) or libpng.dll, which will allow you to load 32-bit PNG files.
Neither solution works under Windows 95, if you are even worried about that and it may be necessary to get the Windows version and use Tranparentblt or a normal draw under 95, instead of AlphaBlend. Not really that complicated. ;)
In case you want them, the search terms I used where:
alpha channel transparency Windows +98 "C++" -directdraw -XP
http://msdn.microsoft.com/library/en-us/vclib/html/vcrefCImageDraw.asp
Which may or may not be .NET related. If so, then there is:
http://www.bridgespublishing.com/articles/issues/0109/Drawing_transparent_images.htm
Which basically explains how to do it without necessarilly having CImage.Draw to work with. However, BMP is only able to store a single transparency mask color, so you still have to have support of GIF (which only allows 256 colors) or libpng.dll, which will allow you to load 32-bit PNG files.
Neither solution works under Windows 95, if you are even worried about that and it may be necessary to get the Windows version and use Tranparentblt or a normal draw under 95, instead of AlphaBlend. Not really that complicated. ;)
In case you want them, the search terms I used where:
alpha channel transparency Windows +98 "C++" -directdraw -XP
I don't think it's that complicated to do in XP, since it has native support for alpha blending, but I don't think it would be easily (if at all) done in other OSes... Oh and by the way, you can't watch DVDs under transparent windows because of the overlay, it just becomes a blackish colour :P Hm, look at these articles:
http://www.codeguru.com/Cpp/W-D/dislog/miscellaneous/article.php/c5065/
and
http://www.codeguru.com/Cpp/W-D/dislog/miscellaneous/article.php/c5019/
The second one seems to work on Win98 etc as well, but may be shareware... Or probably not.
http://www.codeguru.com/Cpp/W-D/dislog/miscellaneous/article.php/c5065/
and
http://www.codeguru.com/Cpp/W-D/dislog/miscellaneous/article.php/c5019/
The second one seems to work on Win98 etc as well, but may be shareware... Or probably not.
Hmm. So basically Windows 2000 and XP provide an API to automatically employ an alpha value, where in 98, NT and ME you have to adjust the alphachannel of your image and use the AlphaBlend API call to draw it.
This just means you have to either ignore the API in 2000 and XP, then use your own implimentation that employs the AlphaBlend functions that 98, NT, ME, 2000 and XP all have and ignore the setting if in 95 *or* alternatively implement code to use the 2000/XP functions if running on that, the 98/NT/ME version if running there or ignore it under 95.... I think we would be better off and less bloated to go the first route and impliment something based on the code from my second link, which will work in everything except 95.
This just means you have to either ignore the API in 2000 and XP, then use your own implimentation that employs the AlphaBlend functions that 98, NT, ME, 2000 and XP all have and ignore the setting if in 95 *or* alternatively implement code to use the 2000/XP functions if running on that, the 98/NT/ME version if running there or ignore it under 95.... I think we would be better off and less bloated to go the first route and impliment something based on the code from my second link, which will work in everything except 95.
Having talked with Magnum about this.. It is possible, depending on how it works under pre-2000/XP system to have settings to define the 'level' of transparency support and to use the full 2000/XP code when running on that for speed reasons. The levels would be:
1. No skin.
2. Solid skins.
3. Skinning with full transparent areas.
4. Alpha-skins 98/NT/ME. - dimmed out in settings and defaults to option 3 if on 95.
5. Alpha-skins 2000/XP. - dimmed out in settings and defaults to option 4 if on an earlier OS.
Depending on how/if alphablend() slows things down on 98, it may be slightly slower than doing skins with solid colors or patches that are completely transparent. This also means that it *may* be slower than the method in 2000/XP, so option 4 should automatically upgrade to 5 internally if on an XP system. Maybe only 4 options are needed in that case.
However, this is of course based on the assumption that a solid image will be handled differently than a full 32-bit by the OS or any real difference exists between them in speed. Some experiments are in order. Unfortunately I don't know enough C++ to make 'a' window, let alone one that has these effects. :(
1. No skin.
2. Solid skins.
3. Skinning with full transparent areas.
4. Alpha-skins 98/NT/ME. - dimmed out in settings and defaults to option 3 if on 95.
5. Alpha-skins 2000/XP. - dimmed out in settings and defaults to option 4 if on an earlier OS.
Depending on how/if alphablend() slows things down on 98, it may be slightly slower than doing skins with solid colors or patches that are completely transparent. This also means that it *may* be slower than the method in 2000/XP, so option 4 should automatically upgrade to 5 internally if on an XP system. Maybe only 4 options are needed in that case.
However, this is of course based on the assumption that a solid image will be handled differently than a full 32-bit by the OS or any real difference exists between them in speed. Some experiments are in order. Unfortunately I don't know enough C++ to make 'a' window, let alone one that has these effects. :(
From what i've seen, transparent windows are a bit slow to redraw, etc, but that could be just an impression...
Yeah. I figured they would tend to be. Purely transparent ones probably wouldn't be, since all they do is *not* draw the background. All forms of windows that employ transparency in the background, like the curved edges on Getright skins, use an image that gets drawn over the background. Normal windows are a solid color, so just use a quick fill that is handled by the windowing code.
The question I want answered is, "Is alphablend significantly slower than a solid image (with or without sections of transparency) and if so is the 2000/XP solution faster. If the result is like:
None = fastest.
Skin/partial transparent = slower.
Alphablend = slowest.
2000/XP alphablend = Something between the fastest and slowest.
If the last possibility above is true, then obviously checking the OS version or API to see if it supports that method and using it instead is much better than just using the 98/ME/NT version of alphablending. If alphablending is in fact slower (which is likely) than doing normal transparency or an image, then it makes sense to have the option to disable it on slower machines, same if it is in fact somehow slower to use an image that has transparent sections, instead of a solid one.
Knowing that it will be slower is a given, how much and which things should be used when available given the highest settings on a particular OS is an unknown.
The question I want answered is, "Is alphablend significantly slower than a solid image (with or without sections of transparency) and if so is the 2000/XP solution faster. If the result is like:
None = fastest.
Skin/partial transparent = slower.
Alphablend = slowest.
2000/XP alphablend = Something between the fastest and slowest.
If the last possibility above is true, then obviously checking the OS version or API to see if it supports that method and using it instead is much better than just using the 98/ME/NT version of alphablending. If alphablending is in fact slower (which is likely) than doing normal transparency or an image, then it makes sense to have the option to disable it on slower machines, same if it is in fact somehow slower to use an image that has transparent sections, instead of a solid one.
Knowing that it will be slower is a given, how much and which things should be used when available given the highest settings on a particular OS is an unknown.
problem with transperency/skins is that, they generally cause the program to slow down.. and I use mushclient for it's speed, not the way it looks (I have a slow computer, heh)
You would have the option to turn it off, that shouldn't be a big problem...
New function added to version 3.83 to allow you to make the MUSHclient application transparent to the amount that you desire.
Here is an example of a semi-transparent window:
An interesting trick is to do this:
What this does is make the gray "frame background" colour transparent. Thus the MUSHclient worlds themselves are full intensity, but in the gaps between the worlds (and notepad windows) you can see the desktop underneath. I think someone was asking about that a while back.
Transparency (GetSysColor (12), 255)
What this does is make the gray "frame background" colour transparent. Thus the MUSHclient worlds themselves are full intensity, but in the gaps between the worlds (and notepad windows) you can see the desktop underneath. I think someone was asking about that a while back.
To illustrate that point, here is an example of making the gray background transparent, so you can see the desktop through it, but the rest is full opacity:
A word of caution about using "keyed" transparency like in the above example.
I was playing around with another problem, when the "map" which appears in SMAUG FUSS seemed all broken up. It turned out the reason was that the map used gray | characters in it, and since I had made gray transparent, the desktop was showing through, making the map look really strange.
One fix is to go into the ANSI colour configuration, and change the "Bold black" colour (top one in the RH column) to be slighly different (eg. click on the "Darker" button once"), or simply edit that colour to make it a little different. That way the transparency no longer keys on the gray, and you don't get windows underneath showing through whenever there is gray text.
I was playing around with another problem, when the "map" which appears in SMAUG FUSS seemed all broken up. It turned out the reason was that the map used gray | characters in it, and since I had made gray transparent, the desktop was showing through, making the map look really strange.
One fix is to go into the ANSI colour configuration, and change the "Bold black" colour (top one in the RH column) to be slighly different (eg. click on the "Darker" button once"), or simply edit that colour to make it a little different. That way the transparency no longer keys on the gray, and you don't get windows underneath showing through whenever there is gray text.
Sorry for the thread necromancy, but this is the closest match I can find for my question: Did the concept of customisable skins go any further?
The summary for suggestion #402 is "Transparent option wanted", and (from reading this thread) it seems that that part of the suggestion has been addressed.
But what I'm interested in is the idea of customisable opaque backgrounds, colours, icons, buttons, etc, so that skins can be designed around specific mud themes.
The summary for suggestion #402 is "Transparent option wanted", and (from reading this thread) it seems that that part of the suggestion has been addressed.
But what I'm interested in is the idea of customisable opaque backgrounds, colours, icons, buttons, etc, so that skins can be designed around specific mud themes.
More recently, miniwindows let you put images behind or in front of your main text. You can also shift the scrolling text portion inwards from the edges.
See this thread for some examples:
http://www.gammon.com.au/mushclient/mw_other.htm
Also take a look at this:
http://www.gammon.com.au/forum/?id=9580
Miniwindows let you implement buttons and icons, there are examples of icons which you click to do things, with cooldown clocks on them, here:
http://www.gammon.com.au/forum/?id=9359
See this thread for some examples:
http://www.gammon.com.au/mushclient/mw_other.htm
Also take a look at this:
http://www.gammon.com.au/forum/?id=9580
Miniwindows let you implement buttons and icons, there are examples of icons which you click to do things, with cooldown clocks on them, here:
http://www.gammon.com.au/forum/?id=9359
Very nice indeed. So I could effectively create a graphical border around the main display, using the same theme as my website - and also use the same button styles as I use on my website?
A large border would probably be undesirable as it would reduce the amount of space available for useful windows, but a small border could be used to help give the client the same look and feel as my website, which I think could prove more appealing to first-time mudders.
It strikes me that this is pretty much full skinning support, and you could reasonably add it to the list of features that MUSHclient offers.
A large border would probably be undesirable as it would reduce the amount of space available for useful windows, but a small border could be used to help give the client the same look and feel as my website, which I think could prove more appealing to first-time mudders.
It strikes me that this is pretty much full skinning support, and you could reasonably add it to the list of features that MUSHclient offers.
KaVir said:
Very nice indeed. So I could effectively create a graphical border around the main display, using the same theme as my website - and also use the same button styles as I use on my website?
Very nice indeed. So I could effectively create a graphical border around the main display, using the same theme as my website - and also use the same button styles as I use on my website?
Yes I don't see a problem with that.
KaVir said:
A large border would probably be undesirable as it would reduce the amount of space available for useful windows, but a small border could be used to help give the client the same look and feel as my website, which I think could prove more appealing to first-time mudders.
A large border would probably be undesirable as it would reduce the amount of space available for useful windows, but a small border could be used to help give the client the same look and feel as my website, which I think could prove more appealing to first-time mudders.
Well the size of the border is totally under your control. You may have a bigger one on the left, say, and put in status bars, buttons, minimap, etc. if you wanted to.