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]

Sounds like this probably isn't the right desktop project for me to dig into
then.  I'm just not interested in working on older base tech or on what I
personally believe to be poor UI, and it sounds like the XFCE team's
priorities and mine are simply not inline, making me a bad fit for this
project.  I'll post what I have in Bugzilla after classes today so you guys
have it available if you decide you want it.

Thanks for the feedback and clarifications.

On Fri, Mar 11, 2011 at 1:27 AM, Jannis Pohlmann <jannis at xfce.org> wrote:

> 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
> _______________________________________________
> 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/20110311/41712c96/attachment.html>