• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category Utils
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by mcuelenaere - 2008-09-28
Last edited by mcuelenaere - 2010-06-06

FS#9424 - WPS editor rework: use native LCD drawing system instead of Qt's one

See title description.

Old description

This patch tries to use the native Rockbox font system instead of relying on Qt’s one.

But due to my lack of knowledge of the Rockbox font format/mono bitmap format, the result currently is only garbage as output.

(When using the patch, don’t forget to modify the hard coded font path)

Closed by  mcuelenaere
2010-06-06 17:04
Reason for closing:  Fixed
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

The new theme editor should replace this.

Fix filesize()

This is a complete rework of libwps, but it currently crashes in lcd_mono_bitmap_part() when drawing strings (probably due too no font being available?)

I’ve shortly looked at the patch. Your current approach definitely sounds better to me (the editor should use as much existing code as possible).

That’s why I’m curious you re-implement/copy some functions, like lcd_putsxyofs or lcd_update.

That’s because the original patch was intended to use the original approach while the newer one has a complete new one, and I apparently forgot to delete the old lcd_putsxyofs() implementation.

lcd_update() on the other hand needs to be implemented, how would the framebuffer otherwise get shown on the screen?

lcd_update_rect has to be reimplemented, lcd_update uses lcd_update_rect and could thus be taken from the original source.

Update WPS editor source to work with current SVN, still not working because Qt can’t interpret the framebuffer correctly (wrong colours are displayed).

A frequent problem I’ve run into is: whenever the WPS source code changes, it requires changes to libwps/.

As this is rather inflexible, I would like to suggest an other approach for the WPS editor:
why don’t we extend the existing UI simulator so it can get built as a lib and as an app (kinda like libwps) and build the WPS editor app around this lib, while still using SDL but integrated into Qt as a widget.

This would give the benefit that whenever something gets changed in apps/, obviously this shouldn’t break uisimulator/ so it also won’t break the WPS editor (compared to now, code should get checked whether it runs in the simulator and in wpseditor/libwps/).

Comments, thoughts?

It’s sad to hear that it’s not working as supposed to be. Wasn’t it supposed to use Rockbox code and need a minimum of “sync’s” the main tree?

Using the a “simulator-lib” in the wps editor would probably be better.
Especially as the wps editor doesnt use the internal wps tree of rockbox, at the moment it uses rockbox code only for display.
Also such a simulator-lib could be used in other apps (for example a preview in rbutil, or for building tagcache).

So if someone has the time and motivation to change this, go forward !!

@ kugel: it uses rockbox code, but wraps it into a libwps, which needs maintainment when wps code changes.

This is a start at how I integrated the simulator into WPS editor.

It’s functional as in running the simulator from within WPS editor, but that’s it atm.
The WPS editor can’t get the simulator to load specific WPS files nor can it control its state.


Available keyboard shortcuts


Task Details

Task Editing