Zardoz2293
Advanced user
Всего сообщений: 302
Дата регистрации: 27.07.2010
|
Создано:
23.09.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
|
|
|
Alexander Mihalkin
Администратор
-retired-
Всего сообщений: 502
Дата регистрации: 21.04.2014
|
Создано:
23.09.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:| Цитата |
|---|
| 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.
|
|
|
Zardoz2293
Advanced user
Всего сообщений: 302
Дата регистрации: 27.07.2010
|
Создано:
08.10.2014 12:49:20
|
|
@Alexander
| Цитата |
|---|
| 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.
| Цитата |
|---|
Please also describe this paragraph in some other words or provide me with more details or examples:
| Цитата |
|---|
| 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
|
|
|
Alexander Mihalkin
Администратор
-retired-
Всего сообщений: 502
Дата регистрации: 21.04.2014
|
Создано:
09.10.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!
|
|
|
Zardoz2293
Advanced user
Всего сообщений: 302
Дата регистрации: 27.07.2010
|
Создано:
09.10.2014 21:40:27
|
Alexander,
| Цитата |
|---|
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. |
What are your thoughts?
Sincerely,
Lars
Sincerely,
Lars
|
|
|
aph
Advanced user
Всего сообщений: 50
Дата регистрации: 18.03.2014
|
Создано:
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.
|
|
|
aph
Advanced user
Всего сообщений: 50
Дата регистрации: 18.03.2014
|
Создано:
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.
|
|
|
Zardoz2293
Advanced user
Всего сообщений: 302
Дата регистрации: 27.07.2010
|
Создано:
11.11.2014 23:06:31
|
| Цитата |
|---|
| This is unexpected behavior and therefore more of a bug fix than a feature request. |
Sincerely,
Lars
|
|
|
aph
Advanced user
Всего сообщений: 50
Дата регистрации: 18.03.2014
|
Создано:
12.11.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. 
|
|
|
Zardoz2293
Advanced user
Всего сообщений: 302
Дата регистрации: 27.07.2010
|
Создано:
12.11.2014 04:27:33
|
| Цитата |
|---|
| 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'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
|
|
|
