haven't blogged in a while .. i got busy for a couple days and then i got the flu, which i'm only now pulling out of .. didn't really feel like blogging while flu-ish.
i have a new neighbour moving into the little apartment/suite behind the house next month. i met her for the first time tonight, and i think things will be well. she's a pierced post-modern hippy lookin' type that has a really nice calm energy about her. this is good, as we'll be sharing laundry facilities in the basement and it's common knowledge that one doesn't want to share laundry facilities with someone you don't get on with. i wonder if she's a vegetarian ....
.... a vegetarian restaurant, only the second one in Calgary, openned this week just 2 blocks from my house. suh-weet!
Peyton was in his first school production this past Friday, the Winter Concert. i was feeling really rough but there was no way i was missing it. how could i? it was an odd feeling to be one of the parents at the school function. very odd, but fulfilling and satisfying too. Peyton did great, singing and dancing his heart out in the three songs his class did. during the tea afterwards the teachers told Mahlah and myself that they'd like to move Peyton up into the kindergarten class in January as it would be more interesting and challenging for him. he turns 5 in May so it's not like he isn't old enough.
i mean, he's already helping me with KDE hacking ;-)
speaking of which, i've got panel-to-panel dragging working, thanks in part to a proof of concept QDragObject Stephen Depooter (sbdep) sent me. i told him a week or so ago on irc that if he did the dragobject that i'd do the rest. well, he came through so i had to as well. you can now drag buttons from one panel to another. huzzah. applets aren't draggable yet, but the new drag object moves Containers around which means it's ready for applets once they get around to dragging state.
i also discovered the wonders of KMultipleDrag, which allows one to attach multiple QDragObjects to a single drag event, making drags that might be any one of a number of types very easy to implement. thanks to dfaure for pointing it out to me!
the initial draft of the panel stacking code is in CVS (though still very buggy), moving a panel from one edge to another is now acceptably fast and i discovered why the panel wasn't initializing for some people. so, baby steps towards release readiness. at this point that's what i'm starting to go after. and that's where the bad news starts.
i haven't seen wicky around for a few weeks and i'm getting concerned i'll be left to debug the new layout code on my own. not a big deal, it just means more on my plate. and i've yet to see the finished patch for the mouse over effects for kicker, which makes me a bit nervous that i'll end up spending a sleepless night or three doing it myself. so ends the feature additions, then, and it's on with the bug fixing. top and left panels still don't draw borders correctly, and the ends of panels need to be capped as well. there are numerous geometry issues and the stacking code isn't as intelligent as it yet needs to be. inserting new items on a panel also leaves much to be desired. it's going to probably take me the better part of a month to root all these issues out to satisfaction. =/
in greener news, Kévin Ottens announced a couple of new ioslaves aimed at making the desktop a better place: system:/ and remote:/. the former is a jumping point to various ioslave-delivered locations in your system, the latter for easily making and finding connections to remote resources. i really hope these make it in for 3.4, so much so that i'm even going to stop bugging Kévin about making the Trash applet a menuext (well, at least for a day or two ;)
between trash:/, system:/, remote:/ and a bevy of general improvements around KDE 3.4 is going to be a cool release; a parting kiss from the KDE development team before departing for the longer journey towards KDE4, if you will.
Tuesday, November 30, 2004
Thursday, November 25, 2004
in other, calmer, news...
... there's a really annoying apparently compiler-specific bug that causes kicker's main panel to not populate with the default set of buttons/applets when run for the first time.
if you are running HEAD, to see if this affects you mv your kickerrc out of the way and restart kicker. if you get a blank main panel, you're seeing the bug. please email the OS, compiler and compiler version you are using.
and if you have a particularly sadistic streak, perhaps you'll even be so kind as to look into why ExtensionManager::the() creates a new ExtensionManager even though has already been created when called from ChilPanelExtension::populateContainerArea(). i'll be happy to walk through the code with you and would appreciate all such efforts as i can't reproduce the problem here (though my limited set of compilers is most likely attributable to this).
at least the clock is transparent again. and custom background colours and LCD modes work too. holy crap.
if you are running HEAD, to see if this affects you mv your kickerrc out of the way and restart kicker. if you get a blank main panel, you're seeing the bug. please email the OS, compiler and compiler version you are using.
and if you have a particularly sadistic streak, perhaps you'll even be so kind as to look into why ExtensionManager::the() creates a new ExtensionManager even though has already been created when called from ChilPanelExtension::populateContainerArea(). i'll be happy to walk through the code with you and would appreciate all such efforts as i can't reproduce the problem here (though my limited set of compilers is most likely attributable to this).
at least the clock is transparent again. and custom background colours and LCD modes work too. holy crap.
if you are too stupid to understand how copyright works, please stay the *&^% away from kicker.
alright. that's it. i've had it. yes, i've &*^%ing had it.
it's a little frustrating that some people decide that the best way to work on kicker is to fork large bits of its code and never submit patches for consideration for potential merging into head. (ok, so there wasn't an active maintainer around for a long time, fair enough)
it's also aggravating that they decide to work off old versions of that code replete with bugs that makes merging harder (ok, so you don't have a CVS check out, fair enough).
it's grating that they reformat the code, making creating patches and finding the changes made even harder (ok, you don't think it's going back into kicker ever so why not adjust it to your personal preferences, fair enough).
it's just plain silly that they change the licensing from BSD to GPL on bits of code so that i can't merge their changes back into head.
but hey, this is all within the rights granted by the Free software licenses we release KDE under. it's not the most polite or efficient thing to do, but hey, it's totally Fair Ball.
but is just being slightly annoying enough?
oh, no!
see, they have to go and take chunks of code and remove the copyright notices to it and slap their own there instead. i've downloaded a few of these "kicker improvements" from kde-apps.org to see what good ideas and code can be harvested and instead i keep finding code that's been misappropriated. this makes the code illegal and the turns the act into something rather disrespectful of those who went before them.
so for goddess' sake people: play with the code, have fun and do cool things with it, but respect those who went before you and respect the law, m'kay? m'kay.
it's a little frustrating that some people decide that the best way to work on kicker is to fork large bits of its code and never submit patches for consideration for potential merging into head. (ok, so there wasn't an active maintainer around for a long time, fair enough)
it's also aggravating that they decide to work off old versions of that code replete with bugs that makes merging harder (ok, so you don't have a CVS check out, fair enough).
it's grating that they reformat the code, making creating patches and finding the changes made even harder (ok, you don't think it's going back into kicker ever so why not adjust it to your personal preferences, fair enough).
it's just plain silly that they change the licensing from BSD to GPL on bits of code so that i can't merge their changes back into head.
but hey, this is all within the rights granted by the Free software licenses we release KDE under. it's not the most polite or efficient thing to do, but hey, it's totally Fair Ball.
but is just being slightly annoying enough?
oh, no!
see, they have to go and take chunks of code and remove the copyright notices to it and slap their own there instead. i've downloaded a few of these "kicker improvements" from kde-apps.org to see what good ideas and code can be harvested and instead i keep finding code that's been misappropriated. this makes the code illegal and the turns the act into something rather disrespectful of those who went before them.
so for goddess' sake people: play with the code, have fun and do cool things with it, but respect those who went before you and respect the law, m'kay? m'kay.
Tuesday, November 23, 2004
features : drugs
kicker's clock applet is a bone in my craw. why? too many features. in particular the background of the clock, which has at least 4 different possible modes (custom color, default KDE colors, LCD background and transparent), some of which are implemented by the clock applet, some by kicker and some by individual clock faces. this code was broken one way in 3.2, another way in 3.3 and yet another way in current CVS. i'll straighten it out for 3.4, but the effort wasted on this is silly.
and therefore the topic of the blog: features are like drugs.
when a feature is included in an application, some subset of the user base will become attached to it. very attached. they'll claim the need it, that they can't live without it. and fair enough, we come to grow comfortable with our configurations and tool sets.
but then if that feature gets removed or altered, you can be certain that somewhere some user(s) exist who are going to be really upset. there are few features that don't have fans. it doesn't matter how stupid the feature is, it can't be taken back as easily as it's given.
moreover, not all users like all features and options equally, just as not all people like all drugs equally. for instance, penicillin makes me break out in hives and pisses off my lungs (thank the goddess for tetracycline!) and marijuana just makes me drowsy and isn't particularly enjoyable to me. and so it is that some people just don't like certain software features.
this means that when a feature is added, some subset of the user base will clamor for it to either be removed, changed or be made configurable. the challenge in removing or changing it has already been covered, so making it configurable is often the path of least flamage. this is how we get insanely large configuration dialogs and things like the clock applet. ug.
now, i'm not advocating featureless software anymore than i advocate the outlawing of drugs. i am advocating that just as we should use drugs responsibly and often with consultation of an expert first, adding features is something to be done with much consideration.
kicker is now (just barely) off the top 20 bug count list, and the wishlist is under 200 entries long. amazing!
this is part thanks to a bug sweep i did one evening in which Maksim Orlovich and Renchi Raju joined me. they threw bug report nubmers at me as fast as i could read and decide on them. the result was rooting out a large number of duplicates, already fulfilled wishes, INVALIDs, etc.. kudos to both, you guys rock!
and speaking of wishlists, a certain Mr. van den Bergh from the Netherlands requested a feature in kicker on IRC. i requested he send me a design document detailing what it was he wanted in detail. to my admitted surprise and great delight, a few days later there appeared an OpenOffice Writer document with an excellent description of the desired feature. he included a screenshot and detailed configuration and usage information. it was really encouraging to see the user put in this sort of effort.
this has made it very easy to understand exactly what Mr. van den Bergh wants and how he would like to use this feature. this in turn empowers me to implement it as well as i can and with greater efficiency as he's done part of the work for me.
it also makes me feel less like a feature slave and more like a collaborator. who wants to be a slave?
so here's my wishlist item: i wish those reporting wishes would take half an hour out of their lives to produce a document that's even half as good as the one Mr. van den Bergh came up with and attach it to their entries on bugs.kde.org.
that would be too cool for words.
and therefore the topic of the blog: features are like drugs.
when a feature is included in an application, some subset of the user base will become attached to it. very attached. they'll claim the need it, that they can't live without it. and fair enough, we come to grow comfortable with our configurations and tool sets.
but then if that feature gets removed or altered, you can be certain that somewhere some user(s) exist who are going to be really upset. there are few features that don't have fans. it doesn't matter how stupid the feature is, it can't be taken back as easily as it's given.
moreover, not all users like all features and options equally, just as not all people like all drugs equally. for instance, penicillin makes me break out in hives and pisses off my lungs (thank the goddess for tetracycline!) and marijuana just makes me drowsy and isn't particularly enjoyable to me. and so it is that some people just don't like certain software features.
this means that when a feature is added, some subset of the user base will clamor for it to either be removed, changed or be made configurable. the challenge in removing or changing it has already been covered, so making it configurable is often the path of least flamage. this is how we get insanely large configuration dialogs and things like the clock applet. ug.
now, i'm not advocating featureless software anymore than i advocate the outlawing of drugs. i am advocating that just as we should use drugs responsibly and often with consultation of an expert first, adding features is something to be done with much consideration.
kicker is now (just barely) off the top 20 bug count list, and the wishlist is under 200 entries long. amazing!
this is part thanks to a bug sweep i did one evening in which Maksim Orlovich and Renchi Raju joined me. they threw bug report nubmers at me as fast as i could read and decide on them. the result was rooting out a large number of duplicates, already fulfilled wishes, INVALIDs, etc.. kudos to both, you guys rock!
and speaking of wishlists, a certain Mr. van den Bergh from the Netherlands requested a feature in kicker on IRC. i requested he send me a design document detailing what it was he wanted in detail. to my admitted surprise and great delight, a few days later there appeared an OpenOffice Writer document with an excellent description of the desired feature. he included a screenshot and detailed configuration and usage information. it was really encouraging to see the user put in this sort of effort.
this has made it very easy to understand exactly what Mr. van den Bergh wants and how he would like to use this feature. this in turn empowers me to implement it as well as i can and with greater efficiency as he's done part of the work for me.
it also makes me feel less like a feature slave and more like a collaborator. who wants to be a slave?
so here's my wishlist item: i wish those reporting wishes would take half an hour out of their lives to produce a document that's even half as good as the one Mr. van den Bergh came up with and attach it to their entries on bugs.kde.org.
that would be too cool for words.
Sunday, November 21, 2004
regressions, bread and NX
i wasn't in the headspace for working on stuff like the strut issues yesterday, so instead i putzed about with a few look issues, including a visible mark on the "outside" of applet handles to help demarcate them and slightly less ugly hide handles (they're still ugly though ;)
there are some visible regressions in kicker HEAD right now. most of them are known to me, but if you aren't sure take a look in kdebase/kicker/TODO. i've updated it with known regressions and issues, all of which will be addressed for 3.4. hopefully this should save me a few emails a day =) i appreciate feedback but kicker is used by so many people so much that it can get overwhelming really fast as people helpfully report issues promptly.
there aren't a whole lot of regressions to work through, thankfully, and then i'll pretty much be "done" with kicker for 3.4 feature-wise. after the feature freeze next month i would like to do some optimizations (code first, optimize last). if anyone is interested in helping out by running kicker and some of the more critical applets through cachegrind under various usage scenarios (first startup, regular startup, appletproxied taskbar, appletproxied system tray, etc) please get a hold of me. this kind of data gathering is time consuming, but highly parallelizable. i wouldn't mind spreading the load this one a bit.
i've received a fair amount of feedback on the systemtray hiding stuff. mostly positive, with some constructive criticism. the current systemtray isn't designed for this kind of thing (e.g. nice user-visible names and icons) and i want to use the config dialog eventually for ordering of icons (another high-demand wishlist item). some has noted that this is just a band-aid over a bigger problem. i agree with that to an extent, however the problem exists and there's no point in pretending it doesn't. moreover, as long as we encourage the use of the panel for apps to put icons on the problem will exist. applets aren't the answer, either, since that just relocates the problems while making life more annoying for both users and application developers.
someone wrote asking about NX stuff, and that's next on my plate. i'm more concerned about kicker right now because it's already a central piece of the desktop and it needs to be Perfect for release. also, kNX can move into KEG and have rapid regular releases independant of KDE, whereas Kicker can't.
one big question is going to be how to integrate krdc and kNX, because i think that's crucial. i don't want to see KDE have N remote connection apps when just 1 will do. as both krdc and kNX need major UI reconstructive surgery, i'm leaning towards getting kNX spruced up _and_ fully functional, then merging the vnc + rdp support from krdc into it. i just don't want to do the UI work twice.
speaking of which, i need to have a discusion with the [Free]NX server people to get someway of telling KDE that it's running through NX. that's going to be key to breaking NX out of its little window and allowing cool integration stuff like putting "Suspend Session" in the KDE logout dialog.
Peyton and i went out for our usual sunday brunch at Nellie's down the street. it's a charming little cafe that has fewer tables than demand and some of the coolest staff. everyone there is a little oddball, like the waitress who will often slip into a "character" for the whole time you're there. she even does different characters for different tables. last week we got Rosy the Mexican. they also have little baskets of toys and colouring books for the kids, which Peyton likes. and they have a lot of veggie-friendly stuff on the menu, which is resonably priced.
on the way home we stopped at the French bakery across the street to pick up fresh croisants for breakfast, some artisan bread to eat with dinner tonight and a couple of pastries for a treat. they also give what they don't sell to a homeless shelter at the end of every day. being a locally owned/run business with superior product and good ethics, i prefer to get my baked goods from them than my local Safeway.
that and it's just so kitsch to buy non-perfectly shaped but wonderful tasting fresh bread from a little bakery. it is part of the Romantic lifestyle, which has less to do with romancing people than romancing one's self and our environs, to which i strive towards with occasional success.
if this lifestyle were culturally Cool (which seems to be the primary motivator for most), i think we would enjoy our lives more, our day-to-day would be more meaningful and we'd avoid the WalMartization of our local economies.
there are some visible regressions in kicker HEAD right now. most of them are known to me, but if you aren't sure take a look in kdebase/kicker/TODO. i've updated it with known regressions and issues, all of which will be addressed for 3.4. hopefully this should save me a few emails a day =) i appreciate feedback but kicker is used by so many people so much that it can get overwhelming really fast as people helpfully report issues promptly.
there aren't a whole lot of regressions to work through, thankfully, and then i'll pretty much be "done" with kicker for 3.4 feature-wise. after the feature freeze next month i would like to do some optimizations (code first, optimize last). if anyone is interested in helping out by running kicker and some of the more critical applets through cachegrind under various usage scenarios (first startup, regular startup, appletproxied taskbar, appletproxied system tray, etc) please get a hold of me. this kind of data gathering is time consuming, but highly parallelizable. i wouldn't mind spreading the load this one a bit.
i've received a fair amount of feedback on the systemtray hiding stuff. mostly positive, with some constructive criticism. the current systemtray isn't designed for this kind of thing (e.g. nice user-visible names and icons) and i want to use the config dialog eventually for ordering of icons (another high-demand wishlist item). some has noted that this is just a band-aid over a bigger problem. i agree with that to an extent, however the problem exists and there's no point in pretending it doesn't. moreover, as long as we encourage the use of the panel for apps to put icons on the problem will exist. applets aren't the answer, either, since that just relocates the problems while making life more annoying for both users and application developers.
someone wrote asking about NX stuff, and that's next on my plate. i'm more concerned about kicker right now because it's already a central piece of the desktop and it needs to be Perfect for release. also, kNX can move into KEG and have rapid regular releases independant of KDE, whereas Kicker can't.
one big question is going to be how to integrate krdc and kNX, because i think that's crucial. i don't want to see KDE have N remote connection apps when just 1 will do. as both krdc and kNX need major UI reconstructive surgery, i'm leaning towards getting kNX spruced up _and_ fully functional, then merging the vnc + rdp support from krdc into it. i just don't want to do the UI work twice.
speaking of which, i need to have a discusion with the [Free]NX server people to get someway of telling KDE that it's running through NX. that's going to be key to breaking NX out of its little window and allowing cool integration stuff like putting "Suspend Session" in the KDE logout dialog.
Peyton and i went out for our usual sunday brunch at Nellie's down the street. it's a charming little cafe that has fewer tables than demand and some of the coolest staff. everyone there is a little oddball, like the waitress who will often slip into a "character" for the whole time you're there. she even does different characters for different tables. last week we got Rosy the Mexican. they also have little baskets of toys and colouring books for the kids, which Peyton likes. and they have a lot of veggie-friendly stuff on the menu, which is resonably priced.
on the way home we stopped at the French bakery across the street to pick up fresh croisants for breakfast, some artisan bread to eat with dinner tonight and a couple of pastries for a treat. they also give what they don't sell to a homeless shelter at the end of every day. being a locally owned/run business with superior product and good ethics, i prefer to get my baked goods from them than my local Safeway.
that and it's just so kitsch to buy non-perfectly shaped but wonderful tasting fresh bread from a little bakery. it is part of the Romantic lifestyle, which has less to do with romancing people than romancing one's self and our environs, to which i strive towards with occasional success.
if this lifestyle were culturally Cool (which seems to be the primary motivator for most), i think we would enjoy our lives more, our day-to-day would be more meaningful and we'd avoid the WalMartization of our local economies.
Saturday, November 20, 2004
systray icon hiding, news at 11
systray icon hiding: over 600 votes and more than 40 emails attached to the bug, two different people working on patches to implement it and people routinely bitching at me about it. in the end i took David Henot's patch, gave it a real good massaging, borrowed some button code from kweather (and massaged that a bit too) and then committed. hooray!
icons hiding:
icons showing:
and the config dialog which is available from the applet handle:
as a bonus, we'll eventually be able to use that same dialog to order the icons in the systray.
and if you don't have any icons set to hide, you don't see the arrow. i rather like the arrow button though; it's even RTL aware. huzzah!
no, it doesn't do autohiding of "inactive" icons. that's just not possible until we get a better systray protocol (KDE4 ...)
for other kicker applet hackers, the above screenshots were taken when running the systray applet through the applet proxy:
icons hiding:
icons showing:
and the config dialog which is available from the applet handle:
as a bonus, we'll eventually be able to use that same dialog to order the icons in the systray.
and if you don't have any icons set to hide, you don't see the arrow. i rather like the arrow button though; it's even RTL aware. huzzah!
no, it doesn't do autohiding of "inactive" icons. that's just not possible until we get a better systray protocol (KDE4 ...)
for other kicker applet hackers, the above screenshots were taken when running the systray applet through the applet proxy:
appletproxy systrayapplet.desktop. very handy for debugging purposes. i also noticed and fixed a bug where running applets through the appletproxy wouldn't result in the applet being deleted when the appletproxy went away, preventing applet dtors from being run. i have a hunch this is why the systray would sometimes lose its icons after kicker crashes in 2.x/3.x. well, it's fixed for 3.3.2 and a non-issue in 3.4 as we no longer use the appletproxy in 3.4.
Wednesday, November 17, 2004
the big merge
the stop_the_insanity branch has been merged into HEAD. there are still a number of TODOs left, but STI was less buggy than HEAD in many ways. i also didn't want to have to keep merging patches committed to HEAD.
i'm afraid it's all going to be a bit anticlimactic, though, since if all goes well nobody will really notice much of a difference ;-)
(or is there anyone out there that has more than one manual hide panel on the same side of the screen that uses CVS? ;)
i'm afraid it's all going to be a bit anticlimactic, though, since if all goes well nobody will really notice much of a difference ;-)
(or is there anyone out there that has more than one manual hide panel on the same side of the screen that uses CVS? ;)
a momentary pause
The last five days; tonight they finished with us going to a book reading, a poetry reading and a concert. She: a young and published author, up-and-coming, a book with her words in it for sale on the table that night, who knew the performers who in turn knew her. First name basis.
The last fives days: We met and left each other at a bus terminal: where people who live in places too insignificant for airplanes to land or who are too poor to afford to fly or are who too eccentric to do otherwise go to depart.
It was the first time she'd seen my son. It was the first time I'd seen her since I missed her wedding.
She said our lives were parallel. What she was doing, what I was doing: the same reasons, the same motions. We suspend our lives, this poetry, momentarily in the presence of the other: I hardly hacked, and she hardly wrote. In its place we stopped to live mundanely in the others' presence. She left a sink of clean dishes and a man re-smitten. Every time. Every time.
We do this yearly, or sometimes more, as is our ritual. And when we part, she mouths back over her shoulder once out of earshot: "I love you."
She knows my answer.
The last fives days: We met and left each other at a bus terminal: where people who live in places too insignificant for airplanes to land or who are too poor to afford to fly or are who too eccentric to do otherwise go to depart.
It was the first time she'd seen my son. It was the first time I'd seen her since I missed her wedding.
She said our lives were parallel. What she was doing, what I was doing: the same reasons, the same motions. We suspend our lives, this poetry, momentarily in the presence of the other: I hardly hacked, and she hardly wrote. In its place we stopped to live mundanely in the others' presence. She left a sink of clean dishes and a man re-smitten. Every time. Every time.
We do this yearly, or sometimes more, as is our ritual. And when we part, she mouths back over her shoulder once out of earshot: "I love you."
She knows my answer.
Tuesday, November 09, 2004
things to do to avoid boredome
this weekend i removed the door from my bathroom. i have a small bathroom and it has a doorway right in the middle of one side of it. to get to the toilet one would have to open the door, walk inside, step towards the sink, close the door, then proceed. this sucked. especially when the needs were urgent. especially for quests who aren't as, shall we say, streamlined as i. so i pulled the door off the hinges. no more door, no more problem. now i just have to find a nice curtain for the portal. i think a bathroom curtain is more Bohemian than a bathroom door anyways.
and i'm all about the Bohemian, baby.
going through a database schema dump i found a funny little shnippet of code i wrote as a quick hack to locate orphaned financial statements during a particularly ugly data migration:
evidently i was attempting to amuse myself during this rather boring task. i wonder if i succeeded.
on the way home from school yesterday, Peyton asked about where my mother lives. he's fascinated by issues of geography lately. i told him she lives on an island in the middle of the ocean where there is no winter called Oahu. i asked if he'd like me to show him where Oahu is on the map when we got home. he said yes, and then said "I know where the map is! You go to the games menu that looks like a controller, then you go to the smiley face, then you go to the bottom!" apparently he's memorized large portions of the kmenu. crazy.
and i'm all about the Bohemian, baby.
going through a database schema dump i found a funny little shnippet of code i wrote as a quick hack to locate orphaned financial statements during a particularly ugly data migration:
CREATE FUNCTION whereswaldo () RETURNS integer
AS '
DECLARE
company record;
oingo record;
bodycount int;
BEGIN
delete from milkcartons;
bodycount := 0;
for company in select distinct company_short_name from crude_statements
loop
select into oingo companyid from clientcompanies where whose = 1003 and position(company.company_short_name in companyid) > 0;
if not found
then
select into oingo max(delivery_period) as lastSeen from crude_statements where company_short_name = company.company_short_name;
insert into milkcartons values (company.company_short_name, oingo.lastSeen);
bodycount = bodycount + 1;
end if;
end loop;
return bodycount;
END;
'
LANGUAGE plpgsql;evidently i was attempting to amuse myself during this rather boring task. i wonder if i succeeded.
on the way home from school yesterday, Peyton asked about where my mother lives. he's fascinated by issues of geography lately. i told him she lives on an island in the middle of the ocean where there is no winter called Oahu. i asked if he'd like me to show him where Oahu is on the map when we got home. he said yes, and then said "I know where the map is! You go to the games menu that looks like a controller, then you go to the smiley face, then you go to the bottom!" apparently he's memorized large portions of the kmenu. crazy.
merging on the weekend
the stop_the_insanity branch in kicker is coming along nicely and should be ready to be folded back into HEAD next weekend. i decided today that the appletproxy won't be used any more, it just causes too many problems. Waldo suggested a really good idea for how to deal with keeping track of which applets cause problems (which is the whole point of kicker using the appletproxy) on irc today. it's quite elegant and will facilitate the removal of two more classes from kicker! the appletproxy will, of course, remain to make developing and debugging individual applets easier.
i'm probably going to remove the use of the taskbarproxy from kicker as well, since that doesn't seem to be used at all, really. boom. another two classes.
in all, i think that kicker's design was pretty decent, just that the code never really got completed. that is to say, the usual post-version-one refactoring didn't get done. eventually we had a big glob of code for an integral part of the desktop that was rather convoluted. who would want to mess with it? with a reasonable amount of effort, we have been able to make kicker's code a lot more straightforward without sacrificing functionality.
there's an interesting discussion going on kde-policy and elsewhere about whether Amazon's web service terms and conditions allow it to be used in a GPL'd application. personally, i think it's fine due to section 7 of the GPL. but i'm not a lawyer, so ... who knows.
i managed to cause a small stir on kde-promo regarding theDot, which has turned out well i think. Waldo, Fab, Navindra and crew are a great bunch of people and i'm really happy theDot is in their hands. they are open to examining the state of things, as opposed to simply guarding the status quo. my hat's off to those folks.
they could always use more content, of course. so if you've got the hankering, don't hesitate to put together some KDE related info and submit it!
oh, and i keep forgetting to note that in an earlier blog where i referenced kstart as being quicker to start KDE apps, i meant to reference kdeinit_wrapper. one of the talkbacks noted this, and they were quite right.
i'm probably going to remove the use of the taskbarproxy from kicker as well, since that doesn't seem to be used at all, really. boom. another two classes.
in all, i think that kicker's design was pretty decent, just that the code never really got completed. that is to say, the usual post-version-one refactoring didn't get done. eventually we had a big glob of code for an integral part of the desktop that was rather convoluted. who would want to mess with it? with a reasonable amount of effort, we have been able to make kicker's code a lot more straightforward without sacrificing functionality.
there's an interesting discussion going on kde-policy and elsewhere about whether Amazon's web service terms and conditions allow it to be used in a GPL'd application. personally, i think it's fine due to section 7 of the GPL. but i'm not a lawyer, so ... who knows.
i managed to cause a small stir on kde-promo regarding theDot, which has turned out well i think. Waldo, Fab, Navindra and crew are a great bunch of people and i'm really happy theDot is in their hands. they are open to examining the state of things, as opposed to simply guarding the status quo. my hat's off to those folks.
they could always use more content, of course. so if you've got the hankering, don't hesitate to put together some KDE related info and submit it!
oh, and i keep forgetting to note that in an earlier blog where i referenced kstart as being quicker to start KDE apps, i meant to reference kdeinit_wrapper. one of the talkbacks noted this, and they were quite right.
Friday, November 05, 2004
elephants, i say!
it is said that elephants have really, really good memories.
i'm beginning to suspect that some of our users might be elephants.
angry elephants.
who believe "being reasonable" means "agreeing with everything i think".
i'm beginning to suspect that some of our users might be elephants.
angry elephants.
who believe "being reasonable" means "agreeing with everything i think".
Tuesday, November 02, 2004
the interface is not the implementation
i often see user interfaces that are nearly literal translations of the algorithms and code structures in the program. the challenge here is that what is efficient for the computer and/or the programmer is often bizarre and confusing for the user.
viewing things from a user's point of view often helps. i try and ask myself, "if i was doing X, how would i do it if i had never used this software before? how would i do it if i weren't using a computer?" this can be particularly difficult, since it means jumping out of our own context as software designers and code crunchers.
a trivial example i recently ran into was digiKam's album properties dialog. it had a list box showing all the collections that you could add this album to. you could only add it to one collection, and if you wanted to add it to a collection that didn't exist yet, you had to click the Add button and fill in a sub-dialog first. you could also delete collections here, which made sense from the code's point of view, but from a user POV it was a bit odd that you could delete a collection here and have it affect all your other albums, too!
so i re-jigged the dialog a bit. nothing fancy really, as i was trying to work through a number of dialogs that evening, but here's the result:
the collections item is now a single, editable drop down. if you type in a name that doesn't exist in your collections, it gets created for you. you can also select no collection (the blank entry) or one that you set up previously in the drop down. deleting collections is now done solely in the collections management dialog. this frees up the user to just "put the album in a collection" without having to think about how to manage their collections; it also made the dialog a lot shorter.
happy day.
viewing things from a user's point of view often helps. i try and ask myself, "if i was doing X, how would i do it if i had never used this software before? how would i do it if i weren't using a computer?" this can be particularly difficult, since it means jumping out of our own context as software designers and code crunchers.
a trivial example i recently ran into was digiKam's album properties dialog. it had a list box showing all the collections that you could add this album to. you could only add it to one collection, and if you wanted to add it to a collection that didn't exist yet, you had to click the Add button and fill in a sub-dialog first. you could also delete collections here, which made sense from the code's point of view, but from a user POV it was a bit odd that you could delete a collection here and have it affect all your other albums, too!
so i re-jigged the dialog a bit. nothing fancy really, as i was trying to work through a number of dialogs that evening, but here's the result:
the collections item is now a single, editable drop down. if you type in a name that doesn't exist in your collections, it gets created for you. you can also select no collection (the blank entry) or one that you set up previously in the drop down. deleting collections is now done solely in the collections management dialog. this frees up the user to just "put the album in a collection" without having to think about how to manage their collections; it also made the dialog a lot shorter.
happy day.
stop_the_insanity
in the 80s/90s there was this crew-cut, thin, blond woman name Susan Powter who went around America shouting "STOP THE INSANITY". she was something of a female Richard Simmons, having gone from whale-riffic to minnow-tiffic and in the process been possessed with the need to spread the gospel of eating sensibly, exercising regularly and getting healthy.
as of yesterday, there's a new CVS branch for kicker called stop_the_insanity. the idea is to do to kicker what Susan wanted to do to America: knock off the pounds and get some sensibility into the code base.
in the first patch (which was a 2000+ line diff, but which netted only ~200 more lines of code) the Panel, PanelManager and PanelOpMenu classes have all gone bye-bye and many of the global settings have been centralized into the Kicker class. the start up sequence, which was one a crazy maze of object instantiation and code paths is now very, very simple: set up our resources, create our key bindings, create the KMenu, start the ExtensionManager (which loads the panels).
there is lots more to go, of course, but i'm really excited about where this is headed. with a simpler code base fixing bugs and attracting new developers will be easier. with less code duplication and settings mania we may even get kicker into a size 3 dress one day. it's also quite likely that we'll gain new opportunities for speed optimizations as things become simpler and the special cases become fewer. KConfigXT is coming to kicker, which should also help with config setting caching and synchronization issues.
what's really cool is that this is actually making kicker more functional than less since we're just a few patches away from being able to optionally disable the main panel altogether for that windowmaker look.
unfortunately, kicker still looks the same. otherwise i'd post a cutesy picture. that's right, my hacking is boring to look at. =P
as of yesterday, there's a new CVS branch for kicker called stop_the_insanity. the idea is to do to kicker what Susan wanted to do to America: knock off the pounds and get some sensibility into the code base.
in the first patch (which was a 2000+ line diff, but which netted only ~200 more lines of code) the Panel, PanelManager and PanelOpMenu classes have all gone bye-bye and many of the global settings have been centralized into the Kicker class. the start up sequence, which was one a crazy maze of object instantiation and code paths is now very, very simple: set up our resources, create our key bindings, create the KMenu, start the ExtensionManager (which loads the panels).
there is lots more to go, of course, but i'm really excited about where this is headed. with a simpler code base fixing bugs and attracting new developers will be easier. with less code duplication and settings mania we may even get kicker into a size 3 dress one day. it's also quite likely that we'll gain new opportunities for speed optimizations as things become simpler and the special cases become fewer. KConfigXT is coming to kicker, which should also help with config setting caching and synchronization issues.
what's really cool is that this is actually making kicker more functional than less since we're just a few patches away from being able to optionally disable the main panel altogether for that windowmaker look.
unfortunately, kicker still looks the same. otherwise i'd post a cutesy picture. that's right, my hacking is boring to look at. =P
getting a backtrace from a KUniqueApplication (like kicker or kmail)
reading Chris Howell's blog on getting a backtrace, i though i'd add a note on how to get a backtrace on a special class of KDE apps: unique apps. these are the applications that you can only run one instance of; starting them again results in the currently running instance to be activated instead. these include applications like kmail, kicker, kscd, kjots and many others. now, if you try Chris' recipe on a KUniqueApplication you'll get something like this:
and then the application window will appear. but you won't be able to get a backtrace. notice the "Program exited normally" line, even though the application is still running! what happens is that the real application is forked off of the initial process as part of the "unique application" magic. unfortunately, this makes gdb lose track of the program. the fix is, thankfully, very simple:
notice the --nofork parameter, and notice that the application no longer exits immediately. huzzah! backtrace here we come.
now, what if the application just hangs, but doesn't actually crash? you can get a backtrace easily enough by loading it up in gdb and then hitting Ctrl-C. this will interupt the program wherever it is and allow you to ask for a backtrace.
aseigo@linux:~> gdb `which kjots`
GNU gdb 6.1
(gdb) run
Starting program: /opt/kde3/bin/kjots
[New Thread 1096345472 (LWP 26469)]
Program exited normally.
(gdb)
and then the application window will appear. but you won't be able to get a backtrace. notice the "Program exited normally" line, even though the application is still running! what happens is that the real application is forked off of the initial process as part of the "unique application" magic. unfortunately, this makes gdb lose track of the program. the fix is, thankfully, very simple:
(gdb) run --nofork
Starting program: /opt/kde3/bin/kjots --nofork
[New Thread 1096345472 (LWP 27257)]
notice the --nofork parameter, and notice that the application no longer exits immediately. huzzah! backtrace here we come.
now, what if the application just hangs, but doesn't actually crash? you can get a backtrace easily enough by loading it up in gdb and then hitting Ctrl-C. this will interupt the program wherever it is and allow you to ask for a backtrace.
Monday, November 01, 2004
... ah, but the start up times!
in a responseblog, Malte S. Stretz (who's a pretty cool guy, i might add) noted that while Konsole may be more efficient in certain workloads, that there is room for improvement in places like start up time.
he's right. KDE has lots of room for improvement. we do a lot of things quite well right now, however. and we'll get more things Right(tm) with future development. but it's being able to hold both the idea that we Rock and the idea that we have room for improvement in our heads at the same time that's important.
anyways, on to Malte's numbers! he notes that `xterm -e bash -c exit` takes 0.363s while 'konsole -e bash -c exit' takes 2.148s. holy crap! over 6 times as long! ah... but there's a catch. a small one, but still a catch...
on my system, with both xterm and konsole in cache so as to remove the affects of disk i/o as much as possible, `xterm -e bash -c exit` takes ~0.165s and 'konsole -e bash -c exit' takes ~.9s, but 'kstart konsole -e bash -c exit' takes ~0.5s. the kstart hack brings konsole start up times down from being ~5.5x slower to being ~3x slower. that's much better, but more importantly, that multiplier works out to just one third of a second longer to launch konsole.
now stop for a moment and consider that: a third of a second. for all those features, for all that KDE goodness. 300 milliseconds.
let's also consider that terminals are really a Worst Case Scenario. xterm and friends don't do a lot, and they aren't very interesting. because of this they start up fast and are slim like that Olsen twin. and still KDE apps compete reasonably in this space.
this bodes very well for KDE applications in more complex venues such as word processors, web browsers and so on.
yes, we have a LOT of optimization possibilities ahead of us. yes, our software can and should be faster, including starting up. yes, we have a lot of development ahead of us to do because KDE isn't perfect yet.
we're only mostly perfect. ;-)
he's right. KDE has lots of room for improvement. we do a lot of things quite well right now, however. and we'll get more things Right(tm) with future development. but it's being able to hold both the idea that we Rock and the idea that we have room for improvement in our heads at the same time that's important.
anyways, on to Malte's numbers! he notes that `xterm -e bash -c exit` takes 0.363s while 'konsole -e bash -c exit' takes 2.148s. holy crap! over 6 times as long! ah... but there's a catch. a small one, but still a catch...
on my system, with both xterm and konsole in cache so as to remove the affects of disk i/o as much as possible, `xterm -e bash -c exit` takes ~0.165s and 'konsole -e bash -c exit' takes ~.9s, but 'kstart konsole -e bash -c exit' takes ~0.5s. the kstart hack brings konsole start up times down from being ~5.5x slower to being ~3x slower. that's much better, but more importantly, that multiplier works out to just one third of a second longer to launch konsole.
now stop for a moment and consider that: a third of a second. for all those features, for all that KDE goodness. 300 milliseconds.
let's also consider that terminals are really a Worst Case Scenario. xterm and friends don't do a lot, and they aren't very interesting. because of this they start up fast and are slim like that Olsen twin. and still KDE apps compete reasonably in this space.
this bodes very well for KDE applications in more complex venues such as word processors, web browsers and so on.
yes, we have a LOT of optimization possibilities ahead of us. yes, our software can and should be faster, including starting up. yes, we have a lot of development ahead of us to do because KDE isn't perfect yet.
we're only mostly perfect. ;-)
Subscribe to:
Posts (Atom)
