I would like to inform the other devs, that I finished updates on the multi-fmr patch too.
It would be good to have a comment for corrections or other possible "bad habbits" from a dev.
That way Jonathan could move more easily to merge if it is commited.
Thanks in advance.
On 13/02/06, Jonathan Gordon <
[EMAIL PROTECTED]> wrote:
weeee....
its actually alot eaiser than i thought it would be to get the wps
going... so ignore this patch, ill post up a new one when im done and
i have merged it with Xavier's patch
On 13/02/06, XavierGr <[EMAIL PROTECTED]> wrote:
> Oh I forgot the link.
> https://sourceforge.net/tracker/?func=detail&aid=1315353&group_id=44306&atid=439120
>
>
> On 12/02/06, XavierGr <[EMAIL PROTECTED]> wrote:
> > Could we apply an older patch first that enables the user to have
> multipreset support (fmr)?
> > There is already an updated patch on the tracker.
> >
> > It changes some parts of the radio.c (and a bit into filetree.c (and some
> other files)to integrate the fileformat). Except the multipreset functions
> (load, save, clear preset lists) it will now save preset lists chnages only
> on radio exit. That way we can avoid many redundant writes to the disk.
> >
> > Only uggly thing that remains is the appearance of the .fmr filetype on
> the browser. My thought on this was to let the user choose the fmr file (and
> if not on the default fmr files folder) then temporarily load the preset
> (keeping the last configuratio) and load the radio screen.
> >
> > Currently (as some devs suggested back then) an fmr file will be shown in
> the browser but if the user selects it, it will do nothing. (though normal
> behaviour on radio screen)
> >
> > What's your thought on this?
> >
> >
> > On 12/02/06, Linus Nielsen Feltzing <[EMAIL PROTECTED] > wrote:
> > > Jonathan Gordon wrote:
> > > > so.. does any1 like the idea? or silly waste of time?
> > >
> > > After a quick glance, it looks like a good start to me.
> > >
> > > Linus
> > >
> >
> >
>
>
