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.
Code:
;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.
Planned features:
Per-pixel Alpha PNGs - IMPLIMENTED
Widgets parsed from INI - IMPLIMENTED
Parse only items from INI that match screen caps - IMPLIMENTED
Display only items that match current screen width - IMPLIMENTED (Effectively switch profile on screen orientation change)
Options screen to set current profile
Widgets
======
Text Type: - IMPLIMENTED
Source: String in INI - IMPLIMENTED
Source: String in Registry
Source: Date from format string - IMPLIMENTED
Image type: - IMPLIMENTED
Plain image - IMPLIMENTED
Status Image - Registry value
Toggles - BlueTooth / WiFi / Phone etc
Other features
===========
Multiple screen resolutions supported per INI - IMPLIMENTED
Detect Power but no Activesync - Allow enabling of BlueTooth for automatic pairing with in-car BT handsfree.
Current questions and stumbling blocks:
Having issues finding a lightweight way of displaying per-pixel alpha PNGs. Current thinking is that AlphaBlend is perfectly capable of doing the blending, it is just SHLoadImageFile that is stripping the alpha info.
See threads here and here
Not sure how I am going to handle toggling of BT / WiFi. Could use VJ's tool, but I would rather do it in my code. Any pointers on how to do it and maintain maximum WM5 / WM6 compatibility would be appreciated - VJ's tool will not toggle WiFi on my Kaiser anyway...
Could do with decent chop and chomp routines (split by char and remove leading / trailing whitespace) - does anyone know an easy way to do this in native code?
Need to work out how to find the size of a text string in pixels *before* it gets drawn to the screen with ExtTextOut
Need to impliment a date format string to text string converter that can handle date and time objects in the same string
Currently I use a bit of code to look at the string and pass it to either GetDateFormat or GetTimeFormat, but not split the string and pass relevant bits to relevant routine, then reassemble.
Need to make whole thing a today item, but delaying doing this as it seems that debugging will be harder? I also guess this would be quite easy, so I am planning on leaving this until near the end. Any advice on this subject would be appreciated.
I am interested in this. I don't know C++, but I have experience coding with other computer languages. I'll definitely be following this thread and watching for updates.
iContact source contains some pretty lightweight INI library. It isn't written by me, and it's called SimpleIni. Everything is contained in one .h file and it's very easy to use.
good luck,
larna
larna said:
iContact source contains some pretty lightweight INI library. It isn't written by me, and it's called SimpleIni. Everything is contained in one .h file and it's very easy to use.
good luck,
larna
Click to expand...
Click to collapse
Nice one, thanks
I got simpleini in and working - you were right larna, it was really easy and pain-free. Thanks!
Update:
I have a working prototype.
All basic functionality coded - text and image widget types, orientation switching, ini parsing...
Currently still not a today item, and there is loads to do in terms of error checking and freeing up memory etc, but it parses INI files OK
Once I have done some tidying up, I will release some source and maybe a demo EXE.
Hey!!
I'm already developing an application which load and extends rlToday Themes!
sources will be released soon!
The app is XIAMultitheme:
Done:
- fully working rltoday themes on a HWND
- done today plugin
- loading external dll
- all widgets are external dll
To do:
- avoid image loading via ImageFactory due to memory leak on wm6x
- port to CxImage to load PNG
- use AAROT to free rotate images (analog clock)
- today plugin does not load the engine yet
http://www.xiaprojects.com/?section=All&project=XIAMultiTheme
what do you think? mail me on priv (stefano) on xiaprojects.com
stefanux said:
Hey!!
I'm already developing an application which load and extends rlToday Themes!
sources will be released soon!
The app is XIAMultitheme:
Done:
- fully working rltoday themes on a HWND
- done today plugin
- loading external dll
- all widgets are external dll
To do:
- avoid image loading via ImageFactory due to memory leak on wm6x
- port to CxImage to load PNG
- use AAROT to free rotate images (analog clock)
- today plugin does not load the engine yet
http://www.xiaprojects.com/?section=All&project=XIAMultiTheme
what do you think? mail me on priv (stefano) on xiaprojects.com
Click to expand...
Click to collapse
hi stefano
i see nothing on your web site , nor screenshots nothing in download binaries
Why ???
evilc said:
Update:
I have a working prototype.
All basic functionality coded - text and image widget types, orientation switching, ini parsing...
Currently still not a today item, and there is loads to do in terms of error checking and freeing up memory etc, but it parses INI files OK
Once I have done some tidying up, I will release some source and maybe a demo EXE.
Click to expand...
Click to collapse
can you upload here the demo program ?
Sounds pretty neat!
I don't understand some of the terminology you use, but I think you may be talking about a feature I had an idea for:
profiles (XML files) can be associated with a today plugin such that you can make a profile appear in the today plugins list for each skin (XML file) you have installed - thus making each XML profile behave like it was a today plugin in it's own right.
Is that what you are talking about?
brunoisa10 said:
can you upload here the demo program ?
Click to expand...
Click to collapse
Demo uploaded to first post. Unzip it to \Storage Card\shared on your device and run.
BE AWARE, there is very little error checking when parsing the INI.
If you omit a horizres line for any widget, for example, the program will crash.
Well I checked out XIAMultiTheme and it looks promising.
I was not aware that there was a memory leak bug in IImagefactory, I wasn't planning on using it in the final version anyway, so no biggie.
If XIAMultiTheme is capable of doing what I had envisaged for openClock, I will probably stop development, as you obviously know what you are doing much more than I do
However, a couple of points:
1) Size.
XIAMultiTheme seems to be a lot bigger and requires .NET - This seems to mainly be to do with the CxImage library - just PNG support seems to add more size than my entire app is! I am flabberghasted that supporting per-pixel Alpha PNGs takes this much, an alphablend routine can be done in a K or two, hundreds seems overkill. Apart from the requirement for rotation (for analogue clocks) I do not see why a full image lib is needed. Just a load and alpha blit.
2) Orientation awareness.
As in I don't see any in XIAMultiTheme. I am really happy with the way I have handled this in openClock - each item in the INI (XML in your case) has a "horizres" value associated with it. At render time, current screen width is compared to each item's horizres and if it matches, the item is drawn, if it doesn't then it isn't shown.
This provides a nice way to combine portrait, landscape and multi-res capabilities into one theme. And as long as you allow relative paths in the theme(eg 320\320bg.png, 240\240bg.png, common\common.png) then you can have a theme which supports all resolutions and orientations, and allow the user to store what they want on their PPC (eg if their device is qVGA, they know they do not need to put the 640 and 480 dirs on their PPC for a given theme, as they won't be used)
3) Stateful buttons.
Items like a voicemail button / wifi button etc should probably have two images associated with them - one for "no messages", one for "have messages". I was planning on putting something in openClock along the lines of specifying a reg key, an operator and an image.
eg:
regkey=HKEY_LOCAL_MACHINE\...
on=thisimage.png, gt, 0
off=thatimage.png
To set to thisimage if the key is of value greater than (gt) 0 or thatimage.png if not.
Good luck!
evilc said:
just PNG support seems to add more size than my entire app is!
Click to expand...
Click to collapse
Yep. Same goes for MortButtons... (and MortPlayer, but there, the player itself is bigger in relation...)
I am flabberghasted that supporting per-pixel Alpha PNGs takes this much, an alphablend routine can be done in a K or two, hundreds seems overkill.
Click to expand...
Click to collapse
The alphablend routine is in the Draw method, and even in source code not much more than 1kB.
The trouble is to load the PNG without losing the alpha information. With Windows' API, you can't do it - there's only the crippled SHLoadImage. So you need the entire code to decode PNGs, i.e. libpng, which in return requires zlib - over 200kB only to load PNG! The remaining kBs are spend to load/decode JPEG (quite some kBs, too), GIF (if enabled), BMP, ... and some basic image processing (resample, rotate, ...).
btw, you might want to check MortImg.dll and MortImage.lib, which is a (quite) simple wrapper. If only one image library is used, at least some memory on the device is saved (and if MortButtons or MortPlayer since b72 is used, also main memory).
Check out http://mort.svnrepository.com/svn/mort/MortTools/trunk with any SVN client (e.g. Tortoise), use "guest" for login and password.
evilc said:
Well I checked out XIAMultiTheme and it looks promising.
I was not aware that there was a memory leak bug in IImagefactory, I wasn't planning on using it in the final version anyway, so no biggie.
If XIAMultiTheme is capable of doing what I had envisaged for openClock, I will probably stop development, as you obviously know what you are doing much more than I do
However, a couple of points:
1) Size.
XIAMultiTheme seems to be a lot bigger and requires .NET - This seems to mainly be to do with the CxImage library - just PNG support seems to add more size than my entire app is! I am flabberghasted that supporting per-pixel Alpha PNGs takes this much, an alphablend routine can be done in a K or two, hundreds seems overkill. Apart from the requirement for rotation (for analogue clocks) I do not see why a full image lib is needed. Just a load and alpha blit.
2) Orientation awareness.
As in I don't see any in XIAMultiTheme. I am really happy with the way I have handled this in openClock - each item in the INI (XML in your case) has a "horizres" value associated with it. At render time, current screen width is compared to each item's horizres and if it matches, the item is drawn, if it doesn't then it isn't shown.
This provides a nice way to combine portrait, landscape and multi-res capabilities into one theme. And as long as you allow relative paths in the theme(eg 320\320bg.png, 240\240bg.png, common\common.png) then you can have a theme which supports all resolutions and orientations, and allow the user to store what they want on their PPC (eg if their device is qVGA, they know they do not need to put the 640 and 480 dirs on their PPC for a given theme, as they won't be used)
3) Stateful buttons.
Items like a voicemail button / wifi button etc should probably have two images associated with them - one for "no messages", one for "have messages". I was planning on putting something in openClock along the lines of specifying a reg key, an operator and an image.
eg:
regkey=HKEY_LOCAL_MACHINE\...
on=thisimage.png, gt, 0
off=thatimage.png
To set to thisimage if the key is of value greater than (gt) 0 or thatimage.png if not.
Good luck!
Click to expand...
Click to collapse
thanks you for your good words
1) beta version will be lighter ... (need to known what image loader use)
2) will be done on Page component (tab themes are already working)
3) will be done on sensor dll with "regex" (maybe)
XIAMultiTheme is in alpha development...
I would like to "merge" code with you or may be DLL collaboration.
XIAMultiTheme does NOT need .NET it's low level GDI "C" source
When XIAMultiTheme go on Beta status the dll will be around 10kb
Configurator is .net
Thanks you
Thanks for that mort!
However, if my entire app is (currently) 61K and it supports per-pixel alpha PNGs (Via the apparently bugged IImagefactory), then surely it is more than possible in less than 100K.
It seems like libpng must be grotesquely bloated for our needs. In an ideal world, someone would re-code SHLoadImage to not lose the alpha channel for PNGs. Maybe a workaround would be to convert the PNG into a 32bit per-pixel BMP with alpha before it is passed to SHLoadImage, as SHLoadImage deals with alpha BMPs just fine and AlphaBlend works just fine with AC_SRC_ALPHA data.
stefanux said:
thanks you for your good words
1) beta version will be lighter ... (need to known what image loader use)
2) will be done on Page component (tab themes are already working)
3) will be done on sensor dll with "regex" (maybe)
XIAMultiTheme is in alpha development...
I would like to "merge" code with you or may be DLL collaboration.
XIAMultiTheme does NOT need .NET it's low level GDI "C" source
When XIAMultiTheme go on Beta status the dll will be around 10kb
Configurator is .net
Thanks you
Click to expand...
Click to collapse
Hi stef,
I am more than happy to help out on your project with design ideas, testing and proofreading of english translations.
I have plenty of ideas on what the ultimate today screen widget app should feature, I just had to set my sights lower due to my (lack of) coding abilities.
Do you have a forum or something on your site? I don't see one.
I am slightly concerned about point (3) and your regex example. I would maybe try and keep it simpler, XML is already a little complicated for non-technical users to understand, throwing regexs into the mix may be the straw that broke the camel's back. That's why I went with INI files - simpler to use for lusers
evilc said:
Thanks for that mort!
... it supports per-pixel alpha PNGs (Via the apparently bugged IImagefactory), ....
Click to expand...
Click to collapse
Please try to do this test:
load 20 png's with imgfact. and start drawing all of them like a simple animation for 10 fps... image[]->Draw() after 5 minutes my application will blow up my pda (wm61) I thinks it's a "COM" bug because it happend only calling "Draw"
stefanux said:
Please try to do this test:
load 20 png's with imgfact. and start drawing all of them like a simple animation for 10 fps...
Click to expand...
Click to collapse
Are you kidding??? 10FPS? I have a kaiser!
Seriously though, if we can get a code snippet that proves this, surely we can get MS to issue a patch?
Hey, i created an Android card game and i got the coding part nailed down, but the layout part i'm still trying to improve, the current layout seems unprofessional (and the layout creator that comes with the SDK kinda sucks), is there some way to make a great looking layout for my app? Any tricks for the Layout Creator of the SDK or any other tools?
My app is this: https://play.google.com/store/apps/details?id=com.rtt3ch.suecaonline
DarknessWarrior said:
Hey, i created an Android card game and i got the coding part nailed down, but the layout part i'm still trying to improve, the current layout seems unprofessional (and the layout creator that comes with the SDK kinda sucks), is there some way to make a great looking layout for my app? Any tricks for the Layout Creator of the SDK or any other tools?
My app is this: https://play.google.com/store/apps/details?id=com.rtt3ch.suecaonline
Click to expand...
Click to collapse
There are no good wyswig layout editor IMHO, for example, the eclipse graphical editor should be used more like a way to get a quick sneak-peak at what the xml code you're writing will look like than a way to actually generate the UI.
I can recommend some resources that really helped me improve the UI of my app :
Read the Design Guidelines thoroughly, once you're done reading, read them again^^ : http://developer.android.com/design/index.html
watch some Android Design in Action videos, gives a lot of inspiration, and there might be an episode specifically about your app's purpose (it's a weekly show held by Google engineers Roman Nurik, Adam Kosh & Nick Butcher, working on the Android Team, and they often do redesigns of existing apps or treat a specific type of app and the design it should have) : http://www.youtube.com/watch?v=2....
Take a look at the great open source custom views & libraries showcased on : http://androidviews.net
Use the Android Assets Studio to generate custom icons, 9patchs, framed screenshots etc... : http://android-ui-utils.googlecode.com/hg/asset-studio/dist/index.html
Use the Action Bar Style Generator to create a custom action bar theme that suits your branding/color palette : http://jgilfelt.github.io/android-actionbarstylegenerator/
Use the Holo Colors generator to get all the Holo-compliant variants of a defined color (i.e : for button states - pressed/selected) : http://android-holo-colors.com/
Watch some Dev.Bytes videos, they are short and straight to the point, and always about implementing some custom animations and effects to jazz-up your app (again, held by Chet Haase & Nick Butcher, engineers at Google) : http://www.youtube.com/watch?v=XNF...
Take a look at Cyril Mottier's blog : http://cyrilmottier.com/
Nadav Fima's blog : http://nadavfima.com/
Join the Android Design community on Google+, ask for advice & show your designs/mock-ups to get feedback : https://plus.google.com/communities/113499773637471211070
Hope that gets you going, good luck
Android layout is the bane of my existence. Especially when you're trying to get things to work across 10 inch, 7 inch tablets and phone screens.
A lot of the time things just don't work like you'd expect them to. Practice a lot, google a lot and you'll build up your own bag of tricks to handle things, like using empty frame layout to pad things and when to (and when NOT to) use layout weights and layout margins.
Don't trust the software preview in the IDE, or even the simulator. Always test on actual devices and try to test on as many devices as you can.
Wish I could be of more help, but android's layout is a *****.
Hi all,
Firstly many thanks to Smartwatch Ticks for those excellent tutorial videos detailing what's in the XML files behind the ClockSkin faces on the D5 / Lem5 etc.
This sparked an interest in using something I discovered last year called Leo Editor (www.leoeditor.com). It's open source and written in Python. It's basically an outline editor. It has a tree structure and each node can contain text. However, the trick to Leo is that you can generate external files from any node. Also each node can be cloned and used anywhere.
This means that you can have a tree node which just contains the definitions of all your image arrays. If you want to use them for a particular face just clone the node again and paste it into your watch face structure where it's required.
The advantage with these clones is that if there's an error, once you fix it in one place, they're all fixed!
When you save your outline it writes all your generated files, creating new files for new nodes as required.
It doesn’t just support xml. It can be used to work with any language to break up code into manageable structures.
It's documentation which generates the code for you.
A concept called "literate programming".
I think there is already a software for creating android based smartwatches such as the D5.
It's called ClockSkinMaker created by @rromeroa
Clockskin Maker
Hi yes, I've had a look at ClockSkinMaker. I didn't find it very intuitive and I have been toying with the idea of developing my own that will include being able to edit the images, but for now I think I'll use it to test my faces and create them using Leo Editor.
Most stuff doesn't change anyway, it's just a matter of creating the new images, plus it makes it very easy to create a group of faces that have slight differences. Cloned nodes containing the desired "drawables" can easily be added in.
This enables very easy creation of several versions of the same face, but each one with slightly different features.
If a GUI was always better, the good lord wouldn't have given us bash!
richardtwyning said:
Hi yes, I've had a look at ClockSkinMaker. I didn't find it very intuitive and I have been toying with the idea of developing my own that will include being able to edit the images, but for now I think I'll use it to test my faces and create them using Leo Editor.
Most stuff doesn't change anyway, it's just a matter of creating the new images, plus it makes it very easy to create a group of faces that have slight differences. Cloned nodes containing the desired "drawables" can easily be added in.
This enables very easy creation of several versions of the same face, but each one with slightly different features.
If a GUI was always better, the good lord wouldn't have given us bash!
Click to expand...
Click to collapse
Ohh I see. Good luck then :good: