• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category User Interface
  • Assigned To
  • Operating System Another
  • Severity Medium
  • Priority Very Low
  • Reported Version Release 3.7.1
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by dionoea - 2011-01-22
Last edited by dionoea - 2011-01-29

FS#11902 - Android Widget

The attached patch adds a Rockbox control widget for the android application.
It displays the title, artist and album when a track plays and features a play/pause button and a next track button. Clicking on the text label launches the Rockbox application. Icons from the cabbiev2 theme are used.

The widget-*.png files are screenshots corresponding to the current code.

Closed by  dionoea
2011-01-29 20:48
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Now in svn.

Cool! I had the idea of doing this by displaying Rockbox’s remote LCD as widget, but this works too.

Yeah, I thought about that too but it seemed way too complicated :) (It becomes even more complicated once you realize that widgets run as separate processes and that you can have more than one)

Btw, as stated on IRC, there are 2 remaining issues which would probably need to be fixed:
- The buttons do not work unless the application is already running. I see two solutions to this problem: send the key intents to the activity instead and make it launch without taking focus, or keep the current code which sends the intents to the service and properly start it (I do not know what changes to the code this would imply).
- The PLAYBACK_EVENT_TRACK_FINISH event occurs a bit too soon which leads to the current track info being cleared before the track actually ends (something like 2 or 3 seconds early). According to amiconn this is a know issue with that event.

how much control over the touch area do widgets have? It would be pretty awesome if the look is entirely skin driven. the text is easy but placing buttons need the widget to be able to know x/y coords of where it is pressed without placing real buttons on it.

I’m not sure that we have much control. As far a I understand the only information we have is that an interface element was clicked. We could still emulate (x,y) coordinates by adding a transparent button grid on top of the widget. To be honest, I doubt that using a skin would be feasible and would integrate well with the OS (for example with trackball button highlighting). See for more info about the usable elements and, which seems to be the only way of getting user interaction.

An alternate widget layout is used in the attached screenshot. A 2×2 grid seems to have a bit more usable space than the 4×1 one.

I’d like a 2×3 one with album art :)
Can you please seperate out changes that simply rename variables and other unrelated ones? It makes the patch harder to read.

I don’t think the widget necessarily needs to themable. While it would be nice it shouldn’t be a requirement IMO. I also think it shouldn’t act as a remote display. I can’t see a practical reason for it, but it would make homescreen look ugly.

nice contradictory reply there :)

with some limits on the touch ares (no popups) we could populate the widget with invisible buttons using the skin engine, that way we could allow the user to load up their homescreen with any number of any shaped widgets they want!

I think allowing a single remote LCD widget would also be nice (and this doesnt have to be a one-or-the-other thing)

actually tihnking about it for more than a second, drawing into that “screen” could cause some interesting problems in the rockbox code.

There are no “variable renaming” only changes in this patch (at least none which could be extracted in a meaningful way). I’ll try to extract the build system changes though, as those are really independent from the actual widget code.

Edit: about allowed widget sizes, seems to imply that you can only have 4×1, 2×2 and 3×3 sized widgets, which is a bit weird since I’ve been able to create a 4×4 one too. This doesn’t seem to be a hard restriction but we might want to stick to one of these 3 sizes.

you for sure can create 4×4 widgets, and probably bigger on tablets :)
I’d really like to eventually see a UI to choose the size and what is displayed (with that leading to eventually skinning capabilities :) ) but this is a great first go

I don’t know if widget sizes can be changed at runtime. I haven’t seen anything to that effect in the android sdk documentation. I’ll try to see if it’s possible using a widget configuration activity ( ).

Edit: Nevermind: “This Activity will be automatically launched by the App Widget host and allows the user to configure available settings for the App Widget at create-time, such as the App Widget color, size, update period or other functionality settings.”

I think they can, try adding the default power widget somewhere in adw.launcher and choosing the edit option after longpressing it.
It looks like runtime changeable, however it could just reinit the widget under the hood. (this is from an user POV)

(Tested on SGS Android 2.2.1)

As far as I can tell from all the information I could find on the web, you need one widget entry in the menu per widget size. The widget size cannot be changed from the configuration activity with the standard android API. I’ll probably update the patch to provide 2 widget sizes as an example.

Can you provide an updated patch now that parts of it are committed to svn please?

I’ll upload the updated patch this weekend. I haven’t had time to finish writing support for multiple widgets yet.

So here it comes. This updated patch comes with 2 different sizes (4×1 and 2×2) as well as a configuration activity to chose which buttons to display in each widget instance. The two issues mentioned previously still exist. Comments are welcome.

Edit: A third issue is that track info is only available after the first track change which follows widget creation. So if Rockbox was already playing music when you decided to create a widget it won’t display that track’s info. That could be fixed fairly easily by sending an intent from the widget upon creation to request updated info if any.

Edit 2: Add git patch.

After applied the patch to a clean SVN checkout I get the following errors when I run make apk:

jpoppe@astray98:~/Android/rockbox/android$ make apk
AAPT bin/resources.ap_
/home/jpoppe/Android/rockbox/android/res/layout/appwidget_2x2.xml:11: error: Error: No resource found that matches the given name (at ‘src’ with value ‘@drawable/rockbox’).
/home/jpoppe/Android/rockbox/android/res/layout/appwidget_configure.xml:8: error: Error: No resource found that matches the given name (at ‘src’ with value ‘@drawable/rockbox’).
/home/jpoppe/Android/rockbox/android/res/drawable/appwidget_background.xml:4: error: Error: No resource found that matches the given name (at ‘drawable’ with value ‘@drawable/appwidget_background_normal’).
/home/jpoppe/Android/rockbox/android/res/drawable/appwidget_infodisplay_background.xml:4: error: Error: No resource found that matches the given name (at ‘drawable’ with value ‘@drawable/appwidget_selection_clicked’).
/home/jpoppe/Android/rockbox/android/res/drawable/appwidget_infodisplay_background.xml:5: error: Error: No resource found that matches the given name (at ‘drawable’ with value ‘@drawable/appwidget_selection_over’).
/home/jpoppe/Android/rockbox/android/res/drawable/appwidget_infodisplay_background.xml:6: error: Error: No resource found that matches the given name (at ‘drawable’ with value ‘@drawable/appwidget_selection_transparent’).
/home/jpoppe/Android/rockbox/android/res/drawable/appwidget_next.xml:4: error: Error: No resource found that matches the given name (at ‘drawable’ with value ‘@drawable/appwidget_ff_normal’).
/home/jpoppe/Android/rockbox/android/res/drawable/appwidget_pause.xml:4: error: Error: No resource found that matches the given name (at ‘drawable’ with value ‘@drawable/appwidget_pause_normal’).
/home/jpoppe/Android/rockbox/android/res/drawable/appwidget_play.xml:4: error: Error: No resource found that matches the given name (at ‘drawable’ with value ‘@drawable/appwidget_play_normal’).
/home/jpoppe/Android/rockbox/android/res/drawable/appwidget_prev.xml:4: error: Error: No resource found that matches the given name (at ‘drawable’ with value ‘@drawable/appwidget_rew_normal’).
/home/jpoppe/Android/rockbox/android/res/drawable/appwidget_stop.xml:4: error: Error: No resource found that matches the given name (at ‘drawable’ with value ‘@drawable/appwidget_stop_normal’).
make: *** [/home/jpoppe/Android/rockbox/android/bin/resources.ap_] Error 1

jpoppe@astray98:~/Android/rockbox/android$ svn up
At revision 29161.

poppe@astray98:~/Android/rockbox/android$ cat rockbox-info.txt
Target: application
Target id: 100
Target define: -DAPPLICATION
Memory: 8
CPU: hosted
Manufacturer: android
Version: r29159M-110129
Binary size: 848267
Actual size:
RAM usage: 0
Features: crossfade:lcd_bitmap:lcd_non-mono:lcd_color:pitchscreen:quickscreen:swcodec:tagcache:touchscreen:large_plugin_buffer:ab_repeat_buttons:albumart
gcc: arm-linux-androideabi-gcc (GCC) 4.4.3
ld: GNU ar (GNU Binutils) 2.19
Host gcc: gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Host system: Linux

It looks like you’re missing the png files. They’re not in the svn patch so you need to add them manually.

That fixes the problem, thanks! Sorry for the spam, I thought only screenshots were attached.

Looks rather nice to me, although I think the title/artist/artist lines shouldn’t be line-wrapped (can it scroll?). It looks awkward for long titles and makes it difficult to differentiate between the 3.
Adding a 3×3 widget simple.

I’d like it to scroll too but haven’t found if/how that’s possible with regular view elements (in our case a Button object). Having some of the text in bold (like the track title) might also help a bit.
I can add a 3×3 widget if you want (although if you were to ask me I’d say that 3×3 widgets kind of defeat the purpose since they don’t leave much space for other elements on the screen … except maybe on tablets. that’s unless you add album art in which case it might make sense).

Oh, my sentence was horrible (and hence unclear), I already added a 3×3 widget locally.

Albumart could fit well in this 3×3 one. I don’t feel I waste space, my home screens aren’t full of app icons :)

Ah ok, nice. About scrolling, it seems that an attribute ( allows scrolling but that it is only effective (at least for widgets) if the TextView has focus.

Let me know if you feel that this can be commited to svn or if some changes are required.

I think it’s a great start so no problem if it’s in SVN. Perhaps move the RockboxWidget* files into a subfolder?

I wonder if it makes sense to make it a separate app? Widgets cannot really be moved to the sdcard.

Commited to svn in r29170.


Available keyboard shortcuts


Task Details

Task Editing