Kategoria: IT-ala (syyskuu 2010)

So, once again I wanted to try out Qt for Symbian, just a bit. I've installed Nokia Qt SDK previously but not used it. I've once tried Qt Creator and found out that for me it looks like a quite horrible thing. But now I wanted to try it again. So, please correct me if/when I'm wrong about something.

So, let's start by creating a project for a mobile application. Very straightforward thing. Naturally I wanted to use the UI designer, since it's supposed to be so great. Not so straightforward.

I put a list widget on the main window. Looks like a normal Windows list. Run on simulator. Looks like the horrible basic Symbian list. Umm... So, the UI designer is useless, since the Qt applications won't look the same on different platforms? Great. Just great. So it's all to be done in code, just like before. Why am I thinking about Java all of a sudden. "It's portable, one app will run everywhere" and all that jazz. And the reality? Different apps, different UIs for different platforms etc are/were required. And that seems to be the case for Qt also.

What I would've wanted was a separate thing for developing different platforms, if indeed Nokia didn't want to make Qt look and act the same on Symbian as it does on desktop platforms. Why clutter the property view with dozens of settings that do nothing on Symbian? Why show the list control very differently?

I run the application in debug mode. Complains about cdb not being installed (hey, it's Windows. Why would I use some mingw crap when I can use real tools?). Ok, I turn it on and it finds the path. Still complaining. Until I restart the whole Qt Creator. Nice.

Oh, every time I run the application, the UI designer turns into some XML view, which can not be edited, and I have to switch it to GUI mode every time. Why? What's the point? Why do I want to watch read-only XML when I run the app? Hello?

The simulator/created application shows Options and Exit menu buttons. Even the Exit button won't work. The red phone key doesn't exit the app. Why oh why?

Updating the Qt stuff is also nice. Lots of updates, crash when it has downloaded 2 GB of stuff. Naturally we'll start all over again. Great. Wonderful design. And why the heck are there always mingw and MSVC2008 versions of stuff? And why the heck is mingw simulator twice the size of MSVC2008? Come on, Qt people, MSVC compiler/debugger etc are available for free. Just ditch the whole minwg already, or at least make it an option, not a default...

So if I understand things correctly after this test: I can use Qt Creator for coding, but not the UI since it won't look the same in different devices. And I can't create separate UI designs for separate devices easily. So it's all code, code, code.

I'm thinking about testing custom drawn list items. They should work. But I'm tempted to bet that they won't get drawn correctly in the UI designer, only when running. But we'll see.

So not a great start, but not a horrible one either. What I (emphasis on the word I, others may have other needs) would want is to do everything in Visual Studio (2010, thank you, 2008 is already old). I would like to have an UI designer that actually shows how the application will be in the actual device. I would like to have a possibility to design different kinds of UIs if I want to. I know that QML is coming, but...

More when I have time to write it. Too busy doing other work on platforms that behave better (yeah, Interface Builder from Apple is horrible crap, but even that seems to be better than this).

Binaries for PostGIS x64

Since I'm an eager PostgreSQL and PostGIS user and I'm sure I'm not the only one interested in using these in 64bit now that it's possible on Windows, I thought I'd put the PostGIS binaries up for grabs if someone needs them. PostGIS developers will have files available for Win32 PostgreSQL 9.0 soon (now?), but they won't distribute 64bit. So here you have them. I hope all the needed files are included, do tell me if they aren't.

Copy the postgis-1.5.dll to PostgreSQL's lib folder and the other files to bin folder. Then just run the installation scripts from PostGIS distribution (not included) and you're all set.

Note! I have not run any thorough regression tests on these. They are compiled from the SVN sources (r6009 r6029) and I've only modified a couple of places to get them to compile (read more below). I have run my own applications on them, so at least there aren't any immediate showstoppers with them. But as I said, no guarantees! I hope I'll have time to run tests on them someday.

Compilation and Whining

I really can't understand why PostGIS developers still want to compile the whole stuff using msys/mingw and that kind of stuff. We have Visual C++ (yes, the compiler is available for free), everything compiles with it and you don't have to whine about how hard it is to compile stuff for Windows because it's not GNU. Just to give some hints: I have never compiled GEOS, PROJ, PostGIS etc for any platform. Still I had Visual Studio solutions done for the whole stuff in under 30 minutes. It's not hard, really! It's only hard if you insist in doing stuff your way and not the way it's supposed to be done.

So, the binaries are compiled with the newest Visual C++ compiler and optimized with the default release settings. I had to change an initialization of two arrays (there is a notice in the source that it's not nice to do it as they've done) and change some includes to get things rolling.

Binaries for PostGIS 1.5.2SVN for PostgreSQL 9.0 Windows x64

28th Sep: updated to r6029

And thank you for the PostGIS authors for clarifying my whinings :) And especially for creating and maintaining the whole PostGIS, which I love!