After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 312123 - All edit windows should not be open when a file is opened
All edit windows should not be open when a file is opened
Status: RESOLVED FIXED
Product: glade
Classification: Applications
Component: general
unspecified
Other All
: Normal minor
: ---
Assigned To: Glade 3 Maintainers
Glade 3 Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-07-31 08:35 UTC by Naba Kumar
Modified: 2005-08-09 20:54 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Naba Kumar 2005-07-31 08:35:09 UTC
When a .glade file is opened in glade3, it shows all the dialogs contained in
the .glade file. When there are lots of dialogs inside, it becomes a mess to
close all of them everytime the file is loaded. The edit dialogs should only be
opened when user double clicks it in windows list.

Other information:
Comment 1 Tristan Van Berkom 2005-07-31 21:34:24 UTC
I've been playing with feature in my mind, its about saving some
"useless to libglade" metadata in glade files that could; for example
save the "viewable" state of a GtkWindow, we could also display the
viewable state of of the GtkWindow in the widget tree.

This could actually easily span to reach every GtkWidget in the
project so they could all be gtk_widget_show'n or hidden dynamicly,
I'm not what the point would be though.
Comment 2 Damon Chaplin 2005-07-31 21:56:51 UTC
I don't think this sort of state information should be saved with the project,
since there may be multiple developers. But it could be saved with gconf.
Comment 3 Tristan Van Berkom 2005-07-31 22:27:42 UTC
Hmmm, 
    saving it with GConf would mean alot of work to be able
to save the state in one workspace, whereas saving the state
as a custom property of the GtkWindow would mean next to no
work and the information would be retrievable in any workspaces.

> since there may be multiple developers

I'm afraid I dont follow, do you mean that 
    "because any plugin writer can declare a custom property"
that we'd have no control over the name-spacing etc ?

Comment 4 Tristan Van Berkom 2005-07-31 22:32:52 UTC
Ok I understand, one user might want to configure 
this information for himself using the same glade file...

Ok, this still needs a little thought.
Comment 5 Naba Kumar 2005-08-01 04:28:43 UTC
Everytime I load a file, it is not necessarily to edit the same dialogs I edited
last time. So I don't see the point of remembering which dialogs were displayed
last. I would rather prefer not to display any of the dialogs at startup/load
(ala glade-2).

If you are talking about session-management, then niether .glade file nor gconf
is suitable for that because the information is not only user specific but also
.glade file specific (and you can't store that in .glade file as pointed out by
damon). Introducing a meta data file, such as .file.glade, to store them is one
possibility.

Whatever the solution be, as least make it not to display any dialogs as
default, instead of the current annoying display-all.
Comment 6 Tristan Van Berkom 2005-08-09 20:54:02 UTC
No more annoying overpopulation of top-levels upon glade file loads,
just double-click in the widget tree if you want to see the top-level
you want to edit.

Fixed in cvs.