WindowBlinds breaks Window close detection?
Saturday, July 14, 2007 by htalvitie | Discussion: WindowBlinds
Dear Stardock,
Early last year I purchased Object Desktop and ran WindowBlinds 5.0 on my Windows XP.
Soon I noticed that most (if not all) skins break the close functionality on the system menu, e.g. double-clicking the icon on the left side of the title bar doesn't close the window as it should.
I struggled for a while and then finally uninstalled WB. I was unable to change my Windows habits.
Today, I was brave enough to give WindowBlinds another run. I installed the current 5.51 on a fresh Windows Server 2003, and found the exact same problem.
Am I really the only one with this problem, or are everybody else using some other shortcut for closing their windows? Since I actually work on my computer and must choose functionality over eye-candy, I was forced to uninstall WB once again. Maybe I'll retry again when 6.0 comes out.
I really like WB and would like to use it permanently so hopefully this single annoyance gets fixed.
For information, I made a screencast of my desktop with v5.51: http://s3.amazonaws.com/BugCast/WindowBlinds/WindowBreaks.html
Hope this helps in locating & fixing the problem!
Regards,
Harri
Early last year I purchased Object Desktop and ran WindowBlinds 5.0 on my Windows XP.
Soon I noticed that most (if not all) skins break the close functionality on the system menu, e.g. double-clicking the icon on the left side of the title bar doesn't close the window as it should.
I struggled for a while and then finally uninstalled WB. I was unable to change my Windows habits.
Today, I was brave enough to give WindowBlinds another run. I installed the current 5.51 on a fresh Windows Server 2003, and found the exact same problem.
Am I really the only one with this problem, or are everybody else using some other shortcut for closing their windows? Since I actually work on my computer and must choose functionality over eye-candy, I was forced to uninstall WB once again. Maybe I'll retry again when 6.0 comes out.
I really like WB and would like to use it permanently so hopefully this single annoyance gets fixed.
For information, I made a screencast of my desktop with v5.51: http://s3.amazonaws.com/BugCast/WindowBlinds/WindowBreaks.html
Hope this helps in locating & fixing the problem!
Regards,
Harri
 |
|
Page 3 of 3 | |
|
|---|
Daiwa
Reply #42 Monday, July 16, 2007 10:44 PM
JAFO -
Easy there... you're talking about my inspiration, you know, & still one of my favorite skins.
Reply #42 Monday, July 16, 2007 10:44 PM
This is old,[2001], grey and boring....
JAFO -
Easy there... you're talking about my inspiration, you know, & still one of my favorite skins.
Bichur
Reply #43 Tuesday, July 17, 2007 1:14 AM
Reply #43 Tuesday, July 17, 2007 1:14 AM
Firefox - WC Select - double clicking FF icon in upper left closes window
Same for IE7
Same for Opera
Same for IE7
Same for Opera
Bichur
Reply #44 Tuesday, July 17, 2007 1:17 AM
Reply #44 Tuesday, July 17, 2007 1:17 AM
not sure why the FF icon is on IE7 or Opera... eh, still works..
htalvitie
Reply #45 Tuesday, July 17, 2007 9:24 AM
Reply #45 Tuesday, July 17, 2007 9:24 AM
Some on this thread have blamed the skin author of the leaving the double-click action non-defined for the system icon on the top-left side in a window frame.
I'm using a Stardock-provided skin and checked the customization on system icon:
As far as I can tell, it's properly defined.
I'm using a Stardock-provided skin and checked the customization on system icon:
As far as I can tell, it's properly defined.
htalvitie
Reply #46 Tuesday, July 17, 2007 9:32 AM
I do not want to make double-clicking the title bar close the window..
Reply #46 Tuesday, July 17, 2007 9:32 AM
And you have a global override to make double-clicking the Titlebar "always" close the window.
I do not want to make double-clicking the title bar close the window..
htalvitie
Reply #47 Tuesday, July 17, 2007 9:51 AM
Reply #47 Tuesday, July 17, 2007 9:51 AM
Since people have misinterpreted my description of the problem repeatedly, I will once again add a visual aid. This time with an animated GIF, since some commenters haven't clearly analyzed the Flash versions.
I'll try to keep it simple this time.
I'll try to keep it simple this time.
ArileenDesign
Reply #48 Tuesday, July 17, 2007 10:16 AM
* double-click detected when second press occurs in less than 200 ms
did you try to change the speed of the double click occurs in less or more?
Reply #48 Tuesday, July 17, 2007 10:16 AM
* double-click detected when second press occurs in less than 200 ms
did you try to change the speed of the double click occurs in less or more?
htalvitie
Reply #49 Tuesday, July 17, 2007 11:34 AM
The 200 ms speed detection quote was from the Autohotkey script, not built-in Windows value. That script is a kludge, and doesn't provide a real solution.
Just in case you are interested in the built-in values, I have experimented the different double-click timeout and pixel thresholds. I have modified HKCU\Control Panel\Mouse\DoubleClickWidth and HKCU\Control Panel\Mouse\DoubleClickWidth (TweakUI, mouse control panel), but haven't noticed any change in the success ratio.
Since WindowBlinds bring more processing overhead, I would start solving this problem based in the timing-consideration. It has been discussed for example at Raymond Chen's blog post:
(Source: Logical consequences of the way Windows converts single-clicks into double-clicks)
Reply #49 Tuesday, July 17, 2007 11:34 AM
did you try to change the speed of the double click occurs in less or more?
The 200 ms speed detection quote was from the Autohotkey script, not built-in Windows value. That script is a kludge, and doesn't provide a real solution.
Just in case you are interested in the built-in values, I have experimented the different double-click timeout and pixel thresholds. I have modified HKCU\Control Panel\Mouse\DoubleClickWidth and HKCU\Control Panel\Mouse\DoubleClickWidth (TweakUI, mouse control panel), but haven't noticed any change in the success ratio.
Since WindowBlinds bring more processing overhead, I would start solving this problem based in the timing-consideration. It has been discussed for example at Raymond Chen's blog post:
On a heavily loaded system, delivery of messages can be delayed. If the WM_LBUTTONDBLCLK message is delayed more than the WM_LBUTTONDOWN message, then the time would expire and the program would incorrectly interpret the action as a single click, before subsequently receiving a double click message.
(Source: Logical consequences of the way Windows converts single-clicks into double-clicks)
htalvitie
Reply #50 Wednesday, July 18, 2007 1:47 AM
Reply #50 Wednesday, July 18, 2007 1:47 AM
Just my additional 5 euro cents:
On a Terminal Services connection, identical double-clicking closes window always. I'm using rdesktop v1.5.0 on a Gentoo Linux (IBM TP770ED) and a rdp5 connection to my Windows Server 2003 box.
Interesting (and also quite nice), that my WB-themed desktop works better on a remote desktop connection to a Linux box than natively. Just slower. :-/
And as somebody mentioned here earlier, it's not consistent from app to app. There seems to be a small group of programs allowing the clickety-click to work correctly.
For example, when I was closing the Control Panel window (and/or an Control Panel applet, don't remember now for sure which) by double-clicking, I was able to close it with a 100% success rate.
For most apps, however, it's closer to 0%.
On a Terminal Services connection, identical double-clicking closes window always. I'm using rdesktop v1.5.0 on a Gentoo Linux (IBM TP770ED) and a rdp5 connection to my Windows Server 2003 box.
Interesting (and also quite nice), that my WB-themed desktop works better on a remote desktop connection to a Linux box than natively. Just slower. :-/
And as somebody mentioned here earlier, it's not consistent from app to app. There seems to be a small group of programs allowing the clickety-click to work correctly.
For example, when I was closing the Control Panel window (and/or an Control Panel applet, don't remember now for sure which) by double-clicking, I was able to close it with a 100% success rate.
For most apps, however, it's closer to 0%.
ArileenDesign
Reply #51 Wednesday, July 18, 2007 2:56 AM
Reply #51 Wednesday, July 18, 2007 2:56 AM
If you like WB and you think it's a bug ok but developpers are now aware that it's possibly a bug cool, change your habits a little and use the close button in waiting for WB6 who maybe (or the clean install) will fix it.
If you cause of this bug dislike WB but you wanted tell them it's made, now you can disable it in waiting for WB6 who maybe (or the clean install) will fix it.
Just my 100€
If you cause of this bug dislike WB but you wanted tell them it's made, now you can disable it in waiting for WB6 who maybe (or the clean install) will fix it.
Just my 100€
htalvitie
Reply #52 Wednesday, July 18, 2007 12:02 PM
Speaking of fixes and versions... I haven't found a issue tracking system anywhere. It's difficult (if not impossible -- without testing each patch) to find out, what fixes are included in each release.
Reply #52 Wednesday, July 18, 2007 12:02 PM
waiting for WB6 who maybe (or the clean install) will fix it
Speaking of fixes and versions... I haven't found a issue tracking system anywhere. It's difficult (if not impossible -- without testing each patch) to find out, what fixes are included in each release.
Hankers
Reply #53 Wednesday, July 18, 2007 12:16 PM
Reply #53 Wednesday, July 18, 2007 12:16 PM
This has some info on release fixes - WB History
htalvitie
Reply #54 Wednesday, July 18, 2007 2:25 PM
Reply #54 Wednesday, July 18, 2007 2:25 PM
Yes, I'm familiar with the history file (shows up on the Stardock Central UI).
I was actually studying it last weekend, when I attempted to figure how much progress there has been within the last 12 months or so.
Can you tell based on that file? I couldn't.
The revision file doesn't provide any references to issues reported or requested by users. It has even stopped reporting dates for the releases (I can only guess why).
I would appreciate, if the revision file had info and references to this or other forums to give some idea what has been fixed and what not.
For example: "Version 5.52, released Aug 1, 2007, Minor tweaks: [xxx], see: url forums.wincustomize, post 123 ..".
I was actually studying it last weekend, when I attempted to figure how much progress there has been within the last 12 months or so.
Can you tell based on that file? I couldn't.
The revision file doesn't provide any references to issues reported or requested by users. It has even stopped reporting dates for the releases (I can only guess why).
I would appreciate, if the revision file had info and references to this or other forums to give some idea what has been fixed and what not.
For example: "Version 5.52, released Aug 1, 2007, Minor tweaks: [xxx], see: url forums.wincustomize, post 123 ..".
Buggerstop
Reply #55 Thursday, July 26, 2007 4:49 PM
Reply #55 Thursday, July 26, 2007 4:49 PM
I have a similar and equally annoying problem with WB.
To close a window, apparently a lot of people move the mouse to the "X" button, make sure they're right on top of it, and click it. That's a big waste of time. I simply move the mouse to the corner with one small motion (it's not very far depending on the mouse pointer speed and acceleration) and click without looking, because the far upper-right pixel is part of the button.
However, most of the WindowBlinds themes have an inactive area in the far corner, so I have to watch where the pointer is and put it right over the button. For me this was bad enough to be a showstopper.
I use the keyboard whenever I can to save time, but ALT+F4 isn't a very convenient key combo.
So this probably doesn't help you, but no, you're not the only one who chooses efficiency and functionality over eye candy.
To close a window, apparently a lot of people move the mouse to the "X" button, make sure they're right on top of it, and click it. That's a big waste of time. I simply move the mouse to the corner with one small motion (it's not very far depending on the mouse pointer speed and acceleration) and click without looking, because the far upper-right pixel is part of the button.
However, most of the WindowBlinds themes have an inactive area in the far corner, so I have to watch where the pointer is and put it right over the button. For me this was bad enough to be a showstopper.
I use the keyboard whenever I can to save time, but ALT+F4 isn't a very convenient key combo.
So this probably doesn't help you, but no, you're not the only one who chooses efficiency and functionality over eye candy.
Please login to comment and/or vote for this skin.
Welcome Guest! Please take the time to register with us.
There are many great features available to you once you register, including:
- Richer content, access to many features that are disabled for guests like commenting on the forums and downloading skins.
- Access to a great community, with a massive database of many, many areas of interest.
- Access to contests & subscription offers like exclusive emails.
- It's simple, and FREE!
|
|
Page 3 of 3 | |
|
|---|
Reply #41 Monday, July 16, 2007 10:10 PM
PSPX here, may be older version did not have the menu access from system icon. Even changing icon in SKS to close window, was set as system icon, still have menu from left side of icon, double click to close on right.
May have seemed 1/3-2/3 in FF as FF default icon may not be centered on background whereas PSP icon is a square and fill background so would be 1/2-1/2.