gEDA-dev: GschemDialog (work in progress)

[Peter Clifton]

On Wed, 2007-05-09 at 12:24 +0200, Ivan Stankovic wrote:

> > 2. A better interface might be to define signals, "state-save" and
> >    "state-restore" which are emitted appropriately on map and unmap.
> > 
> >    These signals would have the benefit of abstracting the necessity to
> >    chain up the mapping code, and allow dialogs to more easily overload 
> >    and chain the signal handler, (or hook it with g_signal_connect).
> 
> Yes, definitely, that would be nice to have.
> 
> >    Ivan: I've not thought hard about the practicalities, but how easy is
> >          it to pass a suitable pointer / object with the GKeyFile and
> >          name straight into the signal handler?
> 
> I'm not quite sure what you're talking about here, but you can
> pass arbitrary arguments to g_signal_emit() (see
> http://developer.gnome.org/doc/API/2.0/gobject/gobject-Signals.html).

Indeed, that was the thinking - you just have to define the signal
appropriately.

If you pass the signal handler enough information to get the g_key_file
and section name, it allows other state to be saved..

g_key_file_set_integer(dialog_geometry, name, "frob-value", frob_value);


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.

> > 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.

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?

> I too think these dialogs should be left to gtk (and wm). Thanks 
> again for the great work!

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?


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 tried restoring settings before the map operation, and the resize
worked, but the dialog's position wasn't updated.

I used:

+    gtk_window_move (GTK_WINDOW (dialog), x, y);
+    gtk_window_resize (GTK_WINDOW (dialog), width, height);

Ivan's patch used:

+      gtk_window_move(GTK_WINDOW(dialog), x, y);
+      gtk_window_set_default_size(GTK_WINDOW(dialog), width, height);

(I can't remember why I changed from set_default_size)

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).


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.



> Thanks again for the great work!

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.

PS:  Sorry for any white-space changes when I copied the settings-change
code. As gschem doesn't have a particular coding style (and I started
GschemDialog by copying another sub-class), so I altered it to fit what
I'd copied. I'm not convinced I like the style I ended up using, but its
not a big issue.


Kind regards,

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)