What's wrong with using -1 (i.e. 0xffffffff)? That's the highest possible priority so IMHO this absolutely makes sense.

The problem is that -1 isn't a uint.   In gstreamer-sharp for instance (and with pygst too I bet) you get an error if you try to assign anything but a uint to that property.

Pitivi and Jokosher end up doing "priority = 2**32-1" which seems like an awful hack to me.

Could also fix this by making this special priority = 0, the highest priority = 1, etc.

Or, if you're going to keep 0xFFFFFFFF being the special value, at least change the documentation to make sense - say that the special value is G_MAXUINT32 and say that "The lowest priority is G_MAXUINT32 - 1."

(In reply to comment #2)
> The problem is that -1 isn't a uint.   In gstreamer-sharp for instance (and
> with pygst too I bet) you get an error if you try to assign anything but a uint
> to that property.
> 
> Pitivi and Jokosher end up doing "priority = 2**32-1" which seems like an awful
> hack to me.
> 
> Could also fix this by making this special priority = 0, the highest priority =
> 1, etc.
> 
> Or, if you're going to keep 0xFFFFFFFF being the special value, at least change
> the documentation to make sense - say that the special value is G_MAXUINT32 and
> say that "The lowest priority is G_MAXUINT32 - 1."

IMHO saying -1 for unsigned integers is just the lazy people's way to say 0xffffffff or whatever the maximum of the type is. But you said that 0 is highest priority and 0xfffffffe is the lowest, right? Then this is really a bit inconsistent :) If 0xfffffffe was the highest priority all would make sense.
But then, priority = 2**32-1 is no different from saying priority = 0xffffffff so that's no awful hack I'd say.

So yes, the docs should clarify and say: 0xffffffff is a magic priority to mark the default source, 0xfffffffe is the lowest priority and 0 the highest. Edward, what do you think?

That's what gst-inspect-0.10 gnl* shows (0xffffffff). I don't see the problem. Closing bug.

At the very least the documentation should be improved IMHO, it's very confusing:
http://gstreamer.org/data/doc/gstreamer/head/gnonlin/html/GnlObject.html#GnlObject--priority

I think it's inconsistent, as per comment #3, and we should change it now that we have the opportunity, before gnonlin is released for 1.0.

I would change the property type to a signed int, and continue to use -1 as the special value. The lowest priority is then G_MAXINT.

The current code is also broken btw, in that it assumes sizeof(int) = 4. G_MAXUINT32 is used instead of G_MAXUINT.

Good point. I guess the orignal idea was that using G_MAXUINT would prevent having to make it an exception, but in the end, it would force any operation to have a fixed number of sink, otherwise it would endup being included in operation like adder and videomixer.

I'm currently writing a new graph generator and will consider this.

I'm closing this bug because in the end we will remove the notion of "special" priority. The extendable property and the normal range of priorities is sufficiant. Filling gaps in operation will be done differently.