[Pharo-project] TilingWM improvements

Gastón Dall' Oglio gaston.dalloglio at gmail.com
Tue May 31 18:03:24 EDT 2011


2011/5/31 laurent laffont <laurent.laffont at gmail.com>

>
>> I write a test, to do the following (but you can load this method and you
>> can do now at hand to understand what I mean): maximize a window, use
>> topWindowMoveTop, then topWindowMoveBottonLeft. The result is that the
>> window is 1 / 8 the size of the screen (I attach screenshot). With the
>> resolution size of the current monitors or the possibility of having
>> multiple monitors and extend the main window Pharo through these, using
>> windows of 1 / 4 of the screen can be a waste, plus there are tools that do
>> not need more a small space.
>> Moreover, this way you can only have 4 move operations: topWindowMoveTop /
>> Bottom / Left / Rigth, since the rest of you combined the above.
>>
>
> Ah OK. Estelle at our local coding-dojo today told me that in xmonad
> there's this sort of behavior.
>
>
Cool :) I don't know about xmonad, but I like this:

xmonad is *tiling*.xmonad automates the common task of arranging windows, so
you can concentrate on getting stuff done.


> Maybe another way is to add #moveUpward /  #moveDownward / #moveLeftward /
> #moveRightward mapped to keyboard shortcuts.
>

yes, and these names are best for these operations. But considered to have
the fewest possible operations:

xmonad is *minimal*.out of the box, no window decorations, no status bar, no
icon dock. just clean lines and efficiency.



>
>
> Laurent.
>
>
>
>
>
>
>>
>>
>>
>>> I've implemented automatic refresh (see TilingWMSettings
>>> class>>initialize). May break the first time you load it if you have a
>>> version before the change.
>>>
>>
>> Yes, I see, thanks.
>>
>>
>>>
>>> There's a first shot of GUI controls for world snapshot / navigation but
>>> it needs more work to be intuitive.
>>>
>>>
>> There are many new features, it is time to make a new screencast:)
>>
>>
>>
>>
>>> Laurent.
>>>
>>> 2011/5/28 Gastón Dall' Oglio <gaston.dalloglio at gmail.com>
>>>
>>>> Laurent, coincidere change this method (o part of):
>>>>
>>>> TilingWM>>newTopWindowBoundsInArea: aBlock
>>>> SystemWindow topWindow bounds: (aBlock value: world clearArea).
>>>>
>>>> to this one:
>>>>
>>>> TilingWM>>newTopWindowBoundsInArea: aBlock
>>>> | topWindow |
>>>> (topWindow := SystemWindow topWindow) isMaximized
>>>> ifTrue: [ topWindow expandBoxHit. topWindow bounds: (aBlock value: world
>>>> clearArea) ]
>>>> ifFalse: [ topWindow bounds: (aBlock value: topWindow bounds) ]
>>>>
>>>>
>>>> For one hand this solve the problem of maximized state on moved window,
>>>> and for other hand apply recursive "moving" of window based in their current
>>>> bounds (but not usable display area) if that is not in state maximize (I
>>>> choose this rule for my convenience).
>>>>
>>>> ---
>>>>
>>>> When I load new version of this package, I use the Settings to see new
>>>> version de la barra, but the old version keep visible too, and I use
>>>> SHIFT-ALT-Click to see the halos and remove this. Is possible clean up of
>>>> older versions of bar automatically?
>>>>
>>>> ----
>>>>
>>>> And I see that you comming work in TWMWindowSnapshot :) I like it, I
>>>> hate wasting time accommodating the size and position of the windows
>>>> manually because I want to have another hearing, again and again!
>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20110531/08f54b97/attachment.html>


More information about the Pharo-dev mailing list