bloat?
an excerpt:
But most of all, you will see programs getting a Mozilla complex… Lots and lots of bloat, with no effort going into optimizing anything. KDE and GNOME have that problem. Even formerly lightweight programs like XFce are now heavy programs (thanks in no small part to the bloat of GTK2).
*sigh* ignoring for the moment the fact that gtk2 is actually much more cleanly implemented and less bloated than gtk 1.2 (what makes gtk2 slower in many cases is pango-xft or pixmap-heavy theme engines), just the perception that xfce is bloated makes me sad =(.
but i think that’s the natural course of things – no matter how much you want to write a barebones piece of software that is very light, there’s always the pressure to add more features as time goes on. deciding which features are necessary (or at least just useful) and which features actually constitue “bloat” is the problem, i suppose. but the fact remains that it’s very hard to look at a piece of software and say, “there. it’s done. i have no desire to add anything more to it. it does everything i want it to do – no more, no less – and there will never be a need for it to do anything more.”
WM eye candy
i was poking about on slashdot, and noticed an article about sun’s “looking glass” window manager. it renders windows in 3D, presumably using your hardware’s 3D acceleration (i hope). they have some screenshots up, and they’re pretty nifty. i can’t say anything about how functional that kind of stuff is without actually trying it, but it sure does look cool.
xfdesktop rewrite done
well, it’s been quite a while since i posted here. i was getting tired of posting bad news, so i decided to stop.
but now i have good news: i finished my partial rewrite of xfdesktop, and not only is it designed much better now for multihead support, the app-crashing problem is gone (at least for me).
probably easiest is to point you to my post to the mailing list. the tarball can be downloaded here. hopefully i’ll have it all merged into CVS in a few days.
enjoy ^_^
multihead goodness
jasper rightly pointed out that i haven’t posted here in over a month, so i suppose i’m overdue.
my latest big improvement to xfdesktop is multihead support (not xinerama yet, unfortunately). xfdesktop can now handle multiple screens grouped under a single X display. you can set the backdrop, color, etc. independently for all screens. i’ll probably add an option to use the screen 0 settings on all screens if you’re too lazy to set different stuff for each. anyway, doing the multihead stuff was fun – i learned a lot about how X handles that sorta stuff. thanks to danny for a lot of testing and bug-hunting help.
another cool new feature is that you can set the backdrop to a color gradient. françois put up one of my screenshots displaying the feature, with a semi-transparent image sitting on top. mmmm, i love gradients…
the new multi-screen required a bit of a redesign to the backdrop settings dialog. soon i’ll be adding some global menu preferences to the dialog as well.
from a request on the mailing list, i just added the ability to add directories of image files to image lists. you can either do multi-select in the file chooser, or drag and drop a directory from xffm (and probably other filemanager; i haven’t tested).
in other news, i did some libxfcegui4 work as well. olivier wasn’t too happy about the backported gtk 2.4 code i stuffed in there, since it was causing a bunch of binary compatibility problems. i ripped all that stuff out, and created some less-functional wrappers for gtk 2.2 users. in the process, i also created XfceFileChooser, which is a thin wrapper over gtk 2.4’s GtkFileChooserDialog and gtk 2.2’s old GtkFileSelection. this enables xfce apps to use either the newer or older dialog, depending upon which version of gtk was used to compile libxfcegui4.
unfortunately, xfdesktop is still making some apps crash when launched from the desktop menu. olivier and i have done a lot of bug-hunting in the past couple days, but we can’t figure out what’s causing it. olivier can reproduce the problem using panel launchers as well, which leads him to believe the problem isn’t restricted to xfdesktop. i’m not so sure (as i can’t reproduce it that way), but i can say that so far we’re pretty stumped as to how to fix it or what the root cause could be.
whew, i guess that’s it for now.
commenting, anyone?
a quote i saw on slashdot that i (and perhaps others) should think about a bit more often:
“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”
–John F. Woods
another milestone in xfdesktop reorg…
last night i released my latest patch that moves all of the menu code into a dynamically loadable library. the patch is basically finished, minus a small amount of trivial functionality i forgot to implement/reenable.
the patch also includes a new xfce4-panel plugin that is a button that can display the desktop menu.
please test this if you are able (remember to run autogen.sh after patching). assuming i get good feedback, i’d like to put this in CVS asap so i can move on to other things.
i still don’t have a solution for the app-crashing problem xfdesktop exhibits when it runs some threaded/gconfed gnome apps. i _have_ been able to narrow the problem down to xfdesktop itself rather than in the new menu code, as the panel plugin appears to load apps fine. i have a couple ideas of things to look at, but if they don’t pan out, i guess it boils down to figuring out what’s different between 4.0.4 and CVS head…
gmodules are your friends
hi all-
i noticed moe commenting about xfdesktop, so i thought i’d give a little status update. the menu code was in a state that i was relatively happy with, so i went and broke it utterly. i’ve noticed people clamoring for keeping things simple and configurable so we can keep the bloat out and the memory footprint low. so, to this end, i’m moving the menu code into a loadable gmodule. this isn’t a plugin system (at least not yet), as each module is going to need to be loaded individually and will proabably have different initialisation and use requirements inside xfdesktop. i think a more generic plugin interface would be nice, but i really don’t see the overwhelming need for one since xfdesktop shouldn’t be doing all that much in my opinion.
currently i have a prototype of the menu code in a gmodule (it only parses menu files and doesn’t do the autogenerated menu yet). it seems to work well so far, with a few bugs i need to work out (that’s what i get for coding at 5am). i’m planning on putting the forthcoming desktop icon code into another gmodule, and if anyone can think of any other cool features that would be candidates as pseudo-plugins, i’d be interested in hearing ideas.
oh, and my new menu code uses XfceAppMenuItem, finally. it seems to work well so far, though porting the menu dentry code to use it will be a challenge since i have to sort the hard way. i’m also planning on adding drag-n-drop support to the menu so you can drag items out onto the panel or onto the desktop. after i finish the menu gmodule i’ll write a panel plugin that can display the desktop menu. ah, modularisation…
i’m really pleased with how xfdesktop is shaping up; in a month or so, hopefully we’ll have a very featureful – but still lean, configurable, fast, and lightweight – desktop manager.
gtk stuff, xfdesktop plans
i was looking through the gtk2 api docs the other day, and i noticed they added documentation for a new GtkIconTheme class in gtk 2.4. while i like my icon finding code, it will be nice to relegate it to a fallback and use a somewhat “official” method for finding icons.
the other night i wrote XfceAppMenuItem, a subclass of GtkImageMenuItem that should make handling the desktop menu a bit easier. making use of it will take a bit of code rework that i’m not ready to do right now, so i’ll shelve it for later. you can check out my preliminary api in the header. make suggestions if you want.
yesterday tuukka sent me his work on a freedesktop.org desktop menu spec-compliant menu parser. i’ve only just started looking at it, but now i understand why there still isn’t a production-quality parser/generator out yet: the spec is incredibly complicated. i think it’s a good spec, to be sure – it has to be, to both be flexible for new ideas and to support old legacy menu hierarchies, but i’m somewhat afraid that when i hook it all into the menu system it’s going to make everything terribly slow. at any rate, it’ll be at least a week before i figure out what exactly is the best to do with this…
welcome (to me!)
hello all-
for those of you who don’t know me, i’m brian (aka kelnos), and i’m the new maintainer of xfdesktop. i don’t really have all that much to say right now; i just wanted to check in. i threw together a little web page that i’m going to use to update the world on my progress with xfce – what i’m working on, screenshots, etc.
hmm, i need to get myself one of those disembodied floating head pictures…
that’s all for now, i suppose.
-brian