Christmas update...

No, development will NOT progress until mid-jannuary because i will be away, in Socotra, for vacation. Meanwhile i will extensively test 1.3.0 beta1 for your pleasure...

But i wanted to update you on OVI store: still NOTHING. Right now, i have my last submission to Q/A stuck at 75% passed since the last 15 (FIFTEEN) days.

Hey guys at OVI store, this is YOUR fault, with your last idiot update of the metadata, which caused FreeTrack (and i guess other apps too) to FAIL just before Christmas... Good work! Keep it that way and you show the world why IPhone and Android will keep eating Symbian market shares!

By the way if you are a developer and have suffered the same problem, please contact me in private.

Working toward 1.3.0

Good morning all!

So, yesterdays work was productive, and i spent the evening finding some most basic bugs and crashes. Today i am gonna fix those and some more, i hope. A couple of serious crashes where due to the new FreeTrackList implementation, which i am going to rewrite today to make it behave like a hash instead of a simple list, and due to the Waypoint implementation which i am going to fix forcing the waypoint ID to be unique among all loaded tracks!

Stay tuned...

Update: FreeTrackList and waypoints have been fixed properly. What is taking some time is to draw the waypoints on the table in a nice way... Something Qt really make complicated!

Update: I forgot! I want to add into 1.3.0 also the rewrting of the transformation equations in TrackMap! I want to add support for roteted maps too... Anyway, 1.3.0 is getting pushed a bit, so no rush. I will release a "beta1" anyway for Christmas, and that will be a "feature fix", but as bugfixes and smaller improvements, i will use the NEw Years vacations to make that list big! And fix them during jannuary.

Code cleanup...

Since i managed to implement all the features (minus a few bugs), i am doing a bit code-cleanup. This is required to release a nice 1.3.0beta which will accept only bugfixes before 1.3.0 release...

So stay tuned and be patient...

Update: The cleanup went quite well... I removed a couple of classes and rationalized some code... Now i am busy implamenting properly a kinetik-scrollable list of widgets...

Update: Working on improving FreeTrackList. I want to add this list also to the list of waypoints and i hope i can fix it wor kinetik scroll too...

Cleanup TODO

I want to track here a few areas i want to clean up as soon as 1.3.0 will be out (at least, the beta!)

1) TrackModel: do we need this class? Can we make it so general it does not need references to LayerTrack and LayerMap?

2) AboudDialog: can we use FreeTrackDialog as parent?

3) ConfigDialog: can we use FreeTrackDialog as parent?

4) FreeTrack: can we get rid of the StackedWidget and simply use the main content here?

5) MainContent: do we really need this class? Why not move all into FreeTrack and simplify a bit?

Waypoints & OZI calibration...

While i need to debug more the huge map support (seems that some smaller maps are sometimes broken now), i am actively working on waypoints. Its not complicated and i hope to have them working by today.

The basic idea is to have a "add waypoint" button in the tracking table. When you tap that, you are asked for a name and a description. These toghether with the current position will be added into the livetrack as a new waypoint. You will then be able to edit the waypoints from the layer config dialog box.

Waypoints are then saved into the GPX track.

Update: waypoints are now working, they are drawn as small rectangles. More customization will come in the future.

Update: i have also added support for OZI explorer map calibration file import. It seems to be working, but it need WAY more testing!

Stay tuned for a FreeTrack 1.3.0 Alpha4 release soon, maybe today!

FreeTrack 1.3.0 alpha3 is ready!

People,
i am proud to announce FreeTrack 1.3.0 alpha3! This pre-release of FreeTrack 1.3.0 offers you HUGE maps support, actually working!

While there might be some improvements, right now you can load up maps up to 64k x 64k pixels (tested up to 11k x 13k pixels so far). The limitation is that the map MUST be a jpeg file.

This works by "precaching" the map in smaller chunks and using those to speed up drawing when needed. So you actually need to sacrify some SD space.

It seems to be working pretty well on my Nokia 5800XM, please report your mileage on the website o on the mailinglist.

ps: you can download this alpha from FreeTrack website

As for the immediate roadmap, i hope within next week to be able to add the following features:
- ability to add "waypoints" to the current Live Track with a simple button press
- ability to import calibration data from OZI explorer

The release of a "beta" 1.3.0 with those three features will be my Christmas gift to you all... i hope!

ON-device testing for huge maps...

I started testing on device the new huge-maps support and i must say that i am VERY excited! Speed is simply great on my 5800XM, both when caching and displaying!

Unfortunately i hit a bug somewhere, triggered inside libjpeg, which causes a crash on the phone but not on the simulator, so today i need to spend some time debugging on the phone, which is a pain and a waste of time. But what can you do? Nothing!

Update: the bug was mine... Sorry, i mixed up cols&rows, ending up with a crash! This is the consequence of rushed work. Anyway, if everything goes well, i will release a 1.3.0 "alpha" release today on the mailinglist...

Update: i have released the alpha... there are still some crashes i am working on, but its a good starting point for testing huge maps!

Update: the crash was related on how i was managing to sync the chunks loading. I was emitting a signal inside the paintEvent, which tunrs out cannot be considered safe. Sometimes, in fact, that signal gets executed immediately (Qt::DirectConnect) or never  (Qt::QueuedConnect). So to keep it simple i added a QTimer in one-shot mode and just fire it inside the paintEvent. This ensure that the chunk loading is done outside the paintEvent itself.


Stay tuned...

Work is progressing...

I am currently busy working on implementing the changes i discussed last week on this blog, it's taking some time due to the lack of time of these days!

Update on development...

Sorry guys,
being busy with work and other things...
but work is ongoing and i hope to release at least a release candidate for 1.3.0 before Christmas... It will have huge maps loading, map precaching and OZI Explorer calibration...

Just wait and be patient!

OVI Store: again you...

Hi guys!
Well, i have more news on OVI. Yes, FreeTrack got rejected once more, this time was kind of expected due to this email Nokia sent to us OVI publishers on 6th December:

"Dear Publisher,

This email contains important information about an upcoming Ovi Publish and Ovi Store maintenance break, new features, and technical bulletin.

 ^[cut]

^{OVI PUBLISH TECHNICAL BULLETIN}

^{New Metadata Introduction in Next Release of Ovi Publish May Create “Limbo Effect”}

<sup>If your content is submitted to QA prior to this release, but not evaluated prior to tomorrow's release, the content item will fail due to missing metadata.

NOTE: Content already published to Ovi Store will not be affected by this release.</sup>

^{We apologize for this inconvenience. Please resubmit the content with the new Categorization Tag metadata after the maintenance break."}

 So it did not come as a big surprise when today i found FreeTrack rejected once more with the following notice:

"Revision 83 of this content item can NOT be submitted to QA as some metadata requirements have not been met (see Content Item tab below).
Please provide the missing data."

I just want to add a couple of considerations.

The first one is that you do not undergo such a stupid thing as doing a major change to your store (forcing all pending app to fail approval) just two weeks before Christmas, thats suicidal, and plain stupid, even I can see that.

The second is related to the new meta-tag that made my app fail. It is categorized under "sports", so the new metadata is called "Categorization Tags" and can have the following values:

"Air Hockey Auto Racing Baseball Basketball BMX Bowling Boxing Cricket Darts Foosball Football Golf Hockey Ping Pong Pool Skateboard Skating Skydiving Snowboarding Soccer Surfing Tennis Track & Field UFC Wrestling "

 Now i want you to check that list again (its a copy/paste from the publishers page). Why on earth there is "snowboarding" and now "skiing"? Why there is "BMX" and not "Cycling" or "Bycicle"? Then what, do we also have "Foosball" and "darts" but not "Fencing", "trekking", "mountaneering", "climbing"?

Can anybody from OVI or from Nokia try to explain this very simple thing to me:

"Why FreeTrack, which i am trying to publish since september, has been rejected once more due to such a rushed and bad-timed upgrade? Why haven't you tought of a 'default value' for that tag instead of failing the apps?"

Nokia, come on, this is absolutely a RUSHED, BADLY TOUGHT and abslutely bad-timed upgrade to OVI store. 

(i would also reply to Lucian whi sent, but didnt gave me his email to reply back, a note on my previous post on OVI store. I do not "claim compatiblity" with a platform. On OVI, there is a "should work" setting i selected for my app. If there is such a setting, why reject the app for ALL the platforms, even the fully tested ones? Just fail for that platform, or get rid of that idiot setting which makes no sense at all. Also, unfortunately, OVI responded to my request about Symbian^3 not being supported and that is NOT a copy&paste error but it reflects a real problem with Symbian^3, Qt and OVI. I can forward to you OVI reply, if you like, its quite interesting)

Overcomplicating...

Hi all,
i finally understood why i am making no progress on the dynamic map. It always looks like i am there, but i am not. The reason is: i am overcomplicating everything!

So, today will be devoted to simplify, simplify...

Stay tuned...

Update: i got rid of QThreads everywhere, i got rid of MapCacheManager (what for, actually? moved just two members to LayerMap, the rest discarded as useless)...
Also, fixed WaitDialog to work without threads!

Update: its working! Both the nice progress dialog AND the LayerMap loading stuff.. Now trying on the phone!... Its working even here! The problem is caching speed... Its unbeliable SLOW!

But i had an idea:
1) Cache the entire image for one zoom level in one go
2) really remove all cache stuff from paintUncalibrated, schedule instead to reload outside paintevent...

Last update for today: i am working on quite a rewrite a ImageJpeg, to make the interfaces more effective and logical. WorkerPrecacheMap is benefitting from this, and while it does not work yet, it will be HUGELY faster.

At the same time, this rewrite requires a rewrite in the paintUnalibrated. Now it will be mandatory to move all the data fetching (and possibly cache rebuild) outside the paint event, which is by the way the logical thing to do anyway.

I will be AWAY until sunday, so no new posts for a bit...

ciao!

Status on 1.3.0

Hi all!

Another weekend has gone by, and unfortunately not much progress so far.

Unfortunately, i found out the QThread documentation is very misleading, so i am in the process of rewriting all the thread related stuff... Which is taking a bit of time!

Update: i got another couple of not-so-nice news on Qt... The first is that you cannot open a modal dialog box from a paintEvent. Actually, it make sense, because opening a dialog box will cause screen redraw causing an infinite loop with the paintEvent call...  But its quite annoying because i was counting on starting a modal dialog and a background thread to "cache" map chunks on the fly.

The second is related to the WaitDialog, under no circumstances i am able to have it running on the simulator. I am now trying to deploy on the phone and see what happens.

I am thinking a doing this:
- Get rid of MapCacheManager and threads!
- a map will select the list of chunks to paint...
- any chunk loaded, will be painted immediately
- any chunk NON loaded will add the chunk to a list and a "not loaded" image drawn on screen
-After the paint is done (maybe a one-time trigger event? queue-scheduled during the paintEvent?) the new chunk(s) gets loaded
- upon chunks loaded, another update() is somehow scheduled.

Precaching can work like it is now, but why i cannot get that dialog to show?

libjpeg progres...

Well, beside my previous rant about OVI store, work is going on albeit a bit slowly.

I am struggling a bit with libjpeg... Nothing serious, but i wasted a few hours understanding why libjpeg was showing only 20lines of each jpg... The answer? Easy, look at this code:

void ImageJpeg::initialize()
{
    QFile image_file.setFileName( filename );
    if ( !image_file.open( QIODevice::ReadOnly ) )
    {   // quit on error
        error = true;
        return;
    }
    // Convert QFile to FILE (needed by libjpeg)
    FILE* pFile = fdopen(image_file.handle(), "rb"); // This will be reused in other methods to load jpeg data
    // initialize jibjpeg data structure
    cinfo.err = jpeg_std_error(&jerr);
    jpeg_create_decompress(&cinfo);
    // Initliazed must be true whenever we need to destroy cinfo
    initialized = true;
    // Set file in libjpeg
    jpeg_stdio_src(&cinfo, pFile );
    // Read header
    jpeg_read_header(&cinfo, TRUE);
    // set error status
    error = cinfo.err->msg_code == 0;
    return;
}

 Do you see the error? Well, image_file will be closed on function return, leaving the libjpeg to handle a closed stream when reading an image!

Placing image_file in the class (as private attribute) solved the problem...

Update: ok guys, there will not be much more for this week, i guess. Right now, i am fixing some bugs in the readImage function of ImageJpeg, responsible to load a piece of jpeg and scale it properly. It took me a while, specially to filter out all the special cases leading to a segmentation fault (magic of working with raw pointers and C code...), but now it works for any zoom level.

Unfortunately speed (Even if hugely better than using Qt's internal QImageReader) is still not enugh on the phone, so i believe some kind of caching is STILL required. Unless i find a way to skip scanlines in libjpeg... whichi did not, so far.

OVI Store

Did i tell you how much fucking idiot OVI store is?

Never enough. Well, FreeTrack has failed (again) the process. This time, the reason is that:

Failed QA
Ovi store test criteria:
SUMMARY: Device distribution doesn't have at least one device per each platform as "FULLY TESTED".
EXPECTED RESULTS: For each platform you wish to distribute your content you must have at least one device FULLY TESTED.
CORRECTIVE ACTIONS: Steps to modify the file:
1. Press "Edit File" button.
2. Check the "Compatibility" declarations for each platform of devices.
3. Select device compatibility "FULLY TESTED" for at least one device in the platform.
4. Press "Submit changes to QA" button.
NOTE #1: When FULLY TESTED device fails in QA, the whole platform will fail. Please select devices FULLY TESTED only if that is the situation.

NOTE #2: Qt content is compatible only with the following devices: E72, E71, E63, E52, E66, X6, N97 mini, C6-00, 5800, 5530, 5230, 5228, 5235, N97, N900 with PR1.3 and later, therefore the rest of devices are left pending.

So what? Dont you expect to FAIL for that specific platform (in this case it was Symbian^3) and pass for the others (in this case, it was PASS for S60v5)?

Moreover, double check that NOTE#2... Yes, you get it... No Symbian^3 device in list! This means that N8, E7, C7, C6-01... all the bright new Nokia phones, yes, the ones you are being hammered by advertising EVERYWHERE are... not supported by OVI yet :)

Guys, What is going on with Nokia is not a question, when they will be wiped out from the serious market is getting more and more a possible reality... That i hope will never come, because i like Nokia phones, but come on, there is a reason Nokia is falling behind on the high-end phones, and its clearer every day, its even clear WHY. Nokia, dont you get it?

MapCacheManager...

Ok all,
what is going on here?

Well, after some initial tests on the device i am please to announce that the new map algorytm is pretty good and maps are displayer FAST. But there is a caveat: only after the chunks have been cached... Creating a new uncached chunk is simply so slow to not be usable for maps even as big as 3000x3000px.

This brought me to think that caching must be forced and pre-caching must be done at image loading time. So i have added a MapCacheManager class which is a QThread and will take care of all the chunk cache management.

During caching, a nice wait dialog will be shown on screen with a progress bar so the user know the phone is not hung...

Update: Of course, it could NOT be so simple. QImageReader, the backbone of my image-reading processing, cannot run into a Thread (i guess because it uses QImage, whatever...). I am so pissed off! But something good can come out of this: i am trying to use libjpeg instead! This of course will limit the map file formats to JPEG (now anything supported by Qt is accepted), but the benefits should be a much faster loading times and more accurate optimizations... So, why not? I am giving it a try.

I hope i do not have to go back to the nice-and-plain long loop with event's loop calls in the middle...

Update: i managed to compile libjpeg quite easily... I am now reworking the MapCacheManager and LayerMap classes to accomodate for it. I also got rid of ALL the QImageReader usage! But one drawback is also that i cannot use the handy painter.drawImage with embedded image-scaling facilities...

What i am going to do is try to implement the same stuff using libjpeg scaled loading capability AND some ol'good memory copies...

Update: i am a bit spent today... Wow, i have been coding on this dynamic maps stuff for one week now! And it was supposed to be simple... Anyway, the matter is now to implement properly MapCacheManager. We want to popup wait dialogs only when rebuilding the cache! Also, i sincerely hope that with the use of libjpeg the speedup will be such that we can, hopefully, even drop the caching. We will see.