The Trunk: Kernel-mt.867.mcz
Locked
 
|
Marcel Taeumel uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-mt.867.mcz ==================== Summary ==================== Name: Kernel-mt.867 Author: mt Time: 12 August 2014, 9:29:37.682 am UUID: f469a687-9e68-6542-b0ae-01fde30002a8 Ancestors: Kernel-eem.866 New preference added for activating system windows on first mouse click. Works for all standard tools that subclass Model for their model. =============== Diff against Kernel-eem.866 =============== Item was changed: Object subclass: #Model instanceVariableNames: 'dependents' + classVariableNames: 'WindowActiveOnFirstClick' - classVariableNames: '' poolDictionaries: '' category: 'Kernel-Models'! !Model commentStamp: '<historical>' prior: 0! Provides a superclass for classes that function as models. The only behavior provided is fast dependents maintenance, which bypasses the generic DependentsFields mechanism. 1/23/96 sw! Item was added: + ----- Method: Model class>>windowActiveOnFirstClick (in category 'preferences') ----- + windowActiveOnFirstClick + <preference: 'Window Active On First Click' + category: 'windows' + description: 'Whether or not you want to directly interact with a widget (e.g. button) in a not-yet-active window' + type: #Boolean> + ^ WindowActiveOnFirstClick ifNil: [ false ]! Item was added: + ----- Method: Model class>>windowActiveOnFirstClick: (in category 'preferences') ----- + windowActiveOnFirstClick: aBoolean + + WindowActiveOnFirstClick := aBoolean.! Item was added: + ----- Method: Model>>windowActiveOnFirstClick (in category 'user interface') ----- + windowActiveOnFirstClick + + ^ self class windowActiveOnFirstClick! |
Re: The Trunk: Kernel-mt.867.mcz
|
Maybe an additional comment:
The feature itself is implemented in SystemWindow and Object (!). I decided to extend Model to make it accessible because all standard tools subclass from that. However, I am not that much pleased to see such a GUI feature implemented in Object. :) We may have to reconsider that in the future. For example, SystemWindow could employ the pattern #respondsTo: as it does in other places to check for the model interface. Best, Marcel |
Re: The Trunk: Kernel-mt.867.mcz
|
|
In reply to this post by commits-2
The idea of this preference is you can click buttons or other list-selections which might be visible in background windows and they will be immediately activated (and the window topped) even though the window wasn't already on top. So it can save you a click and its the way traditional MS Windows has behaved. In a pure sense, it is even somewhat less "modal". The trade-off is that you can no longer just sloppily Top-A-Window. Now you have to pay attention to ^where-in-the-background^ you're clicking, to make sure you don't accidentally activate something you don't want to activate.
For example, if the code-pane of a background Browser is dirty, look for a spot in the text pane itself. You'll lose any prior text-selection and cursor position, but at least it might be less-cumbersome than hitting one of the lists, because doing that would invoke a selection change, which will cause Squeak to prompt you whether you want to discard your changes. So, maybe best to just aim for the very edge of the window to top it... Oh, what was the benefit again?
I believe the user should "drive" the UI, but this creates more of a two-way interaction between Squeak and the user. Window-switching is very frequent, the user will have to "decide" where the safest spot to click every single switch. It's a bit more like being driven, than driving, and all just to save one click except, ror what has to be given up over the long run, it will actually add required clicks..
On Tue, Aug 12, 2014 at 2:30 AM, <[hidden email]> wrote: Marcel Taeumel uploaded a new version of Kernel to project The Trunk: |
Re: The Trunk: Kernel-mt.867.mcz
|
|
That's why it is a customizable preference. :)
I personally find that additional click annoying because I do most of the time not care whether a particular window is active or not. More precisely, I do not want to bother whether a window is active or not---especially for two windows that are barely overlapping. If I see content, I immediately want to interact with it and not continuously be surprised that nothing happend but an additional click is necessary. The user should drive the UI? Fine. But the UI should not interfere with the users intentions, which is typically interacting directly with data on screen. ;) You see, overlapping windows is only one way of organizing top-level containers in an environment. Eclipse does it differently, for example. If a window is overlapped to a problematic extent and needs to be repositioned or come to front, users have to interact with the UI explicetly and not with their data anymore. This should be a very rare case considering overall usability. If not, window placement has to be re-designed. :) You are right, window switching is frequent but manual re-layouting is not. Given this, the situation where users have to "find the safest spot to click" arguably occurs not that often. Modes that are not easily discoverable are annoying. This is-active property of system windows belongs into that category. Especially when working on large screens. ;) I will enable this preference in my images. The default stays "disabled" as it was before. Best, Marcel |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |