Viewports vs custom line

[hakimio]

I am wondering why rockbox devs choce to keep Viewports instead of custom line.

Here are few reasons why I think Viewports are WORSE than custom line:
1) Viewports can not be used in conditional tags (i.e. %?C or %?mh);
2) Viewports are drawn on top of the album art (maybe it's a bug?)(...and putting album art tag at the bottom doesn't solve the issue because AA respects viewports, tries to draw AA in the viewport, which was specified above, and fails if the viewport is too small for it).

Do you know any viewports pros? Do you also think choosing viewports instead of custom line was a good decision?

[Llorean]

1) Using them with conditional tags is being addressed.
2) Everything is supposed to be inside viewports, album art included. Obviously if you actually plan your viewport to be the right size, and have properly sized album art it being "too big" and being clipped will not be a problem.

Viewports are vastly more flexible. They allow vertical clipping as well as horizontal, and extend as a system to add flexibility to the rest of Rockbox. Unless you're familiar with the technical details of how both are implemented, don't assume that one unfinished system is inferior to a hack that was in common use in unsupported builds. Scrolling lines really cannot offer the expandability that viewports can.

Also, I've removed your link to an unsupported build and themes not posted in the official gallery. Please, follow the forum guidelines. Also remember that abbreviations such as "imho" should be avoided in favour of real words for our blind and non-native speakers.

[hakimio]

1) Using them with conditional tags is being addressed.

Hope this will be implemented soon...

Also, I've removed your link to an unsupported build and themes not posted in the official gallery. Please, follow the forum guidelines. Also remember that abbreviations such as "imho" should be avoided in favour of real words for our blind and non-native speakers.

It seems you have very strict rules here...

[Llorean]

1) This will be implemented just as soon as a volunteer implements it. Remember that all work is done by volunteers. You're welcome to pitch in.

As for the rules, if you'd read them as you agreed to when registering you would've known what they were. I suggest you go ahead and do that now. They're posted in the announcements forum.

[hakimio]

You're welcome to pitch in.

The patch would be rejected because of coding style or after a year or so it would be rejected because it would be outdated. So why bother?

PS: I do understand that the project is lead by volunteers.

[Llorean]

We have a contribution document explaining coding style. We've never rejected a patch based on style alone, simply explained to the author they need to resolve issues with it.

As for outdated, patches only become outdated when the author doesn't follow through and meet the requirements to get it committed.

Basically, both of these should only happen if whoever writes the patch chooses not to follow through with getting the work actually *done* and instead throws together some demo code, and leaves it in the hope of someone else doing the rest of the work.

If you don't want to do it, you're welcome to say "No thanks" but please don't simply try to claim we'd reject it outright, especially when it's something we actually want to see done.

[hakimio]

Llorean, tell me what happened to this patch which was written in 2006-01-09?

[Llorean]

The author hasn't pursued getting it included in SVN, as simple as that.

With features, the developer working on the feature will often keep a watchful eye for patches that improve the feature or fix bugs. With plugins such as this, though, most developers are working on their own things so the plugin author will have to come forward and say "I feel my plugin is complete enough for conclusion. Could I get a developer to look over it."

You'll notice it isn't rejected, so I don't see what it has to do with your prior statements anyway. It really bears no relation at all to the feature I propose you work on (a core feature that's highly wanted by both the developer and user community as compared to a plugin that is not actively developed at all, and the author has not followed up on, which is EXACTLY what I said it necessary above).