gEDA-dev: GschemDialog (work in progress)

[Ivan Stankovic]

On Wed, May 09, 2007 at 02:47:37PM +0100, Peter Clifton wrote:
> When speaking of practicalities, I meant that the:
> 
> +   data = g_key_file_to_data(dialog_geometry, NULL, NULL);
> +   file = g_build_filename(g_get_home_dir(), ".gEDA",
> DIALOG_GEOMETRY_STORE, NULL);
> +   g_file_set_contents(file, data, -1, NULL);
> +   g_free(data);
> +   g_free(file);
> 
> after save,
> 
> and all the code which loads the settings file before the geometry is
> restored, would need moving elsewhere. Its probably cleaner (for people
> like me who use laptops - the HDD can spin up and down on file access)
> to save on program exit.
> 
> To keep the current behaviour, we could just put the load check / save
> routine before and after the save / restore signal is emitted.

I admit, the current behaviour is really dumb, but I wanted to send the
patch quickly so I didn't bother with it. The right thing to do is, of
course, to dump geometry info on program exit.

> > > 3. Standard GTK dialogs don't gain the extra functionality by default,
> > >    meaning the attached patch doesn't affect the file dialogs. Whether
> > >    or not that is a problem is debatable. I don't think GTK does too 
> > >    badly in positioning and opening its standard dialog windows.
> 
> Ok - perhaps we should remove the code from the confirmation dialogs in
> that case.

Yes.

> With dialogs opening from hot-keys, I wonder what other positioning
> metrics we might use - like:
> 
> gtk_window_set_position( window,...)
> 
>   GTK_WIN_POS_NONE,
>   GTK_WIN_POS_CENTER,
>   GTK_WIN_POS_MOUSE,               <--- Is this useful?
>   GTK_WIN_POS_CENTER_ALWAYS,
>   GTK_WIN_POS_CENTER_ON_PARENT     <--- Is this useful?

Actually, I really like the current way (GTK_WIN_POS_NONE).
GTK_WIN_POS_MOUSE would be confusing for the user since the 
mouse pointer can be anywhere. GTK_WIN_POS_CENTER_ON_PARENT
might be useful, but then you'd get a dialog pop up right over 
that part of schematic you're looking at.

> Lets assume for a minute we might want to make saving of position and
> size configurable - perhaps independently, often I want to remember size
> but don't care about position.
> 
> Should we do this per dialog (fiddly?), or as a global option? At what
> point should we over-ride the code? Should we save, but choose not to
> use the information?

I think this would only add needless complexity. I may be wrong, but how
many people would actually use this? If you don't care about position,
you just don't move the dialog. I am a big fan of the KISS principle;
generally speaking, simpler code means code that is faster, easier
to maintain and debug.

> Another slight issue I have, the code maps the window, then moves and
> re-sizes it. This works, but incurs performance penalties, as the window
> is redrawn two or three times. (You can see it).
[...]
> I just found gdk_window_move_resize(), which would be better, combining
> the move and resize as one redraw, but there is still a redraw after
> mapping, and before we restore the geometry).

Hmm, I'll need to investigate this more closely...

> Perhaps (but I've not had time to test), the window manager will pay
> more attention to a gtk_window_move() before the window is mapped if we
> set some geometry hints with gtk_window_set_geometry_hints():
> 
> GDK_HINT_POS indicates that the program has positioned the window
> 
> and perhaps (although I'm not sure we can "morally" claim this):
> 
> GDK_HINT_USER_POS indicates that the window's position was explicitly
> set by the user.

>From http://developer.gnome.org/doc/API/2.0/gdk/gdk-Windows.html#GdkWindowHints:

"GDK_HINT_USER_POS will be set automatically by GtkWindow if you call
gtk_window_move()"

So I guess that's alright.

> Its not that great, but its a start. Your settings save code is what
> makes it useful. I'm quite short of hacking time at the moment, so if
> you want to take the code and run with it, I'd be more than happy - just
> let me know.

I don't have much time right now either, but I'll play with the code.
The hardest part is already done.

> PS:  Sorry for any white-space changes when I copied the settings-change
> code. 

No problem.

-- 
Ivan Stankovic, ivan.stankovic at fer.hr

"Protect your digital freedom and privacy, eliminate DRM, 
learn more at http://www.defectivebydesign.org/what_is_drm"