Dynamic Menu system

[Garth Bushell]

Hey,

I've been hacking crazily on the firmware and have come across desire for an up loadable menu for Apps. 

The major problem is going to be that I can't add messages to the watch firmware to be received by the phone. (I think I can do it the other way) which could cause a problem. 

But I would like to go even further. I'd like the android watch app to register with the MWM which would push the app to a menu on the watch. It would register an intent that it could do communication with the app. 

This app could then be accessed by going to the phone menu and selecting the app. 

This would then send a message to the MWM which would send the intent to the registered app. (Or maybe use metadata published with the app so cicada knows the app is a watch app.)

This would then start a conversation with the watch / app. 

At the moment cicada uses MWM to communicate with the metawatch.

But it might be better and more flexible to do all protocol and watch management in cicada as what cicada is doing is working around a flaw in the MWM intent design. The code in MWM is quite small and maybe could be made into library. 

Any thoughts?

Garth

[Joe Hughes]

Hey, Garth. I'm glad you're interested in this stuff. I'm a little
confused by your message--at this point Cicada *does* talk to the
watch directly, for exactly the reasons that you mentioned. After
getting frustrated by the bugginess/incompleteness of the MWM intents
protocol, I just the watch wire protocol myself in Cicada.

Have you had a chance to play around with Cicada and the sample apps
to see how it works?

Cheers,
Joe

[Garth Bushell]

Hi Joe,

Ah sorry my mistake! I should read more carefully.

I have only quickly read about it and a did quick code inspection.

having only 20 days left of my IAR license so am concentrating on firmware improvements and being strict with my time on other things. 

Your protocol implementation is so much nicer that the MWM one. (I see you've heard of constants.)

Looks like we're on the same page looking more deeply at your code. 

I'm going to knock up a menu system tonight .Here's a rough overview of how I see it from an api view.

This encapsulates the info I'll encode in a message

MenuId MenuCreateMsg(String name)

// do you want text or icons or both?

ItemId MenuAddItemText(MenuId menuid, String text, icon)

ItemId MenuAddSubMenu(MenuId menuid, MenuId submenu, icon)

MenuShow(MenuId menuid)

Then there will be a response message which return the MenuId + ItemId of the item selected.

How does this sound?

Cheers

Garth

--
You received this message because you are subscribed to the Google Groups "Cicada" group.
To post to this group, send email to cicad...@googlegroups.com.
To unsubscribe from this group, send email to cicada-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cicada-dev?hl=en.

[Joe Hughes]

Hey Garth,

I was thinking along slightly different lines for the menuing system,
where the phone would send a bitmap, the watch would cycle through
selection regions. I did a more thorough writeup in this forum
thread:
http://www.metawatch.org/forums/thread/71/firmware-enhancement-wishlist

That would allow for whatever combination of text & images the app
author wanted, without having to bake it into the protocol. (On the
other hand, it would take longer to send it over the bluetooth
connection than individual icons or strings.)

At the moment, I'm most interested in text, because I think text is
easier than low-res UI bitmaps for hackers to do a decent job at. :]

Incidentally, how does Cicada identify the firmware version so that it
can know that the watch it's talking to supports fancier menuing
features? I definitely want Cicada to work with stock firmware out of
the box (that is, at least have a fallback implementation similar to
what it has today), so preferably it can query the watch to see what
fancy features it can use.

Anyway, I'm definitely excited that you're investigating watch-side
menuing; that has the potential to greatly increase the responsiveness
of watch interactions. I've wanted watch-side menus (and timer/clock
regions) for a long time.

Cheers,
Joe

On Oct 5, 2:26 pm, Garth Bushell <garth.bush...@gmail.com> wrote:
> Hi Joe,
>
> Ah sorry my mistake! I should read more carefully.
> I have only quickly read about it and a did quick code inspection.
> having only 20 days left of my IAR license so am concentrating on
> firmware improvements and being strict with my time on other things.
>
> Your protocol implementation is so much nicer that the MWM one. (I see
> you've heard of constants.)
>
> Looks like we're on the same page looking more deeply at your code.
>
> I'm going to knock up a menu system tonight .Here's a rough overview of how
> I see it from an api view.
> This encapsulates the info I'll encode in a message
>
> MenuId MenuCreateMsg(String name)
>
> // do you want text or icons or both?
> ItemId MenuAddItemText(MenuId menuid, String text, icon)
>
> ItemId MenuAddSubMenu(MenuId menuid, MenuId submenu, icon)
>
> MenuShow(MenuId menuid)
>
> Then there will be a response message which return the MenuId + ItemId of
> the item selected.
>
> How does this sound?
>
> Cheers
>
> Garth
>

[Garth Bushell]

Ah it's impossible to find stuff on the forum sometimes 

Yeah the other thing on my list is stopwatch / timers. 

Was thinking of using button b to switch the widget view to a timer view. 

Or maybe just add it to a menu. 

Still thinking about that.

Maybe we should get the metawatch people to agree on a caps flag?

So we can query the capabilities of the watch. This would help out having differing firmware.

If you get the version of my firmware I put a G at the end of the version.

Here's the rough menu system. 

http://garthy-com.blogspot.com/2011/10/metawatch-phone-based-watch-menus.html

Next I may add a list view where the menu is a large list and the watch asks for the items.

The bitmap menu is probably possible. Maybe some compression of the screen could happen so we reduce the messages? 

Hmm. more to think about. 

Laters.

Garth

[Joe Hughes]

Garth,

This is fantastic, you're making impressive progress!

The main thing that would make it even better is the ability to show
longer strings associated with each menu item; the current Cicada menu
can fit 15 characters for each selection. This would help a lot when
letting users pick between apps.

I think what we're doing now has a lot of potential for influencing
the mainline firmware, so we should decide what we think would work
best in the long term for the protocol. The two main options seem to
be either just add new top-level messages, or define a new top-level
message code that wraps another namespace of message codes that we
define.

As for identifying firmware features, I think I'd be happiest with
just using a firmware version identifier string with a lookup table in
Cicada to tell me whether a specific version supports the specific
feature *as I use it*. Having flags for supported features (or a list
of supported message codes) is another possibility, but I fear that
that's not expressive enough to express the differences in
implementation/bugginess which might sometimes make the difference
between Cicada using a particular feature or not.

Anyway, nice work!

Cheers,
Joe

On Oct 6, 1:59 am, Garth Bushell <garth.bush...@gmail.com> wrote:
> Ah it's impossible to find stuff on the forum sometimes
>
> Yeah the other thing on my list is stopwatch / timers.
> Was thinking of using button b to switch the widget view to a timer view.
> Or maybe just add it to a menu.
>
> Still thinking about that.
>
> Maybe we should get the metawatch people to agree on a caps flag?
>
> So we can query the capabilities of the watch. This would help out having
> differing firmware.
>
> If you get the version of my firmware I put a G at the end of the version.
>
> Here's the rough menu system.
>

> http://garthy-com.blogspot.com/2011/10/metawatch-phone-based-watch-me...

>
> Next I may add a list view where the menu is a large list and the watch asks
> for the items.
>
> The bitmap menu is probably possible. Maybe some compression of the screen
> could happen so we reduce the messages?
>
> Hmm. more to think about.
>
> Laters.
>
> Garth
>