Hi all.
Does anyone have an opinion on the final version of FS #12288?
http://www.rockbox.org/tracker/task/12288
Or please apply this patch.
Provides an easy way to access the WPS (or previous music) from the main menu,
by pressing home a second time.
This is specifically for the Clip
On 2 March 2011 22:07, Thomas Martitz
wrote:
> Am 02.03.2011 11:41, schrieb Jonathan Gordon:
>>
>> I've recently added some fun stuff to the skin engine which gives up
>> more control over popping up stuff because of touches. So does anyone
>> have a problem with me changing the touch cabbies to o
Am 02.03.2011 11:41, schrieb Jonathan Gordon:
I've recently added some fun stuff to the skin engine which gives up
more control over popping up stuff because of touches. So does anyone
have a problem with me changing the touch cabbies to only popup the
current popup menu if the AA area is pressed
I've recently added some fun stuff to the skin engine which gives up
more control over popping up stuff because of touches. So does anyone
have a problem with me changing the touch cabbies to only popup the
current popup menu if the AA area is pressed?
Also I want to add a demo for the other chang
On 26/02/11 21:39, Thomas Martitz wrote:
Am 25.02.2011 12:43, schrieb Alex Parker:
Er, I somehow managed to send that while typing...
So, If the notification goes away on pause I'd be a fan of that.
Done now. Hopefully we don't need a separate stop button now.
Best regards.
Cool, fine by
Am 25.02.2011 12:43, schrieb Alex Parker:
Er, I somehow managed to send that while typing...
So, If the notification goes away on pause I'd be a fan of that.
Done now. Hopefully we don't need a separate stop button now.
Best regards.
On 24/02/11 23:06, Alex Parker wrote:
Hi all,
1) Currently RaaA (Android, Maemo etc.) follow the same system as normal
targets for the play/pause icon on the WPS - they show playback state.
However on a touchscreen this feels odd as they should show what
clicking on the icon will do. I'd
;>>
>>> Alex
>>>
>>
>>
>> I don't mind any of the points except the extra stop button. There's just
>> too little space for it on the WPS.
>> However, we can change that the notification symbol goes away at pause
>> already.
>
tra stop button. There's just
> too little space for it on the WPS.
> However, we can change that the notification symbol goes away at pause
> already.
>
> I made the cabbies with existing cabbies in my mind, I thought they should
> all look similar. Now if you think the
Am 24.02.2011 23:06, schrieb Alex Parker:
Any thoughts/objections?
Alex
I don't mind any of the points except the extra stop button. There's
just too little space for it on the WPS.
However, we can change that the notification symbol goes away at pause
already.
I made the ca
Oh, I remember a gripe I've had on the 800x480 cabbie. The AA area is
the button for playlist viewer and there is no touch button to get
back to the main menu.
6) The AA area should be the HOTKEY button
7) The popup should include a main-menu button
On 2/24/2011 4:12 PM, Jonathan Gordon wrote:
Firstly its all touch targets not just RaaA. Secondly i agree with
pretty much all of it except the need for a STOP button. (long play is
fine)
I'm not sure long play is particularly intuitive or obvious. We mainly
only use it on other targets whe
On 25 February 2011 09:06, Alex Parker wrote:
> Hi all,
>
> 1) Currently RaaA (Android, Maemo etc.) follow the same system as normal
> targets for the play/pause icon on the WPS - they show playback state.
> However on a touchscreen this feels odd as they should show what clickin
Hi all,
1) Currently RaaA (Android, Maemo etc.) follow the same system as normal
targets for the play/pause icon on the WPS - they show playback state.
However on a touchscreen this feels odd as they should show what
clicking on the icon will do. I'd like to swap this.
2) At lea
On 16 April 2010 17:46, Marcin Bukat wrote:
> 2010/4/16 Jonathan Gordon :
>> Hi all,
>> Well I'm stumped on this bug
>> (http://www.rockbox.org/tracker/task/11175 ). Basically what happens
>> is if you use a wps with the playlist viewer (attached should work on
&g
On 16 April 2010 17:07, Jonathan Gordon wrote:
> Hi all,
> Well I'm stumped on this bug
> (http://www.rockbox.org/tracker/task/11175 ). Basically what happens
> is if you use a wps with the playlist viewer (attached should work on
> every target) the playlist will load in
On 17 April 2010 21:16, Magnus Holmgren wrote:
> * It uses quite a bit of stack (about 2700 bytes, on ARM at least). Probably
> not a problem, but checking stack usage could perhaps be an idea.
>
> * Looks like "buf" (in draw_playlist_viewer_list) can overflow. Consider
> what happens if "buf_used
On 17 April 2010 21:16, Magnus Holmgren wrote:
> On 2010-04-16 09:07, Jonathan Gordon wrote:
>
>> Well I'm stumped on this bug
>> (http://www.rockbox.org/tracker/task/11175 ). Basically what happens
>> is if you use a wps with the playlist viewer (attached should
On 2010-04-17 13:16, Magnus Holmgren wrote:
* Looks like "buf" (in draw_playlist_viewer_list) can overflow. Consider
what happens if "buf_used" goes larger than "sizeof(buf)"... Suggestion:
use strlcat instead. Protects against overflow and simplifies the code.
Don't know if that's what causing
On 2010-04-16 09:07, Jonathan Gordon wrote:
Well I'm stumped on this bug
(http://www.rockbox.org/tracker/task/11175 ). Basically what happens
is if you use a wps with the playlist viewer (attached should work on
every target) the playlist will load in the wrong order and Wierd Shit
(TM) ha
2010/4/16 Jonathan Gordon :
> Hi all,
> Well I'm stumped on this bug
> (http://www.rockbox.org/tracker/task/11175 ). Basically what happens
> is if you use a wps with the playlist viewer (attached should work on
> every target) the playlist will load in the wrong order
Hi all,
Well I'm stumped on this bug
(http://www.rockbox.org/tracker/task/11175 ). Basically what happens
is if you use a wps with the playlist viewer (attached should work on
every target) the playlist will load in the wrong order and Wierd Shit
(TM) happens when jumping around tracks. If yo
the button at the touch
position is armed. Upon a touch repeat or release, the button at the
touch position is triggered only if it is armed. Upon release (and wps
entry), all buttons are disarmed. E.g. when you touch press on an empty
area, then while pressing drag your finger on a button, th
Rob Purchase wrote:
I don't think you can do that with current SVN either...
Maybe I misunderstood his first post. If I understand correctly his
description of its current behaviour is "when the screen is touched,
change the screen contents and do whatever is under the location of the
touch"
On 08/02/2010 19:02, Paul Louden wrote:
Rob Purchase wrote:
That sounds like an improvement on the current situation already.
Others may disagree, but I'd say go ahead and patch it... no option
necessary.
The old option is still useful isn't it? How would you do "buttons
that are always vi
On 08/02/2010 19:14, Jonathan Gordon wrote:
Actually, while we are here, whats the general plan for touchscreen
support in the sbs? do we want to allow buttons outside of the UI
area? Also, is the tag for "which touch mode is it in?" in svn yet?
Buttons outside of the UI area might be usef
Am 08.02.2010 20:01, schrieb Jonathan Gordon:
> On 8 February 2010 10:54, Rob Purchase wrote:
>
>> On 08/02/2010 16:56, Jens Theeß wrote:
>>
>> I then hacked the source to have %Tl turn to true on the touch release, not
>> press. This way, I have to touch once to show the viewport containing th
Am 08.02.2010 20:14, schrieb Jonathan Gordon:
> On 8 February 2010 11:04, Rob Purchase wrote:
>
>> On 08/02/2010 19:01, Jonathan Gordon wrote:
>>
>>> Agreed, although I wonder why we dont have it ignoring touches until a
>>> release happens so the buttons show up instantly but dont do anyt
On 8 February 2010 11:04, Rob Purchase wrote:
> On 08/02/2010 19:01, Jonathan Gordon wrote:
>>
>> Agreed, although I wonder why we dont have it ignoring touches until a
>> release happens so the buttons show up instantly but dont do anything?
>>
>
> Good point. Who implemented it anyway?
>
> ;-)
>
On 08/02/2010 19:01, Jonathan Gordon wrote:
Agreed, although I wonder why we dont have it ignoring touches until a
release happens so the buttons show up instantly but dont do anything?
Good point. Who implemented it anyway?
;-)
Rob.
Rob Purchase wrote:
That sounds like an improvement on the current situation already.
Others may disagree, but I'd say go ahead and patch it... no option
necessary.
The old option is still useful isn't it? How would you do "buttons that
are always visible, but change color when touched" or
On 8 February 2010 10:54, Rob Purchase wrote:
> On 08/02/2010 16:56, Jens Theeß wrote:
>
> I then hacked the source to have %Tl turn to true on the touch release, not
> press. This way, I have to touch once to show the viewport containing the
> buttons, and once again to activate a touch button, a
On 08/02/2010 16:56, Jens Theeß wrote:
I then hacked the source to have %Tl turn to true on the touch
release, not press. This way, I have to touch once to show the
viewport containing the buttons, and once again to activate a touch
button, as intended. This would be ok for me, even though th
Jens Theeß wrote:
I'll clean up my patch and instead of changing the behaviour of %Tl, I
could introduce a new variable (e.g. %Tk) which turns true on the
touchscreen release. Would a patch like this be accepted to the main
trunk? Or do you have a better idea of implementing the wanted behavi
veloper for ten years.
I'd like to implement a WPS similar to the original firmware of the D2:
* By default, the WPS shows only song infos, no touch buttons.
* When pressing the touchscreen (on the press, not release), touch
buttons for play/pause, skip, volume etc. are s
2010/1/12 Nils :
>> So, any thoughts? comments?
>
> Cool!
> I always thought the limitation to only show info on the next track
> was a bit weird.
>
Just to make it absolutely perfectly clear. This can only display as
much info as has been buffered. It doesn't load any metadata from
disk, if its n
> So, any thoughts? comments?
Cool!
I always thought the limitation to only show info on the next track
was a bit weird.
mised playlist
viewer on the WPS (or SBS) using the id3 info from tracks which are
buffered and only the filename for those which arn't (so no extra disk
accesses).
Its obviously not going to be for everyone, and I'm sure someone will
say it doesnt go far enough (customisability wise), but
Jonas Häggqvist schrieb:
So why don't you just do whatever magic happens when any .cfg file is
loaded when a .wps file is loaded also?
I applied this magic for wps loading in r22354, so the problem should be
fixed.
I suggest either fixing this ASAP, or reverting until the patch is
Jonathan Gordon wrote:
> Hi all,
> I thing I forgot to mention in the commit message for r22350 is that
> you should load your .wps files from .cfg theme files (i.e not
> directly in the file browser), this is probably something you never do
> anyway, but I feel I need to let oyu kn
Apparently I wasnt clear enough...
This message was only really meant for themers (who I think have more
intelligence than brain dead monkeys), normal users will NEVER see
this issue the only possible way to have this come up is you load
keep loading .wps files in the browser (and they have
Hi all,
I thing I forgot to mention in the commit message for r22350 is that
you should load your .wps files from .cfg theme files (i.e not
directly in the file browser), this is probably something you never do
anyway, but I feel I need to let oyu know anyway...
The new memory management stuff
>> wrong buffer_alloc(), I'm using the one which steals some
>> audio_buffer before playback starts...
/me is slightly happier ;)
pondlife
it seems to have become malloc-by-proxy. :)
>
> pondlife
>
wrong buffer_alloc(), I'm using the one which steals some audio_buffer
before playback starts... (now if we just had one malloc there wouldnt
be this confusion :D )
2009/8/14 Thomas Martitz :
> how does it work in it
A small (but probably non-useful) comment:
I originally envisaged buffering as being a strictly file-based thing - a
layer on top of file i/o, rather like dircache.
You'd "bufopen" a list of files you were planning to read and it would
attempt to pre-read them into memory. You'd then "bufread"
Jonathan Gordon schrieb:
So, does anyone have any objections to me commiting it as it is (after
the needed error handling code is added)?
Jonathan
how does it work in it's current state, and how's it supposed to work
finally?
I'm thinking we could just buf alloc the w
> I think it's highly unlikely that someone would propose a commit that
> makes rockbox unusable.
What about as a plugin? :)
/me scraps his brickbox idea...
Marc
On Fri, Aug 14, 2009 at 11:27:26AM +0200, Al Le wrote:
> On 14.08.2009 08:44, Jonathan Gordon wrote:
>
>> The patch isnt 100% complete, but I dont want to keep working outside
>> of svn on it because the previous attempt died when the patch got too
>> huge and a small change somewhere broke everyth
On 14.08.2009 08:44, Jonathan Gordon wrote:
The patch isnt 100% complete, but I dont want to keep working outside
of svn on it because the previous attempt died when the patch got too
huge and a small change somewhere broke everything...
So, does anyone have any objections to me commiting it as
Hey all,
A while ago I started a patch which moves the statically allocated WPS
buffers (image, viewport, strings, progressbars, etc) into a single
buffer_alloc()'ed buffer to make it less wasteful and to remove
annoying arbitrary limits in the wps. Anyway after the recent
wps->skin w
code cleanup.
> So if someone could please tell me what file I should be patching instead
of
> gwps.c I would appreciate it.
>
Look through each of the functions your patch changes, and find them in
the current source code. For this you can look at the SVN commit logs or
us
> So if someone could please tell me what file I should be patching instead of
> gwps.c I would appreciate it.
>
Look through each of the functions your patch changes, and find them in the
current source code. For this you can look at the SVN commit logs or use "grep
-r" to search for them i
Hi list.
I am wondering if someone could please give me some advice on resyncing a
patch as there has been some extensive cleanup on the wps.
Because a lot of files were deleted and replaced with new ones in r. 22062.
My question specifically relates to a patch that I have which used to
After the description of the action upon file selection has been unified
(with FS#10038), I'd like to draw your attention to a similar patch. It
unifies the descriptions of WPS tags.
As of now, some WPS tags are described with just what the tag produces
(e.g. "Current track"),
On Sun, Jan 25, 2009 at 10:29 AM, Jens Arnold wrote:
> On 24.01.2009, Dominik Riebeling wrote:
> 1) wpsbuld.pl had several bugs. One was to not check for plain
> "Font:", fixed by Thomas, which made it include too little.
> This also caused that only the font for cabbiev2 was
> included, whi
On 24.01.2009, Dominik Riebeling wrote:
> On Sat, Jan 24, 2009 at 5:02 PM, Thomas Martitz
> wrote:
>> Fonts are part of a theme, as designed by the author. A theme
>> without working font is just as broken as if would show ...
> We intentionally (!) did that for several years, and that was
> agr
Jonathan Gordon wrote:
> 2009/1/25 Thomas Martitz :
>> The other thing is, that Rockbox should work out of the box,
>
> We should stop supplying themes in the small zip (apart from cabbie)
I agree with most (if not all) of Thomas' points, and also agree that not
shipping themes in the default zip
Am 24.01.2009 18:09, schrieb Dominik Riebeling:
We intentionally (!) did that for several years, and that was agreed
upon. While I agree that we shouldn't ship themes with missing fonts
(I already made a suggestion about that) a change in the "shipping
contents" should be discussed first. IMO.
On Sat, Jan 24, 2009 at 5:02 PM, Thomas Martitz
wrote:
> Fonts are part of a theme, as designed by the author. A theme without
> working font is just as broken as if would show the build-in wps. And we
> should not ship broken themes. So, either ship the font, or don't ship the
2009/1/25 Thomas Martitz :
> I'd like to point out 3 things:
> Fonts are part of a theme, as designed by the author. A theme without
> working font is just as broken as if would show the build-in wps. And we
> should not ship broken themes. So, either ship the font, or don'
Thomas Martitz wrote:
I'd like to point out 3 things:
Fonts are part of a theme, as designed by the author. A theme without
working font is just as broken as if would show the build-in wps. And
we should not ship broken themes. So, either ship the font, or don't
ship the theme at
thout
working font is just as broken as if would show the build-in wps. And we
should not ship broken themes. So, either ship the font, or don't ship
the theme at all.
The other thing is, that Rockbox should work out of the box, and should
not require extra downloads for core features (and t
Dominik Riebeling wrote:
"Rockbox
Extras", "Additions" or whatever fits (as it isn't a fonts-only
package anymore).
Small problem with that is that we'd need target-specific "extras"
packages at this point, whereas the fonts aren't target specific. This
isn't a big problem, at all, since
On Sat, Jan 24, 2009 at 5:37 AM, Dave Chapman wrote:
> When the fonts were split from the main zip, the reason was to remove the
> virtually static fonts from the ever-changing rockbox.zip. This meant that
after the fonts were split out we intentionally didn't distribute any
fonts with rockbox.z
> Even though it turns out that it was due to a bug, I had
> always thought
> that the behaviour of only including the font required by the default
> theme was intentional. This commit changes that behaviour to include
> the fonts required by all included themes - including the 2MB
> unifont
mai...@svn.rockbox.org wrote:
Date: 2009-01-23 19:34:06 +0100 (Fri, 23 Jan 2009)
New Revision: 19826
Log Message:
Fix wpsbuild.pl not installing all required fonts
Even though it turns out that it was due to a bug, I had always thought
that the behaviour of only including the font required by
hey all,
I've been working on a new WPS tag and one of the problems I've found
with the current system is if the tag needs to store more info than 1
short it needs to create a new struct and put an array of them into
the global wps_data struct (along with a counter of how many are u
>> On the h300 at least, STOP does nothing at all in the playlist viewer,
>> and being able to stop in there would be nice :)
FYI, I've put a bug report up - http://www.rockbox.org/tracker/task/9551.
pondlife
On Thu, Nov 13, 2008 at 8:22 PM, pondlife <[EMAIL PROTECTED]> wrote:
> > I agree with the general feeling here. "Play" should be a consistent
> > "Resume Playback / Return to the WPS" button. As well, on targets where
> > possible, the button that ser
On Thu, Nov 13, 2008 at 3:55 PM, pondlife <[EMAIL PROTECTED]> wrote:
> - Rockbox Info (PLAY performs the disk free space scan, same as SELECT)
>
I think that this hidden button press thing needs to go altogether, it is
not only difficult for users to know about but bloody annoying to start by
acc
> - Debug Manu (PLAY enters the selected item, same as SELECT)
> - Browse x in Settings, where x = Themes, Fonts or .cfg/.wps/.rwps Files
> (PLAY returns to the menu above, same as LEFT). Perhaps oddly, the plugin
> browser works fine.
>
> Before I start looking into making PL
Robert Menes wrote:
> On Thu, Nov 13, 2008 at 9:55 AM, pondlife <[EMAIL PROTECTED]>
> wrote:
>> Before I start looking into making PLAY act as I expect in these
>> cases, does anyone object (or agree)?
>>
>
> I agree for it as well, at least on the H300's case. This will make
> navigation and pl
> I agree with the general feeling here. "Play" should be a consistent
> "Resume Playback / Return to the WPS" button. As well, on targets where
> possible, the button that serves the "Stop" function should stop playback
> in the same places, when/i
> And maybe make play select/play the selected bookmark in the bookmark
> viewer, while at it?
Actually, I'd think it consistent that SELECT played the selected bookmark,
while PLAY just returned to the WPS (resuming from the previous playback if
required).
pondlife
WPS?
2008/11/13 alex wallis <[EMAIL PROTECTED]>:
I didn't actually no
do you mean 'know' ?
think it would be good if we always new
and 'knew' ?
I have noticed you often use these shortcuts, but since the shortcuts
are real words with a completely differ
pondlife wrote:
I think it should, where possible - and we're almost there (on the H300, at
least).
I agree with the general feeling here. "Play" should be a consistent
"Resume Playback / Return to the WPS" button. As well, on targets where
possible, the but
Magnus Holmgren wrote:
And maybe make play select/play the selected bookmark in the bookmark
viewer, while at it?
Magnus
"Select" invokes files, not "Play." "Play" should always be "Resume
playback", even there.
n selected from the Main>Playlists menu (PLAY returns
to the menu above, same as LEFT)
- Sleep Timer (PLAY does nothing)
- Debug Manu (PLAY enters the selected item, same as SELECT)
- Browse x in Settings, where x = Themes, Fonts or .cfg/.wps/.rwps Files
(PLAY returns to the menu above, same
2008/11/13 alex wallis <[EMAIL PROTECTED]>:
> I didn't actually no
do you mean 'know' ?
> think it would be good if we always new
and 'knew' ?
I have noticed you often use these shortcuts, but since the shortcuts
are real words with a completely different meaning, it's quite hard to
follow when
= Themes, Fonts or .cfg/.wps/.rwps Files
(PLAY returns to the menu above, same as LEFT). Perhaps oddly, the plugin
browser works fine.
Before I start looking into making PLAY act as I expect in these cases,
does anyone object (or agree)?
pondlife
Hi. I agree with you on this one.
I didn&
On Thu, Nov 13, 2008 at 9:55 AM, pondlife <[EMAIL PROTECTED]> wrote:
> Before I start looking into making PLAY act as I expect in these cases, does
> anyone object (or agree)?
>
I agree for it as well, at least on the H300's case. This will make navigation
and playback a little easier.
--Rob
--
Marc Guay schrieb:
I agree. I find it frustrating when I stumble across this inconsistency.
Marc
I agree as well. In that turn, can we make power button stop the
playback in every screen as well (on the e200)? It's especially
iritating that it stops in the main menu and in the filebrowser
> Before I start looking into making PLAY act as I expect in these cases, does
> anyone object (or agree)?
I agree. I find it frustrating when I stumble across this inconsistency.
Marc
AY performs the disk free space scan, same as SELECT)
- Playlist Viewer when selected from the Main>Playlists menu (PLAY returns
to the menu above, same as LEFT)
- Sleep Timer (PLAY does nothing)
- Debug Manu (PLAY enters the selected item, same as SELECT)
- Browse x in Settings, where x = The
ere is no console in the windows sim so if your wps
doesnt load and you cant figure out why come on IRC and buzz me
also, be nice with that link... I only have 22KB/s upload
Jonathan
his number may need to be increased...
One thing to note... if you use the %V (or %Vl) tags at all in a .wps,
the default viewport will be parsed and conditionals checked, but it
will not draw anything in that viewport (This is a work around for a
problem where conditionals clear the line they are
2008/6/4 Matthias Mohr <[EMAIL PROTECTED]>:
> What does "given default value" mean for the width and height?
> To use the whole line/height (in the viewport)?
> Or to use the rest of the viewport line/height, beginning at current x/y
> position?
good point... Its actually "broken" still then.
defa
Hi Jonathan,
or %pb|filename|x|y|width|height| where any of them can be left blank
to be given default values... (e.g %pb100|10| would give a non bmp
bar at the viewports x position, the lines y position, 100 wide and 10 high.)
What does "given default value" mean for the width and height?
2008/6/1 Jonathan Gordon <[EMAIL PROTECTED]>:
> Hey all,
> < snip >
Reminder and update...
FS#9051 I tihnk is pretty much ready to go but needs testing
(especially the recording screen.)
FS#9027 still has a bit of work to go but the progress bar stuff is
hopefully fixed now.
progressbar tag synta
First and foremost: Please do not top post. Quote only the part of the
message you need, if any, and do it within your post as you need it.
Can you explain why it breaks the progress bar, please?
The progress bar tag has needed revising for some time. It doesn't treat
coordinates the same wa
Can you explain why it breaks the progress bar, please? From what I've
read on the tracker, it seems you want to remove the restriction to 1 pb
per wps. I couldn't read that conditional viewports themselves break it,
no matter what. I read "make conditional viewports a bit bett
Hey all,
So, I've got a few patches almost ready to go which affect pretty much
every .wps around so I'm putting this warning up to give everyone
plenty of time to fix their wps'.
The two patches which need your attention is
http://www.rockbox.org/tracker/task/9051 and
http://
--- Rockbox development
> I
was considering adding a custom colour tag to the WPS code. ...
> Before
I start doing more research, however, I'd like to check whether it
> would
be acceptable for SVN.
I'm thinking it will, considering the comment added
to the original comm
Hello,
I was considering adding a custom colour tag to the WPS code. This is already
part of FS#5900 [1] and originally appeared in FS#2838 [2]. I haven't
looked at the patches yet, but I might reimplement it if I don't like how
it's done.
Before I start doing more researc
On Thu, 3 May 2007 05:46:15 -0500
"Paul Louden" <[EMAIL PROTECTED]> wrote:
> Create two sublines, identical. Both have a conditional, one has the
> word "Paused" and the other has six spaces (assuming fixed with font).
> Set the timing on the sublines to the minimum.
On Thu, 03 May 2007 13:52:54
Hi,
you may do flashing text using alternating sublines, e.g.:
%s%t1text;%t1
Flo
>
> Original-Nachricht
> Datum: Thu, 3 May 2007 11:29:49 +0100
> Von: Paul LeoNerd Evans <[EMAIL PROTECTED]>
> An: rockbox-dev@cool.haxx.se
> Betreff: Rende
Alternating sublines plus conditionals should allow flashing text when pause.
Create two sublines, identical. Both have a conditional, one has the
word "Paused" and the other has six spaces (assuming fixed with font).
Set the timing on the sublines to the minimum.
Shaded text would be unsuitable
I've been playing around with (R)WPS files for a while, and come up with
an idea for what I don't think is currently possible - flashing or shaded
text. This is useful for the "obvious" look-and-feel when paused - most
players will use flashing text for the time display, or
ave in any case. And small
size impact.
-Original Message-
From: Dominik Riebeling <[EMAIL PROTECTED]>
Sent: Tuesday, April 17, 2007 12:03 AM
To: Rockbox development
Subject: Re: WPS line height patch
As I have took part of the discussion on IRC I won't repeat myself in
total. J
0:12h
As we're all voting, let me vote for it. It adds more freedom to wps creators
at little cost, and could in the future reduce the number of viewports
needed/used by being able to play with line spacing iso creating a viewport for
each text line. Very KISS for me ;)
1 - 100 of 195 matches
Mail list logo
