ViewPorts

---

Current status

Active development: ViewPorts Design Proposal, FlySpray entry, Forum thread.

---

A Brief Outline of Viewports

Currently, WPS layouts in Rockbox are line based, and contain information to be displayed across the whole screen. This makes laying out information on the screen when doing initial design quite tedious, as you have to keep trying different numbers of carriage returns to get your positioning right. With the Viewports concept it is possible to divide the DAP's screen into discrete areas which can contain different information. The line-based theme is kept within each Viewport to make backwards compatibilty easier - but the concept should allow per-pixel placement of the Viewport boundaries.

Currently the user interface as implemented in Rockbox is a seperate screen for each type of content within Rockbox. The concept of Viewports is to try to divide the screen of a given DAP up into discrete windows, or virtual screens which can be written to seperately by various Rockbox tasks, and have that information displayed all in one place (i.e. the physical screen on the DAP).

This may be seen as analogous to the original implementation of Windows, which divided the screen of a PC up into seperate areas.

Further enhancements to Viewports down the line might include the ability to overlap these areas - but the initial implementation will probably not include this feature.

---

A Sample of How a Viewports Layout in Rockbox Might Look

This initial "concept artwork" is probably a long way off, as it includes both WPS elements, and the main menu. The first attempt at Viewporting will probably only apply to the WPS screen itself, and the elements currently available for display on it.

---

Comments

• Pixel-based placement should be considered for all elements. When multiple fonts are supported the concept of what a 'line' is becomes less clear, and since we're breaking current WPS syntax anyway we should opt for the cleaner design.
• Viewports on a code level should be layered as deep into the text/graphical api as possible, probably into lcd_puts() and the equivalent base graphical functions. This allows the statusbar and the rest of the UI to be implemented as viewports, potentially also allowing these to be themeable (eventually).
• Overlapping viewports is not a problem since we run as a single process. Keeping track of existing elements/being sure not to overwrite anything should be done by the caller, not by the viewports API. This may require a per-viewport redraw callback.
• I have some idea of how this should look/work but it all is waiting on my font work which is progressing (slowly). -- BernardKethlayne

---

Related Pages

• ViewPortsDesign - More detailed information on the ViewPorts design.

---