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]

Hey everyone,

Just a brief introduction of myself as a quick "hello."  I'm an experienced
developer (~18 years) who's also a long-time Linux users (~10 years, with no
real Windows experience until very recently).  I currently work an
independent contractor while attending school for video game development and
design.  I live in Redmond, WA (my last apartment was literally across the
street from Microsoft's main campus -- I'm right in the belly of the
beast).  I use parenthesis when typing prose way more than I should (like
this).  I'm a pretty busy guy with almost no free time at all, and I usually
prefer spending that free time on a video game (making more than playing),
but lately I've been on a kick to get a better Linux desktop out since my
old favorite GNOME has gone towards a workstation-hostile iOS clone
direction recently, and I kinda need a good Linux desktop as working on code
without Valgrind is a sin against sanity and Valgrind is why my games never
crash and the lack of it is why Bethesda's games crash every 10 seconds. ;)
 I had been planning on a fork of the gnome3 code minus gnome-shell, and had
started on that a few weeks ago; it's been slow going, as gnome is a beast
and kind of a pain in the ass to hack on.  But then I realized that the
recent XFCE 4.8 was actually a pretty decent desktop; light years better
than XFCE 4.6, which I had tried before and was very unimpressed by.  XFCE
still clearly has a lot of work cut out for it, but I've come under the
opinion that it'd be easier and more efficient to help out with this project
rather than starting my own.  I'm initially doing some low-level technical
stuff to get familiar with the codebase, but eventually I have some major UI
work I'd like to do, assuming my free time doesn't dry up completely by
then.  I'm fairly sure the things i want to do are fairly in line with what
the rest of you want, which is basically just more polish and more
cleanliness and adding the major obvious features that are currently
missing.  I'll admit to having some strong desire to clean out some "cruft"
that some hardcore old-school XFCE users may not be happy to see go, but
which I still think the majority of XFCE users and maintainers will agree
with.  If not, I promise to gracefully capitulate to the XFCE maintainers
vision; I'm a team player.  :)

I started porting XFCE4 to GTK 2.22, with GSEAL_ENABLE and
*_DISABLE_DEPRECATED turned on, as a precursor to compiling against GTK 3.0.
 That's included converting a few things to Cairo rendering where necessary.
 I also fixed a couple minor bugs, and added a hacky workaround for a major
XRandR bug that was breaking my multi-monitor desktop pretty badly (and
triggering a crash in the X server itself).

I have so far ported xfce4-session, libxfce4-ui, xfce-settings-manager, and
xfce4-panel.  I'm about halfway through xfwm4, and will be doing xfdesktop
next, and finally Thunar.  Then any of the other modules which I actually
use (e.g. all the common ones that 99% of regular people would use).  The
modules I've converted are running on my desktop now and everything is
working perfectly.  I'm "dog fooding" all my changes as I make them to make
sure nothing's getting broken, particularly for modules that needed more
extensive changes to deal with deprecations or GDK->Cairo conversion.

Note that my changes to libxfce4-ui and libxfcepanel are only to make them
compile with those flags turned on.  I have not GSEAL'd those libraries
themselves, which I will need to do after all the core modules are ported.
 And them I'll need to do another round of updates to make all the consumers
of those libraries compile against them with GSEAL_ENABLE turned on.

This lays the ground work for porting to GTK 3.0, which I will also do if
the project is interested in having it done for XFCE 4.10.  It would of
course break the ABI, so maybe it should be named XFCE 5.0 in that case.  :)
 Speaking of which, it would be awesome to get some consistency to the
naming of the xfce repos (and binaries), and maybe drop the "4" from the
names in the process.  The version number can live in the branch names in
git.  Having some modules be xfblah, some being xfce-blah, and some being
xfce4-blah is making things slightly harder than it needs to be.  :)

I'm interested in what the maintainers' preferred method of submitting my
work is.  I can publish my git repos on gitorious or something, or we could
get some personal repos on the xfce git server, and then the module
maintainers can pull from those.  Or I could submit patches to the list or
to bugzilla.  I'd prefer the git approach, personally, as it's a lot easier
for everyone involved.

The only thing I did not port completely is the panel separator plugin's
"dots" style.  That's one of those things I'd like to just see disappear
(seriously, who needs multiple styles for a separator?  who really needs the
separator at all, other than its use as a hack to right-align other
plugins?) and I'm not super interested in investing my limited time into it
(I'm already peeved I had to sink time into porting 5 different clock styles
when 4 of them are totally frivolous, and that time could have been spent
making the remaining applet have a UI that didn't feel reminiscent of 1993),
but the code is still there and waiting to either be ported to Cairo (maybe
30 minutes of work) or just removed.  I'll even do the removal myself if
that's what the maintainer thinks is best.  :)
--
Sean Middleditch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20110310/2e2193fb/attachment.html>