Xfce, GTK+ 3.0 and GSettings

[Nick Schermer]

On Thu, Nov 18, 2010 at 2:29 PM, Denis Washington <denisw at online.de> wrote:
> Am 18.11.2010 13:16, schrieb Nick Schermer:
>>
>> On Thu, Nov 18, 2010 at 12:37 PM, Denis Washington<denisw at online.de>
>>  wrote:
>>>
>>> Am 18.11.2010 12:26, schrieb Jannis Pohlmann:
>>>
>>>> I don't have the GTK+ 3.0 release schedule at hand right now but I'm
>>>> not thinking about porting Xfce yet. (That's just my opinion however.)
>>
>> I agree here. If we port the core (for plugins and stuff isn't not too
>> hard) it will be a lot of work. All allocation and size requests
>> functions need to be ported (if you want to do it properly), lot of
>> rendering stuff changed, so don't underestimate this.
>>
>> Better wait 1 release with the gtk3 port, let the gtk folks iron out
>> the issues first.
>
> Ok, that sounds sensible.
>
>>>>> * Related to the first question: have you thought about moving from
>>>>> xfconf to GSettings? I know that xfconf was just introduced in Xfce
>>>>> 4.6, but wouldn't it lower the maintainence burden to use a settings
>>>>> system directly built into glib instead of having to develop a
>>>>> seperate one? I think this also wouldn't introduce any heavy GNOME
>>>>> dependencies, as dconf, the default GSettings backend, only depends
>>>>> on glib. Using GSettings might also reduce resource usage when using
>>>>> GNOME applications in Xfce because there wouldn't be two daemons
>>>>> running (xfconfd and dconfd) but just one. Again, I would love to
>>>>> help here!
>>>>
>>>> Yes, using GSettings would make sense. Xfconf is great though, so I
>>>> don't see us in a hurry here.
>>>>
>>> A good idea might be to write a Xfconf backend for GSettings (which is
>>> backend-agnostic). Then applications could be gradually ported, and
>>> Xfconf
>>> then replaced with dconf if all components have moved.
>>
>> Porting from xfconf to gsettings is not a lot of work, better do it
>> all at once, but again here, the issue will be settings migration.
>> Even though porting is easy, I'd say we don't do this in 4.10; for
>> users it doesn't matter what settings backend is used, but setting
>> migration are irritating them (it never goes as planned)), so don't do
>> that every 2 major releases; xfconf serves us well, lets benefit from
>> it for a while.
>>
>> We did a lot of porting (GIO) and rewriting (panel, garcon, 4ui) this
>> release, I'd say we focus on polishing the last pieces. There is also
>> enough to cleanup after 4.8: drop xfce-utils, merge xfrun4 into
>> appfinder, better volume handing in thunar, xfdesktop needs some love,
>> mouse settings, you name it.
>>
>> This is something more beneficial to the users, instead of jumping in
>> another hole, we just got out of GIO. Gtk3 may sound l33t to users,
>> but in the end they don't care, because gtk2 and gtk3 are identical
>> for what you do with a computer.
>
> You are probably right with that. I just thought it would be good to at
> least gradually work towards the direction of GTK+ 3 (by ensuring everything
> builds with -DGSEAL_ENABLE etc) so that there is not so much work to do at
> once.

Making sure Xfce compiles with GSEAL_ENABLE and DISABLE_DEPRECATED is
reasonable, but to avoid code with a lot of #if GTK_CHECK_VERSION
lines we then also need to bump the gtk dependency to gtk 2.22, not
sure we want to for Xfce 4.10, we now depend on gtk 2.14, 2.18/2.20 is
more reasonable i think (duno if we need features in those releases).

Like I said, the gseal stuff is not a lot of work, all the work is in
the size handling and drawing cleanup.

> I think the port should be considered for Xfce 4.12 because the new features
> introduced into GTK+ 3.0 will not be available to the Xfce components
> otherwise. And wouldn't the migration be a good point to clean up and remove
> deprecated functionality? (I believe such things are especially important
> for Xfce where unfortunately there is not so much manpower for
> maintainance.)

We obviously need to switch and we all agree gtk3 is a big step
forward (width-for-height will be a big improvement for a lot of
pajnel plugins for example), but that doesn't mean we should use it
directly.

> In any case, it would be nice if there were a clear (long-term) plan
> concerning the migration.

Sure, but for now consider this work for 4.12. 4.10 needs other, more
important, work and considering the lack of developers, big migrations
are not a good idea.

Nick