PDA

View Full Version : Custom skin not updating playlist



JJZolx
2007-02-17, 14:51
I have a simple custom skin that inherits from Default. Running 6.5.2 recently I notice that the song shown as now playing and highlighted in the playlist is no longer being updated. The skin consists of only the following files:

index.html
pageheader.html
skin.css
cmdwrappers_Default+
skinconfig.yml

With skinconfig.yml of


---
skinparents:
- Default
preprocess:
- cmdwrappers_Default+

Any ideas where to look in trying to fix this?

Also, the same skin when used in 7.0 displays a blank page for the new detailed scanning progress page. What needs to be updated to get that working?

kdf
2007-02-17, 15:12
On 17-Feb-07, at 1:51 PM, JJZolx wrote:
>
> Any ideas where to look in trying to fix this?
>
does the standard default skin still update for you?
did you change any frame name/id's in index.html?

> Also, the same skin when used in 7.0 displays a blank page for the new
> detailed scanning progress page. What needs to be updated to get that
> working?
>
nothing should need updating. run command line to see if there are any
log outputs there, such as missing strings or Template Toolkit parsing
errors. the progress page uses ajax updates, so you might want to use
firefox and install firebug to see if there are any errors in the
console that are preventing the required updates.

-kdf

JJZolx
2007-02-17, 15:39
>> Any ideas where to look in trying to fix this?
>>
> does the standard default skin still update for you?

Yes.

> did you change any frame name/id's in index.html?

No.

>> Also, the same skin when used in 7.0 displays a blank page
>> for the new detailed scanning progress page. What needs to
>> be updated to get that working?
>>
> nothing should need updating. run command line to see if
> there are any log outputs there, such as missing strings or
> Template Toolkit parsing errors. the progress page uses
> ajax updates, so you might want to use firefox and install
> firebug to see if there are any errors in the console that
> are preventing the required updates.

Ok, I'm seeing "Ajax is not defined" in both home.html and progress.html.

kdf
2007-02-17, 16:45
On 17-Feb-07, at 2:39 PM, JJZolx wrote:
>
> Ok, I'm seeing "Ajax is not defined" in both home.html and
> progress.html.
>
check the differences you have in pageheader. some recent changes made
in 6.5.2 affect how you have to load up the required javascripts.
-kdf

JJZolx
2007-02-17, 18:20
On 17-Feb-07, at 2:39 PM, JJZolx wrote:
>
> Ok, I'm seeing "Ajax is not defined" in both home.html and
> progress.html.
>
check the differences you have in pageheader. some recent changes made
in 6.5.2 affect how you have to load up the required javascripts.
-kdf
I didn't see any real difference. All I added to the header was a search form. Eliminating the file altogether had the same problems. Something strange is definitely going on. I think it's probably an issue with the skin inheritance. I created a test skin with only one file, skinconfig.yml:

---
skinparents:
- Default

Running 6.5.2, r11464 with this skin I notice three things happening:

- The playlist does not update.

- The contents of the playlist pane get loaded into the status pane. The frame info in Firefox tells me that the url is status_header.html, but it's identical to the playlist.

- Although graphical buttons are used in the playlist pane, in the browse pane the skin uses text controls.

The behavior in IE is identical, with one exception. IE tells me that the page being loaded into the status pane is status.html instead of status_header.html.

JJZolx
2007-02-17, 19:48
Argh... now the custom skin is working correctly in 6.5.2. I just updated to r11464, so maybe something was corrected in one of the more recent checkins.

I'm thinking that the last problem I reported stems from not having a preprocess [cmdwrappers] statement in the skinconfig.yml file, so the default cmdwrappers never gets preprocessed.

Also, I found the difference in pageheader.html files in 7.0, so that's been fixed. If you wanted to produce a skin that could be used in either 6.5 or 7.0, is there a version variable that could be tested in a template to conditionally use one set of code or another?

Thanks.

kdf
2007-02-18, 00:40
On 17-Feb-07, at 5:20 PM, JJZolx wrote:

>>
> I didn't see any real difference. All I added to the header was a
> search form. Eliminating the file altogether had the same problems.
> Something strange is definitely going on. I think it's probably an
> issue with the skin inheritance. I created a test skin with only one
> file, skinconfig.yml:
>


I've got a custom skin that I'm working on as well, and it works as far
as the templates. I did have to copy scripts, but I assume you are
only relying on the default scripts, which are EN only.

It may be that cmdwrappers isn't being inherited from default.
instead, its being inherited from EN. Try copying the Default
cmdwrappers and see if that helps. at the very least it will deal with
the status.html vs status_header.html refresh.

-kdf

kdf
2007-02-18, 00:41
On 17-Feb-07, at 6:48 PM, JJZolx wrote:
>
> either 6.5 or 7.0, is there a version variable that could be tested in
> a template to conditionally use one set of code or another?
>
no, not currently. there is no effort for dual support at this time as
things are still changing.

-kdf

Grotus
2007-02-21, 09:19
On Feb 17, 2007, at 11:40 PM, kdf wrote:

> On 17-Feb-07, at 5:20 PM, JJZolx wrote:
>
>> I didn't see any real difference. All I added to the header was a
>> search form. Eliminating the file altogether had the same problems.
>> Something strange is definitely going on. I think it's probably an
>> issue with the skin inheritance. I created a test skin with only one
>> file, skinconfig.yml:
>>
> I've got a custom skin that I'm working on as well, and it works as
> far
> as the templates. I did have to copy scripts, but I assume you are
> only relying on the default scripts, which are EN only.
>
> It may be that cmdwrappers isn't being inherited from default.
> instead, its being inherited from EN. Try copying the Default
> cmdwrappers and see if that helps. at the very least it will deal
> with
> the status.html vs status_header.html refresh.
>
> -kdf

cmdwrappers is being inherited from Default. Or at least it would
be, if Default had a cmdwrappers.

What is not being inherited from Default is the preprocess within
Default's skinconfig.yml. Nor should it be, in my opinion. Default
preprocesses a file called cmdwrappers_Default. Adding this to the
preprocess list in a skin which inherits from Default would be
necessary if you want the modified controls in the Default skin.