new years is upon us! it's the time when many sit down to make those lists of "new year's resolutions". granted, most such resolutions get forgotten by the time the hang-over has worn off on jan 1 ;) but it's a nice sentiment. so here are two of my new years resolutions ... for other people. i have my own list, but it's mine; a boy needs his privacy at some level after all...
the first resolution is for all those people who have become successful in business during and/or after their involvement with kde. there are a number of tasks within the organizational mechanics side of kde that need people with management experience. things like facilitating developer meetings, helping author planning documents for the e.V. ... sadly, what generally happens is that people who benefited tremendously from their involvement with kde, be it personally, professionally or both, tend to get busy with their new "important" business lives and forget about where they came from.
the resolution is thus this: think about what you can give back to the project with your honed business and management skills.
my second new year's resolution is for everyone who writes software that can store configuration in a directory service. yes, i'm looking at you kolab, samba, asterix (ok, so it's a nasty bit of perl scripts in that case ;), pam_ldap, etc... i'm also looking at novell and red hat with their pet directory solutions.
listen up: one place where microsoft is kicking our ass, and not gently at that, is in the integration they offer at the directory level. it's trivial to set up a directory based log in system that also houses your groupware log ins ... or pretty much any other bit of their software stack.
on linux? it's a pain the ass (which means our rump is doubly sore: once from microsoft's boot and once from trying to configure our own systems). where is the coordination between these projects? why is it that integrating kolab with a samba ldap system is arcane black magic that requires manual maintenance?
c'mon, this isn't rocket science. it just takes some very basic goal setting ("a coherent directory strategy in the open source world that is sys admin friendly"), some basic communication and a bit of work.
if we don't do this, we're only hurting ourselves. if we don't have a kolab with good samba directory integration by the time kontact is running on win32 and macOS with kde4, we'll have 'earned' the right to be called incompetent. and why should people behind kolab (to pick on them for a moment ;) do this? because it will expand their user base dramatically. it's good for everyone. well, except microsoft.
so, if you know someone who might benefit from adding either of the above 2 resolutions to their own new year's resolutions list, please forward them this blog entry.
happy new year everyone! =)
Saturday, December 30, 2006
the case for distributed revision control
in the world of revision control, the debate between centralized (cvs, svn, etc) and distributed (git, mercurial, bzr, etc) has been going on for a while. from the distributed camp i've heard arguments about the blessings of being able to branch wildly, of patch management bliss and of file storage formats.
recently i started using git for a few things and i have to say it is fast, compact and rather easy to use. (this is a combination other distributed rc's i've tried haven't offered) i've come to the personal conclusion that git is a very nice tool that may even be able to meet our demanding and whacky requirements in the kde project in a few years time. maybe sooner. and this got me thinking: why would we use such tools?
the answer came to me as i travelled to various locations on the planet this year.
the internet is absolutely core player in free software development. it is how we collaborate at every stage: irc, email and source sharing. email is just fine over a slow and intermittent connection but something like subversion is hellacious to try and use in such situations. since it requires you to be online to update and commit, it also means that you need to be online whenever you are doing development. there's also a non-trivial amount of network traffic that gets generated.
so where does my travelling fit into all this? i've been in a number of very populous countries where such internet connections simply aren't the norm, particularly not in private homes. which means using tools like subversion is a blocker to participation.
if we really want to reach out to people who have the knowledge, skills and drive to get involved but who have slow (by broadband standards) dial up access that they pay for by the minute we will need to move towards systems that allow people to work offline as much as possible.
for me, this is where tools such as git shine. you can work in your local repository without a network connection just fine, including committing, branching and the whole bit. you only need to go online to send patches and pull updates. patches by email are manageable even on dial up and git's speed means that pulling updates can be economical.
furthermore, git's on-disk storage format makes it friendly for use on systems with smaller disks and its performance makes it more than usable on slower systems. i haven't looked at its memory consumption, so perhaps that an achiles heal.
so, long story short: reaching out to the just-getting-wired world means we need to look beyond centralized online systems. until there's broadband everywhere, and that's not going to happen in the mid term, we may want to think about our tools in that light.
distributed bug systems are probably equally attractive for these same reasons.
recently i started using git for a few things and i have to say it is fast, compact and rather easy to use. (this is a combination other distributed rc's i've tried haven't offered) i've come to the personal conclusion that git is a very nice tool that may even be able to meet our demanding and whacky requirements in the kde project in a few years time. maybe sooner. and this got me thinking: why would we use such tools?
the answer came to me as i travelled to various locations on the planet this year.
the internet is absolutely core player in free software development. it is how we collaborate at every stage: irc, email and source sharing. email is just fine over a slow and intermittent connection but something like subversion is hellacious to try and use in such situations. since it requires you to be online to update and commit, it also means that you need to be online whenever you are doing development. there's also a non-trivial amount of network traffic that gets generated.
so where does my travelling fit into all this? i've been in a number of very populous countries where such internet connections simply aren't the norm, particularly not in private homes. which means using tools like subversion is a blocker to participation.
if we really want to reach out to people who have the knowledge, skills and drive to get involved but who have slow (by broadband standards) dial up access that they pay for by the minute we will need to move towards systems that allow people to work offline as much as possible.
for me, this is where tools such as git shine. you can work in your local repository without a network connection just fine, including committing, branching and the whole bit. you only need to go online to send patches and pull updates. patches by email are manageable even on dial up and git's speed means that pulling updates can be economical.
furthermore, git's on-disk storage format makes it friendly for use on systems with smaller disks and its performance makes it more than usable on slower systems. i haven't looked at its memory consumption, so perhaps that an achiles heal.
so, long story short: reaching out to the just-getting-wired world means we need to look beyond centralized online systems. until there's broadband everywhere, and that's not going to happen in the mid term, we may want to think about our tools in that light.
distributed bug systems are probably equally attractive for these same reasons.
just another manic wikiday ..
another busy friday on the dev wiki for me. with new years celebrations peeking around the corner there weren't as many other people around compared to past weeks, but Dominik Haumann and myself did have company.
there were additions made to the solid tutorial, several corrections and other minor edits provided by the eagle-eyes (and fingers) of readers and the kexi team discussed pulling their developer content over to the wiki. Dominik also started looking at the isv section and researching what others have already written on the topic around the 'net.
as for myself, i got pulled into a couple of unexpected but fruitful discussions throughout the day but still managed to put up a number of i18n/l10n tutorials. virtually all of that material was pulled over from the rather comprehensive kde i18n howto. in fact, it's almost too comprehensive. i spent quite a bit of time grooming passages, rearranging the order of sections, updating code examples and breaking it out into several separate tutorials.
this is something i'd actually really appreciate some feedback on: in line with the "university of kde"/lyceum concept, i've set up a couple of sections in the tutorials area much as one might find courses in an american university system. which is to say, they are numbered according to the nature and complexity of the information they cover, have a nice little abstract and note prerequisites (both for technologies you need and tutorials you should cover first). so, for example, "localization 101" covers the basics of unicode and Qt while "dbus 211" covers creating interfaces (and has dbus 101 and 201 as prereq's).
the idea is to give the reader a sense of what order to cover the material in each section as well as a way to succinctly note what you should know about before diving in over head. this way if someone wants to go and learn about a particular advanced topic, they can figure out what they need to know first by looking at the tutorial on that topic and working their way backwards through the prerequisites.
eventually i'd love to see a mediawiki module/plugin/whatever-they-are-called that can help automate the process a bit, including allowing tutorial authors and editors to select prerequisites via an html form listing existing tutorials and known technologies as well as tracking for logged in users so they can see alongside the pre-req's what they've already covered. such a thing is a ways down the road, but before i start spending too much thought and energy in that direction, i'd like to hear from people who might actually end up using the developer wiki to learn if this would be useful to them.
you can either let me know your opinion in a comment attached to this blog entry or by emailing me directly (aseigo at kde dot org). and if you're a mediawiki savvy php developer who'd like to take a crack at such a plugin, please let me know =)
there were additions made to the solid tutorial, several corrections and other minor edits provided by the eagle-eyes (and fingers) of readers and the kexi team discussed pulling their developer content over to the wiki. Dominik also started looking at the isv section and researching what others have already written on the topic around the 'net.
as for myself, i got pulled into a couple of unexpected but fruitful discussions throughout the day but still managed to put up a number of i18n/l10n tutorials. virtually all of that material was pulled over from the rather comprehensive kde i18n howto. in fact, it's almost too comprehensive. i spent quite a bit of time grooming passages, rearranging the order of sections, updating code examples and breaking it out into several separate tutorials.
this is something i'd actually really appreciate some feedback on: in line with the "university of kde"/lyceum concept, i've set up a couple of sections in the tutorials area much as one might find courses in an american university system. which is to say, they are numbered according to the nature and complexity of the information they cover, have a nice little abstract and note prerequisites (both for technologies you need and tutorials you should cover first). so, for example, "localization 101" covers the basics of unicode and Qt while "dbus 211" covers creating interfaces (and has dbus 101 and 201 as prereq's).
the idea is to give the reader a sense of what order to cover the material in each section as well as a way to succinctly note what you should know about before diving in over head. this way if someone wants to go and learn about a particular advanced topic, they can figure out what they need to know first by looking at the tutorial on that topic and working their way backwards through the prerequisites.
eventually i'd love to see a mediawiki module/plugin/whatever-they-are-called that can help automate the process a bit, including allowing tutorial authors and editors to select prerequisites via an html form listing existing tutorials and known technologies as well as tracking for logged in users so they can see alongside the pre-req's what they've already covered. such a thing is a ways down the road, but before i start spending too much thought and energy in that direction, i'd like to hear from people who might actually end up using the developer wiki to learn if this would be useful to them.
you can either let me know your opinion in a comment attached to this blog entry or by emailing me directly (aseigo at kde dot org). and if you're a mediawiki savvy php developer who'd like to take a crack at such a plugin, please let me know =)
Friday, December 29, 2006
because we can
i slept in this morning, mostly due to staying up late hacking last night. that and i hate mornings. so the more of them i miss the better i figure life is ;)
but today's dev wiki friday ... and so now that i've taken care of errands that needed running and lunch (mmm.. roasted red peper soup and whole grain bread!) i'm off to #kde-www on irc. i see there are already several dozen edits on the wiki.
how do i know this? because you can track changes by subscribing to this RSS feed. in fact, if you go to the recent changes page you'll see the little RSS icon pop up at the bottom of the window. well, assuming you're using a decent browser like konq. =) click 'n add and track how we're doing.
if you had been subscribed yesterday, you may have noticed the oxygen team starting to accrue documents there. kde4 may well be the first kde release with comprehensive documentation on creating art elements for the platform. woo-hoo!
i also came across Benoit Jacob's blog entry on eigen. it's a math library written in and for c++ (and language that bind to it) that does precisely what they needed and wanted: the ability to perform the math needed for things like controlling cameras in opengl scenes.
the example app, shown in a screenshot to the right, is 122 lines of code most of which is setting up the opengl scene. you can pan and zoom freely and completely smoothly through the scene in 3 dimensions. the cpu monitor doesn't even twitch on my laptop as i zoom around; the beauty of rendering on the graphics chipset. the part eigen plays is to manage the 4x4 matrix used to manipulate the camera based on mouse movement. this is done with 4 lines of code, 2 for the left mouse button actions and 2 for the right mouse button actions.
it's interesting to see these kinds of frameworks emerging. and by "these kinds" i mean things like kimagefx, zack's work on a physics engine, canvases (a simple one, kboard, and a complex one, qgraphicsscene), svg, eigen ... (hm. zack's involved in 3 of those things). this work will allow us to experiment with new ideas quite easily and efficiently.
and why are we doing this? because we can. we don't need to justify it further than "it's fun to do", "this is going to be so freaking cool!" or "because i want to". we don't have financial bottom lines to justify, market researchers to appease ... and i firmly believe that in the end this creates a better user experience. it's not about buzzwords we think will hook people or investing in visual polish enough that the rough ugly boringness gets hidden beneath the rug, but actually creating something that's interesting to use and, perhaps even more importantly, interesting to create with.
but today's dev wiki friday ... and so now that i've taken care of errands that needed running and lunch (mmm.. roasted red peper soup and whole grain bread!) i'm off to #kde-www on irc. i see there are already several dozen edits on the wiki.
how do i know this? because you can track changes by subscribing to this RSS feed. in fact, if you go to the recent changes page you'll see the little RSS icon pop up at the bottom of the window. well, assuming you're using a decent browser like konq. =) click 'n add and track how we're doing.
if you had been subscribed yesterday, you may have noticed the oxygen team starting to accrue documents there. kde4 may well be the first kde release with comprehensive documentation on creating art elements for the platform. woo-hoo!
i also came across Benoit Jacob's blog entry on eigen. it's a math library written in and for c++ (and language that bind to it) that does precisely what they needed and wanted: the ability to perform the math needed for things like controlling cameras in opengl scenes.
the example app, shown in a screenshot to the right, is 122 lines of code most of which is setting up the opengl scene. you can pan and zoom freely and completely smoothly through the scene in 3 dimensions. the cpu monitor doesn't even twitch on my laptop as i zoom around; the beauty of rendering on the graphics chipset. the part eigen plays is to manage the 4x4 matrix used to manipulate the camera based on mouse movement. this is done with 4 lines of code, 2 for the left mouse button actions and 2 for the right mouse button actions.it's interesting to see these kinds of frameworks emerging. and by "these kinds" i mean things like kimagefx, zack's work on a physics engine, canvases (a simple one, kboard, and a complex one, qgraphicsscene), svg, eigen ... (hm. zack's involved in 3 of those things). this work will allow us to experiment with new ideas quite easily and efficiently.
and why are we doing this? because we can. we don't need to justify it further than "it's fun to do", "this is going to be so freaking cool!" or "because i want to". we don't have financial bottom lines to justify, market researchers to appease ... and i firmly believe that in the end this creates a better user experience. it's not about buzzwords we think will hook people or investing in visual polish enough that the rough ugly boringness gets hidden beneath the rug, but actually creating something that's interesting to use and, perhaps even more importantly, interesting to create with.
Thursday, December 28, 2006
on oxygen, on dolphin
just got out of another oxygen meeting, this time specifically about icons. ken will be blogging about it in more detail so i won't steal his thunder, but i do want to note that what's really nice about the oxygen process is that it's one that encompasses developers, artists and usability people.
so something i'm doing today is cataloging the icons used in kdelibs so that we can ensure coverage of them. in the process we'll be using work Riddell (yes, the kubuntu guy =) has done on mapping our icon names to the ones in the freedesktop.org spec.
the idea is that for the next developer release we'll have at least oxygen icon coverage for libs and, hopefully, the workspace apps. this should give some of those visual improvements people are wailing for as well as help get wider testing of the icons. thus, we are prioritizing the work in that direction.
when will that developer release happen? sooner rather than later, i hope. and with the newly forming release team i expect to see plans emerge in the new year once everyone's recovered from xmas and new years partying.
from art to file managers, i thought i'd also post a quick note about the point of dolphin and how it fits into the scheme of things as those of us who work on those bits are concerned. btw, david faure is a huge part of that "us"; i think he occupies three or four complete slots in that line up actually, kind of like that bugs bunny cartoon where he plays every position in the baseball team ;)
so, what is the point of dolphin? first, i think it's obvious to everyone that konqueror kicks some pretty serious ass. the downside is that it's really tuned for a particular category of power users. our plan is therefore to introduce a file manager that is aimed at the rest of the masses and tuned specifically for file management. where does this leave konqueror? as a power user's app and generally useful multi-function tool. i expect we will continue to ship konqueror in its current form, modulo kde4 improvements to the ui and guts.
and its the guts that are really exciting: most of them are being shared between konqueror, dolphin and even the file dialog. so as core features become available they are showing up across all the apps. this limits the concern that everyone focuses on dolphin and konqueror bit rots, or vice versa. sharing code through libraries and loadable components has always been a strategy in kde, and one that has worked well for us in the past. expect to see similar fruits borne from the revamping of our file management core functionality, with konqueror and dolphin being two front ends to it all that are built for two different audiences both of whom are important to us.
so something i'm doing today is cataloging the icons used in kdelibs so that we can ensure coverage of them. in the process we'll be using work Riddell (yes, the kubuntu guy =) has done on mapping our icon names to the ones in the freedesktop.org spec.
the idea is that for the next developer release we'll have at least oxygen icon coverage for libs and, hopefully, the workspace apps. this should give some of those visual improvements people are wailing for as well as help get wider testing of the icons. thus, we are prioritizing the work in that direction.
when will that developer release happen? sooner rather than later, i hope. and with the newly forming release team i expect to see plans emerge in the new year once everyone's recovered from xmas and new years partying.
from art to file managers, i thought i'd also post a quick note about the point of dolphin and how it fits into the scheme of things as those of us who work on those bits are concerned. btw, david faure is a huge part of that "us"; i think he occupies three or four complete slots in that line up actually, kind of like that bugs bunny cartoon where he plays every position in the baseball team ;)
so, what is the point of dolphin? first, i think it's obvious to everyone that konqueror kicks some pretty serious ass. the downside is that it's really tuned for a particular category of power users. our plan is therefore to introduce a file manager that is aimed at the rest of the masses and tuned specifically for file management. where does this leave konqueror? as a power user's app and generally useful multi-function tool. i expect we will continue to ship konqueror in its current form, modulo kde4 improvements to the ui and guts.
and its the guts that are really exciting: most of them are being shared between konqueror, dolphin and even the file dialog. so as core features become available they are showing up across all the apps. this limits the concern that everyone focuses on dolphin and konqueror bit rots, or vice versa. sharing code through libraries and loadable components has always been a strategy in kde, and one that has worked well for us in the past. expect to see similar fruits borne from the revamping of our file management core functionality, with konqueror and dolphin being two front ends to it all that are built for two different audiences both of whom are important to us.
geeks aren't the only ones with women challenges
post-hacking tonight i went to a local bar. there was a cover band playing called "bulls on parade". rather unique; i've never heard a rage against the machine cover band live and they did a great job.
there was a group of women who were obviously together. as the music got louder they receded to a quieter area. a group of guys went up to them in between sets and they started pairing off .. and then .. it was women on one side and guys on the other.
i had to know.
so i went up and asked what the dynamics were. apparently they all knew each other! and apparently the guys were not so great at sealing the deal. it was like being at a grade school dance: a line down the middle separating girls from boys.
so we talked for a while. they (female) asked what i did while they (guys) brooded. i explained what i did (guys: improving the world through freedom is a big seller. trust me). they (female) asked about my shirt, i explained about linux conf australia, tux and penguins. they were all attentive. so i asked what they did.
they said: guess.
so i went around the table and guessed. i nailed every single guy's profession and then lied about what i thought each girl might do. the women were amazed at how accurate i was about the guys (out of work, construction, english major; even though each looked superficially like the other) and how off i was about them (never let a woman know you know anything about them; they love to think mystery is what cloaks them) ..
the guy next to me (the out of work one) looks at me unhappily. i say "how are you holding up?" he says "great, until you came. you can leave whenever you want."
mission accomplished. i went and and danced to the second set and bought the two birthday girls in the group (that's why everyone was out) tequila .. and left.
walking home as the snow fell, i looked up and across.. clouds, stars, people and sky.
we'll call 3 days from now "next year" but it's all constructions of our perception. just like everyone in the club tonight.
i thought of the svn commits i'll do tomorrow and smiled. yeah. KMimeActions.
there was a group of women who were obviously together. as the music got louder they receded to a quieter area. a group of guys went up to them in between sets and they started pairing off .. and then .. it was women on one side and guys on the other.
i had to know.
so i went up and asked what the dynamics were. apparently they all knew each other! and apparently the guys were not so great at sealing the deal. it was like being at a grade school dance: a line down the middle separating girls from boys.
so we talked for a while. they (female) asked what i did while they (guys) brooded. i explained what i did (guys: improving the world through freedom is a big seller. trust me). they (female) asked about my shirt, i explained about linux conf australia, tux and penguins. they were all attentive. so i asked what they did.
they said: guess.
so i went around the table and guessed. i nailed every single guy's profession and then lied about what i thought each girl might do. the women were amazed at how accurate i was about the guys (out of work, construction, english major; even though each looked superficially like the other) and how off i was about them (never let a woman know you know anything about them; they love to think mystery is what cloaks them) ..
the guy next to me (the out of work one) looks at me unhappily. i say "how are you holding up?" he says "great, until you came. you can leave whenever you want."
mission accomplished. i went and and danced to the second set and bought the two birthday girls in the group (that's why everyone was out) tequila .. and left.
walking home as the snow fell, i looked up and across.. clouds, stars, people and sky.
we'll call 3 days from now "next year" but it's all constructions of our perception. just like everyone in the club tonight.
i thought of the svn commits i'll do tomorrow and smiled. yeah. KMimeActions.
how not to save temporary data
yesterday i drew up a diagram of kapplication's methods and how they interact. it looks something like this:
the three groups you see there are session management, focus stealing prevention (mis-labeled "startup notification" in the diagram) and x11 event filter management. that is essentially what kapplication adds to qapplication now. there are a few black and grey boxes at the top. the grey ones are methods don't belong in kapplication and the black ones are deprecated by other classes.
in that category comes KApplication::tempSaveName. this returns a path to which one might autosave a file to. well, we now have KAutoSaveFile for that. however, several applications were abusing it to save data in general. this is a bad idea because there is no guarantee that those files will be there on reboot and it isn't safe against temp file races. in fact, the names are probably easily known as there is no file name substitution at all.
what i saw in several places was essentially a call to
anyways, in all of the cases where tempSaveName is used the developer should be using one of:
and yes, we need a nice tutorial on using these classes on developernew.kde.org. feel free to join us on friday to author it =) i'll be doing another dbus tutorial and a tutorial on another topic (i've got about 4 lined up to choose from) ...
in other good news it looks like we can get rid of KApplication::notify which was process every single event passed to the application. this should provide some additional speed up to kde4. whether its user visible or not remains to be seen as i haven't done any benchmarking, but it's certainly an easy pick. there's also code in the x11EventFilter than will be dieing soon making that method much faster as well. hooray.
the three groups you see there are session management, focus stealing prevention (mis-labeled "startup notification" in the diagram) and x11 event filter management. that is essentially what kapplication adds to qapplication now. there are a few black and grey boxes at the top. the grey ones are methods don't belong in kapplication and the black ones are deprecated by other classes.
in that category comes KApplication::tempSaveName. this returns a path to which one might autosave a file to. well, we now have KAutoSaveFile for that. however, several applications were abusing it to save data in general. this is a bad idea because there is no guarantee that those files will be there on reboot and it isn't safe against temp file races. in fact, the names are probably easily known as there is no file name substitution at all.
what i saw in several places was essentially a call to
doc->save(kapp->tempSaveName(filename)). the intention often seems to be to save the document in a temporary state; in that case i highly recommend creating a MyDocument::autosave() method which uses a KAutoSaveFile internally to do this rather than try and manage it from the outside. you also get, as a free bonus, document recovery so that if something goes bad (crash, power outage, etc) the next time the app starts up you'll have easy and reliable access to the last saved state much like how kmail manages to not lose email drafts in this manner.anyways, in all of the cases where tempSaveName is used the developer should be using one of:
- KSaveFile
- KAutoSaveFile
- KTemporaryFile
and yes, we need a nice tutorial on using these classes on developernew.kde.org. feel free to join us on friday to author it =) i'll be doing another dbus tutorial and a tutorial on another topic (i've got about 4 lined up to choose from) ...
in other good news it looks like we can get rid of KApplication::notify which was process every single event passed to the application. this should provide some additional speed up to kde4. whether its user visible or not remains to be seen as i haven't done any benchmarking, but it's certainly an easy pick. there's also code in the x11EventFilter than will be dieing soon making that method much faster as well. hooray.
Tuesday, December 26, 2006
kdelibs monday tuesday
today was the day to make kdelibs changes. a few were indeed made, including the following class renames:
david faure also committed a bunch of changes to KPropertiesDialog that touched its api.
the rest of the changes shouldn't affect those working on applications.
right now i'm about to get started on getting as many of the modules building again as possible. i have a gym date in a little over an hour, so we'll see how far i get. if you'd like to help, please do so. coordination on #kde4-devel is appreciated, of course.
so, where do we go from here? well, someone (e.g. me; perhaps you) needs to do something with the remaining lone class not organized in kdeui which is KLanguageButton, which isn't really a language button but a button that shows a drop down with a table in it. so .. it desperately needs a rename and perhaps some api lovin'. beyond that bit of trivia, it's time to go through the classes in kdecore and kdeui and see which are actually used in a way that warrants them being in kdelibs. some probably aren't. there's also the question of api changes that ought to be made to these classes.
i'm still hoping for the replacement of xmlgui with liveui. it seems to go in fits and starts. and i really, really do need to get back to work on the kconfig branch and finish that stuff up.
so, lots more libs mondays for me it seems =)
btw, it would be very useful to get feedback from application developers on what isn't working for them in the classes in kdecore and kdeui.
- KStdAccel becomes KStandardShortcut
- KStdGuiItem becomes KStandardGuiItem
- KWindowListMenu is moved to libkworkspace in kdebase
david faure also committed a bunch of changes to KPropertiesDialog that touched its api.
the rest of the changes shouldn't affect those working on applications.
right now i'm about to get started on getting as many of the modules building again as possible. i have a gym date in a little over an hour, so we'll see how far i get. if you'd like to help, please do so. coordination on #kde4-devel is appreciated, of course.
so, where do we go from here? well, someone (e.g. me; perhaps you) needs to do something with the remaining lone class not organized in kdeui which is KLanguageButton, which isn't really a language button but a button that shows a drop down with a table in it. so .. it desperately needs a rename and perhaps some api lovin'. beyond that bit of trivia, it's time to go through the classes in kdecore and kdeui and see which are actually used in a way that warrants them being in kdelibs. some probably aren't. there's also the question of api changes that ought to be made to these classes.
i'm still hoping for the replacement of xmlgui with liveui. it seems to go in fits and starts. and i really, really do need to get back to work on the kconfig branch and finish that stuff up.
so, lots more libs mondays for me it seems =)
btw, it would be very useful to get feedback from application developers on what isn't working for them in the classes in kdecore and kdeui.
Monday, December 25, 2006
happy holidays
merry whatever-you-celebrate-or-enjoy-at-this-time-of-year.
did dinner and what not over at t.'s family's place. we brought a couple of vegan apple pies and a dozen or so home made roles of sushi (plus half a dozen or so nigiri) .. the food was great and the conversation stimulating. huzzah for that.
today is christmas with p.'s mom's family. gift exchange, etc. i'm svn up'ing before leaving the house ;)
i didn't manage to get an opportunity to blog on friday about dev wiki day, so i'll do so quickly here before i jump in the shower and then go over the p.'s aunt's house:
it was a terrific success. probably somewhere around 100 edits and several new tutorials, including one on writing indexers for strigi, a dbus tutorial (i need to figure out how to upload non-image files so i put the example .service file online), one on qt4 designer and one on using solid. links to a few older tutorials from around the 'net that need to be ported to qt4/kde4 and put on the wiki were also added, including a few from the kde edu team. at this rate we can make the 100 tutorials mark by summer.
please join us this friday for developer wiki day. we still have lots of content to move over and tons of content to author. personally, i'll be continuing to work on the dbus tutorials and porting the i18n tutorial. what are you working on that hasn't been documented properly and is therefore keeping people from contributing to your kde project?
did dinner and what not over at t.'s family's place. we brought a couple of vegan apple pies and a dozen or so home made roles of sushi (plus half a dozen or so nigiri) .. the food was great and the conversation stimulating. huzzah for that.
today is christmas with p.'s mom's family. gift exchange, etc. i'm svn up'ing before leaving the house ;)
i didn't manage to get an opportunity to blog on friday about dev wiki day, so i'll do so quickly here before i jump in the shower and then go over the p.'s aunt's house:
it was a terrific success. probably somewhere around 100 edits and several new tutorials, including one on writing indexers for strigi, a dbus tutorial (i need to figure out how to upload non-image files so i put the example .service file online), one on qt4 designer and one on using solid. links to a few older tutorials from around the 'net that need to be ported to qt4/kde4 and put on the wiki were also added, including a few from the kde edu team. at this rate we can make the 100 tutorials mark by summer.
please join us this friday for developer wiki day. we still have lots of content to move over and tons of content to author. personally, i'll be continuing to work on the dbus tutorials and porting the i18n tutorial. what are you working on that hasn't been documented properly and is therefore keeping people from contributing to your kde project?
Friday, December 22, 2006
oxygen, graphics
a couple weeks ago the oxygen team finished putting together a one page presentation, seen in the above thumbnail, of what the oxygen icons project is all about. it's a really nice little piece to pass around to those wondering just what the motivation and concepts behind oxygen are. you can download your own copy of the oxygen presentation here. it's suitable for printing and therefore is a bit big (4.7MB).
zack's kimagefx lib is developing at a nice pace. the graph demo app is taking shape nicely and the number and quality of filters is growing by the day.
you can get it via git with `
git clone http://ktown.kde.org/~zrusin/dev/kimagefx.git` or read more about it here in zack's announcement email to kde-core-develdeveloper wiki friday is going tremendously well today. i'll blog about that this evening though once it's over. right now .. it's lunch time!
a website does not make you smart
so i read this bit of drivel over at osnews.com. i'd just like to point out to Thom Holwerda that having a website does not make you informed or intelligent. if anything it gives you a soapbox on which to showcase just how with it, or not, you are.
first, Thom points to a quote from me that our goal is to have a 4.0 ready sometime in the first half of next year. that gives us until sometime in june and i'm still thinking we can make it. i'm not sure what world Thom lives in, but not shipping this year what you hope to ship next year seems rational.
Thom also says that all the vision behind KDE4 has amounted to nothing but vision. i suppose, Thom, you aren't following progress in svn are you? obviously not, otherwise you would have noticed phonon, solid, decibel, strigi/nepomuk, oxygen, model/view-ization of the file management facilities, modernization of several parts of our libraries, etc, etc... even smaller items like sonnet, which is right now getting some nice grammar checking support, are moving forward. koffice2 jumps leaps and bounds along with many of the other apps in kde's svn. in other words, Thom is full of crap when he says 4.0 is stalled.
of course Thom ignores these facts while picking out two projects in particular: plasma and appeal. let me talk about both of them for a moment here, starting with appeal.
appeal was never a software project, and nobody ever said it was. it was an attempt to change how certain development processes occur in kde. and it has been a great success in my mind. directly out of it came the ideas for plasma and for oxygen; it also helped inspire others to think along new lines and come up with impressive new ways of addressing old issues. if Thom doesn't see the impact appeal had, he just isn't afforded the benefit of the viewpoint of someone inside the kde development community. this is the danger when you peer inside from the outside and try and expound sagely: odds are high you'll miss the mark.
plasma on the other hand is the visible part of an iceberg: the top couple percent of the whole structure. i've had to wait on item after item after item over the last year and half to be ready for plasma. during that same time i've been travelling like a mad man paying attention to kde issues that were also in need. a project like kde, which is to say a huge global meta-project, doesn't run itself anymore and it needs attention in ways it didn't used to. we had let it go to seed on a few fronts and i had been working to fix that. with the help of several others in the community i think we've accomplished much of what has been needed and now have in place mechanisms to continue that progress. that is to say that i've been both time committed to other items while the rest of the iceberge is prep'd for plasma.
last week i started working on parts of the replacements for kdesktop, which is part of the plasma project. i now have 4 days a week set aside for work on these issues, something i haven't had until this month. *shrug* i'm not particularly worried or concerned, but maybe that's because i'm in the driver's seat here. i understand that being a passenger can be a lot more disconcerting.
but when someone comes out and says that things are stalled or that it's all hot air when it isn't ... that sounds a lot like, what's the word? oh yeah, libel!
Thom takes advantage of Tim's blog about gtk+ needing more maintainers to write an alarmist piece that makes the national enquirer look like informed journalism. this is a double disservice: not only does it whip up unwarranted alarm amongst users and give our detractors unfounded ammunition, it punishes developers like Tim for speaking openly about the challenges we face. the free software community relies on our ability to speak openly and honestly to each other; if we start to get punished for it then we have a real problem. today that problem has a pair of names behind it: Thom Holwerda and osnews.com.
now, Thom does have one good point: we don't have enough developers. but asking me if we have enough developers is like asking a tribble if it thinks there are enough tribbles yet on captain kirk's enterprise. we can never have enough developers; there is always so much to do. even once we've accomplished everything we've set ahead of ourselves right now, there's still so much more to do =) with the developers we currently have things move ahead at a certain pace and i have to note that 4.0 is moving ahead faster now than it has at any other point in the last year. but yeah, we could always use more hands.
update: i just saw that Thom's article was picked up on slashdot. way to the do the community a disservice and join the libel brigade, cmdrtaco! merry christmas to you, too.
first, Thom points to a quote from me that our goal is to have a 4.0 ready sometime in the first half of next year. that gives us until sometime in june and i'm still thinking we can make it. i'm not sure what world Thom lives in, but not shipping this year what you hope to ship next year seems rational.
Thom also says that all the vision behind KDE4 has amounted to nothing but vision. i suppose, Thom, you aren't following progress in svn are you? obviously not, otherwise you would have noticed phonon, solid, decibel, strigi/nepomuk, oxygen, model/view-ization of the file management facilities, modernization of several parts of our libraries, etc, etc... even smaller items like sonnet, which is right now getting some nice grammar checking support, are moving forward. koffice2 jumps leaps and bounds along with many of the other apps in kde's svn. in other words, Thom is full of crap when he says 4.0 is stalled.
of course Thom ignores these facts while picking out two projects in particular: plasma and appeal. let me talk about both of them for a moment here, starting with appeal.
appeal was never a software project, and nobody ever said it was. it was an attempt to change how certain development processes occur in kde. and it has been a great success in my mind. directly out of it came the ideas for plasma and for oxygen; it also helped inspire others to think along new lines and come up with impressive new ways of addressing old issues. if Thom doesn't see the impact appeal had, he just isn't afforded the benefit of the viewpoint of someone inside the kde development community. this is the danger when you peer inside from the outside and try and expound sagely: odds are high you'll miss the mark.
plasma on the other hand is the visible part of an iceberg: the top couple percent of the whole structure. i've had to wait on item after item after item over the last year and half to be ready for plasma. during that same time i've been travelling like a mad man paying attention to kde issues that were also in need. a project like kde, which is to say a huge global meta-project, doesn't run itself anymore and it needs attention in ways it didn't used to. we had let it go to seed on a few fronts and i had been working to fix that. with the help of several others in the community i think we've accomplished much of what has been needed and now have in place mechanisms to continue that progress. that is to say that i've been both time committed to other items while the rest of the iceberge is prep'd for plasma.
last week i started working on parts of the replacements for kdesktop, which is part of the plasma project. i now have 4 days a week set aside for work on these issues, something i haven't had until this month. *shrug* i'm not particularly worried or concerned, but maybe that's because i'm in the driver's seat here. i understand that being a passenger can be a lot more disconcerting.
but when someone comes out and says that things are stalled or that it's all hot air when it isn't ... that sounds a lot like, what's the word? oh yeah, libel!
Thom takes advantage of Tim's blog about gtk+ needing more maintainers to write an alarmist piece that makes the national enquirer look like informed journalism. this is a double disservice: not only does it whip up unwarranted alarm amongst users and give our detractors unfounded ammunition, it punishes developers like Tim for speaking openly about the challenges we face. the free software community relies on our ability to speak openly and honestly to each other; if we start to get punished for it then we have a real problem. today that problem has a pair of names behind it: Thom Holwerda and osnews.com.
now, Thom does have one good point: we don't have enough developers. but asking me if we have enough developers is like asking a tribble if it thinks there are enough tribbles yet on captain kirk's enterprise. we can never have enough developers; there is always so much to do. even once we've accomplished everything we've set ahead of ourselves right now, there's still so much more to do =) with the developers we currently have things move ahead at a certain pace and i have to note that 4.0 is moving ahead faster now than it has at any other point in the last year. but yeah, we could always use more hands.
update: i just saw that Thom's article was picked up on slashdot. way to the do the community a disservice and join the libel brigade, cmdrtaco! merry christmas to you, too.
Thursday, December 21, 2006
screenshot wednesday
seeing as i have something for monday and fridays, i thought i'd invent something for today: screenshot wednesday! yay! *glitter* *confetti* *balloons*
(as an aside, i spent all of last wednesday thinking it was thursday. it wasn't until the next day, thursday, that i realized it wasn't friday but thursday and that the day before had to have been wednesday. the term is "temporally challenged". ;)
today i was building kde4 and looked at the icemon window sitting in the top corner of the screen with its jaggies and thought, "wouldn't it be nice if there was a kde4 port of icemon so that we could have something slightly less ugly to look at." i wandered over to the icemon code in trunk/playground/devtools/icemon (why is it in playground?!) and lo! there was a kde4 port. i fixed up the code a bit so it ran against current kdelibs and voila, i had a nice kde4 icemon:
what is the connection between freedom and liberty?
like a magic 8 ball, icemon knows all
i also got time to work on krunner a bit today. you can now launch things with it even! =)
the above shot shows the composition manager support by way of the translucent background. that's because the svg used has translucent areas and krunner checks to see if you have a composition manager running. if you don't, or the svg used is opaque, you get something much less interesting/annoying (depending on your viewpoint ;). but it's real translucency. and yes, that's an example svg not something intended to be final; one of the oxygen artists (hey ruphy!) threw it (and a couple others) together for me in about 15 minutes the other day.
and just so it doesn't come as a shock to anyone: i have no plans to support anything but such real translucency in plasma. so if you aren't running a composition manager you get less bling on your panels (though the desktop canvas will still be properly blended and beautiful). the upside is that what bling you do get is both real and not just a silly performance hogging hack. =)
anyways, with a run command dialog that works i'll be able to move kdesktop aside in favour of a plasma canvas. yay. there's still a good couple days of solid work (unlike today in which i got maybe 3 hours in on krunner if that due to working on other items). so yes, i'm quite aware that there isn't any label telling you what this window is, that the options label is far too subtle and that the search runner can take over and not give control back to the shell or app runner. among other TODOs.
in any case, i'll probably check the code in either tonight or tomorrow morning (i have to go to the christmas concert at p's school this evening, so that'll dictate timing) so that others who wish to can help out. or just point and laugh at my code. their choice really. ;)
(as an aside, i spent all of last wednesday thinking it was thursday. it wasn't until the next day, thursday, that i realized it wasn't friday but thursday and that the day before had to have been wednesday. the term is "temporally challenged". ;)
today i was building kde4 and looked at the icemon window sitting in the top corner of the screen with its jaggies and thought, "wouldn't it be nice if there was a kde4 port of icemon so that we could have something slightly less ugly to look at." i wandered over to the icemon code in trunk/playground/devtools/icemon (why is it in playground?!) and lo! there was a kde4 port. i fixed up the code a bit so it ran against current kdelibs and voila, i had a nice kde4 icemon:
what is the connection between freedom and liberty?like a magic 8 ball, icemon knows all
i also got time to work on krunner a bit today. you can now launch things with it even! =)
the above shot shows the composition manager support by way of the translucent background. that's because the svg used has translucent areas and krunner checks to see if you have a composition manager running. if you don't, or the svg used is opaque, you get something much less interesting/annoying (depending on your viewpoint ;). but it's real translucency. and yes, that's an example svg not something intended to be final; one of the oxygen artists (hey ruphy!) threw it (and a couple others) together for me in about 15 minutes the other day.
and just so it doesn't come as a shock to anyone: i have no plans to support anything but such real translucency in plasma. so if you aren't running a composition manager you get less bling on your panels (though the desktop canvas will still be properly blended and beautiful). the upside is that what bling you do get is both real and not just a silly performance hogging hack. =)
anyways, with a run command dialog that works i'll be able to move kdesktop aside in favour of a plasma canvas. yay. there's still a good couple days of solid work (unlike today in which i got maybe 3 hours in on krunner if that due to working on other items). so yes, i'm quite aware that there isn't any label telling you what this window is, that the options label is far too subtle and that the search runner can take over and not give control back to the shell or app runner. among other TODOs.
in any case, i'll probably check the code in either tonight or tomorrow morning (i have to go to the christmas concert at p's school this evening, so that'll dictate timing) so that others who wish to can help out. or just point and laugh at my code. their choice really. ;)
Wednesday, December 20, 2006
appreciating the platform
if you watched sesame street as a kid, this phrase will either bring back warm memories or send shivers down your spine (depending on how you feel about muppets, i suppose =): "today's show was brought to you by the number 3 and the letters 'n' and 'p'. sesame street is made possible through the support PBS..."
whenever i look at a kde application a similar thought runs through my head: "this application was brought to me by this application and the kde, qt and x.org projects". yes, that's a simplification, but the idea is clear: our applications don't stand as lone monuments to the application developer's work. they are both part of something bigger (a whole universe of cool apps!) while also made possible by the efforts of those working on the platforms on which they rest.
if you are a kde application developer, perhaps take a moment over the holidays to look through your code and see all the K's and Q's in there. and if you look deeper into the libraries those letters came from you'll see other letters like X.
for me, there are two really important things here. first off, when i write an application i have something of a duty to the platform i'm using. when i diverge to afar afield, i'm actually not doing anyone aside from my ego a favour. when i don't send my Cool Amazing Generally Applicable Techqnique(tm and copylefted, patent not pending) down-stream so that other app developers can benefit and help me maintain it, i'm also losing out. kdelibs would not be where it is today without these concepts.
the other important bit for me is that spending some time working on the foundations is really, really valuable. applications are what defines values on a platform, but without a solid platform you don't get valuable applications. it's a virtuous circle.
right now, however, that virtuous circle is breaking down. and not just in kde. tim janik wrote a really great blog entry today abut the unfortunate state of maintenance in gtk+. i really recommend reading the email tim sent to the gtk devel list on this same topic. there are some truly sage points in that email and it is as applicable to kdelibs as it is to gtk+.
it really doesn't take much, either. even helping maintain just one class or one set of functionality goes a long, long way. every lib hacker has the support of the others and it doesn't take a huge time commitment, just a little time here and there consistently. those who do put in large amounts of effort are also welcome and needed, of course, but that isn't the only way to be involved in a meaningful manner. and when you are involved in a meaningful way with the libs, every application benefits including your own.
this tuesday is "libs monday" (due to monday being a signficant holiday for many people, so we moved it ahead one day so as to work around that) and much of the work i'll be doing could be done by anyone with a bit of direction and an svn checkout of kde4. even if libs mondays don't work for you time-wise, pick any day or time that works for you and find us on #kde-devel or #kde4-devel and there's probably someone there than can help with your questions and what not. the usual mailing lists (kde-devel at kde dot org being the most common one) are also at your disposal.
by getting involved we'll continue to be able to say for years, even decades, to come: "these apps were brought to you by the developers of the application and made possible by the support of the kde project..." =)
whenever i look at a kde application a similar thought runs through my head: "this application was brought to me by this application and the kde, qt and x.org projects". yes, that's a simplification, but the idea is clear: our applications don't stand as lone monuments to the application developer's work. they are both part of something bigger (a whole universe of cool apps!) while also made possible by the efforts of those working on the platforms on which they rest.
if you are a kde application developer, perhaps take a moment over the holidays to look through your code and see all the K's and Q's in there. and if you look deeper into the libraries those letters came from you'll see other letters like X.
for me, there are two really important things here. first off, when i write an application i have something of a duty to the platform i'm using. when i diverge to afar afield, i'm actually not doing anyone aside from my ego a favour. when i don't send my Cool Amazing Generally Applicable Techqnique(tm and copylefted, patent not pending) down-stream so that other app developers can benefit and help me maintain it, i'm also losing out. kdelibs would not be where it is today without these concepts.
the other important bit for me is that spending some time working on the foundations is really, really valuable. applications are what defines values on a platform, but without a solid platform you don't get valuable applications. it's a virtuous circle.
right now, however, that virtuous circle is breaking down. and not just in kde. tim janik wrote a really great blog entry today abut the unfortunate state of maintenance in gtk+. i really recommend reading the email tim sent to the gtk devel list on this same topic. there are some truly sage points in that email and it is as applicable to kdelibs as it is to gtk+.
it really doesn't take much, either. even helping maintain just one class or one set of functionality goes a long, long way. every lib hacker has the support of the others and it doesn't take a huge time commitment, just a little time here and there consistently. those who do put in large amounts of effort are also welcome and needed, of course, but that isn't the only way to be involved in a meaningful manner. and when you are involved in a meaningful way with the libs, every application benefits including your own.
this tuesday is "libs monday" (due to monday being a signficant holiday for many people, so we moved it ahead one day so as to work around that) and much of the work i'll be doing could be done by anyone with a bit of direction and an svn checkout of kde4. even if libs mondays don't work for you time-wise, pick any day or time that works for you and find us on #kde-devel or #kde4-devel and there's probably someone there than can help with your questions and what not. the usual mailing lists (kde-devel at kde dot org being the most common one) are also at your disposal.
by getting involved we'll continue to be able to say for years, even decades, to come: "these apps were brought to you by the developers of the application and made possible by the support of the kde project..." =)
Tuesday, December 19, 2006
more (teachers + kde)
what happens when you get 10 teachers from rural indian schools, 8 of whom had never used a computer before, and teach them how to use a computer powered by kde and linux? read all about it in this entry on the sikshana blog.
spoilers: the 8 new to computers had an easier time and apps like kalzium, filelight and xara were hits =)
just imagine: visiting a town where the kids at play in the streets and the adults working their trades alike are not only all educated and computer literate, but have only ever known free software systems. =)
and so as not to downplay what they are doing, introducing computers (on the teacher's terms) is probably one of the least things they are doing. they are donation supported and doing some great things for rural schools in the area. they recently got funding to put together some slick video showcasing their work and i think it turned out pretty well.
spoilers: the 8 new to computers had an easier time and apps like kalzium, filelight and xara were hits =)
just imagine: visiting a town where the kids at play in the streets and the adults working their trades alike are not only all educated and computer literate, but have only ever known free software systems. =)
and so as not to downplay what they are doing, introducing computers (on the teacher's terms) is probably one of the least things they are doing. they are donation supported and doing some great things for rural schools in the area. they recently got funding to put together some slick video showcasing their work and i think it turned out pretty well.
on deprecated api
there are a lot of "warning: foo defined in blah.h is deprecated" type warnings that scroll by as one compiles kde4. totally expected, but we'll eventually want to do something about it.
makes for a great junior job, really. if you'd like to get a feel for what kde4 is like but want to start in the safer end of the pool, think about taking on these deprecated warnings. virtually all of them are listed in kdelibs/KDE4PORTING.html (though a few bits are also here).
however, every so often i come across an api change that isn't well documented. there is no excuse for this. the kaction changes, for instance, aren't documented anywhere that i could find (and now that i've said that, some one will point me to the exact location in svn within the next 30 seconds).
i also saw a deprecation warning for kdelibs/kio/bookmarks/kbookmarkimporter_ns.h. sure enough, everything is marked as deprecated ... but there are absolutely no notes on what to replace those calls with. i suppose i could become overly intimate with the rest of the bookmark api, but then i'd rather just have some nice clear documentation as well.
and here's where i hand off to ade, my favourite documentarian. ;-P
makes for a great junior job, really. if you'd like to get a feel for what kde4 is like but want to start in the safer end of the pool, think about taking on these deprecated warnings. virtually all of them are listed in kdelibs/KDE4PORTING.html (though a few bits are also here).
however, every so often i come across an api change that isn't well documented. there is no excuse for this. the kaction changes, for instance, aren't documented anywhere that i could find (and now that i've said that, some one will point me to the exact location in svn within the next 30 seconds).
i also saw a deprecation warning for kdelibs/kio/bookmarks/kbookmarkimporter_ns.h. sure enough, everything is marked as deprecated ... but there are absolutely no notes on what to replace those calls with. i suppose i could become overly intimate with the rest of the bookmark api, but then i'd rather just have some nice clear documentation as well.
and here's where i hand off to ade, my favourite documentarian. ;-P
it's a wiki. you edit it.
the new developer wiki has also been going quite well. over the weekend danimo, with the help of a number of css wizards who answered the call in his blog, made the look of things like code boxes even cooler.
he also installed a wikimedia plugin that does syntax highlighting. that was cool enough. but then he tweaked it a bit and now it even links class names to the api documentation. holy crap! =)
i also uploaded images for the various licenses we support (by default we're dual licensing gfdl and creative commons attribution, share alike) and also created templates for them. so if you need to have some different license on your page,then you can just use the templates.
why other licenses, you ask? (ok, you probably didn't, but work with me here) we're getting some contributions such as some ruby/qt tutorials that are currently under creative commons attribution, non-commercial, share alike. we can't do much about the non-commercial bit unfortunately, but we can accommodate it. all darshan (the author) will need to do is do a {{CC-BY-NC-SA}} and boom! license is noted.
i hear tale of other tutorials coming too .. e.g. for kmetadata, a cool new library from the kde nepomuk project and sebastian trüg (if that name rings bells, think "kde cd burning software"), solid and more..
someone noted a bit of out of date content on the wiki and msg'd me on irc to let me know. i told them it was a wiki and that they could edit it. we both laughed and they made the change.
and remember, you too can edit it. really! (why does that sound like one of those 80s saturday morning cartoon "morals" they'd always tag on to the end? "remember he-man, recycling can help save the world! don't do drugs!")
he also installed a wikimedia plugin that does syntax highlighting. that was cool enough. but then he tweaked it a bit and now it even links class names to the api documentation. holy crap! =)
i also uploaded images for the various licenses we support (by default we're dual licensing gfdl and creative commons attribution, share alike) and also created templates for them. so if you need to have some different license on your page,then you can just use the templates.
why other licenses, you ask? (ok, you probably didn't, but work with me here) we're getting some contributions such as some ruby/qt tutorials that are currently under creative commons attribution, non-commercial, share alike. we can't do much about the non-commercial bit unfortunately, but we can accommodate it. all darshan (the author) will need to do is do a {{CC-BY-NC-SA}} and boom! license is noted.
i hear tale of other tutorials coming too .. e.g. for kmetadata, a cool new library from the kde nepomuk project and sebastian trüg (if that name rings bells, think "kde cd burning software"), solid and more..
someone noted a bit of out of date content on the wiki and msg'd me on irc to let me know. i told them it was a wiki and that they could edit it. we both laughed and they made the change.
and remember, you too can edit it. really! (why does that sound like one of those 80s saturday morning cartoon "morals" they'd always tag on to the end? "remember he-man, recycling can help save the world! don't do drugs!")
kdelibs (and artwork meeting) monday
i worked on krunner for a little bit on saturday before heading out with t. to her company xmas party. it's a bit odd to go to these events as a number of people there know me as "that kde guy" and i end up getting asked about kde things for much of the night. it's not like i discourage them from doing so (hey, any opportunity to spread the love =) but makes me feel like the proverbial lawyer at a dinner party.
we did get to do some swing dancing. apparently one of the owners is totally into the swing dance thing and brings in people to do a quick swing dance class after dinner so people can move slightly more coherently to the music provided by the band. all in all a good night. so good that i took the next day off. just laid in bed and what not. wow! a day off! =)
but today was monday, which means libs day. i moved a few more classes into appropriate places in kdeui, so for instance all the cool new page model based widgets and dialogs that tobias worked on are in kdeui/paged/ now. the goal with all this is that kdeui is more approachable for a dev who just wants to work on a specific set of classes. which is why we're grouping them based on concept, of course! =)
i also made one wide impacting change: KStdAction is now KStandardAction and defined in kstandardaction.h. this led to me sitting in my work area, which today was the bedroom (happens to be where the desktop system is right now), with the laptop on one side and the desktop on the other running perl scripts and building modules. damn we have a lot of source code! i've still got two modules to compile and then check in: koffice, kwebdev and kdevelop. both are in process.
i noticed that kaction has changed a bit too. the constructors are now more in line with qaction's. so instead of doing:
we now do:
the code is, imho, more readable this way, easier to port from qaction and gives better control over the signal/slot connections.
montel was also a monster today hunting down one run-time dbus error after another. great work =)
and as if that wasn't enough, 7 of us or so gathered on irc for an art meeting. we discussed the oxygen widget style and window decoration. in particular, where we're going to develop it (in oxygen's svn), how we're going to communicate between the artists and developers (things like artists defining gradients in a way that us devs can grok, storyboarding for animations, etc..) and what our goals are (e.g. organics). we're going to have more of these meetings to keep everyone coordinated. look for some initial code drops by casper boemann shortly after ken weimer set up the directory structure in svn.
what a productive day =) tomorrow is back to work on krunner, with the hope of a commit to svn by the evening of a first working draft. e.g. something that launches apps and does basic searching while looking good doing it.
we did get to do some swing dancing. apparently one of the owners is totally into the swing dance thing and brings in people to do a quick swing dance class after dinner so people can move slightly more coherently to the music provided by the band. all in all a good night. so good that i took the next day off. just laid in bed and what not. wow! a day off! =)
but today was monday, which means libs day. i moved a few more classes into appropriate places in kdeui, so for instance all the cool new page model based widgets and dialogs that tobias worked on are in kdeui/paged/ now. the goal with all this is that kdeui is more approachable for a dev who just wants to work on a specific set of classes. which is why we're grouping them based on concept, of course! =)
i also made one wide impacting change: KStdAction is now KStandardAction and defined in kstandardaction.h. this led to me sitting in my work area, which today was the bedroom (happens to be where the desktop system is right now), with the laptop on one side and the desktop on the other running perl scripts and building modules. damn we have a lot of source code! i've still got two modules to compile and then check in: koffice, kwebdev and kdevelop. both are in process.
i noticed that kaction has changed a bit too. the constructors are now more in line with qaction's. so instead of doing:
KAction* action = new KAction(i18n("Name"), "icon", object, SLOT(slot()), actionCollection(), "name")
we now do:
KAction* action = new KAction(KIcon("icon"), i18n("Name"), actionCollection(), "name");
connect(action, SIGNAL(triggered(bool)), object, SLOT(slot()));
the code is, imho, more readable this way, easier to port from qaction and gives better control over the signal/slot connections.
montel was also a monster today hunting down one run-time dbus error after another. great work =)
and as if that wasn't enough, 7 of us or so gathered on irc for an art meeting. we discussed the oxygen widget style and window decoration. in particular, where we're going to develop it (in oxygen's svn), how we're going to communicate between the artists and developers (things like artists defining gradients in a way that us devs can grok, storyboarding for animations, etc..) and what our goals are (e.g. organics). we're going to have more of these meetings to keep everyone coordinated. look for some initial code drops by casper boemann shortly after ken weimer set up the directory structure in svn.
what a productive day =) tomorrow is back to work on krunner, with the hope of a commit to svn by the evening of a first working draft. e.g. something that launches apps and does basic searching while looking good doing it.
Saturday, December 16, 2006
patchserver
so i had this crazy little idea some time ago: people who take free software and modify for their own use should have an easy way to publish patches for others to find and use.
i keep running into people who have patched kde for this or that and for one reason or other haven't submitted the patches upstream. often it's a matter of trying to figure out how to deal with each project they patch, and between the projects we tend to be a bit different. there's also an effort related problem, namely that people tend to take the path of least resistance and while they will often upload patches to their own web server that's about as far as their ambitions will take them.
i blogged about it and got a few responses, including from one
Esteban Manchado Velázquez. he said he had started a small patch server web site using ruby on rails. we discussed some possibilities and he started working on it in earnest.
you can some of the results on the patchserver screenshot page.
even better yet, you can install it on your own server and start cataloging your patches. Esteban uses the darcs rcs, so utter this command to grab a copy:
what all does patchserver do? well, you upload patches and then you can view and edit metadata, such as which upstream version they apply against, related patches, descriptions, etc., view the patches on-line with syntax highlighting, view the history, view patches by various parameters such as for a given app or which ones aren't applied upstream yet, subscribe to rss feeds, full text searches and more.
future ideas involve integration with other development tools such as revision control and bug tracking systems, being able to reference patches in other patchserver installations, etc...
my big hope is that enough people will start making their patches available in this manner and then we can get one of the big open source friendly search providers, such as yahoo or google, to provide a search that is customized for patchserver content.
my dream is to one day be able to type into a search box "patches plasma 4.1" and have a list of links to patches with nice descriptions come up from servers around the world.
and yes, i completely agree that it would be best if people would work with the upstreams directly. i also realize the reality is that isn't likely to happen. i also agree that it would be totally cool if people had access to tools like canonical's launchpad, but they aren't releasing the source code it seems so that's that. (i don't fault canonical for that, it's their work and therefore their decision to do with it as they see fit.)
if enough of a community builds up around patchserver perhaps we can start working on another pet idea: a distributed bug system. ooh yeah. distributed patches, distributed revision control, distributed bug tracking .... we could all work offline, online and as a big crazy hive. yee-haw!
so, thanks to Esteban for all his work to date; and to Esteban: i hope you find yourself with an unqualified success on your hands that takes off to everyone's benefit =)
i keep running into people who have patched kde for this or that and for one reason or other haven't submitted the patches upstream. often it's a matter of trying to figure out how to deal with each project they patch, and between the projects we tend to be a bit different. there's also an effort related problem, namely that people tend to take the path of least resistance and while they will often upload patches to their own web server that's about as far as their ambitions will take them.
i blogged about it and got a few responses, including from one
Esteban Manchado Velázquez. he said he had started a small patch server web site using ruby on rails. we discussed some possibilities and he started working on it in earnest.
you can some of the results on the patchserver screenshot page.
even better yet, you can install it on your own server and start cataloging your patches. Esteban uses the darcs rcs, so utter this command to grab a copy:
darcs get http://www.demiurgo.org/darcs/patch_server/
what all does patchserver do? well, you upload patches and then you can view and edit metadata, such as which upstream version they apply against, related patches, descriptions, etc., view the patches on-line with syntax highlighting, view the history, view patches by various parameters such as for a given app or which ones aren't applied upstream yet, subscribe to rss feeds, full text searches and more.
future ideas involve integration with other development tools such as revision control and bug tracking systems, being able to reference patches in other patchserver installations, etc...
my big hope is that enough people will start making their patches available in this manner and then we can get one of the big open source friendly search providers, such as yahoo or google, to provide a search that is customized for patchserver content.
my dream is to one day be able to type into a search box "patches plasma 4.1" and have a list of links to patches with nice descriptions come up from servers around the world.
and yes, i completely agree that it would be best if people would work with the upstreams directly. i also realize the reality is that isn't likely to happen. i also agree that it would be totally cool if people had access to tools like canonical's launchpad, but they aren't releasing the source code it seems so that's that. (i don't fault canonical for that, it's their work and therefore their decision to do with it as they see fit.)
if enough of a community builds up around patchserver perhaps we can start working on another pet idea: a distributed bug system. ooh yeah. distributed patches, distributed revision control, distributed bug tracking .... we could all work offline, online and as a big crazy hive. yee-haw!
so, thanks to Esteban for all his work to date; and to Esteban: i hope you find yourself with an unqualified success on your hands that takes off to everyone's benefit =)
pantheon
i'm heading out to a christmas party with t. this evening, but before that andy came over and we put some content on the pantheon website.
what is pantheon? it's a website "content management system" that we started several years ago for our own use both personally and with clients. we've both been very busy with other things this last year or so and decided over a beer one day that what would make the most sense is to package it up and release it under the gpl. we did all the hard work in time for this year's akademy so i could show it to some of the people interested in such things there. today, we put the bow on the web site so we can start talking about it with people in general. the server is currently on a fairly limited bandwidth connection, but will do the trick for now. =)
now, it's not the cms for everyone and we know that. there's a fairly specific set of use cases that we had in mind. primarily our own. it's not for bloggers (who seem to have co-opted the term "cms" for their own?), but for people actually creating websites that need to be highly dynamic, robust and easy to use or some combination thereof.
it was designed to be easily administrated (you can have multiple websites running off of one installation; setting up new sites is a matter of running a scripte on the host; you can change settings via the web based administration interface), used by people who may not be the most technical and to create highly dynamic sites.
the core concept is what we refer to as "p.o.r.t.s.": pages (what people see on the website), objects (dynamic sections that you can place anywhere on any page), roles (which define sets of css styles and templates), templates (what wraps page content) and styles (standard css). objects are simple php classes that can be written rather quickly and used either globally on a server or on just one specific website.
there's even some documentation. (thanks t.! =)
it's still a work in progress (when is software ever done, really?) but we have a publicly available svn, mailing lists and a website. what more do we need? ok, a bug tracker and a wiki for the documentation. and more objects that ship with the default installation. and some of the features listed in the TODO. and some more styles and templates. and maybe a cool logo. and ... well, you get the picture.
for now we're just pretty happy to finally get this puppy out the door.
andy will be guiding the community that hopefully builds up around the project. we hope that those who find themselves similarly under-serviced by the cms projects out there today can find a nice home with pantheon.
enjoy =)
what is pantheon? it's a website "content management system" that we started several years ago for our own use both personally and with clients. we've both been very busy with other things this last year or so and decided over a beer one day that what would make the most sense is to package it up and release it under the gpl. we did all the hard work in time for this year's akademy so i could show it to some of the people interested in such things there. today, we put the bow on the web site so we can start talking about it with people in general. the server is currently on a fairly limited bandwidth connection, but will do the trick for now. =)
now, it's not the cms for everyone and we know that. there's a fairly specific set of use cases that we had in mind. primarily our own. it's not for bloggers (who seem to have co-opted the term "cms" for their own?), but for people actually creating websites that need to be highly dynamic, robust and easy to use or some combination thereof.
it was designed to be easily administrated (you can have multiple websites running off of one installation; setting up new sites is a matter of running a scripte on the host; you can change settings via the web based administration interface), used by people who may not be the most technical and to create highly dynamic sites.
the core concept is what we refer to as "p.o.r.t.s.": pages (what people see on the website), objects (dynamic sections that you can place anywhere on any page), roles (which define sets of css styles and templates), templates (what wraps page content) and styles (standard css). objects are simple php classes that can be written rather quickly and used either globally on a server or on just one specific website.
there's even some documentation. (thanks t.! =)
it's still a work in progress (when is software ever done, really?) but we have a publicly available svn, mailing lists and a website. what more do we need? ok, a bug tracker and a wiki for the documentation. and more objects that ship with the default installation. and some of the features listed in the TODO. and some more styles and templates. and maybe a cool logo. and ... well, you get the picture.
for now we're just pretty happy to finally get this puppy out the door.
andy will be guiding the community that hopefully builds up around the project. we hope that those who find themselves similarly under-serviced by the cms projects out there today can find a nice home with pantheon.
enjoy =)
Friday, December 15, 2006
7th umeet
i did a presentation for the 7th umeet conference. best part was that i didn't have to change out of my jammies to do it since it's an online conference held on irc. no travel time, no huge impositions on my schedule ... perfect! =) i "spoke" about kde4, generally working off my kde4 presentation slides.
they have a really nice line up of speakers from all over the world this year. rik van riel opened things up on tuesday, duncan mac-vicar will be speaking on sunday about kopete and rms will be speaking tuesday. the presentations are interactive: you can ask questions in the questions channel and the speaker answers them at their leisure and discretion. they post irc logs and slides (if any) on the site so you can read them whenever.
i look forward to next year's umeet when i can talk about the upcoming kde 4.1 ;)
they have a really nice line up of speakers from all over the world this year. rik van riel opened things up on tuesday, duncan mac-vicar will be speaking on sunday about kopete and rms will be speaking tuesday. the presentations are interactive: you can ask questions in the questions channel and the speaker answers them at their leisure and discretion. they post irc logs and slides (if any) on the site so you can read them whenever.
i look forward to next year's umeet when i can talk about the upcoming kde 4.1 ;)
Thursday, December 14, 2006
developer wiki fridays
monday is my day for kdelibs adjustments, and now friday has become my day to help with the new kde developer wiki. sort of like bookends to my week. i'll be doing developer wiki fridays until at least the end of january. maybe longer, but we'll see.
what is this developer wiki i speak of? it's the replacement for the somewhat haphazzard developer.kde.org. the new approach is to use a wiki so everyone can participate. it's looking pretty good so far, as you can see for yourself.
however, there are challenges ahead.
right now you can find developer documentation scattered across the internet on various servers. for instance, there's some really great content on the kde women tutorials page, there's some articles on ibm's developerworks site, while an article on how to get started with the ruby bindings is hidden under the ever descriptive "bindings" entry on the sidebar on developer.kde.org. there's also a large number of tutorials hosted on people's personal webservers.
sweeping all these altogether is no mean feat. perhaps we shouldn't even bother doing this with older content, due to the time it would take and dealing with other people's links and bookmarks to the content. it's a lot of work.
at the very least we need to make the wiki the natural and first choice of authors of future works.
i spent some time today sorting out kde2, kde3 and kde4 appropriate tutorials on to different pages. right now the idea is to make kde4 the primary focus of the site while keeping the older materials around for reference but in their own area of the site. unfortunately, there's very very little high-level documentation for kde4. sure, we've got the usual great API documentation but that's not a good way for people to learn how to actually write kde applications. that's what tutorials are for.
there are numerous technologies that kde4 is inheriting from kde3. if you look at the page of kde3 tutorials and compare them with the kde4 tutorials you'll notice that there's a lot less content. and even the kde3 tutorial are hardly comprehensive. many of the kde3 tutorials simply need to be gone through and "ported" to kde4. some, such as the xmlgui tutorial, probably aren't worth spending energy on right now as liveui looks like it will take its place now that people are working on it again.
we also have lots of cool new technologies in kde4. several of them are already usable by application developers, such as solid and phonon. we need to get tutorials for these technologies, starting with the basic concepts (e.g. a survey of the classes in solid) with other tutorials covering more advanced or specific topics (e.g. "embedding videos with phonon")
of course, there's also the holes that exist in our current tutorials. for example, we have a good tutorial on kconfigxt, but nothing on using kconfig itself.
we need to start writing these texts. they don't have to be long or overly complicated. even a single page article helps, sometimes a lot.
of course, it's not all about documentation. there's an area for ISVs, for instance, that's mostly content-free at the moment and what is there is already a bit dated. i think there's work here for the kde promo team.
wouldn't it be nice if we couldn't list all the tutorials on the main tutorial page but had to break them up into separate pages because there were so many? wouldn't it be nice if our high level documentation covered enough of kde that people could use that material to create lesson plans around it and teach kde development in classrooms? =) we can do it!
our developer documentation is an important pathway to getting new developers and supporting those that we have today.
if you'd like to join me on fridays working on this, hunt me down on irc so we can coordinate a bit and keep each other company. if you'd like to start writing content or porting older tutorials, please don't wait for friday ... start whenever you can =)
the new wiki was not my idea or the results of my efforts. daniel molkentin and dominik haumann have been pushing this forward with sys admin tasks being performed by dirk mueller and artwork coming from nuno pinheiro and luke parry. there are probably others who have dipped their fingers into the wiki sauce as well. they all deserve a big "thank you!" for getting this started. they also deserve our help in making this the success we all would like it to be.
p.s. a sysadmin.kde.org site with a similar approach that started with the content from the kde.org sysadmin area would be nice, too.
what is this developer wiki i speak of? it's the replacement for the somewhat haphazzard developer.kde.org. the new approach is to use a wiki so everyone can participate. it's looking pretty good so far, as you can see for yourself.
however, there are challenges ahead.
centralizing our content
right now you can find developer documentation scattered across the internet on various servers. for instance, there's some really great content on the kde women tutorials page, there's some articles on ibm's developerworks site, while an article on how to get started with the ruby bindings is hidden under the ever descriptive "bindings" entry on the sidebar on developer.kde.org. there's also a large number of tutorials hosted on people's personal webservers.
sweeping all these altogether is no mean feat. perhaps we shouldn't even bother doing this with older content, due to the time it would take and dealing with other people's links and bookmarks to the content. it's a lot of work.
at the very least we need to make the wiki the natural and first choice of authors of future works.
porting old documentation
i spent some time today sorting out kde2, kde3 and kde4 appropriate tutorials on to different pages. right now the idea is to make kde4 the primary focus of the site while keeping the older materials around for reference but in their own area of the site. unfortunately, there's very very little high-level documentation for kde4. sure, we've got the usual great API documentation but that's not a good way for people to learn how to actually write kde applications. that's what tutorials are for.
there are numerous technologies that kde4 is inheriting from kde3. if you look at the page of kde3 tutorials and compare them with the kde4 tutorials you'll notice that there's a lot less content. and even the kde3 tutorial are hardly comprehensive. many of the kde3 tutorials simply need to be gone through and "ported" to kde4. some, such as the xmlgui tutorial, probably aren't worth spending energy on right now as liveui looks like it will take its place now that people are working on it again.
kde4 documentation
we also have lots of cool new technologies in kde4. several of them are already usable by application developers, such as solid and phonon. we need to get tutorials for these technologies, starting with the basic concepts (e.g. a survey of the classes in solid) with other tutorials covering more advanced or specific topics (e.g. "embedding videos with phonon")
of course, there's also the holes that exist in our current tutorials. for example, we have a good tutorial on kconfigxt, but nothing on using kconfig itself.
we need to start writing these texts. they don't have to be long or overly complicated. even a single page article helps, sometimes a lot.
other useful bits
of course, it's not all about documentation. there's an area for ISVs, for instance, that's mostly content-free at the moment and what is there is already a bit dated. i think there's work here for the kde promo team.
developer wiki fridays
wouldn't it be nice if we couldn't list all the tutorials on the main tutorial page but had to break them up into separate pages because there were so many? wouldn't it be nice if our high level documentation covered enough of kde that people could use that material to create lesson plans around it and teach kde development in classrooms? =) we can do it!
our developer documentation is an important pathway to getting new developers and supporting those that we have today.
if you'd like to join me on fridays working on this, hunt me down on irc so we can coordinate a bit and keep each other company. if you'd like to start writing content or porting older tutorials, please don't wait for friday ... start whenever you can =)
credit where credit is due
the new wiki was not my idea or the results of my efforts. daniel molkentin and dominik haumann have been pushing this forward with sys admin tasks being performed by dirk mueller and artwork coming from nuno pinheiro and luke parry. there are probably others who have dipped their fingers into the wiki sauce as well. they all deserve a big "thank you!" for getting this started. they also deserve our help in making this the success we all would like it to be.
p.s. a sysadmin.kde.org site with a similar approach that started with the content from the kde.org sysadmin area would be nice, too.
run command dialog
the "run command" dialog is a venerable part of kde and it has a number of cool tricks up its sleeve, like allowing you to run a process as another user or answering math problems.
of course, it's part of kdesktop but i want to turf kdesktop and replace it with plasma. this means i need to do something with that run command dialog. what i've decided to do is create a separate app whose primary purpose is to handle that dialog. this should help ensure it doesn't crash (smaller code base == easier to get it right) and may even allow us to do neat things like run it with a higher priority so the user has a better chance of getting it to come up if some other process starts going crazy.
i suppose i could have ripped the run command dialog widget out of kdesktop and just wrapped it up with a kapplication and been done with it, but i'm not really too happy with how the current one looks and acts. so i started writing a new one yesterday. unfortunately i had to deal with one unexpected task after another yesterday which left me with only a couple hours of coding time so i only got so far.
right now it loads up an svg image for its background, uses an argb window if you have a composition manager running for extra bling and accepts input via a line edit at the top. as the user types, the input is passed by a chain of "runners" one by one until one claims that it can handle it. the self-selected runner then populates the possibilities that match and the user can select from that. there's a little "options" label at the bottom which activates when the given runner advertises the ability to set additional options.
i need to write a cute little animation where the options "slide out" in a little drawer-like-thing. it's all about the organics =) this too will be themeable with an svg image so one can make it as obtrusive or non-obtrusive as desired. right now i'm keeping all the images in share/apps/plasma/desktoptheme/default. the goal with that is to create one place where these image files can go so people can create alternative themes (nice for accessibility?) and so other apps can use standard imagery using the Plasma::Theme class.
i also need to make the runners pluggable so that packagers can, for instance, select what search system they wish to use (e.g. strigi or beagle) and supply the runner plugin for that search. other apps could also supply their own plugins i suppose as well. i'm half (but only half) thinking of playing with kross a bit for this as well.
anyways, not counting the new class in libplasma (which actually builds now on my machine ;) it's a little under 400 lines of code at the moment but will probably triple that once it's done. and then i can scratch one more thing off the plasma todo list.
i'll post screenshots when it's a little less clumsy lookin'
of course, it's part of kdesktop but i want to turf kdesktop and replace it with plasma. this means i need to do something with that run command dialog. what i've decided to do is create a separate app whose primary purpose is to handle that dialog. this should help ensure it doesn't crash (smaller code base == easier to get it right) and may even allow us to do neat things like run it with a higher priority so the user has a better chance of getting it to come up if some other process starts going crazy.
i suppose i could have ripped the run command dialog widget out of kdesktop and just wrapped it up with a kapplication and been done with it, but i'm not really too happy with how the current one looks and acts. so i started writing a new one yesterday. unfortunately i had to deal with one unexpected task after another yesterday which left me with only a couple hours of coding time so i only got so far.
right now it loads up an svg image for its background, uses an argb window if you have a composition manager running for extra bling and accepts input via a line edit at the top. as the user types, the input is passed by a chain of "runners" one by one until one claims that it can handle it. the self-selected runner then populates the possibilities that match and the user can select from that. there's a little "options" label at the bottom which activates when the given runner advertises the ability to set additional options.
i need to write a cute little animation where the options "slide out" in a little drawer-like-thing. it's all about the organics =) this too will be themeable with an svg image so one can make it as obtrusive or non-obtrusive as desired. right now i'm keeping all the images in share/apps/plasma/desktoptheme/default. the goal with that is to create one place where these image files can go so people can create alternative themes (nice for accessibility?) and so other apps can use standard imagery using the Plasma::Theme class.
i also need to make the runners pluggable so that packagers can, for instance, select what search system they wish to use (e.g. strigi or beagle) and supply the runner plugin for that search. other apps could also supply their own plugins i suppose as well. i'm half (but only half) thinking of playing with kross a bit for this as well.
anyways, not counting the new class in libplasma (which actually builds now on my machine ;) it's a little under 400 lines of code at the moment but will probably triple that once it's done. and then i can scratch one more thing off the plasma todo list.
i'll post screenshots when it's a little less clumsy lookin'
Tuesday, December 12, 2006
calgary unix users group
this evening at 17:30 i'll be speaking at the calgary unix users group on the topic of "open source desktop software directions". come on out and join the party if you can, it'll be good. the presentation is at the public library downtown (check the cuug site for more info) and i'm sure we'll be visting bottlescrew bill's afterwards. there's a bit of an entry fee to get in, but that's used to bring food and drinks in for everyone and generally support cuug.
i'll be trying out some new material that casts some analysis on the foss desktop community, market and industry before launching into a "status of the kde4" review. so it should be interesting.
i wonder if the novell guy who visited the calgary linux users group last week will be there. probably not, but it would be fun and probably fair play. he presented on novell's new deal with microsoft and attempted to completely by-pass the whole patent agreement issue by not even mentioning it in the presentation, despite that being one of the two major issues people have with the deal. the other issue (openxml) also got short shrift. fortunately i was there. ;) if he does come to cuug tonight he could play critic to my thoughts on the state of our collective efforts. while i won't be talking about the novell/ms deal at all i'm sure there are several points of interest in the presentation for him.
and once i'm done the new slides (finishing them up now) i think i'm going to toddle over to kde4 dolphin for a bit. =)
i'll be trying out some new material that casts some analysis on the foss desktop community, market and industry before launching into a "status of the kde4" review. so it should be interesting.
i wonder if the novell guy who visited the calgary linux users group last week will be there. probably not, but it would be fun and probably fair play. he presented on novell's new deal with microsoft and attempted to completely by-pass the whole patent agreement issue by not even mentioning it in the presentation, despite that being one of the two major issues people have with the deal. the other issue (openxml) also got short shrift. fortunately i was there. ;) if he does come to cuug tonight he could play critic to my thoughts on the state of our collective efforts. while i won't be talking about the novell/ms deal at all i'm sure there are several points of interest in the presentation for him.
and once i'm done the new slides (finishing them up now) i think i'm going to toddle over to kde4 dolphin for a bit. =)
monday is libs day
monday is the day when we're allowed to muck with kdelibs in ways that makes people recompile. the last couple mondays i've been taking advantage of that in an attempt to bring some order to kdelibs. we started this in norway at the kde4core meeting, but then we got back to the usual order of "hack on this" and "hack on that". or in my case "travel here", "deal with business X", "write N emails", "hack on this", "travel there", etc... well, the work needs to be done and monday's the day to do it.
david faure has also been busy on with the monday commits as he works on the kdecore/kdeui split such that kdecore will one day link only against non-UI libraries. this means, just as with libqtcore, you can use these classes from non-graphical apps. who needs x11 anyways ;)
anyways, if you're looking for me on irc on mondays for the next while don't expect me to be overly responsive. i'm around, but probably busy with moving things around in kdelibs.
i did move KActiveLabel into kde3support (the library full of deprecated stuff we'll one day get rid of completely but are keeping around to make life easier for people porting apps). what to do with your code that was using KActiveLabel, you ask? let me quote from the kde4 porting guide:
tomorrow it's on to other things. my todo list is huge right now, but i figure if i eat it one bite at a time the elephant will eventually be consumed.
i'm very happy with what is happening with kde promo right now and have stepped back from having too much to do with it for the time being. i'm also stepping back from visits to airports for the next several months as well. this should give me the room i need. not that i'll be staying still: i've already started a number of balls rolling, but this time almost exclusively on the development front. will be interesting to see where they all land.
so the next few months will consist of quiet days at home with the computer, cats and coffee. who needs anything more? well, besides food, love and water of course. ;)
david faure has also been busy on with the monday commits as he works on the kdecore/kdeui split such that kdecore will one day link only against non-UI libraries. this means, just as with libqtcore, you can use these classes from non-graphical apps. who needs x11 anyways ;)
anyways, if you're looking for me on irc on mondays for the next while don't expect me to be overly responsive. i'm around, but probably busy with moving things around in kdelibs.
i did move KActiveLabel into kde3support (the library full of deprecated stuff we'll one day get rid of completely but are keeping around to make life easier for people porting apps). what to do with your code that was using KActiveLabel, you ask? let me quote from the kde4 porting guide:
"Use QLabel instead. This class was moved to kde3support as K3ActiveLabel."
- QLabel::setOpenExternalLinks(true) for labels with hyperlinks.
- QLabel::setTextInteractionFlags(Qt::TextSelectableByMouse|Qt::TextSelectableByKeyboard) for labels whose text should be selectable by user.
tomorrow it's on to other things. my todo list is huge right now, but i figure if i eat it one bite at a time the elephant will eventually be consumed.
i'm very happy with what is happening with kde promo right now and have stepped back from having too much to do with it for the time being. i'm also stepping back from visits to airports for the next several months as well. this should give me the room i need. not that i'll be staying still: i've already started a number of balls rolling, but this time almost exclusively on the development front. will be interesting to see where they all land.
so the next few months will consist of quiet days at home with the computer, cats and coffee. who needs anything more? well, besides food, love and water of course. ;)
Wednesday, December 06, 2006
kde for teachers
with so much emphasis on getting linux to children, particularly students, one might think there would be nearly as many (maybe more) efforts to get free(dom) software to teachers. they are an important group of people because they teach our children, often with far too few resources given them to accomplish this task. even in the "first world" this is often the case: the school p. goes to has had to fall back on corporate sponsorship deals and still teachers dip into personal funds for classroom supplies. perhaps as poignantly: if we don't have tools of freedom in our institutions of learning how can we ever expect those learning there to understand the benefits and principles of freedom?
it was refreshing to speak with K.K. Subbu while in bangalore, india as he recounted one story of bringing free software to teachers. his opinion, shared by many in the area apparently, is that for students in the rural schools computers just aren't the best teaching device. they are great tools for the teachers, but nothing can replace the teacher themselves in their classrooms. so the NGO Subbu is volunteering in has instead been looking at how to make teachers more efficient and naturally they are looking to free software to help them accomplish this.
it started when a retired professor walked into a Kanakapura elementary school and told them he'd like to help out however he could. one of the challenges he (and later his group of volunteers) uncovered was the teacher's efforts to meet the requirement for students to be assessed three times per year. unlike the annual standardized test, these assessments were to be specific to the school as different schools progress at different rates making standardized testing not realistic. ("no child left behind" might learn something from that statement...)
now, creating tests are part of what a teacher does all the time. but these were particularly inconvenient. they needed to created tests for 4-5 subjects and had to do them on a computer. most used, or rather struggled with, microsoft word to lay out the tests and then they would need to get a master printed out. this would cost them around 40 rupees per test (20 rupees per page, and a two page test). they were rarely happy with the results given word's limited layout capabilities but it was all most had access to and knowledge of. some of the teachers would instead purchase a master from a regional school board and save 50-75%, though the test would no longer be customized to their class. either way, the process meant travel time and would take about a week from start to finish. with the master copy in hand, the teacher would then have to make copies which would cost a rupee or two per test copy.
enter kde and kile.
the volunteers started training teachers to use kile and gave them computers with a locked-down kde on it. the flexibility and completeness of kiosk was a primary reason for using kde and kile was simply perfect for their layouting needs. now these same teachers can simply write their test content and it's professionally laid out, turned into a print-ready pdf which they send to a digital printer. using the dvi format they can actually measure items on the screen with a ruler to make sure things are just right removing the need for a master print. the total cost is now less than half a rupee per test with no master copy cost. they are also able to make up to two tests per day.
who can argue with lower costs and saved time? not these teachers. and so now this group has adopted 50 schools with some 200 teachers. they have only just begun as the state they are in has some 48,000 elementary schools that provide classes for over 8,000,000 students. just imagine the potential savings in both time and money!
and of course the teachers who are using these kde systems have been poking around the computer and finding some of the other great pieces of software that came with the systems.
you can read more about this project at the sikshana blog. which reminds me, i promised Subbu i'd introduce him and the kile developers since they have some feedback for them, not to mention a few notes of thanks. =)
it was refreshing to speak with K.K. Subbu while in bangalore, india as he recounted one story of bringing free software to teachers. his opinion, shared by many in the area apparently, is that for students in the rural schools computers just aren't the best teaching device. they are great tools for the teachers, but nothing can replace the teacher themselves in their classrooms. so the NGO Subbu is volunteering in has instead been looking at how to make teachers more efficient and naturally they are looking to free software to help them accomplish this.
it started when a retired professor walked into a Kanakapura elementary school and told them he'd like to help out however he could. one of the challenges he (and later his group of volunteers) uncovered was the teacher's efforts to meet the requirement for students to be assessed three times per year. unlike the annual standardized test, these assessments were to be specific to the school as different schools progress at different rates making standardized testing not realistic. ("no child left behind" might learn something from that statement...)
now, creating tests are part of what a teacher does all the time. but these were particularly inconvenient. they needed to created tests for 4-5 subjects and had to do them on a computer. most used, or rather struggled with, microsoft word to lay out the tests and then they would need to get a master printed out. this would cost them around 40 rupees per test (20 rupees per page, and a two page test). they were rarely happy with the results given word's limited layout capabilities but it was all most had access to and knowledge of. some of the teachers would instead purchase a master from a regional school board and save 50-75%, though the test would no longer be customized to their class. either way, the process meant travel time and would take about a week from start to finish. with the master copy in hand, the teacher would then have to make copies which would cost a rupee or two per test copy.
enter kde and kile.
the volunteers started training teachers to use kile and gave them computers with a locked-down kde on it. the flexibility and completeness of kiosk was a primary reason for using kde and kile was simply perfect for their layouting needs. now these same teachers can simply write their test content and it's professionally laid out, turned into a print-ready pdf which they send to a digital printer. using the dvi format they can actually measure items on the screen with a ruler to make sure things are just right removing the need for a master print. the total cost is now less than half a rupee per test with no master copy cost. they are also able to make up to two tests per day.
who can argue with lower costs and saved time? not these teachers. and so now this group has adopted 50 schools with some 200 teachers. they have only just begun as the state they are in has some 48,000 elementary schools that provide classes for over 8,000,000 students. just imagine the potential savings in both time and money!
and of course the teachers who are using these kde systems have been poking around the computer and finding some of the other great pieces of software that came with the systems.
you can read more about this project at the sikshana blog. which reminds me, i promised Subbu i'd introduce him and the kile developers since they have some feedback for them, not to mention a few notes of thanks. =)
multiple actions in toolbars, take 2
one of the bits of feedback i got fro my last blog entry on kmultiactionbutton is that it might be possible to do this via the style itself. this would be preferred since it would mean every app could take advantage of it with less special code. the baghira style for kde3 does this, for instance, but it does so with some pain and some hacks. in fact, there is this cute comment in the sources at the relevant point:
dude, i feel your pain.
looking at qt4, we obviously don't have support for conjoined buttons. or ... do we? enter QActionGroup! according to the documentation:
exclusivity is optional in an actiongroup, and so this gives us what looks like a nice generic way to denote "these actions belong together". with a bit of trickery in the style, more reliable than what baghira was able to accomplish with qt3, we should be able to detect buttons on a toolbar that are next to each other and belong to the same action group.
the application code might look like:
sadly for the style code, the QStyleOptionToolButton class doesn't note which action group (if any) an action belongs to and so we'd need to do a bunch of casting and parent/child traversing. even if it did contain some info on the action pointer, it would only work for toolbuttons (as opposed to any/all widgets) and the style would still need to know what the previous and next button's groups are (meaning wandering the parent/child tree a bit). and yes, we'd probably only check widget.actions().first() but that's an ok limitation.
so, moral of the story is that perhaps we should start using QActionGroup, even when it's only used for semantic purposes. this might be something the liveui guys want to consider if they haven't as well since this ought to be part of our toolbar building technology (yes, i'm looking at you tronical and ervin ;)
this is crap at all - so if the best thing would be to patch qtoolbutton to provide conjuncted buttons - i'll ask them (maybe qt4)
dude, i feel your pain.
looking at qt4, we obviously don't have support for conjoined buttons. or ... do we? enter QActionGroup! according to the documentation:
In some situations it is useful to group actions together. For example, if you have a Left Align action, a Right Align action, a Justify action, and a Center action, only one of these actions should be active at any one time. One simple way of achieving this is to group the actions together in an action group.
exclusivity is optional in an actiongroup, and so this gives us what looks like a nice generic way to denote "these actions belong together". with a bit of trickery in the style, more reliable than what baghira was able to accomplish with qt3, we should be able to detect buttons on a toolbar that are next to each other and belong to the same action group.
the application code might look like:
QActionGroup* group = new QActionGroup(this);
new QAction(i18n("Some Action"), group);
new QAction(i18n("Another Action"), group);
toolbar->insertActions(group->actions());sadly for the style code, the QStyleOptionToolButton class doesn't note which action group (if any) an action belongs to and so we'd need to do a bunch of casting and parent/child traversing. even if it did contain some info on the action pointer, it would only work for toolbuttons (as opposed to any/all widgets) and the style would still need to know what the previous and next button's groups are (meaning wandering the parent/child tree a bit). and yes, we'd probably only check widget.actions().first() but that's an ok limitation.
so, moral of the story is that perhaps we should start using QActionGroup, even when it's only used for semantic purposes. this might be something the liveui guys want to consider if they haven't as well since this ought to be part of our toolbar building technology (yes, i'm looking at you tronical and ervin ;)
Tuesday, December 05, 2006
KMultiActionButton
inspired by the "grouped actions" toolbar widgets in vista and macos i figured i'd try my hand at doing something similar with qt4. the results are currently less than inspiring visually:
the neat thing is that it mimics the api for qtoolbar so you can simply sling actions at it and they show up grouped:
i still have to implement things like showing menus for actions that have them and respecting action groups (not to mentioned seriously working on the currently crapitudinal eye candy), but i'm interested in feedback from other developers before i spend to much time on it. if you have a Qt4 or KDE4 app (there are currently no KDE dependencies in the class) and would like something like this in your app, please let me know as i'm looking for some guinea pigs, er, test cases before attempting to inflict this upon libkdeui ;)
p.s. no, i'm not trying to replace devel mailing lists with blogs: i've also sent an email off to kde-core-devel, but not all app devels read that.
the neat thing is that it mimics the api for qtoolbar so you can simply sling actions at it and they show up grouped:
KMultiActionButton* button = new KMultiActionButton(window);
button->addAction( icon1, i18n("Quit"), qApp, SLOT( quit() ));
QAction* action = button->addAction( icon2, "action 2", );
connect(action, SIGNAL(triggered(bool)), this, SLOT(someSlot()));
button->addAction( KStdAction::close( mainWindow, SLOT( close() ), actionCollection() ) );
toolbar->addWidget(button);
i still have to implement things like showing menus for actions that have them and respecting action groups (not to mentioned seriously working on the currently crapitudinal eye candy), but i'm interested in feedback from other developers before i spend to much time on it. if you have a Qt4 or KDE4 app (there are currently no KDE dependencies in the class) and would like something like this in your app, please let me know as i'm looking for some guinea pigs, er, test cases before attempting to inflict this upon libkdeui ;)
p.s. no, i'm not trying to replace devel mailing lists with blogs: i've also sent an email off to kde-core-devel, but not all app devels read that.
without effort
it is said that when one is able to perform a task without effort that you have truly mastered that task. by that measure i've mastered exceedingly little thus far in my life.
while bloggin about cyrille's water color work in krita, boudj mentioned that all this work was for something "that nature does without any effort". it's easy to forget that nature is a highly parallel computation machine consisting of some 10 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 or so atoms and even more sub-atomic particles and what not. it accomplishes these amazing and "simple" feats, like forming what are often emotional textures as water colour paint dries on a piece of rough paper, through the tremendous effort of mind boggling numbers of interactions. it only appears to happen without effort. the universe, unlike myself, has mastered much.
that said, krita is doing some amazing things these days (e.g. water colour simulation). and now that they've started in on the optimizations, i can only imagine what we'll end up with in koffice2. something, probably, that appears to work with little effort at all.
on the topic of mind boggling interaction, sebas put out a call for journalists to write for kde, particularly theDot and the response was nearly immediate on kde-promo. i count five responses already and i'm sure even more are on the way.
there are times when it feels like there is a tremendous amount of weight levied upon the shoulders of those involved in open source projects. granted, it's mostly self-inflicted, but we tend to feel that there is so much we want (or even "need") to do compared to the time and energy we individually have. and then someone simply asks for some help and it turns out that there are people just waiting for a bar to be laid low enough and directions made clear enough for them to join in. these are people who have often benefited from our work in the past and that becomes their motivation.
so a huge hug to sebas for asking and one for each person who has stepped up. you all help make it look like it happens without effort, even though we know it takes more than a little.
you know, there should be a free software contributor appreciation day. =)
while bloggin about cyrille's water color work in krita, boudj mentioned that all this work was for something "that nature does without any effort". it's easy to forget that nature is a highly parallel computation machine consisting of some 10 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 or so atoms and even more sub-atomic particles and what not. it accomplishes these amazing and "simple" feats, like forming what are often emotional textures as water colour paint dries on a piece of rough paper, through the tremendous effort of mind boggling numbers of interactions. it only appears to happen without effort. the universe, unlike myself, has mastered much.
that said, krita is doing some amazing things these days (e.g. water colour simulation). and now that they've started in on the optimizations, i can only imagine what we'll end up with in koffice2. something, probably, that appears to work with little effort at all.
on the topic of mind boggling interaction, sebas put out a call for journalists to write for kde, particularly theDot and the response was nearly immediate on kde-promo. i count five responses already and i'm sure even more are on the way.
there are times when it feels like there is a tremendous amount of weight levied upon the shoulders of those involved in open source projects. granted, it's mostly self-inflicted, but we tend to feel that there is so much we want (or even "need") to do compared to the time and energy we individually have. and then someone simply asks for some help and it turns out that there are people just waiting for a bar to be laid low enough and directions made clear enough for them to join in. these are people who have often benefited from our work in the past and that becomes their motivation.
so a huge hug to sebas for asking and one for each person who has stepped up. you all help make it look like it happens without effort, even though we know it takes more than a little.
you know, there should be a free software contributor appreciation day. =)
Monday, December 04, 2006
vtkdesigner
while in india the other week i came across several local foss gems. one of them is vtk designer.
it is a graphical pipeline creator/editor for the visualization toolkit which is written by the folks over at kitware. yep, the same people who make cmake which we now use for our build system. it's a small world after all, isn't it? =)
apparently vtk is used for medical and scientific imaging by a good number of people. they are putting out a new edition of the official vtk book and it will be covering vtk designer. why do i care? two reasons (besides "it's cool!"): first, it's all free software; second, vtk designer (and it's helper tools) are written with Qt/KDE.
one of the primary developers, Prashanth Udupa, showed it to me at foss.in and i attended his presentation on it the next day. i subsequently downloaded it and have played around with it a bit. it's a very promising bit of software. so, what does it do?
well, it lets you explore the various vtk classes:
and then add them to a pipeline canvas where you can connect them up:
this in turn generates, in real time, the vtk output in another tab:
and c++ source code in yet another:
it also sports extensive built-in help, including both a documentation explorer as well as context sensitive popups on just about every property in the property editor pane.
but what if you have your own vtk classes that you would like to add to a pipeline in vtk designer? well, they've done something very smart and something i hope trolltech will do at some point for designer: a graphical app for creating vtk designer plugins. it too has extensive on-line help to guide you through the process of wrapping classes, defining pipeline connectors and datatypes as well as documenting settable properties.
there's certainly more work to be done on this very cool set of apps, but it's already quite usable and useful for those creating applications with vtk. Prashanth imported vtk designer into kde's svn today making it even easier to access. you can find it in trunk/playground/graphics/vtkdesigner. why kde's svn? it's a very cool app that, imho, deserves more attention and could benefit from being in the same repo that thousands of others use every day. personally i have a quiet vision, one passed to me by waldo bastian a couple years ago, of a kde extra gear universe that is ever more inclusive resulting in both intended and unintended benefits by bringing all this development energy together. or maybe i'm just crazy. (perhaps i'm also crazy? ;)
what's also interesting is that vtk designer is part of vcreatelogic's, Prashanth's company's, strategy. they are creating, supporting and giving away this free software toolkit as a way of advertising and showcasing their capabilities in this field. this is sort of the "loss-leader" business strategy and according to Prashanth it's already working out nicely for them. it helps demonstrate just how many different ways there are that one can incorporate free software into a business model.
it is a graphical pipeline creator/editor for the visualization toolkit which is written by the folks over at kitware. yep, the same people who make cmake which we now use for our build system. it's a small world after all, isn't it? =)
apparently vtk is used for medical and scientific imaging by a good number of people. they are putting out a new edition of the official vtk book and it will be covering vtk designer. why do i care? two reasons (besides "it's cool!"): first, it's all free software; second, vtk designer (and it's helper tools) are written with Qt/KDE.
one of the primary developers, Prashanth Udupa, showed it to me at foss.in and i attended his presentation on it the next day. i subsequently downloaded it and have played around with it a bit. it's a very promising bit of software. so, what does it do?
well, it lets you explore the various vtk classes:
and then add them to a pipeline canvas where you can connect them up:
this in turn generates, in real time, the vtk output in another tab:
and c++ source code in yet another:
it also sports extensive built-in help, including both a documentation explorer as well as context sensitive popups on just about every property in the property editor pane.
but what if you have your own vtk classes that you would like to add to a pipeline in vtk designer? well, they've done something very smart and something i hope trolltech will do at some point for designer: a graphical app for creating vtk designer plugins. it too has extensive on-line help to guide you through the process of wrapping classes, defining pipeline connectors and datatypes as well as documenting settable properties.
there's certainly more work to be done on this very cool set of apps, but it's already quite usable and useful for those creating applications with vtk. Prashanth imported vtk designer into kde's svn today making it even easier to access. you can find it in trunk/playground/graphics/vtkdesigner. why kde's svn? it's a very cool app that, imho, deserves more attention and could benefit from being in the same repo that thousands of others use every day. personally i have a quiet vision, one passed to me by waldo bastian a couple years ago, of a kde extra gear universe that is ever more inclusive resulting in both intended and unintended benefits by bringing all this development energy together. or maybe i'm just crazy. (perhaps i'm also crazy? ;)
what's also interesting is that vtk designer is part of vcreatelogic's, Prashanth's company's, strategy. they are creating, supporting and giving away this free software toolkit as a way of advertising and showcasing their capabilities in this field. this is sort of the "loss-leader" business strategy and according to Prashanth it's already working out nicely for them. it helps demonstrate just how many different ways there are that one can incorporate free software into a business model.
window captions
being home with internet on a monday for the first time in a month or so allowed me to check in some small changes to kdelibs. (monday is the "make people recompile everything" day in kdelibs ;) one of these small changes was to the facility to make standard window captions. in kde3 this was KApplication::makeStdCaption(QString, bool, bool) and now it is a static method in kinstance: KInstance::makeStandardCaption(QString, QWidget*, CaptionFlags).
the two non-descript bools are now a flag which defaults to HIGCompliantCaption, but can also include things like ModifiedCaption. the QWidget* is the dialog or window that this caption will be applied to. this should allow other platforms to decide when to tack on application names, etc. in compliance with the native interface guidelines. this particular bit was the result of a thread on kde-core-devel where it was suggested we alter (imho neuter) kde by removing app names from dialogs because every other platform does it. i suggested that we let those other platforms care for their own and do it their way (and now the API allows for that) while leaving us to make independent decisions for kde with the best interests of our users in mind.
personally, i'm wondering which (if any) of the new platform teams will step up and do the necessary work. to me it's a real test of the maturity and commitment, and one that will likely change (hopefully grow) over time.
that said, while making things compile again i noticed a number of "interesting" code snippets related to window captions. so here are some suggestions:
first off, always use KDialog and KMainWindow unless you have very good reasons not to. and no, thinking you might save a few bytes of memory by using QDialog instead is not a good reason. ;) the caption related reason here is that you can then just use setCaption(QString) and setCaption(QString, bool) to set the caption properly. internally, both call KInstance::makeStandardCaption with the correct flags. the version that takes a bool lets one reflect the modified state of the window in the title, so if your app has a document loaded that has been modified by the user (and therefore needs to be saved or have some other action taken on it prior to closing) you can just call setCaption(i18n("Some Caption"), true). yes, this probably should not be using a bool for api readability, but there it stands right now.
i see a lot of manual mucking about with CaptionFlags in the code base. most of it is unnecessary because setCaption should be called instead of directly calling KInstance::makeStandardCaption. i think at least some of this was caused by a fairly brute force scripted porting attempt, but it should be cleaned up now.
if you aren't using KDialog or KMainWindow then you'll need to call KInstance::makeStandardCaption yourself. be sure to pass a pointer to the window along with your caption string and all should be good.
the two non-descript bools are now a flag which defaults to HIGCompliantCaption, but can also include things like ModifiedCaption. the QWidget* is the dialog or window that this caption will be applied to. this should allow other platforms to decide when to tack on application names, etc. in compliance with the native interface guidelines. this particular bit was the result of a thread on kde-core-devel where it was suggested we alter (imho neuter) kde by removing app names from dialogs because every other platform does it. i suggested that we let those other platforms care for their own and do it their way (and now the API allows for that) while leaving us to make independent decisions for kde with the best interests of our users in mind.
personally, i'm wondering which (if any) of the new platform teams will step up and do the necessary work. to me it's a real test of the maturity and commitment, and one that will likely change (hopefully grow) over time.
that said, while making things compile again i noticed a number of "interesting" code snippets related to window captions. so here are some suggestions:
first off, always use KDialog and KMainWindow unless you have very good reasons not to. and no, thinking you might save a few bytes of memory by using QDialog instead is not a good reason. ;) the caption related reason here is that you can then just use setCaption(QString) and setCaption(QString, bool) to set the caption properly. internally, both call KInstance::makeStandardCaption with the correct flags. the version that takes a bool lets one reflect the modified state of the window in the title, so if your app has a document loaded that has been modified by the user (and therefore needs to be saved or have some other action taken on it prior to closing) you can just call setCaption(i18n("Some Caption"), true). yes, this probably should not be using a bool for api readability, but there it stands right now.
i see a lot of manual mucking about with CaptionFlags in the code base. most of it is unnecessary because setCaption should be called instead of directly calling KInstance::makeStandardCaption. i think at least some of this was caused by a fairly brute force scripted porting attempt, but it should be cleaned up now.
if you aren't using KDialog or KMainWindow then you'll need to call KInstance::makeStandardCaption yourself. be sure to pass a pointer to the window along with your caption string and all should be good.
change in plans
a couple weeks ago i showed the p-man how the games that come with kde are made. as he realized that they were something that pretty much anyone with the know-how and determination could make, his eyes widened and he informed me he was no longer going to be a police officer as was the previous plan even though that meant his friend at school was now going to have to find a new partner to drive in his police car with him. instead he decided he is going to grow up and make games. he even promised to send me them as he made them over the internet (because we'd be living in different houses by then, he informed me).
he made up a pretend laptop the other day out of some cardboard, complete with a fold-up screen and proper keyboard. he put a kde logo on the lid of it, wrote "i love kde" on it and informed me that he was going to "work for kde" when he grew up.
so perhaps there'll be another seigo in kde's about boxes for kde 5, this time in the kdegames package ;)
he made up a pretend laptop the other day out of some cardboard, complete with a fold-up screen and proper keyboard. he put a kde logo on the lid of it, wrote "i love kde" on it and informed me that he was going to "work for kde" when he grew up.
so perhaps there'll be another seigo in kde's about boxes for kde 5, this time in the kdegames package ;)
Sunday, December 03, 2006
merry x-mas amd
a few weeks ago i got a call from john terpstra (you might know him from his work with the samba project) who is currently working at amd. during the conversation he asked what i was using for a development desktop and i told him i was just using my laptop these days. so they sent out an amd athlon 64 system and it arrived yesterday making for an early christmas present.it's a fairly middle-of-the-road box (single core; 2Ghz; 1GB RAM; 120GB SATA drive; 256MB nvidia 5500) but will do quite nicely as a dev system. thanks amd! =)
first thing i did after chuckling my way through the windows xp oem set up app was to toss in a belenix live cd. belenix is an opensolaris based distribution that comes with xfce and kde. kde ran just fine, though their choice of desktop icons was a bit odd (evince, particularly when kpdf is also there?), and the addition of the binary nvidia driver by default was kind of neat to see the hardware in action. too bad there isn't a full featured open source driver for the card. i would never have bought this card myself due to that.
belenix did show that while kde certainly runs very nicely on solaris there are a number of things that haven't been adequately ported yet. this can be seen in places such as the info center and kpackage. while in india i talked to a few of the solaris guys there (who gave me the belenix cd i tried out) and they expressed interest in working on these things. i'm sure that would make all the kde-on-solaris users, of which there are quite a few, very happy.
the amd system is now running edgy and things seem to be humming along nicely. kde4 is building and i'll have to decide exactly how to split my time between my laptop (freedom) and the new desktop (liberty). i think i'll probably code on the desktop and use the laptop for communication. this should let me turn the desktop into a kde4 system and even devolve it into an unstable mess at will without choking. =)
Saturday, December 02, 2006
india: foss.in
bangalore is a beautiful city if you keep your eyes on the right bits of architecture, the trees and plants that grow wherever they aren't discouraged from doing so and the people going about their daily business. there's an obvious lack of infrastructure, which i'm told hasn't kept up with the growth the city has seen in the recent past, which leads to insane traffic (at least from a canadian's perspective) and poor air quality at times. but these were minor distractions as i jetted about the city in an autorickshaw, ate breakfast overlooking a tiny jungle in the hotel's courtyard and spent my days at the foss.in event.the foss.in event itself was really well put together. this year it was kept highly technical so the audience was correspondingly technical. they had both local talent presenting, such as ext4's Suparna Bhattacharya, as well as a good number of internationals. i opened the second day with a talk entitled "kde4 and you" which stirred up a lot of interest. you can download my slides in kpresenter format or as a pdf.
it's really nice to be able to present kde4 these days compared to, say, 6 months ago. i can actually start up apps and show them, for instance ;) there's also the work visible in phonon, solid, sonnet, akonadi, etc. we're slowly but surely clawing our way to this rather complex release.
as a side note, what we need now are application developers taking employing things like solid in their apps to be aware of events like network link droppage or phonon for simple multimedia support. these may end up being post-4.0 release features for some (many?) apps, but they need to happen to expose the power of these frameworks in a practical way to users (e.g. us ;) and app developers should start thinking about them sooner rather than later.
my next presentation on kde4 app devel played to a standing-room only audience. one can't ask for much more than that. taj's presentation on qgraphicsview and prashanth's demo of vtk designer (more on that in a later blog!) were both excellent must-attends as well.the kde india meeting (seen in the pictures to the
qapp->reverseLayout() ? left : right) was extremely productive as well. attended by about 20 people in an outdoor tent, we sat around in a circle discussing the allure of and barriers to kde development.one outcome is the start of a project by a handful of people to create a set of step-by-step tutorials, much like the ones Qt has, for kde app development. this will be both a great way for them to learn as well as to provide very useful and badly needed high level development documentation for the project. as an added twist, it seems they will be using python for this. the future is now. ;)
this project came out of the discussion of barriers the attendees faced which included according to them: learning curves, lack of community to motivate them (aka "poke them with a stick"), documentation, making desktop devel more exciting and cool, c++ and access to the source code.
the latter (source code access) is an interesting example of a regional issue. many have very limited internet access though they have modern computing facilities otherwise. for them, being able to get regular drops of source code on physical media (e.g. a dvd) would make a huge difference to them being able to be more involved. not everywhere has broadband and so we face distribution issues in these areas.
but the biggest blocker seemed to be the local community, or lack thereof. there are so many people with development skills who are putting them to good use, even creating open source software. but they don't know about each other often and they certainly don't reach out to the broader global community. for india it isn't a language barrier or even a cultural-incompatibility issue like it is for some other countries in the region. nor is it that the people don't get the tenets of free and open source software; my conversations with people in attendance showed a high degree of sophisticated understanding of the topic.
so what is it? it's mostly a "people standing up and taking the initiative to create community" problem. i hope our foss.in efforts and kde india's maturation into year 2 helps to set this problem on its head and create terrific opportunities for everyone. i'll continue to work with taj, pradeepto and many of my new found friends in india to see what we can do.
i'll be blogging about some of the great kde initiatives and software i experienced at foss.in in subsequent blogs, including a very interesting roll out of kde to rural schools revolving around latex (!), high end visualization software and the local kde solaris community. there's just too much material in my writing book's notes for one blog entry.
but i couldn't write about my few days in india without any mention of the food. as opposed to many countries i go to and more or less starve (vegetarian food is not in every country's vocabulary) i feasted like a king in india. i love strong flavours, spicy heat and new combinations. bangalore did not disapoint. my personal favourite was this one local lunch place we went into: they sat us at a cafeteria style table and put a banana leaf in front of each person. waiters came around bearing flatbreads, curries, stews, rices ... all vegetarian and all deadly good. we ate with our hands (no utensils offered) and only paid 45 rupee a person (a little over a dollar). i ate until i was full and happy and probably effervescing spice through my pores. the evening bbq's at atul the-wunderkind-organizer chitnis' house were similarly amazing gastronomies with the added benefit of additional company. =)
Friday, December 01, 2006
tiddle bits
today's my first day back home, having arrived last night. i missed a week of weather highlighted by -40C days, which is nice. it's "only" -10C right now, and having mostly caught up with email i thought i'd actually blog quickly before taking care of some more work items.
earlier this week the kde e.v. board had a two day meeting in darmstadt, germany. we met at the offices of eva's company, baysyscom, and got a ton done. we actually covered the entire agenda we set out and managed to meet with kenny, the lead organizer for next year's akademy, and the wikipedia germany staffers at their office in frankfurt. a report is forthcoming.
i unfortunately missed the marketing meeting (which i understand was a great success) that happened on the weekend immediately before that as i was still in india wrapping up foss.in. i'll blog about that trip later in a separate entry, but for now i'll just say that there's a number of people working on some very exciting projects related to free software. there seems to be some need for networking and motivational aides, however.
while i was away i got sent a link to a rather interesting, if tin-foil-hat-ish, blog entry which purports that my recent blog entry about positioning "kde" as an umbrella brand is actually an elaborate plot by trolltech to which i am a puppet. you can read it here for youself if you wish. aside from repeatedly misspelling my last name ;) the writer has made what seems to be a common, and incorrect, set of assumptions about my engagement with trolltech. i am not told what to do by them and am given a pretty completely free hand and i have only a modicum of additional insight into what trolltech is doing than other outsiders do. my primary interest is and always will remain kde. any other theory as to where my thoughts are is rubbish.
i did get a nice chuckle out of his claim that my blog entry was obviously "prepared": i mean, it's nice that my ramblings come out as cogent and coherent bits of text. but that's only because i tend to think about these things a bit (ok, quite a bit) before opening my yap. my blog is not a press release channel or an otherwise coordinated event. it's a place for my randomness to undulate.
one interesting thing in the entry is that the fellow seems to think we're moving most applications out of kde itself. which is not the case, at least not at this point. we still intend on providing a fully functional desktop and not just a desktop shell. we may well end up branding and promoting the pieces more effectively individually however. but these are two very different topics (packaging and public relations).
in completely unrelatedness, i don't know if i mentioned it before, but for the spanish speaking/reading group out there i was introduced to the essentia libre e-mag put out by a columbian group of free software enthusiasts. the latest issue (#4) has quite a bit of nice kde material in it.
earlier this week the kde e.v. board had a two day meeting in darmstadt, germany. we met at the offices of eva's company, baysyscom, and got a ton done. we actually covered the entire agenda we set out and managed to meet with kenny, the lead organizer for next year's akademy, and the wikipedia germany staffers at their office in frankfurt. a report is forthcoming.
i unfortunately missed the marketing meeting (which i understand was a great success) that happened on the weekend immediately before that as i was still in india wrapping up foss.in. i'll blog about that trip later in a separate entry, but for now i'll just say that there's a number of people working on some very exciting projects related to free software. there seems to be some need for networking and motivational aides, however.
while i was away i got sent a link to a rather interesting, if tin-foil-hat-ish, blog entry which purports that my recent blog entry about positioning "kde" as an umbrella brand is actually an elaborate plot by trolltech to which i am a puppet. you can read it here for youself if you wish. aside from repeatedly misspelling my last name ;) the writer has made what seems to be a common, and incorrect, set of assumptions about my engagement with trolltech. i am not told what to do by them and am given a pretty completely free hand and i have only a modicum of additional insight into what trolltech is doing than other outsiders do. my primary interest is and always will remain kde. any other theory as to where my thoughts are is rubbish.
i did get a nice chuckle out of his claim that my blog entry was obviously "prepared": i mean, it's nice that my ramblings come out as cogent and coherent bits of text. but that's only because i tend to think about these things a bit (ok, quite a bit) before opening my yap. my blog is not a press release channel or an otherwise coordinated event. it's a place for my randomness to undulate.
one interesting thing in the entry is that the fellow seems to think we're moving most applications out of kde itself. which is not the case, at least not at this point. we still intend on providing a fully functional desktop and not just a desktop shell. we may well end up branding and promoting the pieces more effectively individually however. but these are two very different topics (packaging and public relations).
in completely unrelatedness, i don't know if i mentioned it before, but for the spanish speaking/reading group out there i was introduced to the essentia libre e-mag put out by a columbian group of free software enthusiasts. the latest issue (#4) has quite a bit of nice kde material in it.
Subscribe to:
Posts (Atom)
