[Glade-devel] GladePalette patch

[Tristan Van Berkom <tristan van berkom gmail com> (Tristan Van Berkom)]

On Sun, 19 Dec 2004 19:59:35 -0500, Archit Baweja
<bighead users sourceforge net> wrote:
[...]
> Well ok. But we should really make up our mind about this, because
> initially glade-3 did have a glade-2/gimp like palette. So switching
> back and forth isn't a good idea. Also while we are on the subject,
> personally I prefer the newer arrangement list style as compared to the
> old MxN matrix. Most other UI Designers use a list stlye. Thats why we
> switched in the first place. This thread has a history of the last
> discussion on the subject...
>
> http://lists.ximian.com/archives/public/glade-devel/2004-February/000520.html

Thank you for pointing this out, if there is a reason for the palette
to be in list form,
I'm satisfied to leave it as such, OTOH, we could also do both and let the user
decide...

[...]
> Well I see the GladeCommand code first as code for doing "actions" and
> the undo/redo as a additional feature. Point being I think doing it the
> "from_query_dialog" way, is the best way. If we do it like you suggest,
> we'll be copying lots of code from GladeEditor and GladeCommand, only to
> put it separately as a GladeQueryDialog. Most of the code is already
> written (thats why glade_editor_query_dialog() in its present form uses
> the glade_editor_table_create() and friends anyway). We only skip
> pushing the action on the undo stack.

I am not suggesting duplication of code, I just think that instead of
propagating
the "from_query_dialog" boolean to the GladeCommand code, we should do
something more like this in the glade-editor code:

if (from_query_dialog)
    glade_property_set (property, value);
else
    glade_command_set_property (property, value);

One reason for this is that it's programaticly pointless, essentialy the
GladeCommand would allocate itself for the undo stack, and then just
free itself, all for the sake of executing one line of code.

Another, more important reason IMO is that the same argument could have been
made for any other exception (would you suggest we use 
glade_command_set_property() to set properties on internal widgets loaded
from the glade file ?)

Cheers,
                                                         -Tristan