[Windows Mobile Development and Hacking General] evilc:
There are a lot of clock area today screen apps out there, from the simple such as PDClock, through mid-level stuff like HTC home, up to the fully customizable rlToday.

Few of these seem to be a good all-round solution though, except maybe rlToday, but I am having issues with the rlToday / Sys-to-Reg / Mortscript combo, both in terms of features (ie no support for "on" or "off" images), stability, and ease-of install (S2R seems a bugger to set up right, especially for the less technically inclined user), and the whole rlToday / S2R / Mortscript combo is hardly a turnkey one-install solution.

So to that end, I decided to try my hand at crafting a solution more appropriate to my needs.

Now, until this point I have never coded for C++ or windows mobile. I am not even a professional coder, far from it, but I do have a knack for designing good solutions, so I thought I would start teaching myself native C++ and see what I could come up with. Ultimately, my goal is to release as open source, I am hoping to maybe start a sourceforge project at some point...

I am making this post because I am now starting to get past the proof-of-concept stage and am coming up with some working code. I am tackling the various hurdles one by one and learning as I go, but it is starting to look promising.

This thread is to serve two purposes:

1) Gather my thoughts on how things are going to work so potential users can chime in on possible tweaks or changes to the features and how they should work.

2) Serve as a rallying call for any (preferably more experienced) coders who wish to get involved. I will post up any problems that I am having surmounting various issues, please feel free to help out on those. If an experienced coder liked the project that much and wanted to take the lead, I have no issues with that, as long as it remained open source.

So, with that out the way, here is what I am thinking so far:

Overall idea is pretty similar to rlToday - a script (ie a .INI or .XML file) which lists Widgets is processed and the result is drawn on the screen.

For example, here is an example INI file for a background (say transparent) PNG with a clock overlaid in the middle of the PNG, that has different layouts / images for portrait and landscape mode on a qVGA device.

;ini profile for qVGA (240 width and 320 width)

;PORTRAIT
[PortBG]
width=240
widget=image
clickable=0;
image="bgport.png"
x=0
y=0

[PortClock]
width=240
widget=text
subwidget=clock
clickable=1
clicktype=exe
clickstring="<exe to launch calendar>"
dateformat = "dddd MMMM d"
x=120
y=25
origin="cc"

;LANDSCAPE
[LandBG]
width=320
widget=image
clickable=0
image="bgland.png"
x=0
y=0

[LandClock]
width=320
widget=text
subwidget=clock
clickable=1
clicktype=exe
clickstring="<exe to launch calendar>"
dateformat = "dddd MMMM d"
x=160
y=25
origin="cc"

The [Name] of each section actually does nothing, but it will be useful in debugging / error messages ("Image for [PortBG] not found!").

Widget = choses which kind of widget it is (eg Image, Text)

subwidget = choses the subtype of widget (eg clock is a subtype of text)

The Width= entry is an idea I came up with to handle multiple screen orientations and resolutions within one profile. Basically, as this is not intended to be a full-screen app, the only relevant dimension is the screen width. Each widget therefore has an associated width. When the screen is rendered, it will check what the current width is and only render widgets that match that width. Furthermore, if a script has entries for resolutions not supported by your device, these will be ignored. Profiles are likely to be a directory with one .INI file and assorted images. Images can be in subdirectories, say grouped by width (ie a "240" dir and a "320" dir for qVGA) - that way you could release a skin as one zipped dir that supported all devices and resolutions, and you would not need to upload the "480" and "640" dirs to a qVGA device, thus saving storage space.

Each widget also has x/y coords, which usually refer to the top left, but the origin entry can change that (eg cc would be centre horizontally and vertically)

Each widget will also be able to be specified as clickable, with options as to what to do when it is clicked.

With this system it should be possible to create most things, however, here is what I am currently NOT planning on doing:

I am not aiming at offering tabbed pages of widgets, or an easy way to change widgets without writing a new script. This is aimed at a companion to something like UltimateLaunch for handling the top of the screen - a Clock, SMS / Missed Calls / VM messages, BT / WiFi status and toggles etc.

I am currently using VS2005 and the WM5 SDK, but the app is still so simple that this could probably be changed. I would like to support as much as possible, but am not overly worried about providing backwards compatibility beyond WM5. I am using Native Win32 - I want to avoid as much bloat as I can.