Libxfce4ui api review

[Nick Schermer]

2009/7/8 Brian J. Tarricone <brian@...>:

> On 2009/07/07 13:40, Nick Schermer wrote:
>>
>> 2009/7/7 Brian J. Tarricone<brian@...>:
>>>
>>> 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
_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

[Nick Schermer]

2009/7/7 Brian J. Tarricone <brian@...>:

> On 2009/07/07 02:59, Nick Schermer wrote:
>> Looked a bit through eggsm and I think we should use it, looks clean
>> and contains everything we need. Put it a private library named
>> libxfce4smclient-private (like libxfce4kbd-private) with the xsmp (and
>> maybe osx) backend. Make sure it works with xfce4-session and then sit
>> and wait what gtk+ is going to do.
>> Hopefully others agree with this. IMHO we simply don't think we have
>> the resources (and are in the position) of re-thinking the whole sm
>> backend.
>
> I hate having private libs, but that's probably the best idea for now.

Should I also rename the public egg_sm_client code to xfce_sm_client
or is that not needed? I don't think that will bring any benefit for
us since it's private and temporarily anyway. Also slightly more work
to keep us up2date with the original egg code.

Nick
_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

[Nick Schermer]

For the import of the libxfce4kbd-private library I will use
libxfce4kbd-private-2.la as library name and reset verinfo, this way
we don't get file conflicts between libxfce4ui and libxfcegui4. When
switching a module to libxfce4ui we simply use [libxfce4kbd-private-2]
in configure.in.in. Any objections or better ideas?

Nick
_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

[Brian J. Tarricone-3]

On 2009/07/07 23:38, Nick Schermer wrote:

> 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.

Duh, good call.  If you don't pass a parent, it's gonna go on the
default screen, which may or may not be what you want... if you don't
pass a parent, I think putting it on the active screen makes the most
sense.  So the arg can be a bit more strongly typed.

        -b
_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev

[Jannis Pohlmann-3]

On Wed, 8 Jul 2009 11:28:15 +0200
Nick Schermer <nickschermer@...> wrote:

> For the import of the libxfce4kbd-private library I will use
> libxfce4kbd-private-2.la as library name and reset verinfo, this way
> we don't get file conflicts between libxfce4ui and libxfcegui4. When
> switching a module to libxfce4ui we simply use [libxfce4kbd-private-2]
> in configure.in.in. Any objections or better ideas?

I guess that's ok, considering that the libxfce4kbd-private in
libxfcegui4 is never going to reach API version 2. Like Brian, I'm not
really happy with having those private libraries either, but I guess
having them is okay for now. Gotta rethink the keyboard stuff later
anyway, I guess (still got a lot of people complaining about it), so
moving it into the public part of the API doesn't make sense at this
point.

  - Jannis





_______________________________________________
Xfce4-dev mailing list
Xfce4-dev@...
http://foo-projects.org/mailman/listinfo/xfce4-dev