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

[Jannis Pohlmann]

On Thu, 10 Mar 2011 21:19:10 -0800
Sean Middleditch <sean at middleditch.us> wrote:

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

Introducing ifdefs, configure switches and GSEAL everywhere will make
it hard to merge fixes made to master back to the Xfce 4.8 branches. We
are in no hurry switching to GTK+ 3. The GTK+ maintainers even agree
with this and expressed that it is fine to depend on an older GTK+
version. 

Like Nick, I would prefer to wait with preparing things for GTK+ 3
until after Xfce 4.10. There is no benefit for the end user if we do it
for 4.8 already. 

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

I don't know what g_launch_async is but there is gdk_spawn_async and
that function is not deprecated. Some gdk_spawn_* functions were
removed in GDK 3 though. Are you referring to that?

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

As Nick said we will not rename components. The naming scheme is quite
consistent now. xfce-utils is the only component starting with
"xfce-" (all the others either start with "xfce4-" or "libxfce4").
"xfdesktop" is the only component being called "xfsomething" and as
Jérôme mentioned before, we are aiming at replacing it. So why rename
anything?

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

Git allows to create patches with commit messages. See
http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html
for example.

> >
> > 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?  :)

History as in: things were added at some point and some people are
happy those features are still there, while others may think those
features are old-school or unnecessary. 

Anyway, having different separator styles is good. Also, it's a piece
of code that is unlikely to cause much bug-fixing work, so there is
nothing to remove there.

  - Jannis