On 23 August 2017 at 23:18, Amaury Pouly via rockbox-dev <
rockbox-dev@cool.haxx.se> wrote:
>
>> *set_speaker_mode(int speaker_mode)*
>> *get_speaker_mode(void)*
>>
>> That sounds okay to me on principle, however I would be curious to know
> the application
>
I suggested *set_speaker_mod
>
> As for the api version variable in lua I noticed writing a few scripts
> that there is no versioning so you have to check everything against nil
> before you use it although that is good practice I think it'd be nice to
> know immediately that a function is not available although it's probably
I split all the functions into their own separate commits, whomever commits
them will have to make
sure to keep track of the version depending on when if these eventually
get added
The new commits/ functions in the case of speaker_mode are as follows
http://gerrit.rockbox.org/r/#/c/1567/
Add so
;> *set_sleeptimer_duration(int minutes)*
>> *get_sleep_timer(void)*
>>
>> ^I'd like to add this to allow sleep timer to be read/set/reset from
>> plugins
>>
>
> No opinion, I know nothing about the sleep timer.
>
>
>>
>>
>
max and default to be read from a plugin
>
Sounds okay to me, to be honest I always found it surprising that we can
set but not get the current value.
>
>
> *set_sleeptimer_duration(int minutes)*
> *get_sleep_timer(void)*
>
> ^I'd like to add this to allow sleep
llow sleep timer to be read/set/reset from plugins
*set_speaker_mode(int speaker_mode)*
*get_speaker_mode(void)*
I'd also like to get g#1566 Committed for lua to have access to the version
*'PLUGIN_API_VERSION'*
*'PLUGIN_MIN_API_VERSION'*
Any suggestions, obje
>
> 2) For plugins for which it is suitable, add a pluginlib fallback which
> can provide a minimal set of functionality
>
I thought it would be useful to provide a few examples:
Example 1: cube
The cube plugin currently has one more action than pluginlib provides. Thus
a trivial wa
creen targets and so on, that's at least 3 very different
keymaps (+variants). Doing the keymapping for Rockbox itself is already
quite a thing but doing it for the plugins is just a nightmare at the
moment, it takes a *huge* amount of time and one cannot enable the
pluginswithout fixing all of them
Hello,
I also think that there should be a list with required/optional plugin.
It would be the best way to make sure the plugins are getting correctly
implemented regarding keymaps/manual. + This would avoid working on
stuff that no one care about.
However, some more plugin could get into
2012/2/2 Marcin Bukat
> Hello rockboxers,
>
> Following discussion on IRC
> (http://www.rockbox.org/irc/log-20120202#12:14:31) I would like to
> rise the issue with current state of plugins. We have lots of this,
> almost every one have separate keymap (only a few use PLA). M
On Thu, Feb 2, 2012 at 3:08 PM, Marcin Bukat wrote:
> Following discussion on IRC
> (http://www.rockbox.org/irc/log-20120202#12:14:31) I would like to
> rise the issue with current state of plugins. We have lots of this,
> almost every one have separate keymap (only a few use
On Ven, Febbraio 3, 2012 11:50, Frank Gevaerts wrote:
> On Fri, Feb 03, 2012 at 11:33:05AM +0100, Nils Wallménius wrote:
>> I generally agree about plugins on RAAA. But there are at least two
>> that are directly related to core functionality, the random folder
>> advance
On Fri, Feb 03, 2012 at 11:33:05AM +0100, Nils Wallménius wrote:
> I generally agree about plugins on RAAA. But there are at least two
> that are directly related to core functionality, the random folder
> advance thing and properties, some music formats are handled by
> plugins to
On Thu, Feb 2, 2012 at 10:12 PM, Hayden Pearce
wrote:
> Apart from test_*, what plugins actually are "useful" for RaaA? Perhaps
> vbrfix too...certainly not many. The new Samsung application target is
> really a "special case" as far as I'm aware as I'm no
Apart from test_*, what plugins actually are "useful" for RaaA? Perhaps
vbrfix too...certainly not many. The new Samsung application target is
really a "special case" as far as I'm aware as I'm not certain its a given
that there will be a native application availa
Am 02.02.2012 21:08, schrieb Marcin Bukat:
2) Relax the requirements for target to become stable. I mean we could
agree on minimal subset of plugins (and documentation in manual)
needed for a given port to fulfill stable criteria. Rockbox is about
playing music and not playing games and watching
On 02/02/2012 03:08 PM, Marcin Bukat wrote:
Hello rockboxers,
Following discussion on IRC
(http://www.rockbox.org/irc/log-20120202#12:14:31) I would like to
rise the issue with current state of plugins. We have lots of this,
almost every one have separate keymap (only a few use PLA). Making
Hello rockboxers,
Following discussion on IRC
(http://www.rockbox.org/irc/log-20120202#12:14:31) I would like to
rise the issue with current state of plugins. We have lots of this,
almost every one have separate keymap (only a few use PLA). Making
plugins to compile is tedious work during porting
roject schedule will probably be very similar to what's in that
draft.
Again, please comment on it.
I posted my draft for relocatable plugins to the gsoc site.
I'll clean both applications up until the deadline; in the meantime I'm
very open for comments on them.
Best regards.
commit
access to another project, geany-plugins, which is a collection of plugins
for use with the Geany IDE which I use exclusively. I have contributed code
to the plugins and Geany itself and hang around in Geany's IRC channels
for quite some time. I also contributed many patc
On 30 March 2011 23:15, Thomas Jarosch wrote:
> No objections from the maemo/pandora side. MeeGo might get interesting
> as it won't have a fixed screen size I guess.
>
> Cheers,
> Thomas
>
No point enabling this on those ports if there is only one lcd size
then :) (I wasnt going to enable it on
On Wednesday, 30. March 2011 11:18:15 Jonathan Gordon wrote:
> Hi,
> How much do we really care about the graphical plugins working on
> RaaA? Really I'm asking about pictureflow and credits.
>
> As you might remember, I'm trying to get FS#11615 committed which
> mea
On 30 March 2011 22:25, Frank Gevaerts wrote:
>
never mind, I fixed the bug. I'm going to commit this tomorrow night
(hopefully) and disable it for android.
On Wed, Mar 30, 2011 at 08:42:02PM +1100, Jonathan Gordon wrote:
> They wont compile currently, and yeah, I thought about the gpl issue
> but then is it even possible to break our own license?
I think it is. We don't have a central copyright holder, so everyone
would have to agree on this (for app
On 30-03-2011 11:34, Frank Gevaerts wrote:
I think credits is a bit different though. I think it's fairly reasonable
to interpret GPLv2 2c as saying you're not allowed to drop the credits
plugin
Why isn't AUTHORS included in .rockbox/docs anyway?
--
Jonas Häggqvist
rasher(at)rasher(dot)dk
On 30 March 2011 20:34, Frank Gevaerts wrote:
> On Wed, Mar 30, 2011 at 08:18:15PM +1100, Jonathan Gordon wrote:
>> Hi,
>> How much do we really care about the graphical plugins working on
>> RaaA? Really I'm asking about pictureflow and credits.
>
> I would
Since there's no answer (yet) as to what project would be more valuable
for Rockbox, is it OK if I make two applications? Alternatively I could
make an application that has both projects and we'd decide which one
after the selection process (if I'm accepted) or simply decide for one
project.
On Wed, Mar 30, 2011 at 08:18:15PM +1100, Jonathan Gordon wrote:
> Hi,
> How much do we really care about the graphical plugins working on
> RaaA? Really I'm asking about pictureflow and credits.
I would assume that the people who want pictureflow on a DAP will also
work on RaaA
Hi,
How much do we really care about the graphical plugins working on
RaaA? Really I'm asking about pictureflow and credits.
As you might remember, I'm trying to get FS#11615 committed which
means much simpler building for android and sdl-app (meamo/pandora
shouldnt be affected). The o
> > But I'm also wondering if I should even apply for Rockbox as I can imagine
> > new students are preferred. I already had a project for Rockbox last year
> > and I'm involved for a longer time already.
> > But I'd really be happy to work on Rockbox again, as I really enjoyed it
> > last year.
On 29 March 2011 11:06, Thomas Martitz wrote:
> On 29.03.2011 10:58, Jonathan Gordon wrote:
>
> And I really cant see you leaving if you didnt get the
> spot. Also think of it like this, if you think you'll have time to
> acts as student why not act as a mentor? You get the tshirt **and** help
>
On 29.03.2011 10:58, Jonathan Gordon wrote:
And I really cant see you leaving if you didnt get the
spot. Also think of it like this, if you think you'll have time to
acts as student why not act as a mentor? You get the tshirt*and* help
out the new blood.
The student side is the more fun side b
On 29 March 2011 19:13, Thomas Martitz
wrote:
> I'm interested in one of the two (with a slight preference for relocatable
> plugins).
>
> I would like to find out which one to apply for, so I want to ask a few
> questions:
>
> - Does the project have a preference, is
I'm interested in one of the two (with a slight preference for
relocatable plugins).
I would like to find out which one to apply for, so I want to ask a few
questions:
- Does the project have a preference, is one more important?
- Is one of them not enough for GSoC (JdGordon said he t
On Mon, 4 Oct 2010 12:52:52 +0100
Dave Hooper wrote:
> How many targets have no plugins due to technical constraints (like
> 'impossibility)?
I think only android, and that would be more because of variable screen
size rather than lack of keymaps like on other targets.
> I r
On 4 October 2010 23:06, Rafaël Carré wrote:
> On Mon, 4 Oct 2010 12:52:52 +0100
> Dave Hooper wrote:
>
>> How many targets have no plugins due to technical constraints (like
>> 'impossibility)?
>
> I think only android, and that would be more because of variabl
On Mon, 4 Oct 2010 23:18:09 +1100
Jonathan Gordon wrote:
> I think this is a bad idea because targets which just disable all
> plugins is really due to the dev being lazy.
My goal is to remove the "Plugins" menu when there are no plugins, not
do the work needed to enable plugins
On 4 October 2010 23:44, Rafaël Carré wrote:
> On Mon, 4 Oct 2010 23:18:09 +1100
> Jonathan Gordon wrote:
>
>> I think this is a bad idea because targets which just disable all
>> plugins is really due to the dev being lazy.
>
> My goal is to remove the "Plugins
How many targets have no plugins due to technical constraints (like
'impossibility)? I realise android builds currently have no plugins but I
doubt that will be the case forever (I could imagine demand for things like
fft and pictureflow)
Android menu is nicer (no plugins entry)
plugins is set to 0 or 1 in configure so it can be used in preprocessor
and Makefile
Breaks theming, because some places use plugin_get_buffer() as temp
buffer.
---
apps/apps.make |2 +-
apps/filetree.c |4 +
apps/filetypes.c
On Mon, 12 Apr 2010 07:40:28 -0400
Jeff Goode wrote:
> While you're fixing dependencies, I'm pretty sure test_codec is
> swcodec only.
I had a doubt, not sure why :)
fixed
--
Rafaël Carré
signature.asc
Description: PGP signature
While you're fixing dependencies, I'm pretty sure test_codec is swcodec
only.
On 4/12/2010 07:09, mai...@svn.rockbox.org wrote:
Date: 2010-04-12 13:09:07 +0200 (Mon, 12 Apr 2010)
New Revision: 25603
Log Message:
some test plugins have dependencies
Modified:
trunk/apps/plugi
2010/3/18 Yoshihisa Uchida :
> Then these were commited once. (it is efficient.)
I completely disagree here. Commiting a number of patches in the same
commit is definitely not _efficient_. It might be _convenient_ for you
(assuming that you have all those patches already applied in your
working tr
Uchida
y_uchida...@infoseek.jp
> - original message -
> send: "Thomas Martitz"
> receive: "rockbox-dev@cool.haxx.se"
> date: 10/03/18 03:10
> subject: Re: uchida: r25233 - trunk/apps/plugins
>
> Am 17.03.2010 15:22, schrieb Frank Gevaerts:
> >
Am 17.03.2010 15:22, schrieb Frank Gevaerts:
On Wed, Mar 17, 2010 at 12:17:56PM +0100, mai...@svn.rockbox.org wrote:
Log Message:
text viewer plugin applies patches FS#8445, FS#9546, FS#9853, FS#9855, FS#9892,
FS#9893, FS#9898, FS#9902, and FS#9990.
I think commit messages should hav
On Wed, Mar 17, 2010 at 12:17:56PM +0100, mai...@svn.rockbox.org wrote:
> Log Message:
> text viewer plugin applies patches FS#8445, FS#9546, FS#9853, FS#9855,
> FS#9892, FS#9893, FS#9898, FS#9902, and FS#9990.
I think commit messages should have a description of the commit, not
just a reference
in in plugins.
1. Because it fits better to the rest of pictureflow (the cover
animation and tracklist views both have black backgrounds).
2. I wasn't aware of that. But it shouldn't hurt does it?
Best regards.
menu still seems to use user setting's colors.
i suppose viewpor
2010/1/26 Thomas Martitz :
> 2. I wasn't aware of that. But it shouldn't hurt does it?
>
> Best regards.
>
the plugin loader will disable the theme, this will always happen, or
at least untill all plugins are fixed to not expect that assumption.
until then there is no r
hide_bars parameter to mean hide_theme.
This makes plugins show the menu backdrop in their backdrop so that
they don't look like crap if you have an sbs and look more
integrated. I've test about all plugins and all work fine.
Modified: trunk/apps/plugins/pictureflow/pic
plugins show the menu backdrop in their backdrop so that they don't
look like crap if you have an sbs and look more integrated. I've test about all
plugins and all work fine.
Modified: trunk/apps/plugins/pictureflow/pic
On Tue, Aug 4, 2009 at 8:37 AM, Teruaki Kawashima wrote:
> d) to match behavior with other plugins which use highscore.
>>>>>
>>>> We don't need two quit items then, if both cause disk access, IMO.
>>>>
>>>> but it doesn't alway
c) removing file causes disk access even though the file doesn't exist.
I agree that my change is not so good and better solution is needed.
same thing would be applied to other plugins like brickmania and
jewels.
I think my solution wasn't bad afterall. Bubbles always accessed th
Teruaki Kawashima schrieb:
c) removing file causes disk access even though the file doesn't exist.
I agree that my change is not so good and better solution is needed.
same thing would be applied to other plugins like brickmania and
jewels.
I think my solution wasn't bad afteral
on type of highlevel was struct highscore.
c) removing file causes disk access even though the file doesn't exist.
I agree that my change is not so good and better solution is needed.
same thing would be applied to other plugins like brickmania and jewels.
I think my solution wasn't b
I agree that my change is not so good and better solution is needed.
same thing would be applied to other plugins like brickmania and jewels.
I think my solution wasn't bad afterall. Bubbles always accessed the
disk at resuming, so that's not really an argument. But, you removed a
(imo
hing would be applied to other plugins like brickmania and jewels.
d) to match behavior with other plugins which use highscore.
Thomas Martitz さんは書きました:
Teruaki, I have a few questions/remarks w.r.t to that revision.
First of all, please try to do more atomic commits, i.e. 1 related
change
Teruaki, I have a few questions/remarks w.r.t to that revision.
First of all, please try to do more atomic commits, i.e. 1 related
change per commit. You touched several plugins for several reasons which
doesn't help tracking changes (the point of a version control system).
Then, sec
On Fri, 26 Jun 2009 19:59:33 +0200
mai...@svn.rockbox.org wrote:
> Date: 2009-06-26 19:59:33 +0200 (Fri, 26 Jun 2009)
> New Revision: 21523
>
> Log Message:
> FS#10283 simplify plugins' menus by using stringlist with callback
> (by Teruaki Kawashima - some minor changes b
To simplify plugin init, and especially to simplify pluginlib -
several pluginlib init functions are eliminated which only copied the
api pointer. It also allows for the _WRAPPERS macros to be removed, in
the long run. the MEM_FUNCTION_WRAPPERS functions can be put in
pluginlib, so that plugins
issing is a bit of elaboration on the idea/purpose behind this. Why
is it done? Just to simplify plugin init, or are you planning to introduce
inline stubs to all functions so plugins don't even have to use the rb pointer?
--
Björn
ried on my E200, but I think it needs wider consideration
before commit, primarily because of the number of files it touches.
The latest version is at http://www.rockbox.org/tracker/task/9770, and
should have everything currently in pluginlib, and all plugins,
converted to use the global API.
And
--Original Message--
From: mai...@svn.rockbox.org
Sender: rockbox-cvs-boun...@cool.haxx.se
To: rockbox-...@cool.haxx.se
ReplyTo: rockbox-dev@cool.haxx.se
Subject: zagor: r19663 - trunk/apps/plugins/doom
Sent: Jan 3, 2009 2:50 PM
Date: 2009-01-03 20:50:58 +0100 (Sat, 03 Jan 2009
t; New Revision: 14813
> >
> > Log Message:
> > vel/MROBE500
>
> I can't for the life of me figure out what that means, nor what it has to
> do
> with the following change:
>
> > --- trunk/apps/plugins/midi/guspat.c 2007-09-22 02:17:08 UTC (rev
> 1481
[EMAIL PROTECTED] wrote:
> Date: 2007-09-22 06:55:44 +0200 (Sat, 22 Sep 2007)
> New Revision: 14813
>
> Log Message:
> vel/MROBE500
I can't for the life of me figure out what that means, nor what it has to do
with the following change:
> --- trunk/apps/plugins/midi/guspat
Hi all :)
As I already mentioned, if no files are present in some subdir of
"/.rockbox/rocks/" when browsing it using the "Plugins" submenu in the
root menu, the file browser returns to the root dir or to the last
visited subdir (about this I'm not sure, becaus
med by the
> > firmware instead of by a plugin. I find this very important, and
> > having it into core is, IMHO, a very good idea.
>
> My initial version was incorporated in the core and then moved to a
> plugin because we agreed that this funtionality is not used on a
> re
e indeed wrong. The reason is to save space.
As I imagined down in my message. Sincerely, I didn't thought that
space was an issue.
> The larger the core gets, the less memory is available - this is
> especially important on the Archos targets which are quite limited.
> This funct
, and having it into core is, IMHO,
> a very good idea.
My initial version was incorporated in the core and then moved to a plugin
because we agreed that this funtionality is not used on a regular base and
using plugins as an overlay system seemed like a good idea to save space.
When using dir
DervishD wrote:
> Correct me if I'm wrong, but if I understand things correctly, the
> purpose of having plugins is to add functionality to rockbox without
> having it in the "core", so to say.
Correct.
> So, the reason of having some functionality implemented
Hi all :)
Correct me if I'm wrong, but if I understand things correctly, the
purpose of having plugins is to add functionality to rockbox without
having it in the "core", so to say.
So, the reason of having some functionality implemented using a
plugin instead of havin
On Tue, Aug 07, 2007 at 02:52:48PM +0200, Daniel Stenberg wrote:
> On Tue, 7 Aug 2007, [EMAIL PROTECTED] wrote:
>
> >Search viewer (plugin) : reindent correctly with spaces
>
> [...]
>
> >+static int strpcasecmp(const char *s1, const char *s2){
>
> This is not a correctly indented function defi
On Tue, 7 Aug 2007, [EMAIL PROTECTED] wrote:
Search viewer (plugin) : reindent correctly with spaces
[...]
+static int strpcasecmp(const char *s1, const char *s2){
This is not a correctly indented function definition by Rockbox standards, it
should then be:
static int strpcasecmp(const
Hi,
If I want to write a plugin is there a way I can compile it with out
compiling the whole source. For example if I make a plugin called
plugin.c can I just compile it to plugin.rock somehow and put it in my
rocks dir under .rockbox. If this is possible could someone please let
me know. Thanks fo
On 10.01.2007, Magnus Holmgren wrote:
>> Log Message:
>> Fix FS#6520, allow search.rock to open .m3u8 playlists. Only
>> the extension check was fixed, so playlists with non-ascii
>> chars probably wont work correclty.
> Indeed, but the fix should be simple enough:
> * If opening a .m3u file, cr
[EMAIL PROTECTED] wrote:
Log Message:
Fix FS#6520, allow search.rock to open .m3u8 playlists. Only the
extension check was fixed, so playlists with non-ascii chars probably
wont work correclty.
Indeed, but the fix should be simple enough:
* If opening a .m3u file, create a .m3u file.
* If
DES += $(patsubst %,-I$(APPSDIR)/%,$(subst :, ,$(APPEXTRA)))
endif
Index: apps/plugins/Makefile
===
RCS file: /cvsroot/rockbox/apps/plugins/Makefile,v
retrieving revision 1.77
diff -u -r1.77 Makefile
--- apps/plugins/Makefile 29 Sep 2006 16:15
On Fri, 29 Sep 2006, [EMAIL PROTECTED] wrote:
+ifeq ($(UNAME), Darwin)
+SHARED_FLAG=-dynamiclib -Wl,-single_module
+else
+SHARED_FLAG=-shared
+endif
Barry, since this is done in numerous Makefiles now, wouldn't it be nicer to
have the configure script create the SHARED_FLAG variable in the ro
Vicente Alabau wrote:
What kind of tools or techniques do you use for plugin debugging?
You can use gdb with the UI simulator. Which works pretty well for
debugging most things that aren't specific to the targets.
If you can't find what you need with gdb and the sim, you can always try
maki
Hi!,
I am a iAudio X5 owner who is interested in plugin development for rockbox.
Actually, I successfully installed the simulator and made the helloworld
tutorial.
Now, I am playing around with the plugin. As the plugin gets more complex I
find more interesting the use of a debugger.
Is there a
On Fri, 3 Mar 2006, Frederic Devernay wrote:
I think the clean way to develop a plugin would be to be able to build it
from another directory than the rockbox build dir. Linux developpers may
think about how kernel modules can be built from any directory, making it
easier to distribute them se
our player"; \
fi
$(SRC:.c=.rock): vsm.c game.c rom.h
$(SILENT)ln -sf $(BUILDDIR)/apps/plugins/pluginlink.lds .
@$(MAKE) -C $(APPSDIR)/plugins VPATH="$(PWD)" \
SRC="$(SRC)" SUBDIRS="$(SUBDIRS)" BITMAPLIBS="" V=1
On Sun, Feb 26, 2006 at 03:15:11PM +, roolku wrote:
> I am trying to debug a plugin with gdb in the sim, but
> I can't get it to stop. Breakpoints seem to get
> ignored. They work fine in the main application so
> maybe this is to do with the dynamic loading of the
> plu
Hi,
I am trying to debug a plugin with gdb in the sim, but
I can't get it to stop. Breakpoints seem to get
ignored. They work fine in the main application so
maybe this is to do with the dynamic loading of the
plugins? Any idea how I can interrupt the plugin?
Thanks
Dave Chapman wrote:
As you pondered in irc, policing the code has the advantage of making it
more portable.
I've already fixed all the obvious problems gcc found (i.e. testing if a
var of type "char" was < 0), but I think I would prefer to avoid adding
-fsigned-char unless we run into problems i
Linus Nielsen Feltzing wrote:
> [EMAIL PROTECTED] wrote:
>
>> iPod: signed-char police
>>
>
> Can't we use the -fsigned-char gcc option instead of policing the code?
>
> Linus
As you pondered in irc, policing the code has the advantage of making it
more portable.
I've already fixed all the obv
[EMAIL PROTECTED] wrote:
iPod: signed-char police
Can't we use the -fsigned-char gcc option instead of policing the code?
Linus
Hi,
Is there something going on concerning sound playing from plugins? Couldn't we
use the crossfade stuff (with crossfade_mode = CFM_MIX) for that purpose?
Fred
87 matches
Mail list logo
