Hi,

I wasn't sure if I should bring up this discussion on the mailing list or better on the bug report
(http://bugzilla.gnome.org/show_bug.cgi?id=589474).

I think it could be useful to subscribe to events emited by the XMPModel (although other people know something I don't know). The old XMPModel used a treestore to store property and schema data. My current work version inherits from GtkTreeStore.

There are two things which happen to the treemodel: a property or a schema could be set. If I'm subscribing to the row-changed event only, I have to figure out in my callback what has changed: a property or a schema. By using two different signals, it would be more explicit what was changed.

I'm working on another patch, which uses custom entry fields which "monitor" one property in the XMPModel. Currently they're subscribed to the 'row-changed' event in the XMPModel, which makes it hard to figure out if the change belongs to the Entry or not. If I could subscribe to a 'property-changed' event, I still have to figure out which property has changed, but don't have to figure out *if a property* has been changed. That would make life easier.

Now - as I said - maybe I missed something, but I'm keen to learn :)

Cheers,

On Thu, Jul 30, 2009 at 10:42:55AM +0200, Martin Nordholts wrote:

On 07/28/2009 12:40 PM, Roman Joost wrote:

Hi,

I wasn't sure if I should bring up this discussion on the mailing list or better on the bug report
(http://bugzilla.gnome.org/show_bug.cgi?id=589474). [...]

I'm working on another patch, which uses custom entry fields which "monitor" one property in the XMPModel. Currently they're subscribed to the 'row-changed' event in the XMPModel, which makes it hard to figure out if the change belongs to the Entry or not. If I could subscribe to a 'property-changed' event, I still have to figure out which property has changed, but don't have to figure out *if a property* has been changed. That would make life easier.

Just to get a discussion going: Coulnd't you implement your own "property-changed" and "schema-changed" in XMPModel? I.e. you would have to write some wrappers on top of "row-changed" that provides nicer callbacks than "row-changed".

I could and the patch provided by that bug adds a custom 'property-changed' signal. Sven and Mitch thought, if I inherit from XMPModel, I wouldn't really need the 'property-changed' signal, because I'd be able to control the 'property-changed' signal. That is true, but maybe I wasn't clear enough saying, that I want to distinguish if a schema or a property changed by using different signals.

Or I'm missing information ...

Cheers,

Hi Martin,

On Sat, Aug 01, 2009 at 09:32:36AM +0200, Martin Nordholts wrote:

On 07/31/2009 07:12 AM, Roman Joost wrote:

I could and the patch provided by that bug adds a custom 'property-changed' signal. Sven and Mitch thought, if I inherit from XMPModel, I wouldn't really need the 'property-changed' signal, because I'd be able to control the 'property-changed' signal. That is true, but maybe I wasn't clear enough saying, that I want to distinguish if a schema or a property changed by using different signals.

Inheriting XMPModel from GtkTreeStore (that's what you meant, right?)

Yes - that's what I ment. Sorry for the misunderstanding.

does not change the fact that it would be nice to have a 'property-changed' signal as a convenience if you have the need to listen property changes

So ... I'm just wondering. If I like to use two signals for the XMPModel, does it still make sense to inherit from GtkTreeStore? I mean, I can't currently see any benefits if I inherit from GtkTreeStore.

My current model looks like this:

struct _XMPModel {
GtkTreeStore parent_instance;

GSList *custom_schemas; GSList *custom_properties;

XMPSchema *cached_schema; GtkTreeIter cached_schema_iter; };

The model before inherited from GObject and had another member, which was the GtkTreeStore.

Cheers,

Hi Martin,

On Sun, Aug 02, 2009 at 01:58:20PM +0200, Martin Nordholts wrote:

On 08/02/2009 01:50 PM, Roman Joost wrote:

does not change the fact that it would be nice to have a 'property-changed' signal as a convenience if you have the need to listen property changes

So ... I'm just wondering. If I like to use two signals for the XMPModel, does it still make sense to inherit from GtkTreeStore? I mean, I can't currently see any benefits if I inherit from GtkTreeStore.

In general, aggregation is preferable to inheritance because the former results in more dynamic code with less assumptions. If you think aggregation makes more sense than inheritance in this case, then I'd say go ahead and use aggregation, i.e. have a GtkTreeStore as an instance member in XMPModel

Should I redo the patch posted for the bug I've created at:

http://bugzilla.gnome.org/show_bug.cgi?id=589474

and implement the schema change signal (which is missing), or can someone review the patch again?

Cheers,

On Mon, Aug 03, 2009 at 09:46:34PM +0200, Sven Neumann wrote:

Hi,

On Fri, 2009-07-31 at 15:12 +1000, Roman Joost wrote:

I could and the patch provided by that bug adds a custom 'property-changed' signal. Sven and Mitch thought, if I inherit from XMPModel, I wouldn't really need the 'property-changed' signal, because I'd be able to control the 'property-changed' signal. That is true, but maybe I wasn't clear enough saying, that I want to distinguish if a schema or a property changed by using different signals.

Nothing keeps you from adding more signals to your derived class. You can easily emit more detailed signals from the 'row_changed' handler in your class.

What's probably even better than a plain 'property-changed' signal is one that has a detail that identifies the property. Then code can subscribe to 'property-changed' to get notified about any property changes and your entry, which is probably just interested in a special property, let's call it 'foo', would subscribe to 'property-changed::foo'. See
http://library.gnome.org/devel/gobject/stable/signal.html#signal-detail for more information on the detail argument.

Wow - awesome. That looks very much I'd like to use. I revamp the XMPModel and try to incorporate this for the property-changed signal.

Thank you both, Martin and Sven.

Cheers,