Adjust the recipe to konversations move to git. No other changes.
If you installed build-tool as a gem just issue sudo gem update build-tool.
The tool does not migrate automatically. To migrate delete ( or move ) the previous konversation checkout, then rebuild konversation with kde-build build -u --from-scratch network/konversation.
Build-tool requires ruby 1.8 for now. When i started it ruby 1.9 was still seen unfit for production use and noone was able to estimate how long it would be that way. It doesn't work with 1.9 currently and as long as opensuse doesn't provide a 1.9 package it will stay that way.
Just a short notice that i opened the rubyforge tracker for build-tool. You can submit bug reports, feature request and patches for build-tool.
As some of you out there probably heard i'm developing a ruby based build-tool in the style of kdesvn-build. This is actually the third version i'm currently working on. First was an attempt in python. But my brain is incompatible with python. Then the first attempt in ruby with yaml based configuration files. Which really didn't work. This time with a custom configuration file format with a properly (i hope) done parser.
The script differs from from kdesvn-build in mostly two ways
This time i wrote more or less extensive documentation about the script. If you have problems or find flaws or gaps in the documentation do no hesitate to point it out to me.
The script comes with three recipes included
Today i made the 0.1.3 release. I consider the script suitable for public use now. See the documentation how to get it.
We have done it. Just lay back and glow in what we achieved: Kontact/khtml are on par with Outlook/Internet Explorer
That looks SOOOO convincing.
It's about time to pencil my two cents about the gran canaria desktop summit into the great notebook called world wide web.
I'm contributing to kde since January 2008. This years akademy was my first ever conference of any kind. I knew noone and my hotel was flooded with gnomies. Nice guys really. And they didn't even bite. Who would have thought of that :).
Had two nice weeks. But i suspect beeing part of some of the greater kde communities like plasma, kate, marble, koffice ... makes it even more interesting. I even had to explain why i chose to mostly work on kdelibs stuff :). Interesting question but i'm not quite sure my answer helps in attracting more people to work there.
I met my favorite kate developer ... anyone working on a vi mode HAS TO BE a great person. I even tried to motivate him by offering a crate of beer for a working vi command line mode. Erlend ... don't forget about that. Beer has a drink-by date here in germany and in eager anticipation i already bought the crates. Yes i make it two crates :-) . I'm waiting!
Met some nice local guys and prompty forget their name. Guys if you are out there reading this please contact me. I'm the tall one with curls. And i want to have that picture you guys made.
We made a nice picture showcasing that in kde we grow with our projects. Blauzahl has the better version were you have a standard of comparison (chani iirc) but since she failed to post it yet i will have to do it. Update: Daniel posted a link to the image in the comments. Thanks.
![[Picture of Andre Wöbeking, myself, Volker Krause, Lubos Lunak and David Faure with Chani in front.]](http://michael-jansen.biz/sites/default/files/img4937_1.jpg)
And i have never seen any of the pictures showcasing that kde people know how to party. I mean those drinking two beers simultanuously. The dancing adventures of mr. knut. claudia, erlend, andreas, casper, me and ... dancing.
Have a look at my galleries at smugmug. Thanks to ervin for pointing out the site. But he could have posted about the referal program. So if someone out there wants to have it's own smugmug gallery please contact ervin or me.
See you all next year.
It's not a good idea to post your problems in the comments section of my blog. Even if you provide contact address or website. I can't help you there.
Commenting to or opening a bug is the preferred solution. And please try to be very specific about your problem.
See Bug 190412 for an explanation. The problem is a little broader than the bug reports. See Bug 193085 for a more detailed explanation of the problem.
The problem was me fixing khotkeys without completely adapting it to the new global shortcuts framework in place for kde 4.x . I just didn't realize the consequences. Khotkeys in 3.x ungrabbed the shortcut if the condition was not met or the khotkeys was inactive. In other word whenever the focus was not on an konqueror window ctrl-w was freed. With 4.2 that important bit of functionality was lost. ctrl-w was grabbed all the time. My fault.
If you are on kde 4.2 and want to have your keys back then go to the input actions kcm (kcmshell4 keys) and remove all shortcuts associated with inactive hotkeys. Or go to the global shortcuts kcm (kcmshell4 keys) and disable all khotkeys shortcuts you don't like.
With 4.3 inactive global shortcuts are not grabbed anymore. I made the change last weekend. if you get your hands on the next snapshot and still have problem with that ping me.
That is some kind of unexpected comeback from a classic out of the pre kde 4.0 development time. I once managed to break the 'e' key for all when working on khotkeys. Me fixing khotkeys exposed a qt bug. Qt did parse the "Win+e" string from kde 3.x as 'e' because it didn't recognize the Win modifier. It is called Meta in qt. We fixed the symptom because we couldn't fix the cause and everything went smoothly for some time.
Then reports about that problem having a comeback started to creep in but i couldn't get my hand on someone experiencing it. Not everybody looks my way when having keyboard problems. The last days comawhite - a irc regular - had the problem and we could pinpoint the cause.
The problem this time appeared because of a different reason. comawhite is a gentoo user and his x11 setup didn't provide a modifier usable as the meta key. You can check that with xmodmap -pm. I get:
xmodmap: up to 4 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock Caps_Lock (0x42) control Control_L (0x25), Control_R (0x6d) mod1 Alt_L (0x40), Meta_L (0x9c) mod2 Num_Lock (0x4d) mod3 mod4 Super_L (0x73), Super_R (0x74), Super_L (0x7f), Hyper_L (0x80) mod5 Mode_switch (0x8), ISO_Level3_Shift (0x71), ISO_Level3_Shift (0x7c)
For comawhite mod4 was as empty as mod3. Some kde code didn't care and still grabbed the shortcuts with meta in it globally. Meta was just dropped. So for 'Meta+E' only e was grabbed, for 'Meta+X' only x was grabbed. Makes up for a pretty messed up session. And you couldn't notice the reason because the code didn't trigger the action. So the key was just eaten.
I fixed the kde code and comawhite fixed his setup by adding
xmodmap -e "add mod4 Super_L" xmodmap -e "keycode 115 = Super_L"
And qt having some problems with parsing QKeySequences from String. Since nokia opened the qt repository to external contribution i will try again to fix it. See my Qt Patches.
I just found out that there is another problem having this effect. See Bug 193150: can't type 'e' key. After starting amarok it get's even uglier. Best idea is to skip current snapshot and use the one from next week.
That's because on some keyboards Alt+PrintScrn is used as Sysreq. You can use xmodmap -pke | grep -i print to check if you are affected. If you get something along the lines of keycode 111 = Print Sys_Req Print Sys_Req Print Sys_Req there is no alt+printscrn for you.
Someone managed to put a really bad hack into kde hardcoding keycode 111 to the printscrn key so it worked if you changed the shortcut manually in the config file. That code managed to be there since 3.x. So much to the many eyeballs theory :-) : I removed that hack so it will stop working with 4.3 because it breaks keyboards where 111 is mapped to some other key.
With kde 4.2 my first big kde contribution went live. The khotkeys redesign. It was unfinished and users complained. Most complains - or should i say the loudest? - were about the incomplete mouse gesture support. The lament didn't stop. Then Frank Roscher came around and offered a tool name easystroke as a replacement for khotkeys and the ease was restored. Partially.
When i got the khotkeys gesture support working again in trunk the same guy sent me a patch implementing easystrokes gestures algorithm in khotkeys. Nice surprise. Apparently easystrokes author not only offers it's software for free ... no he also provides a detailed explanation of the algorithm used. That's the spirit! Since easystrokes algorithm is superior to khotkeys old one it was a no brainer to accept the patch. He even added an migration from the old algorithm to the new.
So with 4.3 the mouse gesture support in kde is back. But the documentation for khotkeys is miserable. So it's not easy to guess how mouse gestures work. Perhaps someone out there is willing to write some documentation. I'm bad at doing that. As you will shortly notice.
Groups can have conditions. A condition is something along the line "There is a window named xyz", "The window with title xyz is active". No condition means always true. Have a look at the "Konqueror Gestures" for an example. All gestures in that group will only work if the condition is met. And the condition is that a konqueror window is active. What a surprise!
To start a gesture you must press a mouse button. Click on Settings to configure which. When pressing the mouse button khotkeys follows your moves. After you release the mouse button khotkeys will try to match your gesture against its database. If a match is found the associated action is executed. Again have a look at the Konqueror examples which work perfectly. For me. In case of troubles open a bug.
Mike