is it wednesday already?

holy crap it's been a while since i blogged. a combination of being busy and just not being in the "sharing my life" mood this last week or so. i've really been enjoying my time home and having a more quiet, private existence again. anyways, enough about me (i can already hear the "booooring!" from homer simpson in the back row)

i rearranged the konqueror tab context menu here locally a bit:

very small changes but it feels just so much more right now. it's more in line with firefox's menus (though that wasn't intentional; i checked w/firefox after i made my changes. huzzah for thinking similarly). the idea is that reload is probably next most common after new tab, and that all the tab manipulation items belong in a menu section. so it's a bit more orderly and there is one less menu separator.

but i'm hesitant to commit this to a stable branch though: changing UI elements from minor to minor is crappy, but i'm also unhappy to let 3.5.x continue on with a crappy menu here. i'm torn!

i've also whipped up a class for kde4 called KAutoStart which abstracts away the process of adding/removing applications from the autostart process. i'll be committing that this week to trunk/kdelibs/kdecore/, though i need to touch base with seli about what he's doing with the autostart phases. he has improved them for kde4 slightly and that may mean we don't need start-after anymore.

it occured to me that a similar class for screensaver avoidance would be good. i'm thinking of a class that you new and delete only, and on creation it prevents the screensaver from flicking on and stops doing that when you delete it. sort of like a mutex for the screensaver. i just see a number of kde apps doing this manually, and once we get some standard mechanism for doing this (e.g. via ipc, standardized on fd.o, supported in x.org) our apps won't have to change any code. until then we can just provide a fake key press event mechanism.

these little utility "abstract away a specific system behaviour" classes ought to, imho, be thrown together in a module in kdecore once we divy that stuff up.

besides tracking down and killing yet more bugs in 3.5 in kicker (along with matt broadstone), kconfigskeleton and kmail, i've also been working on kconfig, which needed more work than i anticipated. but the result will hopefully be better than what we have: multiple backends (including pluggable ones), configuration of backends done in /etc/kderc (and hopefully one day /etc/xdgrc?), ldb, elektra/uniconf?... and tobian koenig suggested a nice way to get change notification on the cheap which i'll try and get right ;) and seli provided a number of interesting optimization suggestions. we'll see what comes out of all this (besides me becoming way too familiar with kconfig internals ;)

and finally, i've also been hacking on kaffeine here and there. they have a new startup ui in svn that i think is a nice improvement:

it's still a bit busy in places, but getting better compared to previous releases. it's also the only kde vid player that i can get to do everything i need right now (such as play video fullscreen on my laptop screen and external monitor simultaneously). but there are some issues with it still: the systray icon on by default, screensaver prevention that is always on when kaffeine is on (rather that just when video or fullscreen audio visualization is on), sub-optimal config dialog and lack of kconfigxt (== no kiosk support in the config dialogs and more hand coded stuff in the app). in return for allowing me to turn off the systray icon by default (which is not something most people need or want for playing video) i'm helping fix those issues. there are some other bits of UI improvements that could be made, but i'm trying not to get overly involved in kaffeine hacking as i have enough other stuff to do. and i think christian is doing a pretty nice job here anyways in incrementally improving things in noticeable ways.

i'd really like to see this app get more exposure as well since it is rather good and i noticed it wasn't even up for voting in the recent linuxquestions.org member's choice awards nor is it often mentioned in the "video app" category where it most naturally fits. (yes, i know you can also use it to play audio)

other stuff on the burner include looking into kross for making it easier to open up plasma to scripting languages. i really wish people writing new frameworks would include decent design concept documentation so it didn't feel like reverse engineering so much of the time. we must improve on this in kde4. no ifs, ands or buts on this one.