iPeng Plugin Cookbook [Archive] - Squeezebox : Community : Forums

erland

2008-01-02, 23:42

Thanks for the documentation, just some comments and questions to clarify some stuff:

Registering plugins
It might be better to describe this from a plugin developers point of view.
You normally make a call to the addPageLinks function from your plugin to register it like this:

Slim::Web::Pages->addPageLinks("plugin", { $name => $url });

To support the iPeng skin you will need to make two calls to this method:

Slim::Web::Pages->addPageLinks("plugin", { $name => $url });
Slim::Web::Pages->addPageLinks("pluginiPeng", { $name => $url });

The first row will make your plugin show up as usual in the standard web interfaces, the second row will make your plugin also show up in the iPeng skin. As already described in the documentation, you can use the same idea when registering plugins with addPageLinks under the "browse" and "search" categories.

Questions/Comments
1.
Is there a reason why contentanchor is a separate item ? Wouldn't it be possible to let it be a part of the contentitem if the anchor parameter has been specified, since this is how it works in the other skins ?

2.
I'm not sure I like the textlink as an in-parameter to contentitem, the reason being that I don't think it could be solved like this for the rest of the skins. The reason the rest of the skins can't work this way is that they can contain several links inside the "content" of the wrapper.
I think I would have prefered to have some sort of link component which I could call with something like:
[% PROCESS rowtextlink textlink="/…/…html?…#…" content="xxx" %]
So the code would be like this:

[%- WRAPPER contentitem rightcontrols='controls' %]
[%PROCESS rowtextlink textlink="/…/…html?…#…" content="xxx" %]
[% END %]

The rowtextlink component would then also make sense in the other skins and be added in a future version of SC.

mherger

2008-01-03, 00:20

> iPeng does offer generic plugin support, yet mobile Safari (the Browser
> on th iPhone) has some limitations and specialties compared to a PC
> browser. So most plugins work somehow but look pretty bad with iPeng.

I have roughly followed your exchange with Erland. But I'm still not sure every plugin author will need to write a special skin to be used with iPeng. Let's take eg. my Biography/Review plugins (yes, I'm lazy): they display a simple page, with a picture and some text. Is this really any different on iPeng (I'm sorry, I neither have an iPod nor iPhone)?

From the five main limitations you mention, the Handheld skin meets at least four the same way, and I do not know about the fifth, as I'm not sure it's ever used at all. In fact Handheld does work with all default templates I know, though it's probably even much more limited than Safari:

- mouseovers/d'n'd: set "useAJAX=0" in cmdwrapper_iPeng, and even Favorites & co. won't use d'n'd

- space: Handheld is designed to work at 240x320 - this should imho be no issue as long as the plugin uses standard templates

- exact positioning: that is a real pain indeed. But again: as long as the plugin is using standard building blocks and wrappers and you provide them, there should be no need writing a skin specific page

- onscroll - which plugin's using this?

I'm not sure the approach of disabling all plugins because some don't behave is the right way to go. I've always be hesitant adding additional code to my plugins to allow other plugins to interact with mine. Instead we've tried to come up with generic solutions which should be available to other plugins, too. As of today I would have to add code for three other plugins/skins and maintain it. This is a dead end route to go.

And why fill yet another datastructure in SC when you can add skins to plugins? Wouldn't it be enough for any plugin author wanting the ultimate functionality out of iPeng to add an iPeng folder with the templates in there? No need for additionalLinks.*iPeng.

We should rather look at how we could fix these issues in the generic templates. Instead of asking _all_ plugin authors to change their plugin, we could discuss the real issues with their authors and find a solution which does work for most with the the least effort. If you don't you risk to be without plugin support really soon.

Other than Erland's plugins I'm not sure there are many out there which would need a special skin at all. You should probably give some more examples of what's breaking your skin.

BTW: is iPeng supposed to be working on a standard Safari?

Michael

erland

2008-01-03, 00:33

If I use:
[%- WRAPPER contentitem %]<a ....>...</a>[% END %]
[%- WRAPPER contentitem controls='controls' %]<a ....>...</a>[% END %]

Instead of:
[%- WRAPPER contentitem %]<a ....>...</a>[% END %]
[%- WRAPPER contentitem rightcontrols='controls' %]<a ....>...</a>[% END %]

The result is that I get a white field to the right of the rows that contains the "controls" attributes. If I switch to use "rightcontrols" instead as shown above it works perfectly, but shouldn't it also work with "controls" ?

It works with the "controls" attribute if I have it on all contentitem rows, but not if I only have it on some rows.

If I have understand it correctly the purpose of the the controls attribute are:
- leftcontrols: I want to place some control to the left of the text
- rightcontrols: I want to place some control to the right of the text
- controls: I just want a control but I really don't care where it's placed, the positioning is totally up to the skin to decide.

mherger

2008-01-03, 00:40

erland

2008-01-03, 00:56

And why fill yet another datastructure in SC when you can add skins to plugins? Wouldn't it be enough for any plugin author wanting the ultimate functionality out of iPeng to add an iPeng folder with the templates in there? No need for additionalLinks.*iPeng.

We should rather look at how we could fix these issues in the generic templates. Instead of asking _all_ plugin authors to change their plugin, we could discuss the real issues with their authors and find a solution which does work for most with the the least effort. If you don't you risk to be without plugin support really soon.

I agree with you Michael, however, at the moment I can say that none of my plugins work good with the iPeng skin without adjustments. But the preferable solution would definitely be if the plugins would work as long as they use the standard components available in all skins.

Until we have these standard components that works with both iPeng, Nokia770 and all the other skins my feeling is that the current solution by using double registration in the additionalLinks hash is acceptable. After all it will only make plugins that has been tested available on iPeng.

I can understand that Joreg doesn't want his skin to look bad and contain pages that doesn't work at all just because some plugin developer hasn't done their work. As a plugin developer I can also say that I don't want to support or try to help users that use a skin that I haven't tested my plugin against. I've had some problems regarding the Nokia770 skin earlier regarding this and I've also got reports that some of my plugins doesn't work with the handheld skin.

I'm pretty sure some of the problems are in my code and that I haven't understand how to use the standard components.

Other than Erland's plugins I'm not sure there are many out there which would need a special skin at all.
I think you are correct regarding this. Most plugins have a pretty simple web interface or even no web interface at all, some of mine tends to have a more advanced user interface.

I'll try to create summary of the problems I've had during the Custom Browse adaption to iPeng to get you some sort of feeling about the problems. This could probably be some sort of start point of deciding which standard components that are needed. The major problem are that the screen is a lot smaller on the iPhone, so I can't show all the information in iPeng which I show in the other skins. I'm guessing the same problems probably also is applicable to the Nokia770/Touch skins if I try to make my plugins work good with these.

erland

2008-01-03, 01:00

> If I have understand it correctly the purpose of the the controls
> attribute are:
> - leftcontrols: I want to place some control to the left of the text
> - rightcontrols: I want to place some control to the right of the text
> - controls: I just want a control but I really don't care where it's
> placed, the positioning is totally up to the skin to decide.

The skin is always to decide. I think the styles' names sometimes are misleading. They were defined with a certain layout in mind, and used accordingly. Other skins use different layouts, but still have to rely on the same style names. Default displays all controls on the right hand side. Having some on the left, which most of the time are on the right imho is just confusing.

Michael

Is there any recommendation which one I should use in the plugin pages ?
I would obviously like to use the same in all the skins if possible.
The controls I'm using are:
- Play/add buttons
- Edit buttons
- Mixer buttons
- Cover art icons (Although this is not implemented as a control at the moment, it uses the same implementation as the default skin)

My thought is just that it might be confusing if one plugin puts the play button in leftcontrols and another in rightcontrols.

mherger

2008-01-03, 01:33

> The controls I'm using are:
> - Play/add buttons
> - Mixer buttons

These two usually re in "controls", in the case of playlists/favorites in "leftcontrols".

> - Edit buttons

That's the "rightcontrols" case.

> - Cover art icons (Although this is not implemented as a control at the
> moment, it uses the same implementation as the default skin)

These are handled differently. They use their own styles

> My thought is just that it might be confusing if one plugin puts the
> play button in leftcontrols and another in rightcontrols.

It does indeed. I never understood why the play controls would move from right to left in some cases.

Michael

erland

2008-01-03, 01:42

Here is a summary of the problems I was required to solve when adapting Custom Browse to iPeng. Most of the issues here looks pretty related to the browsedb.html page in the standard skin, the reason for this is of course that the purpose of the Custom Browse plugin is to create custom browse pages in addition to those available in SC as standard.

Joerg, just to make sure you don't interpret these issues as complaints. The iPeng skin is currently the best remote control interface I've ever seen for the SqueezeBox (including the Jive prototype), so I really don't mind if it requires me to adjust my plugins a bit.

1.
There isn't enough space to show all the mixer icons on the iPeng skin, so I had to implement a single mixer icon that lists all available mixers when you select it.

2.
There isn't enough space to show both add and play buttons on the iPeng skin, so instead it just shows an add button. I think the suggestion from Joerg is that hitting the title or cover art icon should result in a "play" action.

3.
The iPeng skin has support for a vertical alpha letter page navigation bar (corresponds to alphamap in the standard skins).
The reason is two as I see it:
- It looks similar to the built-in music player of the iPhone/iPod Touch
- By having a horizontal page navigation the letters can be displayed with more space in-between making it eaiser to access the right letter on the touch screen.
This caused some problem in my plugins since the corresponding component doesn't exists in the standard skins. There is basically no components available yet neither in the iPeng skin for this vertical bar so I basically had to re-implement it in my plugin.
The page navigation bar is displayed as:
- Standard horizontal bar with page numbers if the items isn't alphabetic sorted
- Vertical bar with letters if the items are alphabetic sorted

4.
To make the plugin look good in the iPeng skin it is important that you put everything inside standard component, if you try to use a <p>, <div> or <span> it will often result in that it doesn't look to fit the style of the rest of the page. This might be a stylesheet issue, but I'm not completely sure.

5.
The iPeng skin has a "move to top" button in the footer which makes sense in the iPeng skin but doesn't make a lot of sense in the new default skin where we like to avoid extra clutter. There is currently no component available for this button, so my plugin code currently contains a copy of the necessary code.

6.
Custom Browse normaly displays a header on top each browse pages, for example when you have selected an artists and lists its albums it shows information about the artist in the header.
Here is a sample:
http://erland.homeip.net/arkiv/slimserver/custombrowse1.png
Anyway, the problem with this header is that it takes up too much space on the iPeng skin. Currently I don't show the header at all but I'm thinking that it might be a good idea to be able to access it by clicking a button/link or something similar.

7.
There is not enough space available to show complete titles when they are long, the current solution is that long titles are truncated with a "..." at the end. This is obviously something that you don't want to happen with the skins you use on a standard computer. There is a truncate javascript function available through the iPeng skin, but the plugin currently has to decide what to truncate and how many characters to truncate it to.

8.
There is currently no standard way of handling the "Sort by" list box. This looks differently in all the skins and on top of that I like to replace the contents in it with my own and their corresponding links. The result is that I currently have to handle this differently in pretty much every skin available. I haven't done anything regarding this in the iPeng skin yet, but I know that it will be another variant in addition to the ones already available from the other skins.

9.
Some of the stuff in the iPeng skin is currently based on tables, while most of the rest of the skins is based on divs and spans. The result is that it is harder to get a single implementation to work with all skins when you like to place divs/spans inside your plugin page. However, I've managed to get this to work pretty good in Custom Browse with the iPeng skin without having to revert to use table/td/tr elements.

mherger

2008-01-03, 01:43

pippin

2008-01-03, 02:05

A few clarifications:

1. thanks for the perl explanation, I'll add that.
2. textlink. The problem is, this is an INVISIBLE control, that is, the control is the full content field and you can just provide a link. What do you need the other content for? You can have more than one JS command.
3. useAjax=0. Can you explain me, what the result of this will be? Rationale: I don't want to disable AJAX, in fact I use the AJAX controls whereever I can, the problem is, that lots of plugins make assumptions about the screen layout and UI when using AJAX.
4. 'controls': That's a bug, didn't remove it from a left side condition when moving 'controls' to the right. I will change that. As a fix you can change line 189 in cmdwrappers to
<td class = "listRow" style = "padding-left: 6px" [% IF !leftcontrols %]colspan = 2[% END %]>

The main point is a more general one, that you, Michael, probably don't know because you - having no iPhone - haven't read my UI philosophy article on penguinlovesmusic. So in brief:
I want this not just to be a skin that displays everything that can be shown in SC, but i prefer it to be usable, which is not the case if I just scale stuff. I tried the handheld skin, it's not usable on iPhone IMHO.
I also made the conscious decision to use the iPhone UI philosophy instead of the SC one wherever possible, yet that brings some changes.
I don't want to see lots of stuff that doesn't work. It's annoying for the user. If a plugin developer writes me an e-mail stating "my plugin does this just fine, I've tested it and I don't wanna change it' I can easily hardcode this by adding it to my hash of default plugins. My experience so far has been, that most plugins display badly since most define their own containers or make assumptions about the underlying code. Favorites, for example, generates a list around the content where I use a table, thus favorites completely screws up the layout. This is not my fault, the plugin just doesn't comply to the cmdwrappers code structure, which is no wonder since it's not really documented. My experience is, that this is true for almost every plugin I stumble upon.
Some of the changes in UI philosophy I made: I usually don't want to see a "play this" button on the screen. It just takes up space and annoys users used to iPhone because they are used to click on the item text. Thus textlink. I could just hardcode the playcmd into the text and remove the icon when I decide this is a playable item but I wanted the plugin developer to be able to decide.
I can't just throw in a lot of controls somewhere on the side because if you crowd them, you will always click on the wrong one. I repeatedly hit the wrong one even with a mouse on the default skin this simply doesn't work with the iPhone. They have to be manually positioned or this at least has to be tested. The sense of positioning some of the controls to the left and some to the right is not to accidentally click the wrong one. The maximum number of controls acceptable on the right side, in my view, is two, even that is a stretch!

Good discussion, anyway!

pippin

2008-01-03, 02:16

>
But do the others hurt? As long as there is a way to get back to a working screen I wouldn't bother excluding plugins.

It does. This is not a tech demo but expected to be usable. Sorry, but I will be strict on that: no untested stuff, there is nothing worse than a user stumbling about something that doesn't work, he can't know it's not his fault. It doesn't matter, whose fault it is, it results in unusable software.
You can see what comes out of this, in part, with Linux. When I set up my SC server, I made the mistake to follow the documentation that comes with ubuntu that explains in detail, how you mount a share with smbfs. No mention that this will leave you with a disfunctional system. I don't want any of this with iPeng, I prefer to omit functionality.

erland

2008-01-03, 02:42

> I agree with you Michael, however, at the moment I can say that none of
> my plugins work good with the iPeng skin without adjustments. But the

But this doesn't need to be new perl code in the plugin itself? Why not just add an iPeng folder to your templates?

It's imho a plugin author's job to come up with the skins. But excluding _all_ plugins because _some_ need changes is imho gone too far. I'm sure simple output plugins like mine don't need any adjustment to be of some use, even if the layout probably isn't perfect.

I'm not adjusting the perl code, the adjustments are made in the HTML/iPeng folder. But the problem is that some of the html templates are starting to get a bit complex, so I prefer to not have duplicate copies of the whole code with small adjustments everywhere.
Also making these kind of adjustments for every skin available will in the long run be a problem. I was able to do it for the old default skin and fishbone but pretty much nothing else during 6.5.

For 7.0 the original plan was to support classic, fishbone, default and iPeng. Optionally I would like to support Nokia770/Touch but the problem is that I don't use it myself so I have a hard time to prioritize it.
At the moment I feel that I probably only officially like to support one or two skins, and let the rest have their problems. This will probably result in that just iPeng and one of classic/default will be supported. I need to support one computer screen skin because I don't think I'll make all the configuration pages available in iPeng.

The main problem with supporting many skins as a plugin developer is the testing, when you know the problem you can quite quickly find a solution but the testing still tends to take time.

> As a plugin developer I can also say
> that I don't want to support or try to help users that use a skin that
> I haven't tested my plugin against. I've had some problems regarding
> the Nokia770 skin earlier regarding this and I've also got reports that
> some of my plugins doesn't work with the handheld skin.[/color]

I think you should reconsider your pages' layout. Obviosuly you're doing stuff which isn't expected or which is just beyond the current templates possibilities. Does it have to be that complicated or could you simplify things? Regarding your recent posting about having too much code to maintain, it's probably worth a thought (BTW: I hear you well. I'm not able maintaining SlimCD and making it work with SC7 :-().

I think the problem is that I like them feel like the other parts of the SC interface. For Custom Browse this is especially important since it will be shown together with the other standard SC browse menus. Unfortunately the current cmdwrappers components aren't really built for making plugin pages similar to browsedb.html page but with other kind of information/links, so this is one thing that I'm hoping will be better supported in the future. Of course it might also just be that I haven't understand how to use the components.

Another part of the problem is the history, I have a feeling that some of my plugin pages would benefit a lot of a total rewrite since they were written a long time ago when I didn't know everything I know today. This also applies to a large part of the perl code in my plugins by the way. The problem is just to gather enough inspiration to do this, rewriting stuff tends to be boring while implementing new features is fun.

But if you or anyone else have ideas how to simplify the user interface of my plugins, I appreciate all suggestions.

mherger

2008-01-03, 02:42

>> But do the others hurt? As long as there is a way to get back to a
>> working screen I wouldn't bother excluding plugins.
>>
> It does. This is not a tech demo but expected to be usable. Sorry, but

Well, you've got the choice: get complaints about plugins not working in your skin. Or get complaints about plugins not available in your skin. Your answer in both cases will be the same: contact the plugin author - which is correct. But there will be more plugins missing than there would be breaking your skin.

> I will be strict on that: no untested stuff, there is nothing worse
> than a user stumbling about something that doesn't work, he can't know
> it's not his fault. It doesn't matter, whose fault it is, it results in
> unusable software.

Are we really talking about unusable software or rather layout glitches?

> No mention that this will leave you with a disfunctional system. I
> don't want any of this with iPeng, I prefer to omit functionality.

You do. Users don't. It's your choice, and it probably is the right choice from a developpers point of view. But users are left behind.

Michael

erland

2008-01-03, 02:56

> I will be strict on that: no untested stuff, there is nothing worse
> than a user stumbling about something that doesn't work, he can't know
> it's not his fault. It doesn't matter, whose fault it is, it results in
> unusable software.

Are we really talking about unusable software or rather layout glitches?

I can only answer for my own plugins.
At the current implementation of iPeng and my own plugins we are definitely talking about unusable software, not just layout glitches.

I've tried iPeng with Custom Browse, TrackStat and Dynamic Playlist and none of them was usable without adjustments. Of course it depends on what you mean with layout glitches, but when something isn't shown at all or something is overlayed on top of other items so you can't access all controls it is definitely unusable to me.

But as you said earlier, my plugins are probably not representative for all third party plugins. Most third party plugins have no web interface at all or a web interface a lot simpler than my plugins.

pippin

2008-01-03, 03:28

Well, you've got the choice: get complaints about plugins not working in your skin. Or get complaints about plugins not available in your skin. Your answer in both cases will be the same: contact the plugin author - which is correct. But there will be more plugins missing than there would be breaking your skin.

I did. As I said ;-)

You do. Users don't. It's your choice, and it probably is the right choice from a developpers point of view. But users are left behind.

I see it just the other way 'round. There are tons of MP3 players on the market that have WAY more functionality than the iPod. And there have been before the iPod. Which ones get bought?

Believe me: functionality is developers' first priority, usability is users' first priority!

Erland, thanks for your overview! For the next release I will see that I make some more standard blocks for that additional functionality (like vertical alphameps, goToTop buttons etc.).

Regarding 'contentanchor': It's a different animal, the anchor parameter is still supported. However, the "anchor" parameter adds an anchor to a given row while the "contentanchor" wrapper adds a seperate heading row. It's used for the alphabet headings in the Artist and Album views.
The main drawback for the "anchor" parameter is that it does need it's own table cell because otherwise it would screw up the layout of the main cell (that is supposed to have an anchor fill out the whole cell area).

erland

2008-01-03, 03:38

Regarding 'contentanchor': It's a different animal, the anchor parameter is still supported. However, the "anchor" parameter adds an anchor to a given row while the "contentanchor" wrapper adds a seperate heading row. It's used for the alphabet headings in the Artist and Album views.
The main drawback for the "anchor" parameter is that it does need it's own table cell because otherwise it would screw up the layout of the main cell (that is supposed to have an anchor fill out the whole cell area).
I just felt that the 'anchor' parameter maybe should be implemented as a contentanchor in the iPeng skin. I'm not sure how 'anchor' is used in the rest of the skins, but it feels like it should be the same thing.

To me it would seem logical if the iPeng skin chooses to implement the 'anchor' parameter as a separate visible heading row, while the other skins choose to implement it as a hidden anchor not visible on the screen. The visibility of the anchor makes more sense on the iPhone screen than on a computer screen.
But there might be implementation complexities that I haven't realized that makes this hard to accomplish.

pippin

2008-01-03, 03:42

I just felt that the 'anchor' parameter maybe should be implemented as a contentanchor in the iPeng skin. I'm not sure how 'anchor' is used in the rest of the skins, but it feels like it should be the same thing.

To me it would seem logical if the iPeng skin chooses to implement the 'anchor' parameter as a separate visible heading row, while the other skins choose to implement it as a hidden anchor not visible on the screen. The visibility of the anchor makes more sense on the iPhone screen than on a computer screen.
But there might be implementation complexities that I haven't realized that makes this hard to accomplish.
OK, I was probably making assumptions.
On iPeng 0.1a i put an anchor in EVERY row and I'm not sure, whether others are probably doing the same. If they did, this would look nasty...
I'll give it a try with some plugins and if it works out well I'll handle the anchor parameter like the contentanchor item.

erland

2008-01-03, 04:05

OK, I was probably making assumptions.
On iPeng 0.1a i put an anchor in EVERY row and I'm not sure, whether others are probably doing the same. If they did, this would look nasty...
I'll give it a try with some plugins and if it works out well I'll handle the anchor parameter like the contentanchor item.

I don't think there are a lot of plugins using the anchor parameter, I know I didn't until yesterday when I realize it existed.

The SC browse pages uses it, but it will only set the anchor on the first item for each letter if I'm interpreting the SC perl code correctly.
Possibly it might be a good idea to only show it if the list is more than 40 items long or something, this is what I currently do in Custom Browse.

If you want to try it, too, just change the "[% IF anchor %]..." clause in contentitem to
[%- IF anchor;
WRAPPER contentanchor;
anchor;
END;
END %]

Seems to work good, but you have to move it above the <tr> because else it create an extra empty line before the anchor row.

pippin

2008-01-04, 23:52

OK, I updated the API with some of the suggestions from this thread. The documentation in the Developers' Section on penguinlovesmusic is updated and there is a new release iPeng 0.2d that is mainly targeted at plugin developers. It has only little additional functionality (fixed the "upwards" browsing for Internet Radio), but some changes to the API, especially:

- The anchor feature discussed above
- You can size the contentcontainer; also switched the parameter for a custom <div> to squeezecenter's standard (listid), the old 'containerid' is still valid, though.
- There's a spacer block to keep the bottom bar at the page bottom when not using contentcontainer
- fixed the 'controls' bug

Regarding Erland's earlier remark: I explicitly RECOMMEND using the contentcontainer/contentitem structure for lists in iPeng! If used together with the "textlink" parameter it's the most powerful option to display lists in iPeng since it supports the "moveuplink" control for reordering.

erland

2008-01-05, 00:02

I've noticed that if I have a pageHeaderInfo block defined in my plugin page it results in a blue row at the top of the page and the text in the pageHeaderInfo block is not even displayed on this row.

For example it could look like this in the plugin page:

[%- pageHeaderInfo = BLOCK %]
<strong>[% "NOW_PLAYING" | string %]:</strong>
<span class="exboldnowplaying">[% pluginDynamicPlayListNowPlaying %]</span>
[% END -%]
[% PROCESS pageheader.html %]

If I just have an empty pageHeaderInfo block it works correctly without a blue line, but it would be nice if the pageHeaderInfo block was supported since it is sometimes useful to display an information row at the top of the page.

erland

2008-01-05, 00:15

- You can size the contentcontainer; also switched the parameter for a custom <div> to squeezecenter's standard (listid), the old 'containerid' is still valid, though.
- There's a spacer block to keep the bottom bar at the page bottom when not using contentcontainer

If possible I would prefer if I didn't have to specify the height if I like a full page container.

So if I had code like this, it would look good in both the default SC skins and in iPeng.

[% PROCESS pageheader.html %]
[% WRAPPER contentcontainer %]
[% WRAPPER contentitem %]First item[% END %]
[% WRAPPER contentitem %]Second item[% END %]
[% WRAPPER contentitem %]Third item[% END %]
[% END %]
[% PROCESS pagefooter.html %]

At the moment this code looks good in default SC skins but in iPeng it puts the buttom bar in the middle of the page.

If I really want a half page contentcontainer it might be useful to be able to specify a height, but I don't think I should have to specify it in the default case.

Michael
If you are still listening on this thread, it would be useful to also be able to specify a height of the contentcontainer in the standard skins. This would make it possible to have several contentcontainer blocks on the same page which would solve the problems I had earlier with Custom Browse and the new default skin.

pippin

2008-01-05, 00:27

I've noticed that if I have a pageHeaderInfo block defined in my plugin page it results in a blue row at the top of the page and the text in the pageHeaderInfo block is not even displayed on this row.

If I just have an empty pageHeaderInfo block it works correctly without a blue line, but it would be nice if the pageHeaderInfo block was supported since it is sometimes useful to display an information row at the top of the page.

Ok, I'll check this .... gimme some time ;-)

pippin

2008-01-05, 00:34

If possible I would prefer if I didn't have to specify the height if I like a full page container.

At the moment this code looks good in default SC skins but in iPeng it puts the buttom bar in the middle of the page.

If I really want a half page contentcontainer it might be useful to be able to specify a height, but I don't think I should have to specify it in the default case.

Problem is: Do you, for example, always know if you have a pagebar? Or do you put that inside the container?
I can change that to be the default behavior, won't affect any of my pages (just add an || '323' to the containerheight clause in cmdwrappers). The reason I didn't do it is that ALL the plugins I tried out did actually show stuff above and below the container, so they would scroll the footer off the page even with an empty container. Now that's not nice either, isn't it?
And since the default skin doesn't know the "containerheight" parameter (OK, you want to change that), I thought that's less impact.
But, if you prefer it the other way round I will change it next time.

New line 151 in cmdwrappers for you:
<div id="[% listid or containerid or 'browsedbList' %]" style="min-height: [% containerheight || '323px' %]">

EDIT: OK... that was too quick: it needs a "containerheight='1'" in line 141 of browsedb.html... Maybe more to come, I'll see...

erland

2008-01-05, 01:09

Problem is: Do you, for example, always know if you have a pagebar? Or do you put that inside the container?
I can change that to be the default behavior, won't affect any of my pages (just add an || '323' to the containerheight clause in cmdwrappers). The reason I didn't do it is that ALL the plugins I tried out did actually show stuff above and below the container, so they would scroll the footer off the page even with an empty container. Now that's not nice either, isn't it?

I see your point.
I think the problem you have is similar to the default skin. Earlier I had stuff above and below the contentcontainer wrapper, but to get that to work with the new default skin I had to put this stuff into div's which the default skin uses.

So my plugin pages now basically looks like this:

[%- pwd_list = BLOCK -%]
*** Stuff to display in the crumb list navigation path at the top ***
[% END %]
[% pageHeaderInfo = BLOCK %]
*** Stuff to display at bottom of the header ***
[% END ]
[% PROCESS pageheader.html %]
<div id="browsedbHeader">
*** Stuff to display above the contentcontainer but below the header, for example the pagebar navigation links ***
</div>
[% WRAPPER contentcontainer %]
[% WRAPPER contentitem %]*** Item 1 ***[% END %]
[% WRAPPER contentitem %]*** Item 2 ***[% END %]
[% WRAPPER contentitem %]*** Item 3 ***[% END %]
[% END %]
<div id="pageFooterInfo">
*** Stuff to display below the contentcontainer but above the footer ***
</div>
[% PROCESS pagefooter.html %]

Earlier I didn't have the pageFooterInfo and browsedbHeader as divs, instead I had that information as <p>, <span>, <div> of my own. This worked and still works with the classic and fishbone skin, but it doesn't work with the new default skin. The reason is that the new default skin always tries to resize the contentcontainer to the full height and just takes the pageFooterInfo and browsedbHeader into account when doing this. If you don't put the stuff below/above the contentcontainer into these divs the default skin will push the stuff below the contentcontainer out of the page and you can't reach it.
At least this was the case a few months back when I discussed this with Michael, I haven't checked if he has changed anything regarding this since then.

I'm not sure if it would be possible to use the same ideas to detect the correct size of the contentcontainer also in the iPeng skin.

The main reasons I don't want to specify the pixel height in my plugins are:

1.
I have no idea how high the pagebar is going to get, if you change this in the cmdwrapper components it will break all the plugins which have hardcoded the pixel height.

2.
My vision is still that I should be able to sometime use the same code for all the skins without the need to have iPeng specific templates. I know I will always need small changes such as removing some information, since everything can't be shown on the small screen, but I would prefer if the parameters to the WRAPPER's and the rest of the cmdwrapper could be the same for all skins.

3.
If Apple decides to release a new iPhone with a larger screen with another resolution this will also break all my plugins. It would be nice if this only required changes in your skin files and not the plugins.

It's not urgent, I can hardcode it in the plugins at the moment, but it would be nice if this could be handled in the cmdwrapper blocks automatically.

pippin

2008-01-05, 06:28

Let's see:

How do you want the pageHeaderInfo to behave? Show up below or within the title bar?

Also: My own pages do a lot of evaluating in the pwd_list to define the "return to.." button, maybe I should generalize and include this in the pageheader.

1. I see threee alternatives:
a) the conatiner handles inclusion of the pagebar completely on it's own (than it knows whether it's there)
b) you add a pagebar option to the container and it just sizes appropriately from determining the size of the pagebar itself
c) I generate a information block that returns the pagebar height.
I don't have a preference right now.
2. Agree and understand. That's also why I soemtimes defined my own parameters instead of usinf the default ones: This way you can safely have different values for different skins.
3. I fully understand and fear that one. It's even worse: I'm already working on some landscape views myself ;-)

erland

2008-01-05, 07:05

How do you want the pageHeaderInfo to behave? Show up below or within the title bar?

It's a bit crowed inside the title bar, at least with the current fontsize. So I think it would be preferable to have it just below the title bar. Maybe with some background color that differs it from the container so you notice it better. Maybe something similar to the contentanchor coloring, but I think it needs to be able to contain several rows to be usable. The contentanchor component looks pretty bad if the text wraps around so you get two lines.

1. I see threee alternatives:
a) the conatiner handles inclusion of the pagebar completely on it's own (than it knows whether it's there)
b) you add a pagebar option to the container and it just sizes appropriately from determining the size of the pagebar itself
c) I generate a information block that returns the pagebar height.

I don't like c, so I would suggest a or b. If you choose a it is till important that I'm able to define if the pagebar element should be visible or not from the plugin page, the reason is that Custom Browse uses other criterias than the standard browse menus to detect this.

If the container handles the pagebar, does this mean that it also will be able to handle both the horizontal and vertical pagebar's ? Or do I still have to handle the vertical pagebar manually in the plugin page ?

3. I fully understand and fear that one. It's even worse: I'm already working on some landscape views myself ;-)

It would be nice if the plugin pages didn't have to anything special to get a working landscape view. As long as you only want to resize things and the plugin don't want to rearrange things in the page I think this should be possible.

pippin

2008-01-05, 07:45

It's a bit crowed inside the title bar, at least with the current fontsize. So I think it would be preferable to have it just below the title bar. Maybe with some background color that differs it from the container so you notice it better. Maybe something similar to the contentanchor coloring, but I think it needs to be able to contain several rows to be usable. The contentanchor component looks pretty bad if the text wraps around so you get two lines.

That's a bug. Add
background-color: rgb(182,201,207) !important;
to the "td.ListHeader" definition in slimserver.css. That helps.

I don't like c, so I would suggest a or b. If you choose a it is till important that I'm able to define if the pagebar element should be visible or not from the plugin page, the reason is that Custom Browse uses other criterias than the standard browse menus to detect this.

So b), I think 'hasPagebar' is used on other occasions as well?

If the container handles the pagebar, does this mean that it also will be able to handle both the horizontal and vertical pagebar's ? Or do I still have to handle the vertical pagebar manually in the plugin page ?

I would like to handle that automatically if you use "contentcontainer". No need to perpetuate ugly first time hacks... You would have to set the appropriate info in the pageinfo structure, though.

It would be nice if the plugin pages didn't have to anything special to get a working landscape view. As long as you only want to resize things and the plugin don't want to rearrange things in the page I think this should be possible.
Yep. If I allow this, that's what I want to make happen, don't want to rewrite all of my code as well ;-)
Currently I plan on always defaulting to artwork view in landscape mode anyway.

For the time being just remove "maximum-scale=1.0;" on the portrait section of iHeaderVert.html, then it scales automatically (line 9)