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


Topic: «Feature Request: Initial Position with Save on Exit , Much Needed Enhancement » on forum: Beta Testing   Views: 5949
 
Zardoz2293
 
 Posts: 302
Joined: 07/27/2010
Posted: 09/23/2014 05:05:49
 
 
 Gentleman,

I love AWM. However, I still struggle and waste significant time by my workflow being interrupted with windows/dialogs appearing in inappropriate locations or to correct an AWM rule which has undesired effects. This problem is amplified significantly with multiple monitors. In my opinion, I need to create a ton of rules in an attempt to simulate the desired environment stated below:

Example: Dual or Multi-Monitor System

Without exception each time I execute a specific application I expect it to be displayed with the following rules for Application, Window, or Dialog:

(1) First time: Always center-middle on the monitor with the mouse pointer (unless it is forced to a specific monitor) and if it's an Application always maximized (if attribute exists).
(2) Non-First time: Displayed at the last position and size on exit.
(3) Always retains exact position and size (maximized/minimized) settings from last execution.
(4) If "window/dialog" is child of Application then center-middle of that Application (unless rule #3 applies).

NOTES: Above rules always exist unless the monitor from the last session or forced monitor now doesn't exist or resolution has changed, then the behavior should as if it is the first time executed (rule #1). Ability to override specific behavior on rare case by case basis. Obviously, a way to associate out-of-process Applications, Windows, or Dialogs with another Application so behavior is associated with that Application rather than an unassociated behavior.

What are your thoughts and ideas?

Most Sincerely,
Lars

Sincerely,
Lars
 
Top
Alexander Mihalkin
Administrator

-retired-
 
 Posts: 502
Joined: 04/21/2014
Posted: 09/23/2014 22:22:36
 
 
 Hello, Lars!

Thank you for your post!

That's quite a problem you define.

I think the feature you mean would be to add the stand-alone rule for the first-time opened windows, which would have the first priority among all the rules (Default and Specific) and would also apply to all windows after multiple monitors reconfiguration. What do you think?

Please also describe this paragraph in some other words or provide me with more details or examples:
Quote
Ability to override specific behavior on rare case by case basis. Obviously, a way to associate out-of-process Applications, Windows, or Dialogs with another Application so behavior is associated with that Application rather than an unassociated behavior.

Best regards.

support@actualtools.com
 
Top
Zardoz2293
 
 Posts: 302
Joined: 07/27/2010
Posted: 10/08/2014 12:49:20
 
 
 @Alexander

Quote
I think the feature you mean would be to add the stand-alone rule for the first-time opened windows, which would have the first priority among all the rules (Default and Specific) and would also apply to all windows after multiple monitors reconfiguration. What do you think?

Yes, but it seems to me to be an extension of the Default Settings. The direction I'm coming fr om is trying to significantly simplify and lim it the number of specific window rules. We humans sure love order, it might be different order from the person down the street but it's still order. Therefore, I suspect this capability discussed here could/would be used by most as everyone wants the same behavior for all of their applications, windows, notifications, etc. with a few exceptions.



Quote
Please also describe this paragraph in some other words or provide me with more details or examples:

Quote
Ability to override specific behavior on rare case by case basis. Obviously, a way to associate out-of-process Applications, Windows, or Dialogs with another Application so behavior is associated with that Application rather than an unassociated behavior.

In my opinion everyone has a very specific behavior which they want applied to virtually all applications/windows on their system. Hence what you described as a potential solution, "First/Monitors Change Event" rules applied.

Example on the out-of-process application, windows or dialogs which actually belong to another Application. The product XYplorer.exe uses a copy program called XYcopy.exe. AWM needs to have the ability when/if a rule is created for XYplorer.exe the end-user can "add" associated applications to the rules for XYplorer so the behavior for say XYcopy is inherited from the XYplorer rules. I realize in AWM you can copy existing rules, but there is no visual association when one application is effectively controlled or effected by the parent application. It just makes management of all the rules more complex from an end-user perspective. Often, if I change the parent application, I forget about the associated subordinate application rules until I encounter application behavior which is undesired. I think I'm like most people and desire to solve a problem the first time and not have to continue addressing down the road problems for which I thought was previously solved.

Does that help in clarification?

What are your thoughts and concerns?

Thanks,
Lars

Sincerely,
Lars
 
Top
Alexander Mihalkin
Administrator

-retired-
 
 Posts: 502
Joined: 04/21/2014
Posted: 10/09/2014 21:12:36
 
 
 Dear Lars,

Thank you for your reply!

1. The "first-time run" rule: please tell me (or show me if it's possible) exactly how you imagine the interface of that Default Settings extension.

2. Would Specific Settings grouping be suitable? So that you could create folders and place certain Specific Settings into that folders based on the parent application or on any other criteria.

Best regards!

support@actualtools.com
 
Top
Zardoz2293
 
 Posts: 302
Joined: 07/27/2010
Posted: 10/09/2014 21:40:27
 
 
 Alexander,

Quote
1. The "first-time run" rule: please tell me (or show me if it's possible) exactly how you imagine the interface of that Default Settings extension.

2. Would Specific Settings grouping be suitable? So that you could create folders and place certain Specific Settings into that folders based on the parent application or on any other criteria.
I would enjoy addressing and expressing my thoughts on this subject. However, I'm experiencing problems with the "Default Settings" (as described in multiple postings) and I think it would be best if in AWM 8.2 the "Default Settings" was working correctly (or at a minimum we identify the cause of the problem I'm experiencing). I don't want to pollute a discussion when I'm having problems with the current implementation. When it is working correctly I'm expecting my perspective will change (one way or another).

What are your thoughts?

Sincerely,
Lars

Sincerely,
Lars
 
Top
aph
 
 Posts: 50
Joined: 03/18/2014
Posted: 11/11/2014 15:13:32
 
 
 I think this is reasonable and expected it to work the same way. My expectation was not for any any visual change in the interface at all. Simply to allow both "Move at startup" and "Save position" checkboxes to be selected at the same time (especially since they are checkboxes, which are combinatory and not mutually exclusive like radio buttons.)

The functionality that is very specifically defined in the original post could then be possible along with many other combinations, in a logical way, and form would be aligned with function of checkboxes. In the current implementation, they look like checkboxes but function like radio buttons. This is unexpected behavior and therefore more of a bug fix than a feature request.
 
Top
aph
 
 Posts: 50
Joined: 03/18/2014
Posted: 11/11/2014 15:28:52
 
 
 If desirable to make a subtle interface change to reflect this better, this approach could be best represented by populating the (currently invisible yet stored in the .ini) saved values back up into the text field for horizontal and vertical shift.

The radio button for which monitor would still keep its effect, and the values populated in the text field would be subtracted if any monitor other than primary is sel ected so they are replicated respective to the radio button selection for monitor.

This approach would avoid questions like "Why isn't Save Position working?" since the coordinates are clearly shown as present, and would also disambiguate the current confusion arising fr om hidden numbers stored in the configuration file only.
 
Top
Zardoz2293
 
 Posts: 302
Joined: 07/27/2010
Posted: 11/11/2014 23:06:31
 
 
Quote
This is unexpected behavior and therefore more of a bug fix than a feature request.
It's both.

Sincerely,
Lars
 
Top
aph
 
 Posts: 50
Joined: 03/18/2014
Posted: 11/12/2014 03:54:28
 
 
 Of course. I wasn't trying to contradict anything you said, I was just mentioning that it's a bug fix because I believe those are higher priority than feature requests and we both want it in there.  :D
 
Top
Zardoz2293
 
 Posts: 302
Joined: 07/27/2010
Posted: 11/12/2014 04:27:33
 
 
Quote
Of course. I wasn't trying to contradict anything you said, I was just mentioning that it's a bug fix because I believe those are higher priority than feature requests and we both want it in there. smile:D
I'm right with you.

I've been reading all your postings and I appreciate your insight, comments, and suggestions. I'm hoping the developers feel the same.

I really like AWM, but there are a few things which make managing one's environment a heavy handed on an administrative level. I hope everyone will take the time on the forum to provide feedback so we can resolve to everyone's benefit.

Sincerely,
Lars
 
Top


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.