GNOME Bugzilla – Bug 352018
GtkDialog padding and spacing doesn't reflect saved state.
Last modified: 2006-08-26 15:51:08 UTC
GtkDialog created from template is saved correctly but when opened, padding and spacing of elements from the template are set to their default values. I mean they are not equal to those visible in properties editor. When I change, for example increase and decrease some value by 1, it gets updated in the dialog I'm working on. The same applies to a newly created dialog. It has some default paddings/spacings but defaults in properties editor are set to 0 and therefore seems to be ignored too. As I can see all (dialog) templates have this problem. To reproduce: Create new project, add "Dialog Box", select "dialog-vbox1" widget, set it's padding to 30. Save the project, close it, reopen. I this moment I see the dialog with it's default padding (0), but when I select "dialog-vbox1", properties editor shows 30 in the padding property. I guess the templates should have their default HIG compliant values, set in properties editor and there should be some resizing enqueued after loading so all containers reflect their real saved state. Thanks
An interesting bug you found here. The problem here I think, is that you shouldnt be allowed to configure the border-width of the action area or the vbox or the button spacing in the action area - why ? because the GtkDialog controls these properties via it's style properties "content-area-border", "action-area-border" and "button-spacing". Eventually we should be able to configure these properties via the "Style" tab in the property editor (for user-override priority level rc parse values). I'm now looking into a way to optionally disable properties of composite widget children via the catalog.
I had no idea these are controlled by style, nice to know. :) In this case I agree that dialogs should not set their own custom values here. But if you want to block any of the properties, first make sure it's value has a good default. At this moment it is far too easy to make not HIG compliant dialog (window type, size, title, WM hints, etc.) You can also hide some structure details (if it is possible), i.e. there is no use of showing VBox if it's properties should not be modified. It would be faster to use if clicking on the window background would instantly bring dialog properties. As a little sub-bug-report I can add that those properties which should be left are not always working. I found out that the "Use separator" switch works for AboutDialog but not for MessageDialog and plain Dialog, changing buttons in MessageDialog results in window "jumping" and the dialog does not hide icon when Message type is set to GTK_MESSAGE_OTHER, etc. :) Should I report such little not-so-harmful bugs at this stage or better not introduce too much noise?
> In this case I agree that dialogs should not set their own custom values here. > But if you want to block any of the properties, first make sure it's value has > a good default. At this moment it is far too easy to make not HIG compliant > dialog (window type, size, title, WM hints, etc.) Well in this case, its not a matter of setting good default values - no matter what values are in the glade file, they will get stomped on by the theme engine after loading the UI. > You can also hide some structure details (if it is possible), i.e. there is no > use of showing VBox if it's properties should not be modified. It would be > faster to use if clicking on the window background would instantly bring dialog > properties. Well some things can still be set on it without harming anyone, so I'd rather leave all the possible doors open - on the other hand bug 345893 aims to bring out relevent properties in the editor in order to improve workflow, there are all kinds of things we can do to improve workflow before we mark limits :) > Should I report such little not-so-harmful bugs at this stage or better not > introduce too much noise? Please introduce noise, we want to hear about all that little stuff :)
The problem is fixed since glade-3.0.1. I'm closing this bug.