Actual Tools
Forums list
New topics
Topics list
Search
Help
Login
Register

Messages 11 - 15 of 15
First | Prev. | 1 2 | Next | Last 

Topic: «AWM 8.2 - Final , Deactivated Field Values Being Applied » on forum: Technical Support   Views: 15588
 
Zardoz2293
 
 Posts: 302
Joined: 07/27/2010
Posted: 11/02/2014 08:09:58
 
 
Quote
And yes, Tray Icon Options: No icon is a default Windows value for this option for most of the applications, but not for all of them. Since this behavior is available to control using Actual Window Manager, I don't see any reason why it should be hidden from the user. What do you think?
I think when I view the "Index" and see anything which is displayed is a change in otherwise normal behavior, but this isn't the case. So, if in the case of "Tray Icon Options: No icon" and it isn't enabled anywhere in my configuration I see this as polluting the screen real estate in the Index. To me too much information isn't a benefit. It is also like the Index.Startup -- I find this information is not part of the otherwise normal tabs and the information is duplicated in the Index. Again, too much information as it is reflected in the other items. Perhaps displaying in 'green' the text for items which are 'Startup', such as:

Position Move at startup to monitor:  Having mouse pointer

Sincerely,
Lars
 
Top
Zardoz2293
 
 Posts: 302
Joined: 07/27/2010
Posted: 11/02/2014 19:02:16
 
 
 Alexander,

What are your thoughts on my breakdown of rule concepts (two postings above this one -- the very long posting).

Sincerely,
Lars
 
Top
Alexander Mihalkin
Administrator

-retired-
 
 Posts: 502
Joined: 04/21/2014
Posted: 12/03/2014 15:36:38
 
 
 Hi Lars,

I've re-read your messages regarding Default Settings.

Can you confirm that the main problem is that it's unconvenient to adjust Default Settings because you don't (and shouldn't, of course) remember which Specific Settings values are inherited from Default Settings and thus don't know which Specific Settings are going to be affected (and how exactly) by that adjustment?

What I say is this issue leaves the entire "Default->Specific inheritance" feature in question and I think we should consider some changes. Maybe disabling it at all or letting a user choose whether to activate it or not.

What are your thoughts?

support@actualtools.com
 
Top
Zardoz2293
 
 Posts: 302
Joined: 07/27/2010
Posted: 01/20/2015 19:52:40
 
 
 Well my thoughts are, I'm very frustrated. I find I'm extremely limited on what can be activated for Default Settings as the benefit I receive fr om what I want is less than the negative side-effects which are produced. With few exceptions, I can't imagine why anyone would want global/system wide all on default behavior of attributes which have by their definition conflicting scope of desired implementation.

Example: Transparency: While moving: 25%
I can't think of a reason why I would not want this to occur system wide, so this works.

Example: Title Buttons (too many combinations to specify)
It is very hard for me to think why anyone would want to specify system wide, all windows. This doesn't make any sense to me at all. This means, any specific application and all of its windows will get the title buttons when a caption exists. I'm not sure what other people are running on their systems, but I have hundreds, if not thousands, of applications covering many different domains and there are very few for which it makes any sense to have the children windows of those applications sub-classed with the default Title Buttons. In many cases it's just cluttered and obscures the captions. There are many cases where it doesn't work on the operating system tools. This is a perfect example wh ere less is more. Providing an endless list of Exceptions doesn't work for several reasons: #1) Significant time can be required to "find" the right combination to prevent the unwanted "Default Settings" leaking into the window, but then there may be "Default Settings" you do want, so now you need to create a "Specific Setting" to implement it so you can have consistency throughout. #2) Later on you decide to change a setting and can't figure out why it isn't working, only many, many hours later you discover a conflicting configuration setting. This becomes a real problem with the #32770 windows which typically have few bits of information which can be used to differentiate from one #32770 usage from another.

Each attribute (i.e., "Transparency While moving: 25%", "Title Buttons", etc.) needs to be configurable at the following scopes:

1. System-wide Effect = Applies to all windows and/or parent window as default in the entire system unless excluded at any level.

2. Application-wide = Applies to all windows and/or parent window for all applications as default which are specified as "Specific Settings"

3. Specific Setting = Applies to all the windows and/or parent window for a specific application.

Note: "parent window" = This would be the primary application window. Example: MDI-application if set for parent-only then none of the Child-MDI windows would receive this specific attribute applied to it.

Currently under AWM, my "Default Settings" are:
( a ) Position - Move at startup to monitor: Having mouse pointer
( b ) Size - After Moving to Another Monitor: Fit target monitor
( c ) Transparency - While moving: 25%
( d ) Title Buttons - Stay always-on-top|Move to monitor<next>|Put into Divider tile|Shift the buttons horizontally: +1

Proposed:
System-wide = All windows as default unless excluded at any level.
( a ) Position - Move at startup to monitor: Having mouse pointer
( b ) Size - After Moving to Another Monitor: Fit target monitor
( c ) Transparency - While moving: 25%

System-wide = All Parent windows as default unless excluded at any level.
( d ) Title Buttons - Stay always-on-top|Move to monitor<next>|Put into Divider tile|Shift the buttons horizontally: +1

What are your thoughts?

Sincerely,
Lars
 
Top
Vasiliy Ivachev
Administrator
-retired-
 
 Posts: 2073
Joined: 11/09/2010
Posted: 02/02/2015 15:00:50
 
 
 Hello Lars,

Actual Window Manager doesn't affect child windows except MDI-windows because many applications don't specify the "parent/child window" option. Thus a scheme with the "parent/child window" criterion can't be used for Actual Window Manager.

Could you please provide a more detailed description of differences between System-wide and Application-wide, Application-wide and Specific Setting and provide an example where you are unable to adjust necessary window rules using the current scheme?

We'll try to add an option that will allow to avoid the changes inheritance from Default to Specific Settings. In this case you are still able to quickly make some changes in a number of Specific Settings rules (you are able to select several Specific Settings, go to a tab you need, make some changes and apply these changes to selected Specific Settings). Will this solve some issues you are experiencing?

Best regards.
 
Top

Messages 11 - 15 of 15
First | Prev. | 1 2 | Next | Last 

User(s) reading this topic
Number of guests: 1, registered members: 0, in total hidden: 0
Forums list
New topics
Topics list
Search
Help
Login
Register



 
HomeProductsDownloadOrderContactsPress Map Privacy
Copyright © 2002-2024 Actual Tools. All rights reserved.

Windows and the Windows logo are trademarks of the Microsoft group of companies.