If you happen to be in Bremen, give Sushi Factory a try. It is located right in downtown (see on Google Maps) and easily reachable. The soy sauce is a bit salty for me, but otherwise everything else if fine. The place is cozy. The atmosphere is relaxing. The rolls are of course tasty although they are rather not so cheap. Still, there is a nice bargain for a lunch pack.

2007 was probably The Year Of Free Graphics: AMD/ATI’s specs, a new totally Mesa , output hotplugging via XRandR and the announcement of new shiny OpenGL specs. While this all was truly great, the OpenGL releases never happened, and there are no updates on the topic.

Graphics in Free Software were always a difficult topic in former years: specs for many hardware bits were missing, proprietary drivers often didn’t support new hardware for several months, the graphics API (OpenGL) was seriously falling behind Microsoft’s competing API (DirectX) in terms of features and hardware support and last but not least the main free implementation of the API, Mesa, was hopelessly outdated.

But this all changed, and many important changes were in 2007:

• XRandR made output hotplugging possible
• Mesa was released in version 7.0, finally bringing OpenGL 2.x support to free graphics drivers
• It was announced that the OpenGL API would be released in a cleaned up version as well as a total new version pretty soon.
• ATI/AMD made an impact by releasing proper and detailed documentation for their graphics hardware

While this list is indeed impressive, there is one big gap: the announcement of the new OpenGL specs. These never happened. Not even a cleaned-up version of the current OpenGL API ever came up anywhere. And, although it was said that the communication with the community would be improved there aren’t any information available about the current state. In fact, all possible channels are deserted. The only bit of information available is a post by Barthold Lichtenbelt (OpenGL ARB Working Group chair) in the OpenGL forum dated end of October 2007 stating that the development of the next spec faced difficulties and that the release will be delayed:

The OpenGL ARB found, after careful review, some unresolved issues that we want addressed before we feel comfortable releasing a specification. […] None of these issues we found are of earth-shocking nature, but we did want them discussed and resolved to make absolutely sure we are on the right path, and we are. […] The ARB meets 5 times a week, and has done so for the last two months, to get this out to you as soon as possible.[…] We don’t want to spend time fixing mistakes made in haste.
[…]
More details will follow soon in an upcoming OpenGL Pipeline newsletter.

Of course unresolved issues can turn up. But in such cases a vital part of maintaining a community - and also a stable customer base - is to deliver more information from time to time. And it is important to state schedules as soon as it is possible. If something is difficult, than that must be stated. Communication also means to say something from time to time just to show: we are alive, we care.
But the OpenGL team has failed in that regard: the mentioned OpenGL Pipeline newsletter is totally outdated and therefore a joke, and the forums don’t contain any other official post explaining the situation.

I’m pretty sure that there is work going on behind the scenes - there are many different parties with a vital interest to ship a next generation OpenGL. But the total lack of communication, the inability to handle basic communication principles in the right way is depressing. OpenGL is not only a technology, but also a product, and if the product is managed that bad it can’t be good for the technology.
Also it leaves the sad feeling that, in respect of the API, the free graphics ecosystem is still back in the old days.

Earlier today we released Avogadro 0.6. This release is quite overdue and we had originally planned to make a release around the new year. This release has many, many new features that have been implemented since the last release.

I am especially proud of the new support for displaying surfaces. This initially led to the surface engine that displays a Van der Waals surface. Tim added the ability to map the electostatic surface potential onto that. I then began work on adding support for displaying orbitals. This led to me getting commit access to OpenBabel and making quite a few commits as I got Gaussian cube loading working. While I was there I couldn't resist improving the Grid classes (still a little more I would like to add in).

Another new feature I am really pleased with is the QGraphicsView based periodic table. I think it works very nicely and I am hoping to add this code to Kalzium. I think the Avogadro library is in great shape for me to begin porting Kalzium to use it. Tim and Geoff have been doing some amazing work in OpenBabel on improving the force fields used for geometry optimisations.

We have also been doing a lot of work to improve Avogadro's performance when rendering large systems. We have added quickRender functions and OpenGL display lists to improve interactivity as well as threading calculations where this made sense. We have a cool little colour widget Geoff coded too that allows colours to be displayed and picked easily, improved default layout and one of my personal favourites - persistent settings in most of Avogadro.

There are certainly some bugs remaining. I would like to get to the bottom of as many as I can and hope to make one or two bug fix releases in the 0.6 branch. We would love to get feedback from people. We have already made a source release and a Mac binary. I will be adding Gentoo ebuilds shortly and we will hopefully get a Windows binary out by early next week.

Hope you enjoy this release. I think we are getting close to a stable API that we can call 1.0 and have most of the core features I was hoping to get into Avogadro. Our framework is extremely modular and extensible and I hope that we will be able to build up a community around Avogadro. It was also great to be able to make this release on 29 February - we have so few of them

Additionally to the migration path for PIM applications there are similar options for the actual data access facilities, i.e. the addressbook and calendar plugins traditionally used to access PIM data in local files, groupware servers and so on.

In the Akonadi universe this task is handled by programs we developers refer to as Akonadi resources.
Based on a suggestion by Till Adam, I created two such resources based on our traditional data access plugins, one for addressbook plugins and one for calendar plugins.
This should allow us to port the functionality currently implemented by our traditional plugins one by one and it also decouples the porting efforts of applications and storage facilities.

The following image shows three setups: one for each "end" of the transition and one intermediate step based on the example of an addressbook storage on a Kolab server

(click here for full size)

• Traditional setup

In the traditional setup based on the KResource framework, each application would use plugins to access the storage device directly.
When compared to the other two setups is looks a lot simpler and it in some way it is. However this approach is also more primitive, a lot of work is done multiple times, i.e. each application has its own connections to the Kolab server and each application is transferring all the data.

Migration setup

The main advantage of this setup is to fold the multiple instances of data access into one.
For simplicity of the diagram I assumed that the accessing KAddressBook has already been ported to use Akonadi natively, but of course it would also work in its traditional form using the "akonadi" plugin described in part 1.

Future setup

If your first impression of this setup is that it is less flexible than the one before because it does not use plugins any longer, be assured it is not. Different types of storage devices are now handled by their special resource handler program, where each of them can be specifically tailored to the capabilties of the storage device it is working with. Quite like plugins but with added bonuses like not taking down an end-user application in case of crash. Pretty much comparable to how KDE has been using KIO slaves for document centric data access.

If your second impression is that this setup introduced overhead because its resources are processes of their own, be assured it does not.
Both the traditional and the migration setup require one plugin per type of PIM data and storage device, potentially resulting in more than one connection per application to a remote storage, whereas the new kind of resources can handle all their storage device supported types simultaniously.

Btw, a similar approach could also be used to create a migration path for applications currently using libedata-book and libedata-cal, i.e. applications currently using the Evolution Data Server as their storage service. Ideally using a GLib based Akonadi library similar to our libakonadi, but since these applications already expect to communicate with a local server, one could also implement an Akonadi agent using libakonadi that just "look" like EDS protocol-wise (probably using the D-Bus based EDS implementation Ross Burton created for the Embedded EDS)

I've always thought it a pity that the krita.org domain was already taken when I started hacking on Krita. Originally it used to be the abandoned gallery site of some artist; now it's occupied by a domain squatter. Still, it was taken.

But having a Krita website could very well be a good thing: I've frequently heard remarks along the lines that someone either would never have expected a decent graphics app to be hidden in an Office suite, or even from people who flat-out refused to use Krita because it had got office-cooties.

Enter... krita2d.org. Wait! Don't click that link yet! It's empty...

Someone suggested tacking on the 2d suffix to Krita to show that Krita is about 2d painting -- something I liked so much I grabbed the domain. I might even consider renaming the application with the next version. The website is graciously hosted by the same people who host the koffice website.

But getting the domain and asking for hosting is all I have had time for: I'm really looking for a volunteer who can take the material we've already got and the texts prepared by Valerie and create a website. I guess any kind of cms or php system can be installed -- a wiki with a nice stylesheet and some accounts might be best, even.

So, if you want to help setup the Krita2d.org website -- please mail me: [email protected] or join us on the #koffice irc channel (if not afraid of office cooties) or on #krita2d.

These past days I got contributions to KDE-Edu applications and that remainded me how Educational applications are different from other applications in the sense that they need data.
Pavol Pitoňák sent 5 KTouch keyboard layouts. KTouch changed the way keyboard layouts are done in KDE 4 and thus all layouts need to be redone (there's a keyboard layout editor integrated in KTouch but still you need to update keys and it can be quite tedious). Thanks a lot Pavol for these contributions!
Amine Say sent me the KLettres alphabet sounds in Arabic. Recording sounds is a difficult task as you need clear pronounced sounds. These sounds are integrated in the Arabic l10n module so all Arabic KDE users get them and they are also available via KNewStuff in KLettres.
I tested the sounds and got Arabic l10n module to further test in RTL mode. The kids theme did not accommodate the letter too well so I pushed the bear to the right a bit in the SVG background theme.

Very impressive work, thanks Amine. KLettres has now 19 languages sounds. While being quite a simple program, it's nevertheless efficient and liked by users.
I detected a couple of bugs in KLettres in the process and refactored a bit the language detection code. The program needs to scan for globally installed sounds and locally installed ones (via KNewStuff) and then to update the Languages menu with corresponding languages names in the correct user language. A crash occurred when somehow the current chosen language was removed by the user. In programming, there must always be a fallback of some sort, an index cannot be equal to -1 for example...

As some bits of poetry are causing mystification (but fortunately not slowing the rate of plasma development) here is the full disclosure. The lines are by Shel Silverstein, author and musician. They are quoted from his book Where The Sidewalk Ends (or perhaps one of his other children's books), which has left an indelible imprint on my soul for being both silly and deep. Here is the complete poem as I remember it:I am writing these lines
From inside a lion,
And it's rather dark in here.
So please excuse the handwriting,
Which may not be too clear.
But this afternoon by the lion's cage
I'm afraid I got too near.
So I'm writing these lines
From inside a lion,
And it's rather dark in here.Although Silverstein is connected with with silly poems in my mind, it seems he made quite a career as a singer-songwriter as well and drawing cartoons for Playboy. Multi-talented. For people with a giraffe fixation (you know who you are), here's another one by Silverstein:Please
do not
giggle
and pl
ease d
o not
laugh
it's n
ot eas
y to w
rite o
n the
neck o
f a ru
nning
giraffeYou will just have to imagine the illustration yourself. I hope this illustrates also that the KDE community is an amazingly varied bunch, with interests in ancient instruments (I once met a UNIX sysadmin who had a career as a church-organ-builder behind him) and port wine and giraffes.

PS. Qt 4.4 is going to rock on Solaris, it just needs some gentle encouragement. Thanks to the Trolls who respond to my grumbling. Backtraces where relevant are forthcoming. I'm upgrading and patching the compiler to the latest and also carefully rebuilding all the dependencies before complaining again, because I don't want to send us too much on a wild goose (The Flying [[ something ]] , illustrated with a goose, is another poem of Silverstein's) chase. It might be dirty build environments causing problems, and I want to avoid that. I've already fixed one kerberos corruption deep down in our software stack this morning.

Thiago has set up the KDE Summer of Code 2008 ideas page. Thanks!

I've put some ideas on there (far more than I could possibly mentor), and I'd like everyone else to do so too. The reason is that ideas are fairly cheap, and we need to get students inspired. From previous years, some of the best ideas came from students (not from the mentors' list). In addition, just about every idea on the "list" had a submission (which was sometimes just the name of the idea).

If you have ideas, put them down. I'd like to see around a hundred ideas.

However please note the "fine print" at the bottom of the wiki page. I'll restate it here:
* Before making any modifications, please log in to Techbase. This will help us track who is contributing to the ideas.
* When making modifications to existing ideas, please consider whether you're changing it more fundamentally or just superficially. If your changes are substantial, you probably have an entirely new idea. Similarly, if your idea is modified and you feel it no longer reflects your original thought, please split the idea in two, restoring yours.

An idea needs to be more than a heading - if a potential student only needs the heading, then it probably wasn't really worth adding. The wiki page says:
* if the application is not widely known, a description of what it does and where its code lives
* a brief explanation
* the expected results
* pre-requisites for working on your project
* if applicable, links to more information or discussions
* mailing list or IRC channel for your application/library/module
* your name and email address for contact (if you're willing to be a mentor)

If you want to be a KDE SoC student in 2008, then you can do a few things to help yourself. Things to think about:
* SoC is a job, and you are basically going to have to write a job application. Start the process early. Last minute work always shows.
* Experience will help - you will help your application and your progress if you have a working KDE4 environment.
* At least basic C++ and Qt skills are going to be required for most KDE programming projects - make sure you've at least completed the Qt tutorial.
* Good jobs often come from knowing people, who tell you about things that you might not otherwise be able to find out. Getting known inside the KDE community (e.g. at least subscribe to the mailing list specific to your chosen project) is almost certainly going to help, as long as it isn't for something really bad (like poor behaviour).

Good luck!

since lions have already been done, i decided to hop inside a wallabee wallaby for this one. i'm sitting in its pouch typing away. yes, i am that tiny, especially when i suck my gut in and hold my breath. the wallabee wallaby, however, remains unimpressed.

(if you're wondering what the above is about, so am i. i'd heard of jonah and the whale before, pinnochio and the whale, captain ahab and the whale (man, whales got such a bad rap in literature), dogs inside of snakes, snakes inside of airplanes and airplanes inside of naval vessels (to keep the free association there going) ... but not until now had i heard of ades inside of lions. once i had, though, i just had to get into the $PERSON in $ANIMAL bandwagon. i'm a hopeless follower. no animals were harmed in the making of this blog entry, though the wallabee wallaby continues to be unimpressed.)

my sleep schedule has been completely messed up this week. more so than usual. maybe it was the appearance of Zack. he has that kind of effect on people.

i took him to the airport this afternoon as he has a company meeting to be at in Spain. i'm hoping he'll come back to Calgary when he's done there, but that's all still up in the air.

the good news is that we made progress with quasar, huge progress with packages and webkit in plasma and ate tremendous quantities of kick ass vegan chinese food. you may not care as much about the last bit of information there, but without that .. there would've been less code written, so in a way you probably do care. (the wallabee wallaby has just informed me that it doesn't care and that i've got another five minutes for this entry, max.)

between sleeping (or, rather, often not) at the oddest times and being busy writing code and driving people to school, airports and what not i have been ducking communicating with people (so if i owe you an email or a phone call: sorry, i'll get to you over the next few days here) as well as avoiding doing that screencast. i really wanted to be able to show more of the cool things that we were working on actually working properly and what not, so kept putting it off. well, Zack's gone and things work so it's time =)

i'm going to ping Danny to see if he's interested in including it in the next commit digest. if not, i'll post it here instead. if he is, then it'll appear on the weekend in the commit digest.

in the screencast i show kickoff, installing plasma and webkit packages through the Add Widgets dialog, webkit based widgets (two kinds: one with plasma and one with MacOS apis) and a little bit of quasar stuff.

it's this kind of productivity that makes me ponder what would be possible if there was a little villiage somewhere that i and others like Zack could hang out in, enjoy good food and just hack on free software all day. well, enough pondering for now, my time in this wallabee wallaby is up.

good day, love and hugs.

As Google have announced the Summer of Code for 2008, I would rather like to see NX support finally appearing in krdc, KDE’s pet remote desktop connection client.

Back in 2006 I did a fair bit of work on an abstract client library for NX, and in 2007, Urs Wolfer did a fantastic job of cleaning up krdc and making it far easier to add a different backend to it. What I’d like to see is someone come forward this year and tie these two efforts together to make an unbelievably awesome NX client for KDE.

I’ve put up a preliminary proposal at the KDE SoC wiki, and I’m quite happy to mentor the project so long as the KDE demigods agree (Thiago?)

After attending Fosdem, Linda and I had a few days to spend in Brussels. On Tuesday, we went to the musical instrument museum. This was a really good experience, as they have 5 floors packed with instruments from every age and every corner of the globe, along with wireless headsets that lets you listen to music played by each.

The one thing that I found really intriguing was some of the old "self playing" instruments such as this organ.



This is in essence an early computer, capable of processing many instructions at once from a stored program. The mechanical complexity of it just boggles the mind. And a closer look at the actual "code" shoes just how painstaking a job programming it must have been.



I wonder if it was possible to buy additional "programs" once you had purchased the organ.... If nothing else, this shows that musical software has a long tradition, that we here at Amarok HQ are proud to be a part of!

And just to throw in a bit of Amarok related content. Today I have been hard at work fixing many ( most? ) of the crashes we experienced while demoing Amarok this weekend, so hopefully the upcoming demos at Cebit and OpenExpo will run a lot smoother!

What I really love about myself is that for some reason I can’t stop making really stupid mistakes. I know everybody makes them, but somehow I’ve got the feeling I’m doing much more than anybody else.

Latest two occurence are bugs in KDevelop3.5.0 (one of them being in probably all releases since 3.4.0). I mean how damn stupid does somebody have to be to

a) use 2 variables, one named line the other named sline in the same function and

b) then mix those two variables up, which results in this: Bugreport 158236

The other one was pointed out on IRC today, stupid logic mixup with the same code in the else-part as in the if-part of an if-else. No wonder that you can’t turn off the warnings in QMake projects in KDevelop3.

I only catched the last one “by accident”, because I usually read the IRC backlog when I wasn’t sitting at the PC for a while. This one probably wouldn’t have ended in bugzilla as apparently some people think its not worthwhile to file bugreports against KDevelop3.

Thats however not true, especially if you’re not using one of the unmaintained parts. But even then, no bugreport is always worse than a bugreport that gets closed as wontfix (or fixed in 4.0 which is not yet usable on a wide scale). Obviously the problem here is to know which parts are unmaintained. So here’s a (probably incomplete) list:

fortran, java, php, python (this one will come back for 4.1), sql, csharp, bash, pascal, kdevdesigner (short note: use the normal Qt designer, you loose almost nothing and gain a lot of stability), valgrind, fileselector (known to be pretty buggy), distribution packaging, texttools, clearcase, perforce.

I’m not saying that bugs (especially crashes and the like) against these components will simply rot, I’m just saying its unlikely that they’ll get much attention as we simply don’t have many active developers and need to work on KDevelop4.

Made me query for Krita on Deviant Art. Of course, that doesn't only return images made with Krita, but also images depicting young ladies called Krita and even a fantasy image set in a city called Krita and a picture some Swedish artist made with physical pastell krita -- but there's a lot more art made with Krita than I thought, and a lot of it is pretty good.

I'm not sure what the rules on Deviant art are -- whether I can link to pages with image thumbnails or not, so until I'm clearer on that, you'll have to click on the search link and look for yourself.

Achiest Dragon

AngelOfGod87

Auregann

-->

This entry is being written inside the Qt demo browser using webkit. It is only a proof of concept. If this were a real browser, there would be lots more entries like it.

Lurie provided me with the libQtWebKit.so and browser executables he had built (not using the KDE-Solaris build infrastructure)and these work. Not like a charm, because rendering is very slow (certainly when the machine is also under other load), but as usual: the fact that it works at all is a fundamental success that obscures superficial flaws.

By now kdelibs, pimlibs and base have built against my copy of Qt 4.4 (qt-copy), so I can also run konsole or konqueror. Konsole still has a number of weird flaws on Solaris, konqueror can't load kio_http (missing libraries to link in, probably an artifact of our link flags) and the display of the start page with the nicely rendered gradient borders is broken -- only the corners show up.

But, with this fundamental success, a nice desktop is only a 'pkill dtwm ; /opt/kde-4.0/bin/startkde' away.

One of the results of the weekend in FOSDEM was that I wanted to try CentOS. After downloading the DVD (5.1), the installation within VirtualBox went very smooth. It gives you the options 'GNome Desktop', 'KDE Desktop' or 'Server'. Although I'm testing it for the last option, I, of course, picked the second, just to see what it looks like.

After installation and the usual wizzard for the usual stuff, it started KDE 3.5.4. The panel at the bottom showed some icons to the OpenOffice.org applications and an icon for 'E-mail and managing calanders'. I clicked on it and... voila it started... EVOLUTION. Although I *might* understand that shipping Firefox as default browser instead of Konqueror ( not really, but ok ). I do not understand why they choose Evolution over Kontact. The rest of the KDE seems pretty standard.

Now it's time to find out what CentOS does differently compared to say Debian when used as a server and explore their tools.

Riddell posted the FOSDEM group photo and I labeled those I immediately know; one thing that is clear is that I didn't take the time to introduce myself to all the people wearing Amarok T-shirts. Nor did I shake Mike's paw. So it's basically "I know the KDE people in the back" and "I recognize the Amarok folk in the middle, but don't know who they are."

Bad [ade], no cookie. You can do better community building than that.

I am writing these lines from inside a lion,
and it's rather dark in here.

I really wanted to be able to write "inside a WebKit-based browser" for this episode of "Noun on Noun" blogification, but the stability of WebKit leaves something to be desired. That should be qualified to "of WebKit on OpenSolaris as compiled by the KDE-Solaris team, used in the demo browser in the pre-release qt-copy version," because otherwise it's not really accurate. The demo browser starts up, and will render at least the first page I ask it to (even fancy stuff, but not everything). A click tends to crash it, but opening new tabs is OK. YouTube doesn't work, darn it, and I wanted to watch "Heeeere fishy fishy" with Bert and Ernie.

There's various suspicions to track down: STL corruption or mixing (between Cstd and stdcxx), freetype mixing (between 2.3.5 and something entangled with Xorg, it looks like) or just something else. The debugger is cryptic in different ways from gdb, but produces nice backtraces. So we'll get it sorted, now that we have emerged from the phase of "get it to work at all" and are moving into "make it work well."

KDE Women at the KDE 4 Release Event in January:

Kubuntu at the KDE 4 Release Event in January:

Maryland Ubuntu Loco meeting in February:

Release often and early. But not too early, first impression stays. Besides the fact, that holding your code in a public repository is like releasing all the time, I feel now is the time where the mentioned two rules are getting well balanced for Okteta.

So I have set myself in release mode, removing and hiding all undone things, even if they look interesting and like some fun, and setting up a list of those things which need at least to be done for a good first release. There a quite a few, especially after looking at the requirements to move to kdereview. And that is target No. 2. Two targets, that might be one too much. But a release is simply a subtarget of moving to kdereview, so there shouldn’t be any conflicts, I think.

One thing to be done is making the licensing of Okteta complying to KDE’s licensing policy. Okteta was a GPL v2-only project until now. Trying to grasp the idea of GPL v3 I think I am comfortable with that license, too. So I am relicensing all code also to the version 3. But which one to use for KAboutData, it supports only the mentioning of one license? Oh well, there is the source code, here is my editor, this is the free hour.,. so a patch for support of multiple licenses is pending for review in the mailinglist kde-core-devel, please have a look.

But there is another problem with the “About…” dialog. It only mentions the top level program. What about all the libraries and frameworks used by it, which only make the program possible? In the case of Okteta, the code of the program itself are just a few lines, that wire things together. Instead all real functionality is delivered by libkakao, libokteta*, libkde*, libqt*, …, down to libc. Where do all those software modules and their creators get the credit?

Anyway, for now at least the new program-centric multiple-licenses-capable About-dialog for Okteta, like it is possible with the mentioned patch:

(Copyright since 2006? Yes, the first code fragments date back to that year. It was just this winter where I pushed things a little)

Today I'm fighting the annoying fight. Sometimes I get the feeling the fight is to get Qt 4.4 to compile with all the bits on OpenSolaris in spite of Trolltech. An interesting string snuck into Qt 4.4's configure with some recent qt-copy update, as it now says in the help message:WebKit is built if a decent C++ compiler is used.Something similar applies to phonon. Fortunately the command-line arguments to configure can be used to work around this (add -phonon and -webkit), but the definition of "decent compiler" is kind of weak.

I do realize that "Sun Studio 12 with stdcxx and the flags used by the KDE-Solaris team" is hard to test for. And since I ported WebKit to Sun's ancient Cstd STL earlier this week, I know what kind of ugly patches would be needed to support the indecent combination of Studio with Cstd. So I don't blame anyone, just annoyed to get the build broken like that all of a sudden.

Remember, punch your pillow, not the wall. Actually, I'll just try to whomp someone over the head with a pillow, that always makes me feel better (where is that picture of me in a pillow fight with some GNOME folk?). So here's some patches and explanation (is that pillow talk, then?):

One thing that always bites with Studio 12 is the way a const T is different from a T (and this is reflected in the name mangling, too). In particular, this means that declaring a method with a const T parameter and implementing it without the const gives you linking errors. Eventually, anyway. From a practical types unification point of view I think the distinction is useful and necessary, and it annoys the heck out of me that gcc ignores it. I hear there are long discussions about it on -core-devel, too. In any case, CLucene and Patternist suffer from this kind of little thing (as does WebKit and other places, but these two patches illustrate quite well and are self-contained).

Studio 12 can be quite stupid (or quite strict, depending on your interpretation) about disambiguation. Within WebKit, there's ample opportunity for confusion between String and QString, and Studio 12 just can't figure out what makes sense when adding a const char * to strings (either String or QString) with operator +. Patch adds explicit String() constructors all over; kind of ugly so not providing a separate link.

Strict math implementations don't give you isfinite() in C++ because isfinite() is c99 and C++ is based off the c98 standard (approximately; I don't feel like looking up the details again). Signbit is similarly missing. Fortunately we had this kind of fixes in kdelibs already, so coming up with them wasn't hard. JavaScriptCore suffers from this. Messy patch includes <ieeefp.h> and more such, no separate link.

I'm not sure if <cstdio> is supposed to do using std::fprintf; mine doesn't, leading to help generator patches as well.

There's more patches, some fugly just to get the job done, some almost acceptable as is; they can be checked out of KDE-Solaris SVN as they evolve. I just got one patch in from Paul F. dealing with qatomic -- it seems that gcc and icc get to use qatomic.cpp and everyone else shouldn't, but the logic in the .pri files isn't quite right. But we're getting there: I have Qt 4.4 designer up and running and now waiting for the next recompile (slow on a single core machine) to see if all the demos will work.