introduction, gtk 2.22 porting, code (I don't use the majority of the extra panel plugins that live in their own , for instance, so I'm not going to port those myself)submission preferences

[Sean Middleditch]

On Thu, Mar 10, 2011 at 1:55 PM, Nick Schermer <nickschermer at gmail.com>wrote:

> [Waaay too much text...]
>
> Personally I'm not going to accept gseal patches in master for 'my'
> components, even if they apply against 2.22. The reason is very
> simple: it makes back porting fixes in the 4.8 (gtk 2.14) stable
> branches much harder. Unless code get simpler/better or it requires
> new gtk/glib functions.
>

That is unfortunate, and also unlikely to be a real issue.  Very few bugs
you're going to encounter are likely going to involve any of the code that
needed changing.  Widget initialization and the odd line of code, really.
 All of the actual logic code where the XFCE bugs live are not really
related to direct GTK widget access, which is all that's getting affected.

Really, there's very little to change.  Most of it is quite boiler-plate.  I
think 95% of what I did was things like
s/WIDGET_IS_REALIZED(widget)/gtk_widget_is_realized(widget)/g.  Anything
involving any kind of real, interesting logic is completely untouched.

I'd be willing to ensure everything still compiles against GTK 2.14 and use
a configure switch to enable the GSEAL/deprecation macros, if really
necessary; it's another time sink I'd prefer to avoid if at all possible,
though.


> You can read our statement about that here:
> http://wiki.xfce.org/releng/4.10/roadmap
>
> I've no idea if there is much deprecated gtk/gdk parts usage in the
> core components. Those are fine to remove (if it makes a difference).
>

Not much.  Other than a few GDK things I've run into, the biggest pain in
the butt I've found is the removal of the g_launch_async stuff, which it
seems xfce-util already has a replacement for (which I didn't notice untila
fter porting a few modules to use the full gtk
g_app_info/g_app_launch_context stanza in a few places).

Everything else is really just one-liner replacements that could probably be
done with a quick perl script if I wasn't concerned with having an excuse to
look over all the code.


> Renaming components is not a real option and completely useless. In
> fact it might work against you when at some point we release xfce 5.0,
> in that case 4.x and 5.x can work alongside nicely.
>

git already solves that.  You have absolutely zero need for different
repositories.  Just use different branches.  gnome (for all the other things
they get wrong) manages to keep their gnome2 and gnome3 versions of modules
in a single repo just fine, it's effortless to do so.  Either way, it's a
minor request, and not something in any way critical.  The tab-completion
for all the inconsistent module names just gets annoying, which is why I
mentioned it.  :)


>
> Preferably patches in bugzilla for now, but if you think that's too
> much work, github is fine too (but gives no room for patch discussion
> and history).
>

Patches lose the more valuable history -- the commit messages -- but I can
post patches, and will do so.  libxfce4ui, xfce4-panel, and xfce-setting
will be posted when I get chance.


>
> Some things in the code are there for history purposes, like the dots
> separator.
>

Does that mean "history" like the historic society got legislation passed
making you keep it so they don't have to pretend that it's not 1960 anymore
and their childhood is long gone and kids these days use the internet and
listen to pop music and don't know who Andy Griffith is, or "history" as in
that's there because nobody cared enough to remove it because meh why
bother?  :)


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



-- 
Sean Middleditch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20110310/3a158d76/attachment.html>