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.

I second this and many devs would be glad that titleformatting was kept used for what it was intended for.

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.

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.

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 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.



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


Terrestrial should so make it 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.

Sure, a browser engine to render layout *could* be an improvement. Someone just needs to give it a go. Actually, I'd prefer a CSS-based approach. http://www.mozilla.org/projects/embedding/faq.html

I'd try to make this in a heartbeat if I knew C.

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


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:

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.

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.

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).

It was only a matter of time before the "b" word was used.

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.


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.



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.



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.



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


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.

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.

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

That is fantastic news, stormgren.

Sweet, I'm looking forward to it!

foo_uie_wsh_panel

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.

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.

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).

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.

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

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

I think that a PHP, HTML and CSS based foobar layout would be amazing. PHP just adds more flexibility, and you can call external files and such too. I don't know for sure if you can do that in HTML, cause I have long since stopped coding in just HTML since I find PHP more flexible.

But this idea sounds awesome. If it comes out well, I may switch over to it fro Panels UI.

PHP would be ridiculous to incorporate into a foobar component. I know with SQL databases there are deliberately miniscule implementations like SQLite that are designed for distribution with applications, but I'm unaware of any that fit that bill for PHP. Things would just get crazy. What average user wants to download a big fat package purely so that they can style their foobar?

Besides, I'm pretty sure calling external files can already be done with a few components(foo_run?), and it'd be pretty easy to add if it can't currently be done.

So what I'm reading making a layout in html should be simpler than the panels ui code but with the same/more possibilities?

And does it work in a separate web browser of just when you start foobar?
Seems like a great id, never made something in html before but I'm ready to learn also learned the panels ui code so...