Re: [Sodipodi-list] non-modal xml editor [patch]

[MenTaLguY <me...@ry...>]

On Mon, 21 Oct 2002 07:01:00 Lauris Kaplinski wrote:
> All this is certainly the right thing to do. But if already hacking
> extensively on xml dialog, how about moving it from glade to pure
> gtk? We want to get rid of glade, and it does not add anything useful
> in given case.

That's the eventual goal -- I'm just doing the changes in small steps so I 
don't have to debug so much at once.

> > Implementation changes:
> >     + added SPXMLTree and SPXMLTreeItem widgets
> 
> Do you know, how extensive changes are required for gtk2?

Good point ... I hadn't been thinking about that...

*does some reading*

Apparently GTK2 has a single unified Tree/List widget.  SPXMLTree would 
have to be rewritten (probably rendering SPXMLTreeItem unnecessary).

It doesn't look TOO painful; GTK2 takes care of a lot of the stuff I have 
to do by hand right now.  Anyway, porting working code is easier than 
trying to add features and port at the same time.

> >     + the dialog code doesn't have to worry about maintaining the tree
> > widget anymore; it takes care of itself

> This sound good. :)

It also means rewriting the tree view for GTK2 will impact much less code.

> >     + added sp_repr_synthesize_events(SPRepr * repr, const
> > SPReprEventVector * vector, gpointer data), which delivers a series of
> > events reflecting a node's current children/attributes/contents to the
> > given listener -- useful if a late-coming listener wants to "catch up"
> on
> > what it missed
> 
> I just do not like it being in repr code. The amount of functionality
> is so small, all 'latecomers' can implement it themselves IMHO.

I have mixed feelings about it myself.  In the end it produced simpler 
code, but maybe it's just a local minimum of complexity and there's still 
a better way to do it.

Here's how I arrived at it:

  * originally, the widget constructors subscribed and then scanned the 
repr->children list to create widgets/whatever based on the preexisting 
childen

  * then I realized that I was duplicating code that was also in the event 
handlers; I could either factor that code out and call from both places, 
or I could synthesize the events myself

  * synthesizing events made the code smaller, so I took that route

  * then I realized that the event synthesis code was getting mostly 
duplicated between the widgets using it, so I factored it out into a 
shared function

  * that function was the only part of the widget code making non-trivial 
accesses to private SPRepr fields ... I interpreted that as a sign that it 
really belonged in repr.c.

> Also, if you think there are good reasons keeping it in SPRepr, we
> definitely should emit pre-modification events too.
> And that poses a problem - what if we want to return FALSE
> from pre-modification event, while actually all modifications
> are already present.

...I think the simple solution is not to synthesize pre-modification 
events.  Someone calling sp_repr_synthesize_events() is asking for the 
state of things as-is.  The modifications are already in the past; it's 
too late to approve or reject them.

Looking at it in MVC terms, the pre-modification events are really only 
used by Models (in response to Controllers doing something).  The 
post-modification events are pretty much only used by Views -- something 
like sp_repr_synthesize_events() is only useful to Views anyway.

> Btw, thank you very much for your work!

You're welcome. ^_^

-mental