Libxfce4ui api review

[Nick Schermer]

2009/7/7 Brian J. Tarricone <brian at tarricone.org>:
> Or instead of the enum, could also abuse the GTK_STOCK_DIALOG_* strings.
>  Personally I like this better because of fewer entry points, and if we want
> to add other dialog types in the future (no idea what, though, so this might
> be a silly consideration), it's easy to do without having to add more
> functions.  Yes, it's a little bit more typing, but not a lot, and IMHO it
> makes the API cleaner, especially given the _on_screen() variant and the
> need for 2x the number of functions if you do it the other way.
>
> Thoughts?

Personally I think this will only make the api more ugly. Remember
there is still the possiblity to use the plain xfce_message_dialog
functions. Splitting the function having a *_on_screen possibility is
not ideal either. Note that only the info and warning functions take
the same arguments atm, so the enum won't make it any better too.

Using the pointer parent might look a bit ugly in the first place, but
if we properly document this and we don't crash on a gchar pointer
(all arguments are objects so we can do good type checking), I still
think this is the cleanest solution. Using a pointer is still valid
(see g_object_unref ^_^, I know for a slightly other reason) and keeps
the whole thing clean.

Nick