Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: HTML-based layout (Read 16049 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

HTML-based layout

I was thinking... PanelsUI and SCPL and trackinfo_mod are great and all, but they have a rather steep learning curve and the formatting is rather arbitrary and not all that efficient to write.

Why not use an HTML based layout with CSS for appearance and Javascript for functionality? Many more people would be able to design layouts (there are a larger number of great webdesigners than there are foobar-layout-makers) and they would be much simpler to tweak and so on. It doesn't even have to be full HTML, just some sort of XML-based thing. Then you could even add in panels as xml-elements. I don't have any time to program such a component, but it would make foobar so much more straightforward to customize, and with even a bit of JS support interactive layouts would increase dramatically.

Several programs already use such a layout. For example, Konfabulator/Yahoo! Widgets and (I believe) the MacOS dashboard as well.

Any comments? Is this feasible? Anyone want to program such a thing? I'll look into it this summer, when I have more spare time, but if someone else wants to take the initiative, go ahead.

HTML-based layout

Reply #1 –
I second this and many devs would be glad that titleformatting was kept used for what it was intended for.
Can't wait for a HD-AAC encoder :P

HTML-based layout

Reply #2 –
Here-here.

I think this would essentially be a browser engine component, right? Therefore the first thing some people are going to say is they do not want fb2k bloated by the IE engine. Then you'll have IE vs Mozilla debates. It's been brought up a few times before.

HTML-based layout

Reply #3 –
Really, the amount of new functions PanelsUI and trackinfo_mod have introduced are really pretty minimal considering the amount of functionality they bring.

Anyways, if someone wanted to create skins in XML, they can always skin Winamp.
elevatorladylevitateme

HTML-based layout

Reply #4 –
I agree, an xml/html/js based system would be nice, but... titleformatting is, among other things, a link between tags embedded in the music file / properties in the foobar2000 playback system and the UI. This change would entail a complete rewrite of ColumnsUI and PanelsUI.

HTML-based layout

Reply #5 –
HTML would be amazing to skin in, but then theres the $if functions and stuff that HTML doesn't have.
Maybe Javascript, but that would be a lot.
<if> tags would work though.

Quote from: metal_termite on
I think this would essentially be a browser engine component, right? Therefore the first thing some people are going to say is they do not want fb2k bloated by the IE engine. Then you'll have IE vs Mozilla debates. It's been brought up a few times before.


Just use the Gecko engine Firefox uses, it's open source I believe.


Terrestrial should so make it though.

HTML-based layout

Reply #6 –
Quote from: Nickoladze on
HTML would be amazing to skin in, but then theres the $if functions and stuff that HTML doesn't have.
Maybe Javascript, but that would be a lot.
<if> tags would work though.

Yeah good point, The end result of this would probably be what we have now with functions wrapped in angle brackets, rather than being preceded by dollar signs. 
elevatorladylevitateme

HTML-based layout

Reply #8 –
I'd try to make this in a heartbeat if I knew C.

HTML-based layout

Reply #9 –
Quote from: shakey_snake on
Yeah good point, The end result of this would probably be what we have now with functions wrapped in angle brackets, rather than being preceded by dollar signs. 


You could use something syntaxed like xlst. (example: list of songs with now-playing)

Code: [Select]
...snip...
<li>
  <code:if test="%_is_playing == true">[stuff to style as now playing goes here.]</code>
</li>

And with CSS you can just override the default style, so for that example you don't even need an else.

Other things would be:
Code: [Select]
  <code:if test="len(%album%) > 30">...</code>

len as a function (or $len, if you prefer) makes sense because it actually is relevant to titleformatting strings rather than the appearance/decision-flow of the layout.
However, things like $button and $imageabs2 and all the font effect functions do not make sense because they are purely layout. The whole idea behind css/html is to separate layout and logic... which is why I thought it would work here too.

HTML-based layout

Reply #10 –
Quote from: stormgren on
However, things like $button and $imageabs2 and all the font effect functions do not make sense because they are purely layout. The whole idea behind css/html is to separate layout and logic... which is why I thought it would work here too.

yeah,
I understand the theory of css, because I've done a lot of web stuff before.
I also understand that foobar's titleformatting is more like php/mysql than anything, since we're dealing mainly with logic and accessing database.

I also understand that any effort put into a project like this could be used in a exponentially more beneficial effort of updating and improving the the wiki documentation on the title formatting syntax we already have.
There are only like 3 of us that ever help update the panelUI or SCPL entries in the wiki.
elevatorladylevitateme

HTML-based layout

Reply #11 –
There was a http plugin for I think 083, which allowed you to connect to and control foobar from your browser. Thats about as close as you can get for it imo, and the best overall solution (it doesnt bloat the player with browser code, TAGZ still work, etc).

HTML-based layout

Reply #12 –
It was only a matter of time before the "b" word was used.

HTML-based layout

Reply #13 –
Quote from: metal_termite on
I think this would essentially be a browser engine component, right? Therefore the first thing some people are going to say is they do not want fb2k bloated by the IE engine. Then you'll have IE vs Mozilla debates. It's been brought up a few times before.

Gecko and IE are not the only HTML/CSS rendering engines with scripting support. For example, see Sciter by Terra Informatica. It combines the HTMLayout rendering engine with the TIScript scripting engine (both from the same company). Unfortunately, it is still in development and the licensing situation is still a little unclear (at least to me). From what I remember, Sciter was going to be a commercial product only, unlike HTMLayout and TIScript which are both free for non-commercial use. HTMLayout has custom extensions to HTML and CSS which are designed specifically for the creation of user interfaces.


Quote from: shakey_snake on
Really, the amount of new functions PanelsUI and trackinfo_mod have introduced are really pretty minimal considering the amount of functionality they bring.
The introduction of the $eval() function alone is a good example why such a component would benefit from a real scripting engine instead of trying to extend the titleformatting language for things it was never meant to do.


Quote from: jonpb on
I agree, an xml/html/js based system would be nice, but... titleformatting is, among other things, a link between tags embedded in the music file / properties in the foobar2000 playback system and the UI. This change would entail a complete rewrite of ColumnsUI and PanelsUI.

No, it wouldn't. It is perfectly possibly to create a Columns UI panel using a HTML/CSS rendering engine which is also able to host other panels (been there, done that, abandoned it for mostly personal reasons). Regarding the purpose of the titleformatting language, I would replace "among other things" with "first and foremost" in your statement.


Quote from: shakey_snake on
Yeah good point, The end result of this would probably be what we have now with functions wrapped in angle brackets, rather than being preceded by dollar signs. 

There is no reason to replace titleformatting with something completely different. You could use HTML/CSS to provide the structure and layout and titleformatting for the dynamic content. You don't even need JavaScript for such a scenario though it provides extra flexibility.


Quote from: shakey_snake on
yeah,
I understand the theory of css, because I've done a lot of web stuff before.
I also understand that foobar's titleformatting is more like php/mysql than anything, since we're dealing mainly with logic and accessing database.

It is far more limited in its capabilities and purpose than even PHP alone.

Quote from: shakey_snake on
I also understand that any effort put into a project like this could be used in a exponentially more beneficial effort of updating and improving the the wiki documentation on the title formatting syntax we already have.
There are only like 3 of us that ever help update the panelUI or SCPL entries in the wiki.

I have a strong dislike for the excessive use of titleformatting in Panels UI. I think working on a superior approach is worth more than trying to document the current one.

HTML-based layout

Reply #14 –
I noticed a quick hint towards Winamp's XML skinning language or more correct "modern skins" which is based on the flexible user interface subsystem of Winamp3* and used it's own scripting language called Maki (looked like C code).

This user interface system is one the best IMHO and it would not be terrible to see a foo_ui component which brings this to foobar2000. Of course this will never happen as this part of Winamp3 is closed-source. The rest of the Winamp3 or Wasabi platform is open-source and you can download the latest SDK here or here.

The good thing about foobar2000 is that although it is closed-source it has such an open component architecture that you can even write your own UI engine for it completely from scratch. In Winamp3 (as the player, not the platform which is Wasabi) you had to resort to the Maki language and XML.

I also completely agree in that the title formatting language has been stretched too far. It is really only useful for formatting titles and doing text-processing. Using it as anything else merely displays the lack of structure as in "we just hacked together pieces here and there". Of course it works, but so does a lot of things that are not elegant (think of old Russian cars). The problem with stuff like this is that you can't build upon it and make it any better because that ultimately requires a complete rewrite.
As much as I love Panels UI and Track Info mod, I think it goes in the wrong direction.

*) A short-lived Nullsoft experiment where the primary goals were complete component based architecture as opposed the the semi-component based Winamp 2.x and secondary goals were platform independence.
 

HTML-based layout

Reply #15 –
If there are no other takers for this, I will implement it once school lets out and I have some spare time.

HTML-based layout

Reply #16 –
That is fantastic news, stormgren.

HTML-based layout

Reply #19 –
I think there's need for a language which simplifies anything. Meanwhile I'm not tuning my layouts any more, as I became sick of the complexity of the scripting syntax, which you all know of (42 closing brackets e.g.). With the appearance of panels ui, I lost control. I still don't know what some tagz based fields are for and I also didn't learn the new commands any more.

The current state requires an über geek with über amount of time.

HTML-based layout

Reply #20 –
Quote from: Squeller on
The current state requires an über geek with über amount of time.
If you can come up with something that's easier to code, and has just as much power as columns or panels,
<bad pun>then more power to you</bad pun>.

However, I am still highly skeptical that this do-able.
In all languages, more Power and less complexity are a direct trade-off.
And the titleformating syntax still isn't half as awkward as MAKI,

On a related note, I don't understand why people seem to have given up creating columnsUI layouts.
You can still make really nice layouts with columns, and it's much easier to learn, even if it is slightly less powerful than panelsUI.
elevatorladylevitateme

HTML-based layout

Reply #21 –
Quote from: shakey_snake on
However, I am still highly skeptical that this do-able.
In all languages, more Power and less complexity are a direct trade-off.

Nearly every complex website uses HTML and Javascript. I mean, you can write some pretty slick apps now. Look at what Google's done with Reader and the Personal Homepage and the Google Apps (for example.) It's still all relatively simple JS (by simple, I mean that it doesn't have a very steep curve) and presented with HTML. What I originally envisioned (and still hope to accomplish) was some sort of markup for layout, scripting for interaction, and titleformatting for database access (ie, what would be server-side stuff for a website).
Quote from: shakey_snake on
And the titleformating syntax still isn't half as awkward as MAKI,

MAKI is pretty much c-style code, which is typical. The thing of it is, if you can write one C-style language (Java, C/C++, PHP even, C#, Javascript) you can at least read them all. So MAKI is very easy to learn for anyone who knows any of those languages, and if you can learn MAKI it's also a nice step towards those languages. Even though I don't know very much Java at all, I can guess that the math functions would be exposed under the Math object, which is probably in the System class or maybe in the Language. I don't know if that's even correct, but it would be logical. The current Panels UI titleformatting is pretty damn awkward and arbitrary if you look at it like that.

I still think titleformatting has been stretched too far beyond its original purpose of accessing and manipulating song tags. For example, $imageabs has the X,Y coordinates of the image as the first two arguments. $imageabs2 has the crop area width and height, AND THEN the X,Y coordinates. Why that odd change of order? Another thing, why are the sections like PerSecond and PerTrack defined in comments... That threw me off when I first tried Panels--I thought they were just annotating, but I didn't see any other separation between sections. If we were using a c-style script they would clearly be labelled with brackets, or even as functions. But not as comments. The eval() function has been created to replace $add, $sub, $mul, $div, $muldiv, etc. Why were they there in the first place? Why can't I ever type %tracknumber%+2?

Etc. I can keep nitpicking, but I don't want to. It's still a decent language, but just look at all the inconsistencies.

So, yes, I agree that PanelsUI is indeed very powerful. But that doesn't mean it's not awkward and difficult to use. I am a pretty competent programmer, but I still absolutely hate wading through the spaghetti that most PanelsUI layouts turn out as. Maybe you don't, but I need to check up the documentation for the order of the arguments every time I want to add anything to a layout.

HTML-based layout

Reply #22 –
To be fair, $imageabs2() became deprecated near the end, but it's functionality was combined with $imageabs() with a more sane argument order.

HTML-based layout

Reply #23 –
Do you want foobar2000 to be like Songbird?!?

HTML-based layout

Reply #24 –
Quote from: Fandango on
Do you want foobar2000 to be like Songbird?!?


No, Songbird is what I would call bloatware. It wants to do too much.
Besides, this wouldn't have to be a part of the default Foobar setup, just an extra component/

Songbird is pretty much a mediaplayer and browser combined.
I think a component like this would be awesome, but it shouldn't be a full featured web browser with navigation controls, bookmark system, download manager and stuff like that. A lightweight browser component like this could bring really nice features supporting the main purpose of Foobar which is playing music. I know, some of you will say that Foobar is just about listening to music and nothing else. People hide it in the background and that's it. Well,that's not the case for everyone. While I listen to music I often lookup artist and album information on the web plus I'm an LastFM junkie. I would love to integrate my LastFM statistics in Foobar for instance. A mediaplayer like Amarok shows what a mini browser could bring. Unfortunately it's UI is a pile of poo.

Secondly, it would serve well as a replacement for PanelsUI/Track Info Mod. People could make their own, local mini webpages interfacing with Foobar to show track info, stats, you name it. HTML and CSS are easy to learn, much easier than Panels's formatting, so anyone with some basic HTML coding ability will be able to get started.

A component like this, for me, would be the icing on the cake. I would love it. So, if anyone has the capabilities to make something like this, please do