Unfortunately I haven’t made any blog updates in awhile. I’ve been very busy between work and school (and I will likely spend this weekend working on a 20 page project that I’ve written 0 pages for ;). That doesn’t mean I have nothing to report though…
First off, I have renamed kdesvn-build to kdesrc-build to reflect the fact that it builds from Git-based software repositories. In conjunction I released kdesrc-build 1.12 which has various minor improvements, including a few Git improvements.
I’ve complained about my car breaking down. It’s fixed, although I will be selling it now (my wife and I were debating the merits of getting an improved car for awhile before, this incident sealed the decision).
Just today I’ve committed a new feature to JuK, the sadly neglected KDE Software Compilation music manager. Now you can use the scroll wheel in the track announcement popup to quickly switch tracks without having to use the Next/Prev buttons. It’s probably already in every other media player with a playlist, but it’s at least in JuK now. Note that this is a 4.6 new feature, not 4.5.
I’ve also been “reviewing” a patch to further remove Qt3 support code from JuK, which I will try to clean up and get comitted this release cycle. The big thing I still need to do is to finally convert from K3ListView to a real Model/View architecture to finally be rid of Qt3Support. Help is always appreciated btw =D
Burkhard Lück, the documentation super-hero, has been improving JuK documentation for me, but I still need to make some changes that he’s requested to bring the docs closer to 2008-era (let alone 2010) :(
That’s another good “intro to KDE Platform” kind of job by the way, it’s how I got introducing into coding for JuK myself. ;)
Looking for a good way to contribute and got some spare time this weekend? KDE BugSquad is holding a Bug Day revival this Sunday 1st of August and still looking for people who'd like to help out with getting Dolphin bugs under control.
We'll be gathering in our IRC channel (#kde-bugs) starting around 10:00 AM european time zone. As always, no coding skills required. All you need is a recent version of our beloved KDE Software Compilation. Senior bug triagers will be around to help you get started.
More info on: http://techbase.kde.org/Contribute/Bugsquad/BugDays/DolphinDay1 (available soon)
See you there! :-)
Can't make it then? That's ok, we'll have another. Promise.
But feel free to drop by anytime, bug reports always come in, and somebody has to look at all those duplicates!
Then the big question: do we hold our Bof in the back of a bus next year too? It makes it hard to take a group photo!
As many of you know, the KDE Project is transitioning to using Git with Gitolite and CGit. As such, I thought I’d update my aging Gitweb/posix-permissions installation of git to use CGit and Gitolite, and now my public git repository is kicking away. (If you’d like commit access any place or would like to host your own repo on my server, drop me a line.)
Since Gitolite manages git repositories, it has the option of generating the necessary information for Git’s shipped gitweb. This includes making a static list of repository names that should be included in gitweb as well as optionally adding the gitweb.owner entry inside .git/config and the description file at .git/description. The static list of repository names is boring and standard and easy. The owner and description specifications are standards set by the Git project for this kind of information. Hence, Gitolite supports interfacing with them.
Meanwhile, CGit uses its own configuration format for determining the owner and description and repository path. For interfacing with Gitolite, in the past I have created a hook that writes out a CGit-formated configuration file, which is then included in the main cgitrc with the include directive. Essentially I had to do this:
gitcode@starfox ~ $ cat web/cgit/generaterepos.sh #!/bin/sh cd $(dirname "$0") rm -f repos.tmp cat ~/projects.list | while read gitname; do name=${gitname%.*} fullpath=/home/gitcode/repositories/$gitname owner=$(git --git-dir=$fullpath config --get gitweb.owner) desc=$(cat $fullpath/description) ( echo repo.url=$name echo repo.name=$name echo repo.path=$fullpath echo repo.desc=$desc echo repo.owner=$owner echo repo.enable-log-filecount=1 echo repo.enable-log-linecount=1 ) >> repos.tmp done mv repos.tmp repos gitcode@starfox ~ $ tail -n 1 web/cgit/cgitrc include=/home/gitcode/web/cgit/repos gitcode@starfox ~ $ cat repositories/gitolite-admin.git/hooks/post-update.secondary #!/bin/sh exec /home/gitcode/web/cgit/generaterepos.shThis worked decently, but it was cumbersome and ugly, and was likely not to scale as features in both Gitolite and CGit are added and changed. Luckily, CGit supports the scan-path option, which builds an internal list of repositories automatically by scanning a directory for git folders. One such solution for integrating with Gitolite would be to simply point scan-path at Gitolite’s repository directory. This works fine, but it has three main shortcomings, which I’ve addressed this in a generic non-Gitolite-specific way in three patches. Let’s walk through them one by one.
projects-listWe don’t want all Gitolite repositories showing up on CGit, and Gitolite provides a generic mechanism for controlling this: it writes a list of all the repositories selected for Gitweb to a file called projects.list. It’s just a flat file with each repository’s name written on a new line:
CheeseWhiz.git Geoemail.git MyCoolThangs.gitSo, what about augmenting CGit’s scan-path feature with another setting called “project-list” that points to this file? That’s what this patch does. If project-list is set before scan-path is set, then scan-path only scans the git folders at project-list/${a line in the project-list file}. Problem solved, and this is a pretty generic way of doing it too.
git-suffixMost people store git repositories on disk at MyGitRepository.git. Notice the .git ending. However, most people prefer to see it listed as just “MyGitRepository” and they especially would like to clone it at gituser@domain.com:MyGitRepository, without needing the .git ending. Usually, CGit’s scan-path infers the repository name directly from the folder name. This patch adds a setting called “remove-suffix” that, if set to 1 (default is 0) before scan-path is set, will remove the .git suffix from the repository name and url while still pointing to the correct physical path. This as well is fairly generic and not specific to Gitolite or Gitweb, but rather Git’s usual conventions.
config-ownerCGit’s scan-path infers the owner of the repository from the posix owner’s UID name. But there is an additional Git standard for overriding this for any interface: the “gitweb.owner” configuration key in .git/config, which Gitolite understands and respects, as well as Gitweb. This patch simply calls Git’s internal C functions for fetching this information from the current repository’s config, and prefers this as the owner to the posix owner’s UID name. If gitweb.owner is not set in the configuration, it falls back to the posix owner’s UID name. This is a standard Git behavior. This occurs only for scan-path — cgitrc specified owners are preferred over these former two, obviously. Again, this configuration standard has been determined by the Git project, and both Gitolite and Gitweb respect it. So, this patch adds support inside CGit for it.
it worksNow instead of the include and the ugly set of scripts and hooks, I can just place this at the bottom of my cgitrc:
remove-suffix=1 project-list=/home/gitcode/projects.list scan-path=/home/gitcode/repositoriesand this integrates perfectly with Gitolite. All is harmonious in the Git universe.
On top of all this, I’ve cooked up a wicked good .htaccess file for CGit that allows me to have anonymous http pull at the same time as it rewrites the CGit urls to be pretty. Check it out:
Options FollowSymlinks ExecCGI DirectoryIndex cgit.cgi Allow from all Order allow,deny RewriteEngine on SetEnv GIT_PROJECT_ROOT=/home/gitcode/repositories RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule "^(.*)/(.*)/(HEAD|info/refs|objects/(info/[^/]+|[0-9a-f]{2}/[0-9a-f]{38}|pack/pack-[0-9a-f]{40}\.(pack|idx))|git-(upload|receive)-pack)$" /git-http-backend.cgi/$1.git/$2 [NS,L,QSA] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^.* /cgit.cgi/$0 [L,PT,NS]A strange combination of stopping internal redirects and partial rewritings and odd stop conditions has made it so that the request gets forwarded and reformatted to git-http-backend if and only if it is first valid with cgit.cgi. Is this crackable? Can anyone figure out a backdoor to grab a repository that isn’t in projects.list?
I’ve also written a super generic script for uploading new repositories to my gitolite/cgit installation. From a git working directory, I run ~/Projects/uploadNewGit.sh "This is a description of my new git repo.", and wham-shabam, all the permissions get set and everything is uploaded just fine. Here is uploadNewGit, the latest version of which you can always find in my GitTools repository:
#!/bin/sh GITOLITE_ADMIN="$HOME/Projects/gitolite-admin" gitdir=$(readlink -f "$(pwd)") name=`basename "$gitdir" | cut -d / -f 2 | cut -d ' ' -f 1` description="$1" if [ ! -d "$gitdir/.git" ]; then echo Not a git repo. exit 1 fi if [ -z "$description" ]; then echo You need to specify a description argument. exit 1 fi pushd "$GITOLITE_ADMIN/conf" > /dev/null echo "Writing config..." (echo echo " repo $name" echo " RW+CD = $(whoami)" echo " R = @all" echo " $name \"$(git config --get user.name)\" = \"$description\"") >> gitolite.conf git commit -a -m "Adding $name to repository." git push popd > /dev/null url=`git --git-dir=$GITOLITE_ADMIN/.git remote -v | grep push | cut -f 2 | cut -d ' ' -f 1 | sed "s/$(basename $GITOLITE_ADMIN)/$name/"` git remote add origin $url git push origin master git push --all git push --tags(As a side note, I’m not really sure the best way to quote commands inside of commands with variables that have spaces. something=$(command $(othercommand $argument)) has issues if argument has a space or if othercommand produces something with a space or if command produces something with a space (not totally certain about the latter two — I should check). But I can’t do this: something=”$(command “$(othercommand “$argument”)”)” because of obvious quoting problems. What’s the common solution to this? I’ve been using an awkward combination of the backtick operator `…` and the $(…) syntax but the backtick has some weird rules too. What’s the deal? Can somebody point me in a good place to read about this?)
Anyway, most of what I’ve written about in this post is new to me. Or at the very least, I’m a bit uneasy. So if you have any suggestions, by all means please tell me. I’m looking forward to seeing what the KDE sysadmins do in the end. Hopefully the CGit authors accept my patches.
Update: After some back and forth with Lars, the CGit maintainer, I’ve added a few more patches, including putting the gitweb.owner functionality behind configuration setting and also caching the scan, among various other improvements. You can check out all the commits I’ve made on this at the cgit for my cgit clone.
It's official the combined KDE Akademy and Gnome GAUDEC conferences will be held in Berlin in 2011, next year and this is great news! I played a small part in organising the joint conference in Gran Canaria in 2009, and really enjoyed working with the Gnome guys most of whom I hadn't meet before, as well as the familiar KDE people. It was great fun to see how it turned out. I don't think anyone really knew in advance - we didn't know if too much collaboration would spoil the 'community bonding' aspects of the conference and their individual identities. Or maybe too little collaboration would increase the distance between the two communities. In the end I thought the collaboration aspects could have been better, indeed like the WiFi could have been better - there is always something you can improve at these conferences, but what the heck, by and large it was mostly pretty good.
I enjoyed being able to go to both presentations, and some of my favourite ones, like the MeeGo^h^h^hMoblin user experience talk in the mobile track, came from the Gnome side. Both projects are facing the problem of how to you merge your desktop technology with the upcoming Smartphone/Small devices that run platforms such as Android or Meego.
A consequence of stresses like upstream vs downstream or mobile vs desktop, is that Dave Neary's recent survey of Gnome contributors has given rise to much discussion and flaming about Canonical's contribution. One from Mark Shuttleworth called Tribalism is the enemy within, which is worth a read. That addresses tribalism within the Gnome community, and that is clearly a bad thing.
Another good post from Jono Bacon RED HAT, CANONICAL AND GNOME CONTRIBUTIONS included this from Dylan Macall, which made a good point:
"..This whole thing is really putting forwards an issue Gnome has right now: they can’t, as a community, decide whether they like the idea of external projects building new environments on the Gnome platform. (Case in point: Meego for netbooks).
I think there’s one camp that thinks Gnome should be a user-facing product, with its own special branding and its own distinctive look that everything ships in pristine condition. (I’ll inject my opinion in brackets here: I think that entirely defeats the purpose of having multiple distributions).
Then there’s another camp that sees Gnome as a starting point with lots of handy tools (and common modules) for distributions to build operating systems. For example, Unity, Meego, Jolicloud, UNR…
That first camp sees Gnome as a monolithic project; only internal work is worthy. The latter camp sees Gnome as something akin to Gnu.."
I think you could have exactly the same discussion about the KDE project and what it's relationship with MeeGo should be. Does KDE consist of a lot of useful tools and libraries that we should encourage as many other projects as possible to use? Or should we concentrate mainly on a cohesive desktop experience? Are the two aims incompatible? I don't know..
I hope we can minimise Gnome vs KDE tribalism too, and I'm looking forward to another combined conference, where we can integrate the communities better (and in the process have great parties involving much beer drinking of course). I was slightly disappointed that Gnome 3.0 has been delayed, and I really wish them good luck in getting it out of the door. It is not true at all, that if Gnome does worse, then KDE will do better. If both projects succeed it is more like '1 + 1 = 3' or if one project fails it is '1 + 1 = 0.5'. We now have much infrastructure in common and need each other to succeed so let's "Relax"..
Since the C# bindings are apparently not really used/wanted by anyone (except for some Windows people – but that’s really not my main development platform) I thought that maybe some more people are interested in Java bindings.
There was a poll on kdedevelopers.org two years ago that showed Java ahead of Ruby and C# – but it doesn’t seem to be really representative: there are at least some Ruby plasmoids on kde-look.org, but none in C# (which was still ahead of Ruby). Given that Trolltech/Nokia abandoned QtJambi I’m not too sure about Java bindings either.
So I’m asking the community directly before I start putting too much work into a project that noone really wants: So far we have (active) bindings projects for Python, Ruby and Perl – is there any demand for Qt/KDE Java bindings in the community? Or if not for Java, for any other language/platform?
Looking forward to your comments
<a href="http://kde.org/" target="_blank"><img src="http://e2-productions.com/countdown/counter45-square.php" alt="KDE SC 4.5 Release Counter" /></a>
<a href="http://kde.org/" target="_blank"><img src="http://e2-productions.com/countdown/counter45-long.php" alt="KDE SC 4.5 Release Counter" /></a>
Plasma has a wonderful theming engine, that enables the creation of a really stunning visual appearance, with a great amount of customizability, just look at what is available right now, to not mention that being vector based makes the widget set pretty flexible and able to be used on really different hardware form factors with different sizes and dpi.
But we're developers and we like to write code, hack on stuff, we often forget to document things, and this is an area that really can get better.
Yesterday I've forced myself to look at the quite incomplete and outdate documentation for the Plasma theme system and I've looked file by file, element by element and completed and ordered the whole theme.
Now if you have any doubt on the Plasma theme structure, just go to the relevant techbase page, and you'll find the complete list of every file and every element in every file, updated to the upcoming 4.5 release. this should ease a lot the construction of themes.
It has been a long and painful work, of which developers may really want to avoid it, but it incredibly pays the effort, because it's a really important part of the elegance we are trying to reach. A complete, pretty and documented framework is what is elegant to a quite relevant part of our audience: developers that are approaching the platform for the first time.
Now we are restructuring the techbase page for Plasma, moving here the pages that makes more sense here, having the two wikis more in focus and comprehensible.
If you are interested, if you are trying to approach the development in Plasma and have difficulties to grok some of the concepts, if you already work on some plasma aspects such as plasmoids, just stop on #plasma on freenode and you can give an hand in the documenting effort, being tutorials, wiki pages or API docs, you'll learn quite a lot of the internals in the process and will make easier for others to learn.
When walking in a big group of people you have to check every now and then for the slower ones so you don’t leave them behind and lose them. It’s the same in a community like KDE. Every now and then you have to check if everyone can still keep up and if not take the necessary steps. That’s why for the second time now I’ve asked KDE developers to tell me which parts of KDE they think really needs some new blood or more helping hands. This is the list of answers I got:
Quite the mix – surely there’s something exciting in there for everyone. So if you are someone who wants to contribute to KDE and looking for a place to start or an experienced contributor looking for a new project, this is where your help would be really appreciated. Choose your direction and get your hands dirty
If you were a participant of this years KDE multimedia meeting I would be interested in your opinion:
As you probably know this was the second kde meeting I organized and I plan to do another one next year (btw I got today the OK of a certain person and I think this means the topic for next years meeting is set but more about this in the following weeks). What do you think if I would earn some money with the organization of the next meeting.
As I like or love to organize such meetings and I doesn’t seem to be that bad in this I’d like to organize another and another and … You see ;-). But even if it’s a lot of fun it’s also work and time consuming work nonetheless. For the meeting this year it took a good month of time to organize everything (incl. the meeting time). The whole amout of time is or was distributed over half a year.
And the other thing is that I need to eat (;-), pay the bills and as I’m moving to my girlfriend and my studies end in the next year or two a family is not that far away. And that’s another reason I’d like to professionalize the meeting, make a conference/sprint out of it. An annual one. And don’t missunderstand me: I’d don’t want to become rich on the shoulders of kde developers and/or the KDE e.V. The contrary I starting to plan and search for sponsors much earlier this time to decrease the amount of money the e.V. "needs" to sponsor.
Oh and if or when you’re waiting for my next "kde work day" blog. It’s in the making but as I’m moving (the whole room is full of stuff to package some stuff delays a bit. And there’s anoher idea floating in my mind. Something somehow kde related but not code related and something for the kids and probably something to play and something about Konqi the dragon but …
Oh and I’ll do something like (yes, I like the word "something" a qt and kde course in my local linux user group… Oh and this is the last oh: I’ll do an english course in the next semester to meliorate my english grammar. Hopefully to your pleasure as well ;-).
Hello,
today i will show you a new plugin for Kate, called KateSQL.
As you may have guessed, it brings to Kate the basic features of an SQL client, allowing you to open connections, execute queries, and display result data from SELECT statements or stored procedures.
Since this plugin makes an extreme use of the Qt Sql module, most of database drivers are supported..
Said this, let me explain how it works..
First of all, you have to create a new db connection through a simple wizard, specifying driver, connection parameters (hostname, username, password, etc…), and a descriptive name, that KateSQL will use as identifier.
Done this, what you need to do is just select the query text in the editor and press F5 (or your preferred shortcut). The whole text will be executed through the selected connection.
For SQL output, two toolbox are disposed in the bottom area:
Ah, about this, my last commit implements a configuration widget that let you choose colors and font styles for text fields, numbers, blobs, nulls, booleans and dates… cool, yeah?
Last but not least, on the left panel you can find a basic and useful schema browser, that show the tree schema of the database connection currently selected. With this tree widget you can browse through tables, system tables and views, up to individual fields. obviously, primary key fields are distinguished by the classic yellow key icon.
Currently, there are few problems with multiple query handling.. Some engines doesn’t supports it natively, others can receive queries separated by a semicolon, but the QSqlQueryModel can handle only one resultset at time.. probably the best solution is to parse the text, split queries, and execute them separately.. Surely, this feature will be implemented soon.
Stay tuned!
Of course, if you want to help us with development, you are welcome!
Recent comments
2 weeks 5 days ago
3 weeks 2 days ago
3 weeks 3 days ago
3 weeks 4 days ago
3 weeks 4 days ago
3 weeks 6 days ago
3 weeks 6 days ago
4 weeks 5 hours ago
4 weeks 2 days ago
4 weeks 3 days ago