PDA

View Full Version : Custom playlinks in new default skin ?



erland
2007-09-30, 00:13
In 6.5 I could use urls like this to execute a CLI command through the status.html page.


http://localhost:9000/status.html?p0=dynamicplaylist&p1=playlist&p2=play&p3=dynamicplaylist_standard_3167&player=ca%3A3b%3A70%3Ae3%3A14%3A95

This would execute the CLI command:


dynamicplaylist playlist play dynamicplaylist_standard_3167


I just realized that this links no longer works in the new default skin in 7.0. They work perfectly in the Classic and Fishbone skin also in 7.0. In the default skin they open a status page in the left side of the screen without the correct stylesheets, which is obviously not what I want. What I want is to execute the CLI command and refresh both the left and right sides of the web interface.

The links I have are play buttons, pretty much in the same way as the play buttons on the Random Mix page. In my plugin HTML template I have code like this:


[% BLOCK controls %]
[% WRAPPER playlink %]
href="[% webroot %][% statusroot %]?p0=dynamicplaylist&p1=playlist&p2=play&p3=[% playlist.id %]&player=[% player |uri%]" onClick="setTimeout('document.location.reload(true)',500)"
[% END %]
[% END %]
[%- WRAPPER contentitem controls='controls' %]
[% playlist.name %]
[% END %]


I'm guessing the onClick inside the playlink wrapper used to refresh the left side of the screen is a bit risky, but it didn't work even if I removed that.

Is there some other way I should do this in 7.0 to get it to work with both the new Default skin and the old Classic and Fishbone skins ?

The thing I basically like to do do it a play link which:
- Runs my own custom CLI command
- Shows up as a play button in all skins
- Updates both the left and right side of the SqueezeCenter web interface

I know I can solve it by having different HTML code for the different skins, but I thought the wrappers were supposed to make that unnecessary.

mherger
2007-09-30, 03:47
> I just realized that this links no longer works in the new default skin
> in 7.0. They work perfectly in the Classic and Fishbone skin also in
> 7.0. In the default skin they open a status page in the left side of
> the screen without the correct stylesheets, which is obviously not what
> I want.

That's because the new Default skin is breaking with the old frame based layout. There's no status.html page anymore.

> [% WRAPPER playlink %]
> href="[% webroot %][% statusroot %]?p0=dynamicplaylist&p1=playlist&p2=play&p3=[% playlist.id %]&player=[% player |uri%]" onClick="setTimeout('document.location.reload(true)',500)"
> [% END %]

That link will load playlist.html (same handler as status.html). In the old skins this was ok, as the default target pointed to one of the right hand side frames.

I fear you'll have to add some code to create the link differently for Default. Here's what the links look like now:

[% WRAPPER playlink %]onclick="Utils.processPlaylistCommand('command=playlist&sub command=loadtracks&track.id=[% itemobj.id %]&player=[% playerURI %]', true);"[% END %]

This will do the same request in a background call, causing the right hand side being updated as needed. I'll probably come up with a generic solution (or another or changed wrapper) for this problem. But I'm not there yet.

Michael

kdf
2007-09-30, 12:50
On 30-Sep-07, at 3:47 AM, Michael Herger wrote:
> This will do the same request in a background call, causing the
> right hand side being updated as needed. I'll probably come up with
> a generic solution (or another or changed wrapper) for this
> problem. But I'm not there yet.

we've already got something for skins that use prototype/
scriptaculous. The useAjax flag was created for that. Perhaps a
simple add of useExtjs will be good enough to allow the wrapper to be
written up without having to have custom pages for each skin. Then
the skin cmdwrappers file just needs to flag which library it uses.
I'm sure more extjs will be used in future for other skins.
-kdf

James
2007-09-30, 13:20
Should it still be the case that you can write a single generic template that works OK in all skins?

The LastFM page looks pretty bad in the new default skin, while still looking fine in all the others.

Seems like I'd have to make some Default specific changes to make improvements - or is it just too early to be worrying about this yet?

James

kdf
2007-09-30, 13:31
On 30-Sep-07, at 1:20 PM, James wrote:

>
> Should it still be the case that you can write a single generic
> template
> that works OK in all skins?
>
I would hope so. I'd hate to have to go back to the old "this plugin
doesn't work in this skin" bug report days.

> The LastFM page looks pretty bad in the new default skin, while still
> looking fine in all the others.
>
> Seems like I'd have to make some Default specific changes to make
> improvements - or is it just too early to be worrying about this yet?

Probably too early. There are a few things in Default known to break
the standard usages. Some cases are a slipt, others are
out of necessity. Once the skin is nearer to its final target, I
should expect it should be something we can flag for skin wrappers to
handle.

-kdf

mherger
2007-10-03, 01:44
> Should it still be the case that you can write a single generic template
> that works OK in all skins?

It _should_ be possible. If you look at the Default folder, you'll see
that besides pageheader/footer, stylesheets etc. there are only a few
files which had to be optimized for Default. All the rest is still taken
from the generic EN templates.

> The LastFM page looks pretty bad in the new default skin, while still
> looking fine in all the others.

Do you have screenshots? How is it broken?

> Seems like I'd have to make some Default specific changes to make

You'll probably have to tweak a few items. Let me know where you're having
problems.

--

Michael

-----------------------------------------------------------------
http://www.herger.net/SlimCD - your SlimServer on a CD
http://www.herger.net/slim - AlbumReview, Biography, MusicInfoSCR

mherger
2007-10-03, 01:46
> we've already got something for skins that use prototype/
> scriptaculous. The useAjax flag was created for that. Perhaps a
> simple add of useExtjs will be good enough to allow the wrapper to be
> written up without having to have custom pages for each skin.

That's something I still have on my todo list. I've tried to move any
globally usefull items into utils.js, some of which are direct
counterparts to the "legacy" scripts like eg. refreshStatus() etc. Any
skin using ExtJS should probably load utils.js first (as global.js in the
old skins).

--

Michael

-----------------------------------------------------------------
http://www.herger.net/SlimCD - your SlimServer on a CD
http://www.herger.net/slim - AlbumReview, Biography, MusicInfoSCR

Craig, James \(IT\)
2007-10-03, 02:29
> Do you have screenshots? How is it broken?

I'll sort out some screenshots, but in summary;
1) large blank spaces after sets of items (couldn't work out what was
causing these)
2) item highlighting doesn't work properly (one big highlight over a set
of items rather than individual ones)
3) inconsistent display of item action buttons (probably related to 2)
4) 'inner' scroll bars reported on a long list (haven't seen this
myself)

It's probably just due to bad templates in my plugin, but there are very
few good examples to understand what's required.
The main problem I find is that a web 'page' is generated by so many
functions in different files it's very difficult to track where
everything comes from.

James
--------------------------------------------------------

NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.

mherger
2007-10-03, 02:59
> 4) 'inner' scroll bars reported on a long list (haven't seen this
> myself)

At least that one I know :-). Add "dontScroll=1" to the call to pageheader.html:

[%- PROCESS pageheader.html dontscroll=1 -%]

Michael

James
2007-10-06, 01:07
Thanks Michael, that helped.

I just found that the large empty spaces were caused by end of the contentcontainer wrappers I was using.

Removing them doesn't seem to do any hard so I have done so!

James