[Openmcl-devel] window size & position

Janusz Podrazik info at mracpublishing.com
Thu May 28 12:14:41 PDT 2009


On Thu, May 28, 2009 at 20:19, Gary Byers <gb at clozure.com> wrote:
> We've been using the builtin Cocoa facilities for keeping track of
> window size and position across sessions in the trunk version of the
> IDE for a few weeks now.  That's not quite the same as saving and
> restoring the whole state of the world between sessions, but it does
> mean that named editor documents and listeners open with the size
> and position that they had when they were last closed.
>

is not working on/with Clozure CL-x8664 (Welcome to Clozure Common
Lisp Version 1.3-r12149M  (DarwinX8664) !)
no position or size of any window, listener or editor is restored to
the position or size you are have save/close the window or quit the
CCL.

good example for getting back were you have left it off is VisualWorks.
most of the time my work is 'in progress', hardly ever completed.
returning to you work were you left off is essential in my mind.
it is essay to star new one then restore each time the previous one
which may include many files, ref docs etc... the productivity and
piece of mind is apparent.

we are talking about a preferences option - and useful option too.

> There aren't too many things that can go wrong there.  Cocoa just
> writes the window's bounds rectangle and the screen's to the
> preferences file, and I assume that if you change monitors or screen
> resolutions between sessions it'll try to do something reasonable to
> adjust to that.  (I haven't tried this, and don't know how reasonable
> its behavior is.)  Someone has said (somewhere) that if a saved
> window's height is exactly the same as the screen height it's restored
> to slightly smaller dimensions; if that's true, I don't know why or
> what should be done about it, but I'm willing to say that the scheme
> works out-of-the-box in 99% of all cases, AFAIK.

if we take all possibile scenarios in account (and we often try to do
that - i do and fall many times :-) ) we never would finish or make
any useful/time essential decisions.
i think many of use - i assume - would welcome this functionally.

>
> Nothing in that scheme knows or cares if the file's contents have
> changed between sessions; we're just saying that "/path/to/foo.lisp"
> has a certain frame rectangle associated with it, and that whenever
> "/path/to/foo.lisp" is opened, it should use the size and position
> specified by that rectangle.
>
> Some of the other things that people say they want are more sensitive
> to whether or not the file's externally modified (by a source code
> control system, by editing it in emacs, ...) between sessions.  (For
> instance, keeping track of the selection in some externalizable format -
> integers representing offset and length - would be Really Neat if the
> file isn't externally modified between sessions and could be Really
> Stupid if such an external modification occurred and was undetected.
>
> Those aren't necessarily insurmountable problems, but I'm not sure
> whether it's desirable for an editor to act like it's the only thing
> that could modify a text file and to treat violations of that
> assumption as being exceptional in some way; that doesn't seem to
> have much to do with the real world.
>
> On Thu, 28 May 2009, Janusz Podrazik wrote:
>
>> is there any possibility to add to the preferences the functionality
>> which is indicated but not implemented.
>> i am talking about the size, position and memory of all windows,
>> dialog boxes etc...
>> i think would be very desirable to open CCL and see all the editors
>> open were you left the CCL last.
>> the 'Quit' by default should store all the information - with out
>> extra 'snapshot' functionality.
>> it is very time consuming and frustrating to live with out this
>> functionality.
>>
>> any time soon?
>>
>> janusz podrazik
>> _______________________________________________
>> Openmcl-devel mailing list
>> Openmcl-devel at clozure.com
>> http://clozure.com/mailman/listinfo/openmcl-devel
>>
>>
>



More information about the Openmcl-devel mailing list