Libxfce4ui api review

[Nick Schermer]

2009/7/8 Brian J. Tarricone <brian at tarricone.org>:
> On 2009/07/07 13:40, Nick Schermer wrote:
>>
>> 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.
>
> Right, I forgot that the error function takes a GError, so no help there.
>
>> 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.
>
> Frankly, it's just ugly API, and documenting it well doesn't change that.

Ok agreed.

> What are your objections to the _on_screen() variants, aside from just
> having extra entry points?

Only the extra entry points, which is also ugly api, only in a
different way then using the pointer. Less ugly i agree, but also less
convenient, and that's also what this library is about.

Anyway, I can live with it as it is right now, just wanted to discuss
it again. Maybe we can run the
xfce_gtk_window_center_on_active_screen() function if the parent ==
NULL? That will cover most of the cases anyways and if you don't send
a parent you'll never know where the window shows up, so I think we
can do that safely.

For the other cases we should just use
xfce_message_dialog_new/gtk_window_set_screen/gtk_dialog_run/gtk_widget_destroy.
Much typing, the C-way.

Nick