xAP on the Joggler

[SiliconPixel]

Finally had a chance to look at the slider code - Kevin, I've sent you a custom slider class I found - should do the trick.

Once we've tested - I'll design some slider graphics to go with it.

Paul.

[BodgeIT]

Sounds like the best solution given the various technologies the dimmer may be controlling. Unfortunately I can't test as I have no dimmable devices.

I'm having trouble in an other area, namely with the functionality of the pages.
Can I confirm my expectations on how they should work?
My plan is to have 2 pages, 1 on the left is the leftmenu and is about 100pixels wide, full height. The second is 720 pixels wide, full height. I haven't set onything for the <xpos> for the leftmenu, and I've set <xpos> to 101 for main page. I've then created a grid on the main page of 6x4. My expectation is that <xgrid>00 on the main page should start somewhere after xpos 101.
i.e. the grid uses pixel 101(of the screen) as pixel 0 on the main page?
Is this how it should work?

I guess the alternative is just to not set anything for main page and not to have anything positioned in the area where the leftmenu sits...

[Kevin]

Ahah..that's maybe as it should work but it's not how it does ...

The grid is calculated using the full screen size and can't be recalulated within a smaller/different sized (sub)page. Think of it as calculating the position based on a transparent overlay of the whole screen. There is only one grid , not a grid per page.
However you can offset the x or y position of each button by a fixed amount by including an <xPos> or <yPos> tag within individual <button> elements.
eg <xPos>+50</xPos> or <yPos>-10</yPos>
You can't place one <yPos> or <xPos> tag within the <layout> element to offset every button and within the <page> section this tag is purposed to place the top left corner of the backgound/page.

Also , and this where I think the confusion is , I'm always calculating the xPos / yPos of any button based on the top left screen origin and not adding it to any <xPos> <yPos> that an individual page might have. These tags only effectively place the page background....
The buttons are 'contained' within the page only in respect of their visibility and not their coordinates. I'll think on this as one thing it doesn't facilitate is moving a whole page around , complete with contents just by altering the page's <xPos> or <yPos> .. which could be very useful (and logical) but it makes things awkward in other respects....

So looking at what you're trying to do there are a couple of approaches. I think you're trying to create a 100 pixel wide left menu space on which you're going to later directly place buttons and then you want a 6x4 grid centred and spaced within the remaining 720 pixel wide area to the right.

Consider your default button grid as the main page as full width/height and at the back of everything else and then the left 100 pixel wide as a sub page on top with <xPos>0</xPos>.
Now several approaches..

1) Use 6x4 but create a <marginLeft> that is 100 pixels more than your <marginRight>

2) Use a grid of 7x4 but never place a button in the left hand vertical column so you get an offset 6x4 grid effectively... The unused column grids might be useful for placing buttons on your left menu....

3) Use 7x4 but add an <xPos>+100</xPos> within every <button> section. This will effectively push the grid off the RHS of the screen making the right hand column inaccessible/invisible.

You may have to adjust the +100 to get things looking just right...

Am I on the right track here ?

K

[Kevin]

Also - just one thing re pages, particularly if you are basing a layout on a dual menu selection ....

In the provided brainstorm type XML there is an inference of a central page selection that is a combination of a left hand vertical menu and a second horizontal menu along the bottom of the screen. I'm not sure this is a sensible design approach but regardless it didn't even work as is.....

Martyn has kindly modified the AS3 code to support remembering the page visibility of the combinational selections so that as you reselect previous buttons in either of the menus the correct pages are hidden/shown. This still supports <group> tags that are in place for either buttons or pages and functions by the inclusion of an additional <parent> tag. It supports upto 4 levels of heirarchical depths.

This code (thanks Martyn) will be included in beta 5

K

[BodgeIT]

Thanks Kevin, that cleared up my confusion...

[Kevin]

One of the fundamental aspects of a touch screen is how it navigates between pages .. where the logic sits that performs that function.

At the moment there is some basic page navigation with page toggle, show and hide (beta4 only has toggle implemented). There is also the additional <group> tag that either button or pages can belong to which automatically enforces only one page/button is enabled/visible at any one time.

Beta 5 will add more possibilities with Martyns <parent> tag implementation plus a new way of controlling page navigation - via xAP Page visibility and button clicks will be 'evented' over xAP and I intend to allow the visibility of both buttons and pages to be controlled via xAP. I may allow buttons to be 'clicked' via a xAP BSC command too.

The leading players like AMX and Crestron typically implement a touch screen interface by loading all the graphics onto the screen and feeding back finger presses. Then they have a control program running on a standalone processor that decides what should be displayed at any given time so there is minimal navigation logic actually implemented within the touchscreens. This has an additional benefit that multiple identical screens share one piece of code and can be all updated at once. Generally any displayed data is acquired by the processor and then pushed (via joins) to the touchscreens for display if needed. This keeps the touch screen clients light in terms of processing. It does however mean the screens require a separate processor to function, rather than being standalone.

So I'm intending to keep the Joggler internal navigation to a minimum - possibly as it is now which seems pretty adequate for most needs, and that the xAP BSC schema will mimic the joins. Joins are actually binary, analog or text - which is nicely analogous to xAP BSC.

Those wanting very sophisticated screen navigation or features would then either use a xAP capable controller / PC software or alter the Flash AS3 code directly.

So if there are other page/button navigation functions that people do feel should be included within the Joggler itself and configured via the XML do shout up now... !! I already intend a 'display a page for n secs' that seems sensible and will be useful as I deprecate the inbuilt CallerID screen to allow you to create your own from within the XML.

K

[Kevin]

If you have joined at beta 4 then the iServer application update exe is provided but you will be missing the sample Joggler logon file (ACL) . You should download it from here and place it in the same directory as iServer (and restart it).

http://www.ukusa.demon.co.uk/acl_Joggler.txt

You should then have a 'Joggler' device listed in the 'Configure' Access Control 'Name' drop down. You don't need to change anything here - it should just work 'as is'.

Also do check that if you have firewalls enabled they are passing the xAP port 3639 UDP, iServer TCP port 9996 and the Flash policy file server on TCP port 843

Also ensure that you have a xAP hub running and started before iServer. The instructions imply messages should be visible in the lower left hand corner - this is not the case until a client connects. If anyone prefers a version of iServer that never acquires port 3639 and therefore always requires a hub then v 1.0.9 is available upon request. There are no other changes.


K

PS Please note that if you use 'Weather Display' then older versions implement xAP incorrectly using a CR rather than LF delimiter and are known to crash many xAP applications including this current version of iServer. This was corrected in Weather Display version 10.370 build 12 19Sept2009 so please ensure you update. Previous KCSoft xAP hubs transparently corrected this problem but the latest xFX hubs do not.

iServer runs 24/7 and has proven totally robust for me, but I want to ensure that it's impervious to any and all malformed xAP messages . Should you find any examples that cause it to runtime error then please send a Viewer capture of the xAP message in both ASCII and hex to my email address.

[Kevin]

Just this morning one of my Jogglers rebooted itself and when I looked at the menu the xAP app had gone. I now see its running a 25th June 2010 firmware build so it has auto updated. It's late (early) and I haven't yet had an opportunity to check what's changed but my SCP logon is gone too.

So just whilst I check I would strongly recommend people disable auto updates FTTB (see Joggler forum/Wiki).

I haven't seen any issues reported on any of the forums re this but if anyone does then let me know....

K

UPDATE: Although the software update removed my additional apps and disabled the SSH/SCP access things do reinstall OK so an inconvenience rather than a problem. On this particular Joggler I had installed the apps into the openpeak/gui/apps directory and so I guess this is perilous. I didn't have any custom apps in the media/appshop directory so I don't know if they would have been removed from there or not. Here's a link to a thread about disabling updates should you wish to do it...
http://www.joggler.info/forum/viewtopic.php?f=33&t=344

[kev_t]

Thought I would post my first couple of Joggler screens to encourage others to do the same and share what can be done.

These were created under beta4.

The first one is set up to link to my Livebox HAH controller, see http://www.dbzoo.com/livebox/hah, where the top row controls 4 RF mains plugs, the next row controls the 4 onboard relays, followed by the 4 inputs which i have linked to switches. Th bottom row displays the first 4 1-wire temperatures and on the bottom right are buttons for the CurrentCost Envi CC128 (bit of a problem with the watts at the moment)

The second one is an attempt at a basic control panel for central heating and hot water and shows the temperature profile of the hot water tank derived from 1-wire temperatures connected to a Quasar K3145 logger and also show the use of external graphics for the buttons

KevinT
(the other kevin)

[Otto-Mate]

Nice Kevin. Anyone else got some images to post?

Thanks

M.