Libre Graphics Meeting at Wroclaw (Poland) have been a great event. I have met several actors from open-source world as:
Libre Graphics Meeting at Wroclaw (Poland) have been a great event. I have met several actors from open-source world as:
For those reading the Planet consistently as of late, you’ll notice that Celeste has been on a tear. She’s discussed user research profiles, use scenarios and use cases, user types (Plasma) and user types (Okular). Now, as a member of the elusive Marketing Working Group, remember that we’ve always declared ourselves “participative” - meaning we welcome people to ask questions and look for guidance/help/strategy. It’s great to see community members like Celeste go beyond “participative” and find ways to positively and constructively engage groups without waiting. The nefarious MWG could probably takes notes.
In the interim, I would like to remind everyone that such concepts to assist with usability - don’t have to stop at usability. User identification, profiling, investigation and interviewing at its fullest starts to sound quite like learning about a target audience. The basic tenets of marketing can be simplified to “Know your user (customer) and know what they want.” The more that you understand your user base, you can not only make a better application, but write better contextual help, documentation, web sites, blog entries, news letters and press releases. Even our intrepid translation team may choose different phrasing options based on the end user.
Would you write in the same style with the same goals for KDE-edu and KOffice? Within KDE-edu would you write the same for Kanagram (young user or Ade) as you would for Step (physics student)? Within KOffice would you write the same for Karbon14 (graphics) audiences as you would for KPlato (project related)?
I think about such things daily at work, where I have application teams assembling portlet applications that have radically different user groups: Internal call center agents, general personnel, executives, external brokers and members (over 50 years old). For every site or application, we have our business analysts work on user identification before turning documentation over to our design firm for branding, our tech writers for documentation, our creative writers for copy/content, legal for text approval and user groups for feedback mechanisms. Even our quality assurance groups need to be aware of our target audience (CSS for font sizes and contrast will be different for different “communities”, test different screen resolutions for different user bases, etc). Even further, we tune and optimize for different user bases (clicks-per-minute, length of session, caching options, LoadRunner settings during performance testing, etc).
Better understanding who your users are and what they want is so critical to being successful and building a community around your project. Just because you may discover something during usability investigation, don’t set those results to the side too quickly.
For almost a year now, I’ve been working at Pizza Hut as a software developer on the point of sale team. It’s an awesome place to work (listed as one of the top 25 places to work in Dallas, TX) and now, if you want, you can work there too!
So here’s the specifics on what will help you get in the door:
The online job posting can be seen at CareerBuilder.com. If you’re interested, please send me an email I’ll be glad to help you get your foot in the door.
So, as mentioned earlier, we moved to a new house on March 21st. On April 4th, Sarah was born. Here’s the obligatory picture:
So now I join the ranks of the KDE dads. 
So I’m a pretty big fan of the Amazon MP3 Music Store. It has had very few tracks which I wanted to grab which weren’t available. It’s cheaper than the iTunes Music Store as well. I realize this is the case only because the music labels are tired of getting their terms dictated to them by Apple so they decided to open up the competition and make the deal more enticing. But that works in my favor so that’s awesome. Only thing I’m afraid of is that that music labels will try to do something dumb and try to start adding DRM copy protection to the music again (which breaks the music on my players). But anyways, back to my original point: Amazon’s MP3s even come with the cover art built-in to the track.
I noticed this when I tried playing some of my purchased tracks on my laptop this past underway with Amarok, and noticed that it displayed the cover art just fine. After a bit of work now that I’m back in port I’ve managed to add display of built-in cover art to JuK as well. The patch is available as an attachment to KDE bug 103118. In addition (what the bug was reported against) if no cover is present JuK will look for cover.jpg in the same directory as the music file like many other media players do. No screenshot, it looks just like normal JuK cover art support, only JuK pulls from more sources with the patch.
As far as where this lands I’ll have to email core-devel. I returned to port way too late for the 4.1 feature list :) so this may have to wait for 4.2 (depending on how much toward “bugfix” people are willing to lean). But if people want to test that’s fine. ;)
On a related note, if you’ve been using JuK and notice a bug that is egregrious (i.e. you can’t even play audio because JuK always crashes when you click Next, you can’t add files, etc.) please leave me a comment so I can prioritize. I have limited time so I’d like to make good use of it in time for KDE 4.1.
I already know of the fact that you can’t seem to drag-and-drop tracks to playlists anymore for instance (which hampers my routine at least so I’ll try and fix that soon).
Next week will be the Dutch Ubuntu Release Party. Not sure where that link points too - it shows the dutch release party page for me, but being a rather generic URL - www.releaseparty.eu - I guess one could expect to get a local page served or something. If that's true it would be both neath and annoying.
Anyway. I also gave a talk about KDE 4.1 at Guademy in Valencia (Spain) a couple of weeks ago. It went relatively well, except for the live preview. Shouldn't have done that - not only didn't it work very well, it also destroyed the whole 'flow'. Got lost, so to say. That's why for the Ubuntu Release Party I've spend the last 2 days making screencasts of what I want to show. Took a lot of time so I began uploading them to Youtube. They were made in 1024x768 resolution (My little laptop uses that res natively, and I hope to encounter beamers with the same resolution) for a sharp image.
Guess what Youtube did to them... Yeah, they look horrible.
Now I want to put them online somewhere. But they are - well, what is big? 100 mb together. So, first I decided to create a torrent. Which can be found HERE. Please seed, and ehm - I have a horribly slow upload so it's gonna take a while...
I will also try to find a location to put the files online for faster and easier download, but for now the torrent is all I have.
If you insist on viewing the Youtube videos (or just can't wait a couple of days until the torrent is done downloading :D) just go to my profile on Youtube.
Edit: that was quick - already 4 ppl on torrent. One even KTorrent 3.0.2, I wonder why that person wants to see the videos ;-)
Anyway, if they all share, speed might not be that bad.
Edit2: apparently, it's videos not video's ;-) And screencasts would be even more correct, right?
Downloading the screencasts should be pretty fast now, btw, 25 seeders...
Probably everyone who has been trough some semi-serious kind of programming 101 course has probably been presented with this:
Your lecturer probably told you that this is a common problem amongst software developers. However, as I just learned, it seems to be a diseaseproblem with the entire IT industry.
So what happened? I was visited by a Dell technician because my laptop backlight was broken. He replaced the spare part pretty quickly which made me pretty happy. However, we noticed that some screws needed replacements and some (small) bumpers were missing. My Laptop has two kinds of bumpers, two big, longish ones and several smaller, roundish one. So he was kind enough to order new screws and (small) bumpers with the Dell hotline who promised to send the parts promptly. And when I pulled the envelope from my post box the other day I was a happy camper... until I realized there were six(!) more left in the box. So I took them all and if you lay them out, it looks pretty impressive:
But the technician ordered just 1 set of screws and 6 small bumpers. So how could that add up to 7 air-damped envelopes?? Right, as you probably just guessed (out of your mathematically trained gut), each bumper came in its own envelope. So if you lay out the contents, it doesn't look soo impressive anymore:
And did you realize something else? I am now sitting here with seven large bumpers, of which I can make use of none (well, I will probably replace the old ones that are still there, but that wasn't the actual problem at all, and I still would have five spare...)
I’ve always had a dream that Qt’s widget system would be based on a powerful 2D, or possibly even 3D, graphics engine, reaping all the benefits and optimizations that make games run fast. The reason is, coming from a 3D graphics background originally (alright, I was 16 at the time), I’ve always been puzzled by how poor application UIs perform, and how constrained they are, compared to the most basic 2D and 3D graphics engines out there. I think there are many reason for why graphics toolkits provide limited capabilities, and performance, and I’ve been studying this, hoping to help find ways for Qt to be better than the rest. If you ask me why oh why, be warned, I will talk all night. 
I think I could get shot for saying this, but IMO widgets are monolithic beasts. Input, painting, clipping, geometry, events and all are almost always packed into just one class. And that class plugs into a framework that works in only one way. It’s hard to change the way a widget clips without introducing rendering artifacts (draw outside and try to update with the rendered region - oops, the dirty region is autoclipped to the widget rect). It’s impossible to know what a widget looks like without calling paintEvent(), which is a virtual function that might do something different every time it’s called. Multithreaded painting is extremely hard. It’s hard to make the widget paint outside paintEvent() in general. Couldn’t the widget just say what it looks like instead?
The main reason it’s like this, I think, is that UI toolkits’ graphics capabilities are just a hurdle in the path to the ultimate goal, which is to pull together UIs with a nice tool, perhaps targeting your favorite language, and with a cool style and the perfect widget ;-). IOW modeled vertically, after the concrete problem to be solved (which is generally speaking a good approach), and perhaps constrained by the capabilities of the primary target platform. I still think we can learn a lot from looking at UIs as a specialization of a 2D graphics scene API, rather than 2D graphics being an extension to a UI toolkit. We need to model our graphics the way that graphics works (both software and hardware), and not cling so much to a particular problem space. Make sense?
Qt provides both a high-level widget API, a low-level graphics API, and a “mid-level” canvas API called Graphics View. Graphics View is an example of loosening up the constraints of the high-level API, without exposing too many low-level problems such as geometry and dirty region handling. In a way it’s more a 2D graphics engine than anything else. It manages surfaces in 2D (or 2.5D, quasi-3D) space. Originally, we meant for it to be different from QWidget. Obviously, it’s a framework that’s meant for something completely different than widgets (vector graphics, charts, maps, IC design, large scrollable scenes, and so on). What we’ve learned, however, is that the two aren’t really that different. Why can’t I have 1000 widgets in a QScrollArea, for example.
So looking back a few years, you’ll see that we’ve made changes to improve QWidget. Without breaking compatibility of course (which is amazing in itself, shows how Qt’s architecture allows for significant internal changes).
Before Graphics View came out, in Qt 4.1, we loosened up one constraint in QWidget by enabling automatic background propagation. Now, widgets no longer had any default background (remember this change? how about QWidget::autoFillBackground oh, OK now you remember ;-)), and we were one step out of the box-model that widgets traditionally represent (btw when I use the term “box-model” I refer to a widget representing an independent rectangular region of actual screen real estate). Then, in Qt 4.2, we introduced delayed widget creation (DWC), which allows a widget to be constructed without an actual window handle. As part of the DWC work Paul, Matthias and a few others did for 4.2, they had to ensure that widgets had enough local state to independently represent what it otherwise had with a window handle, as without. Well, this had a ripple-effect. During the Qt 4.2 and 4.3 maintenance cycles, we discussed the fact that the only widget that really needs a window handle, is the top-level. With Qt 4.4, Bjørn Erik did some tough refactoring work (which some of us, me included, thought wouldn’t really be feasible), and gave birth to what we call Alien Widgets, the invisible behind-the-scenes beauty. Because of this, in Qt 4.4, a window and a widget are different, despite being the same class, in that the window signs a “contract” with the windowing system to register some screen real estate. This is the same now on all platforms.
Still, after this, you could see some strings that pull QWidget down. Painting outside paint event - using QWidget for screen shot captures, for example, required painter redirection. Each widget still constructed its own QPainter inside paintEvent(), and with it a separate paint engine, despite how all painting ended up in the same paint device: the QPixmap backingstore, which was associated with the same top-level window. Now in Qt 4.4, QWidget has a render-function, much like QGraphicsItem has a paint-function, and the window is, for a subtree of QWidgets, essentially the same as a QGraphicsView is for a scene. Puh.
Background propagation. DWC. Alien Widgets. Shared Painter. You see what’s happening? We’re on a mission. 
We’re closing the gap between QWidget and Graphics View. And we’re not done, there’s still more to come. There are some things that we cannot easily change, like QWidget’s clipping model for one (it’s opposite from Graphics View) [*]. And that Graphics View can’t make windows like QWidget (arguably, this is solvable though). Plus all our widgets are QWidget-based. Embedding the QWidget-based widgets into Graphics View using WoC is cool, but it’s just not good enough for full-blown exploitation…
Feature by feature, I must say the situation today looks surprisingly good. I’m looking forward to the day when I can simply assign a QGLWidget viewport as QWidget’s window. Or when I can load UIs from Qt Designer into Graphics View. Or in Qt 5, maybe the two are the same thing (the latter is usually only mentioned between some specially interested devs in Trolltech social events after consuming large amounts of beer).
That’s enough blabber for one blog post. I just felt like sharing what’s on my mind these days. This is btw all part of the research we’re doing in Development / Trolltech to support next generation UIs.
–
[*] QWidget is by default clipped to the intersect of its rect() and the localized exposed region before paintEvent() is called. QScrollArea has no explicit clipping features. Because most widgets don’t draw outside their bounds, item-imposed clipping should have been off by default (obviously expose-clipping is unavoidable for viewports that allow partial updates). And scroll areas should instead explicitly clip the widgets that intersect its edges (widgets outside shouldn’t be drawn, you don’t need clipping for that) (most 2D and 3D graphics APIs use subdivision instead, essentially real-time retesselation of the intersecting primitives to avoid clipping altogether). It’s extremely hard to change this in QWidget today without breaking compatibility. QGraphicsItem has the preferred model in place. But all our standard widgets are written using QWidget, not QGraphicsItem/QGraphicsWidget.
Back in .nl again; Calgary was definitely worth it for spring: I arrived with snow, had a day of 18 degrees and sunshine, picked up 2 feet of snow and another thaw and then flew out again. Holland is hot and muggy and green.
There will be gnashin of teeth and writing of articles in the coming days. After that, KDE will pick up again: talking to Aaron over coffee was somewhat inspiring, although my life over in portability land and sometimes QA doesn't seem to allow me much space for "fun" hacking. Maybe I need to think outside the containment more.
thomasz just posted a link to this email from a KDE-on-Kubuntu user. Honest and heartfelt, it's one of the most beautiful things I've read in a while.
The person writing, Robert, bought his daughter a computer for her 14th birthday. He got what they could afford, and due to financial constraints that meant not much. Price often isn't the compelling selling feature for business users in the "first" world (gah, I hate that term), but for many others it is. In this case, it made all the difference. The best part is that this family is not getting cheated because they don't happen to have endless amounts of disposable income: they get to participate on their terms without limitation.
So just what difference does free-as-in-freedom software make? Robert speaks eloquently and clearly:
"I cant tell you how much I appreciate
the work you all have done. Its a work of art. If I could thank each and every one of
you I would.
You have given her the world to learn and explore.
So if you get frustrated or tired in
your work for Open Source/Free Software, just remember that somewhere in Missouri
there is a 14 year-old girl named Hope, an A-student who runs on the track team,
who is now your biggest fan and one of the newest users of
Linux/Ubuntu."
If you are compiling kde strigi analyzers and installing them into a different path where strigi is installed on, you should be aware that strigi won't find your kde analyzers unless you instruct it to.
Let's say your strigi is in /usr, so it is looking for plugins in /usr/lib/strigi and your kde is in /home/kdesvn/installed/ so the KDE strigi analyzers are on /home/kdesvn/installed/lib/strigi.
You should define the environment variable STRIGI_PLUGIN_PATH to /home/kdesvn/installed/lib/strigi:/usr/lib/strigi
That in case you use strigi 0.5.9 that supports more than one path to be defined in STRIGI_PLUGIN_PATH, in case you are using 0.5.7 like Ubuntu users, you are out of luck as STRIGI_PLUGIN_PATH can only be one path, so you might want to define STRIGI_PLUGIN_PATH to /home/kdesvn/installed/lib/strigi and then go there and create symbolic links from all the ones in /usr/lib/strigi.
Anyway if you are using Ubuntu strigi your analyzers won't work because what seems to be a packaging bug.
So, as a final follow-up to my desperate out-cry, I've solved problem #2.
I’m still learning the power of gdb. It’s an immensely useful tool for debugging programs (funny, that…).
Today I wanted to find out the contents of a QString. “print s”, where “s” is a QString, doesn’t do much for you, though. The data is stored as an array of ushorts inside a shared data member. But all I want is to print out the string as it would appear if I did “qDebug() << s”, for example.
Solution: head over to the kdesdk module, and into the scripts directory, where mountains of useful bits reside. The script you want is kde-devel-gdb.
Now copy this to your home directory and put the line “source ~/kde-devel-gdb” into your ~/.gdbinit file. Or, if you’re building KDE in the manner prescribed on techbase, you can just put “source /home/kde-devel/src/KDE/kdesdk/scripts/kde-devel-gdb” into your ~/.gdbinit file.
To use, check out “help user-defined”. For example, to print a QString called s, type “printq4string s”. Ta-da!
Never forget how important it is to communicate through SVN....
Recently there was a short thread on kde-devel@ about how one should go about obtaining some form of record of activity within KDE. Immediately svn log seemed like the obvious choice. svn log is usefuil for all sorts of stuff.
How often have you looked at a piece of code and not understood it (at least in part)? It happens quite often, right? Generally when this happens we get a reaction which can be neatly placed somewhere on the hackers' scale of dismay:
svn log can be a great way of getting to the bottom of problems like these. This is not far removed from how I do a lot of my research... I think I have mentioned in the past how much empirical research can end up being like trying to solve a mystery. Well the clues are in the log....
For research purposes it is much better to get an XML log: svn log --xml, they're easier to parse. Each entry looks a little like this:
<logentry
revision="1">
<author>cajus</author>
<date>2005-04-18T12:46:46.376283Z</date>
<msg>Initial checkin. CVS conversion did not work :-(
</msg>
</logentry>
The "revision" tag is simply a unique ID.
The "author" tag is, of course, useful for gathering who did what. From the research perspective there are ethical considerations here. This tag is also helpful where individual effort is important but identity is not. In all of my research I generally throw this info away as I am interested in team effort, not individuals.
The "date" tag provides a decent timestamp of the moment the SVN server performed the transaction. Note: this is not neccesarilly the time at which you make the commit.
The all-important "msg" tag. This is the message the committer types into their editor when they do svn ci
This last tag is massively important; for researchers and hackers alike. What we type into our commit messages can be incredibly important later. They should help us understand what was done and why.
I recently screamed WTF!! at piece of code in the SQO-OSS project. It was crazy stuff and totally incomprehensible. svn log was massively helpful explaining what was going on.
Not least of which, it let me know that it was actually my own code I was annoyed with.
Last May 2, 2008, Ubuntu users from all over Metro Manila gathered for what was to be the Ubunu-Ph Hardy Heron Release Party. Ok, so it wasn’t really a release party in the strictest sense of the term. For one, there were no Hardy CD’s going around (except for a burned Kubuntu DVD). And there was no beer! (But lots of caffeine to go around). Nevertheless, it was still lots of fun and an event worth remembering, and most of all, repeating.
We really didn’t have a concrete plan of where to go and what to do. And most of us will only be meeting each other in real life for the very first time. So it was decided earlier on to meet at McDonald’s first (Filipino time, anyone?). There was free wifi at McDo, but only one of us had the pleasure of being able to connect, allowing us to monitor the IRC channel and forums for anyone who needs to catch up. Once we’ve waited long enough, we “formally” opened the release part. And then came the most important part of the event: Dinner!
But of course we had to take a picture first 
We decided to have a taste of some Filipino cuisine, so we headed over to Max’s Restaurant over at SM Megamall. Besides, it was more “affordable” than the nearest alternatives. You know how us geeks love to save up (for our next toy, of course).
What the pictures will not show is our mystery Php 400.00. When the time came to pay the bill and every one had chipped in, we had an excess of Php 400 which no one claimed to own. To this very day, we still don’t know where it came from, nor has anyone reported it missing. We just decided to put it into our community fund which we later put to very good use (as you’ll see later).
With our digestive system full and hard at work, our next task was to look for a place where we could lounge around and socialize. Of course, WiFi was a necessity… and enough room to pack 10 people with their laptops. After searching near and far (or actually, just far), we ended up at a quiet place in Ortigas Garden called The Coffee Bean and Tea Leaf. Fortunately, there was room for us inside the air conditioned area.
Once we settled down (and some coffee have been ordered), we proceeded to bring out our laptops and try to enjoy the free internet. And that’s when the fun started. Ironically for an Ubuntu release party, none of us could actually get online. Fedora could connect and so could Windows (yes, that would be me using Windows in one of the pics). Eventually, we just gave up trying to figure it out and just enjoyed the coffee (why was my iced latte still warm after an hour?) and the biscotti (which we paid for using our “community fund”).
Anyway, we mostly spent the night talking about many different things, laughing at/about Linux or Ubuntu not being able to connect to the Internet, and other little things. Soon, those who were unfortunate enough to have either work or appointments for the next day started taking their leave. But some of us chose to stay behind, either until someone gave up or until we were kicked out of the shop for closing (which was at 02:00). It was survival of the fittest! It was only when we had reached that state of sublime consciousness called “sleeplessness” that we started talking about more serious FOSS-related topics, such as problems in free software advocacy and acceptance in the Philippines, other local Linux distributions and communities, local FOSS and Linux events or conferences, as well as about organizing the next Ubuntu-PH gatherings. (Mental note: we have to follow that one up).
All in all, the event was a relative success. Even without beer, pizza, or Ubuntu-compatible WiFi (anyone knows of a place that serves all three under one roof?), I am sure that being able to meet fellow Ubuntu users and giving faces and voices to the nicks that we see in IRC channels and forums makes the experience truly worth it.
Thanks to everyone who joined in on the party and we hope more will be able to make it next time. We are all looking forward to the next gathering that will bring free software advocates together, be it an Ubuntu release or any other event. After all, communicating with each other, making friends, and building up communities is one of the things that make FOSS really great and really human.
View all pics on Jucato’s Gallery or Nap’s Flickr (until we can decide where best to put up Ubuntu-PH pics).
We still don’t know where the Php 400.00 came from…
Special thanks to Jeff (punong_bisyonaryo), Marlon (strong007), and Nhatz (nhatz69) providing the pictures.
[KDE Users: Have no fear! KDE was adequately represented by Nap Ramirez and myself, showing off KWin 4’s fancy and very useful Desktop Grid effect, even if I had to use Windows to be able to go online. :P]
so tonight i was thinking/daydreaming a bit. daydreaming is a very underrated past-time / skill, imho. anyways... i was thinking about laptops and it occurred to me that i'd love a laptop with two screens: one where it usually is, and one where the keyboard is. kind of like a great big nintendo DS.
the "bottom" screen would be a multitouch surface so that i could put a keyboard there. when the keyboard layout switched, the keys could actually change. the touchpad would also be on the "screen", and though could simply be "put away" when i didn't want it (e.g. when i have a mouse plugged in). perhaps it could even autohide when i have a mouse plugged in? hm.
best of all, those "multimedia buttons" could be replaced with real software. i'd be able to put any set of buttons i wanted there. perhaps even the toolbars from apps. imagine how useful that would be in a word processor! no taking the hands off the "keyboard" just to swap fonts or paragraph style: just reach up and press the font or style combo and it would pop down over the keys.
you could have a volume button somewhere that would popup an actual volume slider ... you could put useful widgets, such as perhaps a news, weather or stock ticker above the keys. or put the taskbar there for easy switching between windows.
the possibilities are limitless.
i googled for something like this and found this year+ old story about a vapourware laptop. the logitech G15 seems to come sort of close, but misses by not going all the way and replacing the whole thing with a dispay surface. oh well.
thinking about it some more i suppose it's probably not overly realistic to expect such a laptop to come about until we have something better than today's batteries for portable power (fuel cells?).
but still .. damn. it would be sooo cool. one more place to play with plasma ;)
speaking of which, the new krunner ui is coming along nicely and the dialog-less panel config is downright awesome. i'm trying to schedule time for a screencast this week so i can share it with everyone who isn't tracking svn (or, in the case of the krunner ui, the git repo for it)
This is what you might find at Akademy 2008...
More info on Akademy 2008 on http://akademy2008.kde.org
So this evening we set out excited and anxious for the Radiohead show. The venue was 45 minutes away (+30-45 minutes in weekday traffic which we didn’t have since it was Sunday). Torrential downpours screwed with traffic and the roads, with the police redirecting traffic all over mother earth, basically in circles around the arena. 3 hours later, we turned around having been 5 miles from the arena for the last 2 hours. When we turned around, it was already 1 hour in to Radiohead’s set (we had called to see if the set would be postponed because of weather) and we still had 3 miles to go, then park, then get in to the arena. Basically we would miss the show regardless of our actions since Virginia has noise ordinances which requires shows to be over by 11/11:30PM. There were still hundreds (not exaggerating) of cars lined up trying to gain entrance to the arena and park when we turned back to go home. The lady on the phone said to call the Box Office tomorrow about refunds (I’d like to see pictures of how empty the arena was).
No Radiohead tonight. BOO
Trueg is the KDE-Nepomuk dude, and has been running a few cool blogs, for example about Nepomuk Virtual Folders - The Next Level, We Don't Search... and Fetch, Nepomuk, fetch!
Tagging is the future. Overcoming typos in tags, synonyms is a conflicting feature, but does not limit the wide applicability of being able to tie information together. Now, Nepomuk is a bit strict on the type of metadata allowed, which is why Strigi has a super ontology (as in super set), to which we can add chemistry bits.
I have yet to install KDE 4.1, assuming that a good deal of truegs work found its way into that. At least, the virtual folders bit, I hope. But just imagine tying together PDFs, PDB entries, etc, I have on my desktop, all belonging to a diabetes, by just typing this URL: nepomuksearch:/diabetes.
On a different note, this tagging if available in Kmail would provide a powerful approach to organize the processing of my inbox; I can tag emails with todo, toreply, toread, toarchive, ...
Oh, and let me squeeze in this statement too (sorry, jriddel) : Kubuntu 8.04 has required me to tweak to work around bugs than any other previous Kubuntu release. Things tend to be encountered by others earlier, so that Googling generally helps sufficiently. But missing dependencies is a bit ugly (sorry, forgot which program it was, so can't link to the bug report). And, still am a happy Kubuntu user!
There was a TODO on KPluginSelector. Internally is a beautiful mess. Is where you had to add some widgets inside itemviews and there was no “right way” of doing it. Since Goya will be probably moved to kdelibs this friday if everything goes OK, I recalled this TODO and have started to rewrite it. Very few code has been saved from the old version. Right now this has a very more useful face: plugins are sorted by title name, and you can actually filter with the search box that is above the list view. It also uses KCategorizedView. After Goya is moved into kdelibs, I will make the buttons come again, but using this library. This is all in my hard disk yet… so there is no public place where you can see it, but is amazing how the code has become this simple… You can take a look at couple shots:
Here you can see how plugins are automatically sorted by name:
And in this screenshot you can see the filtering working:
I hope this change will come for 4.2 version. There are no chances of 4.1 can come with this improvement before you ask me =)
I have been a happy user of a Lex Neo fanless server for a few years until two weeks ago, when it froze. It produced a continuous beep when I tried to reboot it, symptom of memory problems. It accepted to boot on an old 64Mbyte stick, but would not start on anything bigger :(. I left it running in this state until today, when it definitely stopped…
This tiny machine has been serving various duties at home, ranging from git server, backup relay to the (excellent) rsync.net service, file server, address book, note taker… and mail server, thanks to a combination of getmail, dovecot and spamassassin. This is where the story might affect you: Some of my email is trapped in the server for now, so you will have to wait even longer than usual for an answer from me.
I ordered a replacement one which should be there in the next week. Hopefully transition will be smooth and everything will be up and running quickly. Meanwhile I can answer new mail, so if you need a quicker answer, please send your mail again.
In two and half weeks the likely biggest Linux Event kicks off: LinuxTag 2008 in Berlin. Four days of exhibition and more talks (the organizers say 240, German/English mixed) than ever before. I plan to be around all the time. 
On Wednesday everyone's darling, the multi-headed president of KDE e.V. and the galaxy, Aaron Seigo will give a keynote about KDE4. On Friday is a day-long track with KDE talks, on Saturday is openSUSE day and there are separate talks about Amarok and Kontact planned. Additionally there will be of course KDE and openSUSE booths all the time.
Special tip: one can travel for 59 Euro from everywhere in Germany with ICE to LinuxTag/IT Profits and back.
All KMail users will know this widget to setup their signature:
Yesterday evening I moved this widget to kdepimlibs. One of the few classes within KMail that can be moved without untangling at least 40 other classes.
The result of that move and integrating it into Mailody means that Mailody gained support for signatures coming from files or from the output of a command.
Then I looked at the KRichTextWidget which is now in review. I know the author will give more info about it in one of the next digest, so I won't spoil all the fun, but basically it is the start of a wysiwyg html editor for KDE. I decided to implement that in Mailody's composer. That means that from the moment the class moves to kdelibs, it will be possible to send html-mails from within Mailody.
Integrating it in the sending parts of Mailody was easy, as Mailody already had the option to automatically send a html-part of the message with each message. For those wondering: yes at the first glance it seems perfectly possible to reply to html-only mails too, the formatting will stay preserved.
After that I went back to the signature configurator, there it is also possible to insert HTML code by hand and use that as a signature. I decided that it would be good to have the wysiwyg editor there too.
So, that means it now looks like this:
The beauty of it, is that KMail automatically also gets this. Sharing is great. It also means Mailody got complete HTML support now. I need to tweak some things whenever the class is moved to kdelibs, but the hard work is already done.
So you think Ken Lee is the best Internet meme? Hold on, you haven't seen Benny Lava yet!
Just want to point out four improvements of the YaST Qt package selector in the upcoming openSUSE 11.0 that were missing too long, much requested (at least by me) and now added :
The first screenshot shows the new special package groups "Suggested packages" and "Recommended packages" to list packages which enhance your installed packages. Also the strange "zzz All" package group of previous releases is renamed to "All packages" and visible without endless scrolling.
On the second screenshot you can see the new "@System" meta repository to list all installed packages only. And note the new secondary filter "Unmaintained packages" to detect which packages are not contained in your activated repositories (also a nice way to detect which old packages were wrongly not obsoleted by a distro upgrade).
Almost everyone at LGM is using Gnome -- there are few KDE desktops to be seen. And no KDE4 desktops at all. Until now: Dave Coffin of DCRaw fame uses KDE4! And XV -- ages since I last saw that.
Dave's presentation was another very satisfying, very technical and deep presentation. This year had quite a good mix of presentations at different levels.
For the third day of Libre Graphics Meeting 2008, there were two presentations from people coming from KDE: Emanuele about colors, and Gilles about Digikam.
This picture was taken near the conference center, when we tried to go to a Japanese garden.
I'm just following up on my last post - thanks to everyone commenting!
Regarding points #1 and #3, this was compiz running and wm. I'm back to kwin after having removed the file $HOME/.kde/share/config/compizasWM.
For point #2, I'll deal with it as well, but is seems to be an issue in the proprietary ATI driver's package. When changing to the free ATI driver I cannot get the resolution I want (I admit - I did not hunt for mode lines for very long).
git-svn is a wonderful tool. It allows me to have the flexibility of Git in a Subversion environment.
One downside I mentioned in my blog some time ago was that it didn't scale well with larger repositories (huge amounts of diskspace). But that was version 1.5.3.x. I can tell you this has been fixed in the 1.5.5.x series.
So now I'm using this tool for a real project and getting more and more experience with it. Because git-svn isn't a trivial command, it requires some discipline from the user. This is because Subversion has no notion of a non-linear history, so you have to be careful with merging back your changes. The dcommit subcommand will choke when you're trying to commit merge points.
Here I'll describe how you can accomplish certain branching tasks with git-svn, such that the history remains linear. It assumes you're already familiar with checking out Subversion repositories with git-svn. If you're not, I think Flavio Castelli's posting is a nice introduction.
Branching
To prevent hassle later on, it is recommended to start a branch from a commit which is already written back to SVN. Consider the following histories (where lowercase characters are commits already in SVN and uppercase characters are local commits in your Git repository):
o---a---B master
\
C---O topic
and
o---a---B master
\
C---O topic
If you're going to dcommit the master, things will look like this afterwards:
o---a---b master
\
B---C---O topic
and
o---a---b master
\
C---O topic
As you can see, the topic branch got polluted with the original Git commit B. This is because git-svn rewinds the history till the last checkpoint and re-applies all commits afterwards. B is preserved because it's the parent of C. And a is the parent of B, so now the history of the topic branch looks exactly the same now as before.
In the second case, the history of the topic branch also remains exactly the same. But because a wasn't touched during the dcommit, the topic branch didn't get polluted with Git commits.
Having two different commits in your repository doing the same thing (B and b) is undesired. B may even be completely unrelated to your branch. When you want to merge your topic branch, you only want to take care of the intended changes, not changes that already found their way in. So it's better to keep that kind of commits out of your branches in the first place. That's why you should better branch at commits which are already in SVN.
In case the master's tip is on B and you want to start a new branch with a as parent, enter:
git branch topic2 a
Or you can dcommit B into SVN before starting a new branch, taking the resulting b commit as parent.
Merging
As written above, SVN cannot handle non-linear history. Therefore, you shouldn't confuse git-svn with a normal merge, causing a commit having more than one parent. But the merge subcommand offers the squash option to work around this:
git checkout master
git merge --squash topic
git commit
It collects all commits in the topic branch until the branch point and makes one commit from it, applying it on the tip of the master branch. The tip of the topic branch remains untouched (in a Git frontend like qgit you'd see there's no path back to the master branch). If you're no longer interested in the history of a merged in squashed commit, you may delete the topic branch once you've committed your changes:
git branch -D topic
So this is my workflow of using Git and Subversion, and it seems to work quite well for me. If you have suggestions or additions I'd like to hear that.
Colour is a big topic at the Libre Graphics Meeting. Today, Kai-Uwe Behrmann will speak about his Oyranos project. Yesterday, it was Emanuele Tamponi's turn. Emanuele presented his work on the Kubelka-Munk colorspace. His presentation went very well, even though some of the less mathematical-inclined people left at the third slide with formulas. I was glad to see, however, that there are a number of rather more in-depth presentations at this LGM.
Showing off the mixing algorithm in Krita
Emanuele discussed the research in the field of pigment representation and his totally new roundtrip conversion method for going from RGB to a realistic pigment colour representation and back with a high degree of realism and fidelity. There are also way more applications for his work than just the colour mixer in Krita.
Emanuele discussing the finer points of colour theory with SVG guru Chris Lilley
Just like last year, it's a really great conference. It's mostly meeting up and talking and getting to know each other, but there's also real, hard work being done. Gilles Caullier from Digikam fame presented the current and future Digikam and has started all kinds of cooperation with other photo handling applications.
By the way, this is my hotel room:
But Wroclaw is a city with many beautiful spots. We had a nice walk with the Scribus people last night, ending up at a restaurant next to this arch: (which Alexandre Prokoudine was nice enough to photograph for me):
Yesterday we took a walk with Udi Fuchs from UFRaw, his girlfriend and a random collection of other hackers to the Japanese Gardens, which unfortunately was closed, but I managed to make this picture of the Centennial Building, built when Wroclaw was still Breslau:
