Even though I was not feeling well today (spent day sick at home, having cold shivers all the time…), I did look into one small new feature for SynCE-KPM.
I noticed that on my windows computer, Windows Mobile Device Center was able to show a picture of my device. I was always wondering where this information was taken from. Turns out that this picture is actually taken from the device itself. I guess it must be something prescribed by ActiveSync or Windows Mobile Device Center to have the image /windows/sync.ico present.
After the device is connected, SynCE-KPM will now look if that file exists, and if it does, obtain it and show it to the user in the main window.
Example screen with two different phones I have:
SynCE-KPM now shows device (example 1)
SynCE-KPM now shows device (example 2, my HTC HD2)
I still have the major new feature left: implementing the remote registry editor. This is still on my TODO list, but unfortunately I don’t have as much spare time as I would like to have to work on this.
Another thing that I need to work on with SynCE-KPM is the usage of layout managers instead of not being able to resize as with the current implementation. Will take me some time also. Will get there though, slowly
Has not been very busy on my weblog lately. Reason for this was that we went on a vacation to the US, and to be more precise to Florida.
We decided to rent a car and just drive around to different places of interest, not really knowing beforehand what our exact route was going to be. We knew that there were some places we definitively wanted to view (i.e. Kennedy Space Center, Miami, Key West, etc) but besides that, nothing was planned. After the vacation was finished we basically made the following tour through Florida:
Besides the above basic tour we made a lot of visits to the different places. The second day we arrived we went to visit the Kennedy Space Center. I only have one word for this place: awesome! Walking there and seeing the sheer size of the rockets required to get humans to the moon is unbelievable. Also, if you look at the room the astronauts had, it is not that much.
After this we drove down to West Palm Beach and from there we started driving US Highway 1 all the way down through Fort Lauderdale, to Miami, and finally all the way to mile marker 0 in Key West. While in Fort Lauderdale, while sipping on a huge Margaritha, we met Mike, who turned out to be a pianist in the Crazy Pianos in Miami. The next day we were in Miami and in the evening we decided to pay a visit to the Crazy Pianos in Miami. Even though it was completely not busy on the Monday evening, it was a really nice evening and even got to speak Dutch to some people again in the US Definitively have to pay a visit to the Crazy Pianos in Scheveningen soon
After Miami there was the really nice drive to Key West. Somehow in my mind I had the idea that the overseas highway would be bridges all the time, but it turned out to be one long bridge (the 7 mile bridge) and the rest of the bridges between all the other keys were really short. In Key West we just had a really relaxing time
After Key West, our trip started going up north again. After finding a hotel in key Largo, we decided to go the everglades and visit one of the alligator farms. The airboat ride we did there was a blast!! These boats are so extremely loud, but sooooooo much fun At the alligator farm we also visited a snake show and an alligator show. During the snake show my wife was chosen as ‘volunteer’ to grab a snake out of a bag and hold it for some time. Luckily, she surived
The next part of our trip took us to Sanibel Island, where we visited the Ding ‘Darling’ National refuge. In this refuge we ran into an alligator (or crocodile, don’t know for sure) in the water next to the road. Really amazing to be able to stop the car, get out and take a picture of the animal laying in the water about 6 meters away from where you are standing (without a fence….. ).
After Sanibel we still visited Sarasota and Tampa. In Tampa we decided to go and visit something classical American: a drive-in theater. We watched the movie zombieland from within our car This really was a very nice experience. Unfortunately, this was already the last evening again and we had to drive back to Orlando, return the car and wait for our flight back home again….
After the previous post I started working on integrating the stand-alone prototype within SynCE-KPM. As mentioned, at the moment I only have a view on the keys, not yet the values. Furthermore, at the moment there is no error checking, switching a device will not work, and some other minor things
However, as you can see from the screencast
it is already possible to view all the registry keys that are present in the registry. Also, from the screencast you can see the Fetching… node that is shown to the user whenever the actual data is being queried for the first time. It can also be clearly seen that the fetching is done in a separate thread, not related to the GUI thread, because even while fetching, the GUI still is responsive. Any further requests for fetching the user does, are just queued to the dataserver, which will retrieve them in the order they were requested.
I have already thought about how to incorporate the values and I have come up with a solution that uses the current registry and registry key objects, but with a different model. This means I will have to custom models, both subclasses of QAbstractItemModel, using the same underlying data, but only the parts they need.
One thhings I still need to do is determining what to do with updates (i.e. when to refetch keys, when being clicked on, or have the user explicitly request refetch). Also some GUI things need to be changed. At the moment it appears that the current window width of synce-kpm is not enough for a registry editor, might have to make the application a little bit wider. All in all, plenty of things to be done (and sooooo little time… )
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
For the new feature of SynCE-KPM I am working on at the moment, I want to emulate the look and feel of the windows standard program regedit.exe. This means showing the user a QTreeView showing the hierarchy of the keys and a QListView on the right showing all values within the selected key.
While the other day I have been working (and finished) on the librapi2 stuff, in particular the python bindings, to facilitate a registry editor, for some days I have been looking at this whole QTreeView stuff. I have to say that I really do appreciate the idea behind MVC, but I have to say that to use this in a nice way in PyQt is really difficult. After some days I am now at least able to create a nice QTreeView based on a model that represents the registry. Currently, everything is still hardcoded, but at least I can see a structure now (the QListView with values will come much later ).
Next step is to see if I can connect the model to the actual contents of the registry on the device in a dynamic way. The problem is that I need to fetch new data from the registry only when it is needed. One simple approach is to first read the complete registry into the model and then show this to the user. However, I don’t think users will like it if there is a 5 minute delay showing “Fetching data” when going to the registry editor before they can actually use the registry editor. This means I will have to fetch data in some asynchronous way. Fortunately, I already have some ideas about this. For some reason I think this fetching part is again the easy component….. Don’t want to think about all the mess that is involved to show this in a nice way to the end-user.
For the moment just happy that at least the very basics of the left-hand side of the future screen (i.e. the hierarchy of the keys) needed to display actual data are there. Onwards to new challenges with PyQt and its MVC
Now that the moving is almost finished and I have a bit of spare time again, I would like to work a bit more on implementing new things for SynCE-KPM. A lot of people have asked me in the beginning to create a file-browser within SynCE-KPM, though I think that programs like Nautilus are far more suited for this purpose. I have had some ideas about this, and although I am not very much in favor of this, there might still be possibilities to implement this.
One thing I am looking at right now is a remote registry editor within SynCE-KPM that allows you to edit the registry of your device. For this to work I first have to add some additional functionality to the python bindings of the RAPI2 library, which I am working on right now. One of the things I would like to implement is a registry key rename function: Unfortunately, by design you cannot just change a key name; to rename a registry key you must first copy the whole key recursively to the new name and then delete the old key. If somebody does know a better way for doing this for Windows Mobile devices via RAPI, please let me know, really interested in this.
When all the work on the python bindings of librapi2 is finished, I can start working on the QTreeView/QListView stuff that must be added to SynCE-KPM. At the moment really reading into everything that is needed to be able to show the end-user a nice view of the registry on the device.
If you have any other ideas that could be nice additions for SynCE-KPM, please let me know via a comment.
Update 20091104: Added “1 on 1 with notes landscape”, based on work of Edson Valle. Also added “2 on 1 with notes” and “3 on 1 with notes” layouts.
Update 20091108: Added “2 on 1 with notes landscape”, based on work of Edson Valle.
Update 20091202: Added “1 on 1 with notes”, based on work of Harald Welte.
For all my presentations I have been using LaTeX-Beamer package. One of the things I missed was the possibility of having handouts of my slides with some lines for notes besides the slides. After some searching I found that in the mailing lists of latex-beamer somebody had already come up with a solution.
If you put the file handoutWithNotes.sty either in your local texmf directory or in the same directory as your presentation you can include it with the following command
\usepackage{handoutWithNotes}
After that, to get 4 sheets on the left side of the page with on the right side of the page some lines for people to write notes you can use the following command
\pgfpagesuselayout{4 on 1 with notes}[a4paper,border shrink=5mm]
The resulting PDF file will contain pages like:
Updated 20091104.I received a note from Edson Valle that he created an addition to the notes files, namely one that allows you to print your sheets 1 per page, but with notes on the side. Made a some small alteration to his original contribution to allow for easier usage.
I have updated the original download-link, so you only have to download the latest handoutWithNotes.sty file and you should be ready to use it.
Again, make sure that you include the style file with:
\usepackage{handoutWithNotes}
after which you can now use the “1 on 1 landscape” layout with the following command:
\pgfpagesuselayout{1 on 1 with notes landscape}[a4paper,border shrink=5mm]
.
The resulting files will look something like:
Showing the 1 on 1 with notes landscape
While I was at it, right away I also created two additional styles “2 on 1 with notes” and “3 on 1 with notes”. The first of these two was already requested once by kc853. Hopefully this new style will be sufficient for his needs. If not, I hope that it will serve as a good starter for modifications.
The “2 on 1 with notes” layout can be used with the command
\pgfpagesuselayout{2 on 1 with notes}[a4paper,border shrink=5mm]
with the following result:
Finally, the “3 on 1 with notes” pages was created because I think that the “2 on 1 with notes” seemed a bit empty You can use this “3 on 1 with notes” layout with the command
\pgfpagesuselayout{3 on 1 with notes}[a4paper,border shrink=5mm]
with the following result:
Update 20091108 : Based on the above updated styles, Edson Valle provided me with another addition, the “2 on 1 with notes landscape” layout. You can use it with the command
\pgfpagesuselayout{2 on 1 with notes landscape}[a4paper,border shrink=5mm]
and the output you will get will be something like:
Update 20091202 : Based on the above updated styles, Harald Welte provided me with yet another addition, the “1 on 1 with notes” layout. You can use it with the command
\pgfpagesuselayout{1 on 1 with notes}[a4paper,border shrink=5mm]
and the output you will get will be something like:
All of the above layouts can be used by downloading the handoutWithNotes.sty file.
Just drop me a note in case you like this or find it useful or in case you have any questions
In some weeks we will get the key to our house we recently bought and I thought this was a perfect opportunity to buy a small light-power computer that I can use in the new house as a server. Currently I have my desktop running 24/7 because it also works as a simple webserver and provides me with my email wherever I am.
Yesterday I bought an Asus EEE Box PC. Unfortunately the thing came with Windows XP preinstalled on it, which was not right for the task I had it mind. I thought installing Ubuntu 9.04 Jaunty (server) was going to be really easy, but when I created a bootable USB stick with the installation ISO on it, it did not get recognized by the EEE box as a boot device. I tried all the different USB mass storage device settings in the BIOS, repartitioned my USB stick to use FAT16 instead of FAT32, nothing leading to a satisfying result.
In the end I found a 1GB micro SDHC card I still had laying around, put it in the SD slot and after forcing the BIOS to force the USB boot mass storage device to “Forced FDD”, I finally got the linux boot menu I was looking for (instead of the windows xp boot screen). After I got this far, the rest was really easy and in no-time I had Jaunty up and running.
Now the only thing left is to move all server-data from my desktop computer to this new server and I will be finished completely.
Definitively have to pay a visit to the Crazy Pianos in Scheveningen soon 
