sorted by: recent | see : popular

Content Tagged with KDE + qt

In case you missed it, it is now official
Trolltech merges with Nokia

But do not be scared, my open source friends. This means that Qt and Qtopia will continue to be developed, and have even wider recognition that it is the greatest cross platform GUI toolkit on the planet.

More info here

I am sure there will be more press releases coming soon, so I won’t comment on anything else that might happen. But I can say this, this merger is a two way street. i.e. Nokia wants to learn from Trolltech and Trolltech can learn from Nokia.

What I wonder, is if Nokia can make a rubber boot for my phone. After all, it has been fairly rainy here in Brisbane this year.

Remember, “Trolltech has benefited greatly from the feedback the community has been providing while using Qt to develop free software. We respect the symbiotic relationship Qt has with the community and we wish to continue and enhance this relationship.”

So, keep on hackin’ Qt, Qtopia and Kde hackers, there’s good things around the corner!!

Well,
I start work for a different company today, namely Nokia. Perhaps you have heard of them? No? Well, they used to make rubber boots but now make phones. Lot’s of them. They have a few employees. Lot’s of them. and now, a few more, thanks to the (more or less) peaceful assimilation of Trolltech.

Am I worried? A bit. The management structure at Nokia is overbearing, not like Trolltech’s lean and mean machine. I doubt I will see the CEO of Nokia getting drunk and wrestling with engineers any time soon. I doubt I will ever be called to a meeting with him to pick my brain about community matters, much less even get an email from him. I liked that about Trolltech. The openness, the friendliness.
Hopefully my boss will stop wearing his shoes so much. He used to go barefoot a lot more than he does now. I liked that about him.

Today, I start work for Nokia, sitting in the same desk (I hope), loging into the same machines (I hope), and continuing my work from yesterday (except today is the BBQ beer fest.. wweeeeeeeeeee!), on the Qtopia SDK, on the n8×0 and Neo devices. I still get to work with the greatest multi licensed cross platform toolkit ever - Qt. I get to use the greatest and Kool Desktop Environment - blackboxqt! heh and also - KDE.

Best of all - I get a new phone and some Nokia schwag.

I, for one, welcome our new Nokia overlords!

I’m studying how we can add light and shadow to widgets and items. I want to hear what you think :-). So I’ll just throw out my ideas and see what happens.

Light and shadow are special effects that follow and decorate items, and affect how they are rendered, at the same time as they’re a bit different from regular items / subitems, or subwidgets. For both light and shadow effects, there’s sometimes a need to render outside the item’s boundaries and blend into surroundings. For widgets, we then need to do something to break out of the box model… to make that happen. For inside-widget light effects, we’re limited to what we can do inside paintEvent() or inside the paint() function. I don’t know about you, but I think both light and shadow effects should be primary citizens of the scene graph, which essentially means they are also items. Stack-above / always-on-top (overlays) or stack-below / always-below items (underlays?).

Here’s a flash video showing a sample of what I’m working on. This is based on Graphics View.

The scene consists of 150 elliptoid items with shadows, and one light source that’s flying over it. It’s a bit psychedelic; anyone who loves colliding mice will love this. Haha.

Let’s start with shadows. In 2D, shadows can be pretty simple. Shadows can be thought of as transformed filled outlines of an object with a dark semitransparent fill and possibly fuzzy/blurred edges, stacked below the object itself. It has an offset, and/or an angle. The offset can be fixed for all items, or relative to one or more light sources. Ideally two shadows on top of each other don’t make a darker shadow, rather they blend with each other along the edges. Exact shadows are expensive to do accurately, and in many cases they’re completely pointless because they’re hard to see in the first place; at least the types of shadows we foresee being used in 2D / 2.5D UIs… Extreme shadows are cool but useless, subtle shadows, however, to me, are/can be beautiful. There seems to be a “market” for simple stupid fast shadows (e.g., bounding rect / bounding region based), pretty good medium-speed shadows (e.g., shape based), and custom shadows. And possibly perfect shadows (e.g., based on paint()) but I don’t really think that market is very big :-)).

As for how shadows are stacked, the easiest way is to just say that an item with a shadow always renders the shadow before itself. This works fine for most cases. But as soon as sibling items come close, and one’s shadow renders on top of the other, it starts looking wrong.

Take 1: Sibling shadow overlaps	Take 2: Sibling shadows behind both

It would be nice if I could set a shadow on our favorite “Drag And Drop Robot” without having lower leg shadows cast on the upper legs, or a shadow from the left leg draw on top of the right leg. I can see the need for both, but what would the API look like? And how would the items be stacked? My solution right now is to add a special flag to QGraphicsItem called QGraphicsItem::ItemStacksBehindParent (the child and its children are behind the parent), which is certainly one step on the way.

The other thing is how the shadow is placed. I don’t know about you, but I hate it how some presentation tools rotate the shadow relative to the item when you rotate and item that has a shadow on it. A picture says more than a thousand words:

No Shadow follows item.	Yes! Shadow follows scene :-)).

It’s a bit complicated though because you want the shadow to follow the item, but you wants its offset to be done scene-relative. Turns out it’s just that the item’s local transform is prepended to instead of appended to the parent item’s scene transform. So I added a flag for that: QGraphicsItem::ItemBeforeSceneTransform. Btw this is just research, it’s not in Qt snapshots or anything.

Now light effects come in many different shapes and colors. Light can affect shadows, or it can just add a glow to an item. Light is typically represented by an abstract member of the scene, to which you can calculate distance and angle and apply a suitable effect to your item, or the background, and so on. In styling, we usually fake light big-time by just applying light and dark effects to our button bevels, or use pixmaps that look shiny and sparkly. Which, of course, is in many cases much faster than doing “correct lighting”. I recall once Zack Rusin and I were talking crap, I don’t know who brought it up but if the whole UI was a complex detailed 3D scene graph, lighting could come by itself (I think the discussion started with why buttons in RTL mode don’t have shadows cast as if the sun shine from the upper right).

For blend effects it’s also necessary to apply aftereffects that combine the source and destination. That can be done in two ways - either just via an offscreen buffer, or directly onto the destination device / framebuffer / or so. If we want blend effects I think we need some type of shader integration. Let’s not digress though.

So, ball in your court. What are your thoughts about light and shadow?

Earlier this month, we released the single, largest release of Qt since the 4.0.0 release two years ago. Qt 4.4.0 is the result of 10 months of hard work by the Trolls, including numerous distractions. And while it’s being digested by our clients and users, we’re working on Qt 4.4.1, which will include fixes for bugs that were already known at the time of the 4.4.0 release, as well as some that people have reported.

In the meantime, we take two steps back, to the 4.3.x series, and then one step forward: we’re releasing today Qt version 4.3.5. This release is meant for those who cannot upgrade to Qt 4.4.0 yet, but need fixes for some important issues. All of the changes done for 4.3.5 will be present in 4.4.1 and some are even part of 4.4.0 already.

This is the first time ever we’re doing a public release of the previous minor series. In the past, we’ve always stopped development of the previous minor series when the next one came out. Sure, we’ve done security fixes when needed and Trolltech Support continued to support clients using them, but we’ve never made a public release. So this is news for us too.

One of the main reasons that made us decide to release 4.3.5 was the sheer size of the 4.4.0 upgrade. Many customers are scared to take the leap. Not that 4.4.0 is a bad release — no, far from it, all indications so far are that it is a great release. (At least, the Trolltech head of Support hasn’t tried to kill me yet for it!) But nonetheless, we decided we would reassert our commitment to all clients and users despite all distractions, by providing them with one more 4.3 release.

If this proves to be a good thing, we may repeat it for the 4.4.x branch when Qt 4.5.0 is released, although we’re not expecting anything as groundbreaking for that release as 4.4.0 was. We also have two or three bugfixes up our sleeves in the 4.3 branch, which may lead to a 4.3.6 release if necessary.

Including the pictures of the Qt developer team again, since a few more people have been patched in.

Oslo team	Berlin team

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.

That’s the moment we’ve all been waiting for… or dreading. We’ve worked for long months getting it done and you’ve all been asking for it. Some of you even realised it has already been available for a few days, unannounced… And now it’s finally, at last, there!

Qt 4.4.0 is released

Last week, we had a sneak release to current customers. And now it’s on the Trolltech homepage for the world to see. To make your life easier, here’s a download button:

We’re quite proud of this release. It’s the most feature-packed release of Qt ever and certainly the largest release since Qt 4.0.0 itself. This release adds:

• The Windows CE platform
• The Phonon new module: multimedia integration
• The QtWebKit new module: web integration
• The QtXmlPatterns new module: powerful XML support
• The QtHelp new module: flexible help support
• The QtConcurrent framework: parallel programming
• A new network resource access stack
• Support for regular widgets on Graphics View
• Support for non-native windows
• Support for shared memory
• Support for inter-process semaphores
• Support for painting on auxiliary threads
• Support for atomic operations on integers and pointers
• Improved printing support
• A new Qt Assistant
• And much more, since I will never be able to remember everything we’ve done

Not happy with all of that, we’re also bringing you:

• A video showing our demos
• A downloadable version of the pre-built demos (Windows only)
• White papers on embedded development, web support, XML, user interface styling

Continuing with the tradition started with the past minor release, we bring you those who did the work:

Oslo team	Berlin team

Trivia: there’s someone on both pictures. Can you spot who?

I am writing now from the Trolltech booth at FISL, where the KDE contributors have also taken up shop. It’s the second of three days and I’m already very tired. I was very surprised by the toll that booth duty takes in such a large conference!

FISL (International Free Software Forum, in its acronym in Portuguese) is held yearly in the city of Porto Alegre, of the southern state of Rio Grande do Sul in Brazil. It is probably the largest South American event and one of the largest in the world. Yesterday I’m told there were 7000 people walking by and today it’s probably going to be even more, since it’s Friday. This is the first time that Trolltech has a booth here, but technically not the first that it has had presence.

At several points in time yesterday, we had our 3m x 3m booth packed with people listening to my ramblings (or Knut’s, or Helio’s, or Josef’s more constructive speeches). Questions ranged from people who wanted to know what Qt was and if it could be used for their application purposes (”Does Qt have forms?” or “Do I have to know C++?”), to people who were asking about Qt 4.4 new features, such as WebKit and Phonon.

There were also people asking about KDE 4 and its current state. Hélio had a nice presentation yesterday showing the state of things. Today, Kévin Ottens from KDAB is holding an introductory course to Qt4 development. Later on, there’ll be a KDE-Edu presentation by Maurício Piacentini (the KDE Games coordinator) and one by Andreas Hanssen on the future of graphics development in Qt. He says it’s Qt 4.6 material…

We also had people asking about Java and other languages. I was pleased to be able to tell them about Jambi, but I think I need to learn I lot more about it. Thankfully, Helio downloaded and installed Qt/Jambi on one of the demo computers here. It’s packaged by Mandriva, so it was a matter of a few commands only.

What amazed me was how much crowd two books and one Greenphone attract. Lots of people asked us when the Greenphone would be on the market — to which we had to answer that it’s already over. They also kept on asking if we were selling the C++ GUI Programming with Qt4 books we had on display.

Things to remember for next time:

• Bring A4 or A5 leaflets with information on Trolltech
• Bring a set of small loudspeakers so that the Qt4 Dance video can be heard

Greetings from Helsinki airport. I came back from my visit to Milan (thanks Riccardo for arranging the sprint, it was great to be there!) at around 02:30am this morning. Now I’m waiting for my connection through Frankfurt to go to Brazil.

I chatted with Thiago, who’s there already, and he said it’s a good 28C degrees in Sao Paolo right now. Here I am with my suede leather jacket, long jeans and a sweater, my suitcase has only black t-shirts in it, no sun glasses and no sunscreen, feeling pretty silly. He-he!

Milano was fun, I think I’ll want to sign up for more of those events in the future. My idle task was optimizations in QGraphicsScene’s sorting and transform code (I’ve managed a 15-30x speed-up so far, will submit changes to main/4.5 some time when I come back, see patch below). There’s still more optimizations to come, I think I’m just in the flow with this stuff now. Fun to help out with the port to using QGraphicsWidget, and also with some work we did to speed up the SVG cache. Sorry that I couldn’t stay for the API review. :-/

I’m bringing some feedback home to our team in Oslo:

* QtSvg could use some optimization work
* It would be very nice if QtSvg covered the entire SVG 1.1 Tiny standard
* I should write a blog or a Qt Quarterly article (or both) about tricks to make graphics fast / like device space pixmap caching for static content.

Now I’ve been in Helsinki, holding a presentation about our ideas for improving widgets, theming, animations and the like. Fun and interesting! And now I’m headed to Brazil to do the same. Wee!

PS: Apply to Qt it you have problems with performance with deeply nested structures in Graphics View: http://www.andreas.hanssen.name/scene-speed.txt (no warranty!)

Hello,

Some of you might know the generic geographical map widget Marble that is part of KDE 4.
As already stated in Torsten Rahns’s Blog I started porting Marble to Windows CE.
Since Marble is a pure Qt application and does not rely on OpenGL the port is pretty straightforward.
The main problems were memory constrains, because Windows CE 5 only supports 32MB virtual memory. And of course speed is another issue. I had to reduce the complexity of the vector data set, because there is no tiling implemented, yet, and all the vector data has to fit into memory. The bump map is also significantly smaller than in the desktop version.

And now Marble runs on Windows CE as you can clearly see:

Marble on Windows Mobile 6.0 (America)

The Marble port proves that Qt really allows to port fairly complex application easily from the desktop to embedded devices. In this case the new Windows CE platform. It is also a good test case for stability of Qt for Windows CE.

Marble on Windows Mobile 6.0 (North Pole)

Marble on Windows Mobile 6.0 (Afrika)

Marble running on a ViewSonic Windows CE 5.0 tablet, also powered by an ARM cpu.

Marble in full action on a Dell Axim

Another video of Marble running on a Dell Axim.

Marble running on a Fujitsu Siemens Futro A220 (x86)

The Futro has a 400Mhz x86 processor, which is the reason that Marble runs really fast even on a high resolution.

nice weekend.

Exactly one month ago, I blogged about three different Qt 4 releases in the space of two weeks, even though one was an alpha. Now, I’m happy to bring you to the Qt 4.4.0 Release Candidate, which you can readily download from our FTP servers and mirrors in the Open Source version, or from the commercial distribution server for our commercial licensees.

This is the last scheduled step before the final release. If all goes well, we’ll have the final packages out the door in more or less a month. In the mean time, our team will be resting and doing nothing…

Wait, no, just kidding.

As the name says, this is a release that we consider to be of release quality. While we still have a few outstanding issues we want to fix before the release, this release is good enough to be used for most tasks. In special, we’re interested in knowing if anything is broken as compared to previous releases.

We’re doing our best to anticipate the ways our product could break, but we can’t catch all cases. And as proven by our own final sanity checks this morning, it’s getting more and more difficult to do it. And there comes a point when you can’t think of creative new ideas to do it (pasting 1 MB worth of junk into line edits, for instance).

Here’s where you, dear reader, comes in. Please download the RC1 and run your Qt4 application with it. If you see things not working like they used to, let us know.

I won’t be talking anymore of the cool new features of this release. I did that one month ago and I’ll let our Marketing Team take over now. Besides, there are no new features since the beta. In fact, there haven’t been any since the Technical Preview, which was when we entered Feature Freeze mode. But soon we will have Qt 4.5 development start and Labs will fill again with blogs from developers about the CoolNewStuff™they’ll be working on, as well as information from our roadmap.

Snapshots

Some people have already noticed that there are changes in the Qt snapshots. A couple of weeks ago, we started publishing snapshots of the Qt 4.5.x tree (mainline development, a.k.a. “trunk” for Subversion users). We’re publishing those snapshots in the so-called “minimal set”: only the Qt/Embedded Linux, Qt/Windows CE and the merged Qt/X11+Mac+Win (the misleadingly called “qt-all” package) packages are published daily.

Also, last week, the Qt 4.4.x tree snapshots changed version numbers to 4.4.1. What happened there was that the 4.4.0 release was branched off for final fixes, while other development continues in what will become Qt 4.4.1. Our development process calls for a branch before public releases so we can do some intensive testing without many changes going in and potentially invalidating previous test results.

We use a lot of tools and applications when we develop Qt and Qtopia. Strangely enough, it turns out a lot of these tools are open source We’ve always been wanting to give something back to the talented developers of these tools, be it money or just praise. These tools make our working day better, more efficient and sometimes even FUN!

So, the engineers here are at Trolltech decided it’s time to have an annual award where we vote and select the best open source development tool available out there. In other words: The Trolltech Open source Development Award.

So here are the finalists for the 2008 awards. They’ve all been nominated by at least one Troll, so there is at least one person out there that loves your tool

The price will include money AND a signed T-shirt. But regardless who wins we’d like to thank the developers of the tools below: You make our day a little bit better. THANK YOU!

	Coding requires music. Music requires a player. This is the one.
	It’s everywhere. So are we. It’s a match made in well, maybe not heaven but pretty close?
	All the other revision control systems are easier to use - but this one is more powerful.
	When we don’t code we chat. But don’t tell management. (They use Mirc)
	Good looks and doesn’t nag you for every single thing.
	Editing for oldtimers. Some people just can’t move on
	Feature packed editing for Windows developers.
	Higher quality for the same bit rate. And you don’t have to pay royalties.
	Not everybody uses MySQL
	A must have if you work on several systems at the same time. Take your KVM switch outside, and put it out of it’s misery. We mean it.
	You can spend two days debugging, or you can just run Valgrind.
	Emacs sucks!
	Possibly the most beautiful way of comparing diffs on Windows.
	Why drive a Golf when you can drive a Ferrari ;D

The Trolls have already started voting, and there are two very strong candidates who are competing for the first place. Now all votes are not in yet, so keep your fingers crossed Btw. I’ve masked using patented superfancy GIMP filters, so don’t bother guessing which two it is

Once the voting is complete we’ll publish the winner here of course

One small feature that I have wanted Qt to have when writing applications was a way to get some common directories. Where is the desktop, the music directory, or even the location where I should store my data files? On Mac, Windows and Linux these have always been different. A big problem in adding this feature has been Linux with the lack of any sort of standard, but this past year with the xdg-user-dirs spec released and with distributions like Ubuntu and others adopting it I decided it was a good time to revisit the problem. In Qt 4.4 QDesktopServices got a new function, storageLocation that returns the default system directory where files of a certain type belong. The currently supported types are: Desktop, Documents, Fonts, Applications, Music, Movies, Pictures, Temp, Home, and Data. Note that storage location can return an empty string or even a directory that currently doesn’t exists such as where the Music directory should be, but the user deleted it.

In a media player you could set the initial directory of the file dialog to open the music directory.

    QString fileName = QFileDialog::getOpenFileName(this, tr("Open File"),
                                                     QDesktopServices::storageLocation(QDesktopServices::MusicLocation),
                                                     tr("Media Files (*.ogg *.mp3 *.flac *.wav)"));

Or when looking to store some application data, say palettes for an image editor.

    QString directory = QDesktopServices::storageLocation(QDesktopServices::DataLocation);
    // embedded platforms currently don't define this location and you don't want to write to /foo
    if (directory.isEmpty())
        directory = QDir::homePath() + "/." + QCoreApplication::applicationName();
    // the first time I am saving data
    if (!QFile::exists(directory)) {
        QDir dir;
        dir.mkpath(directory);
    }
    // save my data
    QFile file(directory + "/custompalettes.dat");
    ...

Lots has been happening downunder lately. Namely, summer has come and gone. Wasn’t too hot this year, but rained heaps. Causing my pitiful electric mower to die a horrible death on my back yard that was in some spots, a meter tall. Several lawn mowing services balked at the idea of mowing it, so I bit the big one, and bought a petrol mower. How I hate mowing grass, it goes against nature, is noisy and smelly. My daughter of almost 6 months has started sitting and somewhat getting some sort of locomotion going, although it usually ends up in tears, because she wants to just jump into the whole walking thing like her brother and everyone else does. My 2.5 year old son started painting. Luckily not on the walls, but on an easel.

On the Trolltech front, besides the whole Nokia thing, we released Qtopia 4.3.1 SDK for Neo. What better way to create software for Qtopia for your FIC Neo. It seems that OpenMoko have been slowly coming around to officially using Qtopia, in some sort.

Other than the SDK I have been busy preparing the Qtopia 4.4 webkit demonstration, that was at 3GSM, errr MWC. Cool things are possible with webkit in Qtopia. Although it is rather large, the sizes of flash memory can be quite large, and most phones now have huge amounts of space, classing them not in the embedded space any longer.

The Neuros OSD I have has some competition, as I bought an already-configured-for-Australian-use series 1, Oztivo’ified Tivo (thanks Ian!), (for research purposes, my dear wife!). Neuros really needs some scheduling information, they know it, and have put up a bounty
What I like about the Neuros OSD over the tivo is it’s size. The tivo is just huge, like a regular desktop box, and has cooling fans. The OSD has sexy curves, is sleek, glossy black and silent. Makes me want to lick it. Not to mention Neuros will be using Qt Embedded, errr Qtopia Core soon.

I feel bad about my old Sharp Zaurus 5000d’s. Gathering dust, or played with by my son, until he realizes they need charging. Perhaps I will charge them up…

Almost forgot to mention, I have been putting together a virtual keyboard for X11 using Qt. Based largely on kvkbd for kde, but reads the keys and keycodes from an xml file. It works too!

tsdogs, who is one of the HTC-linux guys (who have ported linux to HTC Universal phones and friends), recently gotten embeddedkonsole 4 to run on Qtopia 4. It’s named qterminal and I have put a qpk package for the Neo at qtopia.net. For those who think they need a terminal on their phone. The HTC-linux guys have done quite a lot to hack Linux onto these phones, although it needs to be run from an sd card. The sources can be found in the unofficial Qtopia git repository : git clone git://git.asheesh.org/qtopia_snapshot.git

Reading about Benjamin getting motivated to work on KDE on OS X got me motivated, too. So, one svn checkout later, I realized that before I can even start with KDE 4, I need a bunch of dependency libraries, which are obtainable from Finc or MacPorts. Since I’m not very patient (and low on disk space), I decided to do something about it.

A low hanging fruit is to remove the dependency on the image libraries (e.g. PNG, JPG, JPEG 2000, TIFF) and let OS X do the work. After a 2 days hack, I came up with a Qt Image IO plugin that uses Mac OS X’s ImageIO Framework (source code). It requires Qt >= 4.3 and probably OS X >= 10.5.

The plugin can load all image formats supported by OS X, including animated ones (e.g. animated GIFs), but doesn’t handle image properties yet. Once it matures, I can fix the CMake build scripts to stop looking for libpng and friends, and finally start configuring kdelibs on OS X