Re: Geometry issues ...

[Frank Worsley <fworsley shaw ca>]

> 	Fine - but lets not keep saving it - I mean drag the window around, and
> see it flicker - switch virtual desktop with a large directory and see
> the horrible slowness as it re-sorts, re-lays out and re-renders the
> whole thing. Also, the disk IO is just ugly.

I think a better solution would be to fine-tune the way we save the
metadata. Ideally the metadata system would only flush it to disk once
and not constantly while we save it, since that is not the case we
should just not save it all the time.

Instead of using an idle handler when saving the metadata I suggest we
use a timeout instead. Maybe a half-second timeout and we reset it to
half a second whenever a resize event occurs. That way we will only save
the metadata once, a half-second after the user finally stops resizing
the window. That is what I originally wanted to do, but then we thought
the idle handler would be ok.

[How often do you resize a window anyway? The idea here is that the
windows always restore in the size _you_ want, then there will be no
need to resize all the time. :)]

As for the metadata changed signal, obviously the fact that the window
position changed in the data is not important to anyone. Maybe we could
add a function that lets us save to metadata without emitting a changed
signal and then use that function for the window positions. That would
also be useful in otherplaces of the code, where the metadata change
should not emit a changed signal. A finer grained change signal might
also be a good idea.

> 	It is also the case that the geometry management doesn't work at all
> with virtual desktops, for example start nautilus, switch to the desktop
> to the right of it, killall -9 nautilus, watch the window appear in a
> totally manic position. [ to do with negative offsets, clipping etc. ]

That is a bigger problem that really has nothing to do with this
problem.

> 	Saving / obeying the geometry in the meta-data seems to only make sense
> to me for the "browse each URL in a new window" setting, and if that
> setting is not turned on, then we are really doing a dis-service to
> usability, since when you do 'Control-N' your windows all get piled on
> top of the other window instead of the WM doing something sensible with
> them.

That is unfortunate, but I must say I hadn't noticed it until now. I am
not sure how Windows handles that case, but I am sure we could come up
with a solution. 

Maybe do a check if a window with our URI is already displayed and if it
is then load our saved geometry but add a 15 pixel offset so that we are
in a slightly different position. Since metadata is saved at every
resize of the original window we can also be sure the offset is correct.

> 	So, action item 1: Don't do geometry saving for the single 
> 			   window browse mode - it just complicates the
> 			   semantics horribly.

The whole reason for this patch was that we have geometry saving, just
reverting it seems stupid to me.

> 	So, action item 2: Since we get a new window per URI _anyway_ we 			  
> only need to save the geometry on window close
> 			   and restore it on window creation.

It was agreed on the list that on window close was a bad idea. Read the
archives for more info.

- Frank