Currently, the feature is only available in the SVN version of SynCE-KPM (which depends on the SVN version of librapi2). However, we are currently thinking about releasing the 0.15 version of SynCE, which would [...]]]> After some final coding last night, I finally finished the new feature for SynCE-KPM: viewing the registry of your device via SynCE-KPM.

Currently, the feature is only available in the SVN version of SynCE-KPM (which depends on the SVN version of librapi2). However, we are currently thinking about releasing the 0.15 version of SynCE, which would contain this new feature. As soon as more information about the new release is available, you will also see that on my website.

To show the new feature in this version, I decided to create another screencast. While the previous screencast did show a lot, it was relatively boring due to the fact that there was no sound at all. Therefore, I decided to add a voice over to this new screencast, explaining everything in a bit more detail. In the screencast I do not show all features related to the syncing part (via sync-engine) again, because this takes quite some time and this has already been shown in my previous screencast. In the current screencast, sync-engine is not running and only the device management capabilities of SynCE-KPM are shown.

The screencast:

Of course, you can still view the old screencast if you would like to see the display the status of an ongoing sync-process, or installing a CAB file onto your device. This old screencast is in the Lost screencast post on my website. Please note, that this old screencast is without any sound.

When you have the feature of viewing the contents of the registry, of course the next question is to be able to edit the contents of the registry. This is what I see as the next feature to implement in SynCE-KPM, though at the moment I don’t know when I will have time for this. As with this currently implemented new feature, whenever I have time, I will start working on it

If you have any questions, suggestions, etc, please leave a post or send me an email.

I would like to include this as a new feature within SynCE-KPM, and because this is written in PyQt4, the addition needed to be in PyQt4 also. This meant investigating the MVC concept within [...]]]> The last couple of weeks I have been working on the basics for a remote registry under linux for windows mobile devices.

I would like to include this as a new feature within SynCE-KPM, and because this is written in PyQt4, the addition needed to be in PyQt4 also. This meant investigating the MVC concept within Qt4, with the QAbstractItemModel, QModelIndex, and QTreeView (at least for the hierarchical folder structure on the left part of the remote registry editor).

After lots and lots of fighting with the QAbstractItemModel and QModelIndex, I think I have finally understood howto succesfully use them together in order to show a nice treeview structure in the QTreeView widget.

One part that caused me a lot of headaches is what the exact role of the QModelIndex is and how exactly to use these. The problem is that you are not allowed to save them in some dictionary, because they are considered to be volatile. Eventually, with some reading of the Qt website I found out how, given a particular registry key within my own backend registry storage classes (that gets its data eventually from the device), I can create the correct QModelIndex that can be used by the model.

In the end the QModelIndex turned out to be not that difficult, because it basically is only a small holding object, that contains a reference to the actual underlying data that I can access via the internalPointer() method. Another way is to use the internalId() method, but that would require me to keep my own dictionary from internalId to the actual data objects. My first thought, that this QModelIndex needs to contain all information about parents etc, turned out to be false: the QModelIndex just queries the model again for parent information.

Most of the times, when looking back after lots and lots of investigating and frustration, the concept and howto actually use it turn out to be relatively simple

The prototype I have at the moment is not yet integrated within SynCE-KPM, it is just a separate program at the moment. Furthermore, it does not show any of the values within the registry just yet, only the structure of the keys are shown via a tree within the QTreeView. I have made a small screencast which you can see below:

For the moment you have to take my word that the data shown is actually taken realtime from the device and is not hardcoded in my program One thing that I still like to solve is the issue that can be seen towards the end of the video: clicking on HKEY_CLASSES_ROOT takes a really long time before anything is actually shown. My current idea to ’solve’ this is to give all nodes by default one virtual child key with the name “Fetching…”

When the user expands a node, he will first see the “Fetching…” childkey being displayed. At the same time Synce-KPM will be retrieving the data from the device. After all sub-keys have been retrieved, they will be shown and the “Fetching…” childkey will then be removed.

I have tried implementing the above approach within the current prototype program, but this resulted in a lot of segmentation faults that I could not place. I am not sure what is causing this issue, but it appears that the segfaults are caused when I both delete the “Fetching…” childkey and add the actual childkeys all within the code that handles the the node-expand signal. My guess (well, hope ) is that in the final SynCE-KPM version this should not be a problem: because of the two separated processes (GUI and dataserver) I can ensure that I am only doing either deletion, or adding, but not both.

Still todo are:

• Include within SynCE-KPM (instead of separate program)
• Create a listview for the values that are stored the selected key
• Add possibility of not only viewing the registry, but also modifying