[Glade-devel] GladeCommand



On Sat, 2003-06-07 at 23:01, Archit Baweja wrote:
Two things in this email. First, I'm so happy Paolo took the pains to fix that
bug :D. Undo/Redo for Cut/Copy works like a charm.


good :)

Secondly this is just a thought and needn't be really taken any heed. By I
think the decision to move the code of widget creation and deletion and
widget cut and paste to the glade-command.ch isn't such a good idea. Because
now we have a file with two slightly unrelated pieces of code along with the
basic Undo/Redo system code in one file. Before widget creation and deletion
was in glade-widget.[ch] and cut paste was in glade-clipboard.[ch], so we had
3 "systems" in their own seperate files. Do you guys get what I'm saying?

My reasoning behind the move was to separate various object, making them
independent of their use in glade-3. This was suggest by the idea of
moving toward a collection of widgets (sort of a library) that can be
used in other projects: e.g. anjuta.

glade-widget is a class that models a gtk-widget in glade and the
actions you can do on it (create one, modify one of its fields, etc.).
Adding one widget to the project, or touch the undo/redo stack implies
acting on things that are not part of the widget object.

glade-clipboard is a class that can store widgets, what it can do is add
widget to it and get widget from it.

As you can see those files are self contained and do not depend on on
the use glade-3 makes of them: e.g. one could write a different gui and
just instantiate a glade-clipoard and then implement its own cut and
paste.

glade-command instead is more strictly tied to glade-3: it uses the
various objects (clipboard etc) to implement the actions that glade-3
does with them. As a matter of fact it depends on glade-project-window
which is our main data structure.

A side effect of the code shuffling is that following the codepaths is
easier: e.g to understand how cut works now you just have to follow the
codepath in glade-command which calls a series of "library" functions
which you can take as opaque, without jumping from one file to another.

I usually do diffstat on my patches before sending them and I like to
see that the code lines are less and functionality is the same :)
In particular I take as good indication the removal of exported
functions in .h files: if a function is only used in one file it often
means that that file is where it belong.

Sorry for being so verbose as usual :)

ciao
        paolo

ciao
        paolo





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]