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: Prototype Interface Idea (Read 18003 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Prototype Interface Idea

I don't have one yet, but I had the idea today to design an interface for foobar in Photoshop to exemplify what we each would like to see an interface look like for "our perfect player". So don't think "current" components and columns ui... I'm thinking more along the lines of do what ever the hell you want and show whatever information you want.

This could be interesting considering plugins will be built for the next version of FB2K once .9 is released.

What do you guys think?

Prototype Interface Idea

Reply #1 –
It's not a bad idea, but I think most people are happy with ColumnsUI...
Personally I can't imagine anything better, hopefully you or someone else can!

Tony

Prototype Interface Idea

Reply #2 –
Quote
It's not a bad idea, but I think most people are happy with ColumnsUI...
Personally I can't imagine anything better, hopefully you or someone else can!

Tony
[a href="index.php?act=findpost&pid=285850"][{POST_SNAPBACK}][/a]

Well, what I was thinking was a redesign of the entire interface... like having the ability to have the visualization effects behind the text of the playlist... and getting out of the "panel/bar/box" mode.

Prototype Interface Idea

Reply #3 –
Sounds cool, though I don't know how many people will switch to something like that (for normal use atleast).

As of right now, Columns UI suffices, but then again, you don't miss what you don't know....

Prototype Interface Idea

Reply #4 –
Okay, if you really want to do this, go download the Avalon Community Technology Preview and design the interface using that so that Foobar can enter the Longhorn era with some grace. If you don't know, Avalon will also be released for all windows xp users as well, so the advanced 3d interfaces of apps in the 2007 to 2009 timeframe will be available to a wide installed base.

Prototype Interface Idea

Reply #5 –
God damn it...

I'm not talking about COLUMNS UI... I'm talking about the whole fricken window... jesus christ people, break out of the box model... we can do all sorts of things if we model it right. Columns UI is good for track lists, but look at the history/directory/db/etc... integrate that into a seamless interface...

I'm talking about going to photoshop and putting things where you want... screw the framework we have to work in now...

Prototype Interface Idea

Reply #6 –
Eh, why screw the current framework?

I switched to fb2k to get away from most of the flashy shiny skinned crap that is Winamp. fb2k plays my music, and almost never crashes. This is good enough for me: IIAB,DFI.

Prototype Interface Idea

Reply #7 –
I would love something like this.

based on fb2k and musikcube.



on the sides left and right, the user should be able to add, remove, resize any panel.  e.g. album art, treeview, playlist whatever.

every section or panel should be truly dockable, including the actual playlist itself.

how you like the idea, well actually its 2 players mixed together so its not my idea really.

alex

Prototype Interface Idea

Reply #8 –
Quote
I would love something like this.

based on fb2k and musikcube.



on the sides left and right, the user should be able to add, remove, resize any panel.  e.g. album art, treeview, playlist whatever.

every section or panel should be truly dockable, including the actual playlist itself.

how you like the idea, well actually its 2 players mixed together so its not my idea really.

alex
[a href="index.php?act=findpost&pid=286033"][{POST_SNAPBACK}][/a]

You can already have (almost) this, except maybe the left-sidebar (not sure), but this can be easily implemented I think.

I dont think SuperPhly was referring to that kind of changes...

Prototype Interface Idea

Reply #9 –
Quote
God damn it...

I'm not talking about COLUMNS UI... I'm talking about the whole fricken window... jesus christ people, break out of the box model... we can do all sorts of things if we model it right. Columns UI is good for track lists, but look at the history/directory/db/etc... integrate that into a seamless interface...

I'm talking about going to photoshop and putting things where you want... screw the framework we have to work in now...
[a href="index.php?act=findpost&pid=285968"][{POST_SNAPBACK}][/a]



Chill out dude.

Lots of FB2K users just happen to be very happy with the interfaces they've got at the moment.

In case you want something different no one is stoppping you from programming it.

Prototype Interface Idea

Reply #10 –
The only thing that should be possible is adding panels on all sides of the playlist imo, then panel extensions can be made and used for everything else...

Prototype Interface Idea

Reply #11 –
Interesting idea for a thread. I'd actually been kicking around ideas about basing the foobar UI (or, at least, the playlist part) around XML / XSL / HTML / CSS, though I'm pretty sure it'd be far too slow to implement a full XSL system whilst still retaining the speed and 'light' feeling of the UI.

Nonetheless something *roughly* like this would be great for me:



arty

Prototype Interface Idea

Reply #12 –
That is a nice UI set up right there, but I think Super was thinking of skinning it in a way kind of similar to winAMP 5, or other players.

I do enjoy that setup though.

Prototype Interface Idea

Reply #13 –
Quote
Interesting idea for a thread. I'd actually been kicking around ideas about basing the foobar UI (or, at least, the playlist part) around XML / XSL / HTML / CSS, though I'm pretty sure it'd be far too slow to implement a full XSL system whilst still retaining the speed and 'light' feeling of the UI.

Nonetheless something *roughly* like this would be great for me:



arty
[a href="index.php?act=findpost&pid=286068"][{POST_SNAPBACK}][/a]

Yes, that's exactly what I was thinking...

Having tags like: <albumname> and <artist> would be great for generating HTML style templates. The css/html/xml stuff isn't all that hard to do for this sorta thing. I mean just add the hooks for <a href="blah"> to tell the player what to do.

I mean this even takes foobar as a "server" that you control via... html browser... which really isn't all that different than what we have now ya know, one's an API the other is via the network... same principle...
 

Prototype Interface Idea

Reply #14 –
Quote
Quote
Interesting idea for a thread. I'd actually been kicking around ideas about basing the foobar UI (or, at least, the playlist part) around XML / XSL / HTML / CSS, though I'm pretty sure it'd be far too slow to implement a full XSL system whilst still retaining the speed and 'light' feeling of the UI.

arty
[a href="index.php?act=findpost&pid=286068"][{POST_SNAPBACK}][/a]

Yes, that's exactly what I was thinking...

Having tags like: <albumname> and <artist> would be great for generating HTML style templates. The css/html/xml stuff isn't all that hard to do for this sorta thing. I mean just add the hooks for <a href="blah"> to tell the player what to do.

I mean this even takes foobar as a "server" that you control via... html browser... which really isn't all that different than what we have now ya know, one's an API the other is via the network... same principle...
[a href="index.php?act=findpost&pid=286194"][{POST_SNAPBACK}][/a]

... Curse you.

You found a way to make me eat my words.
I would actually like to have something like this.

Sure, sure, if I could find a way to make MPD work on my system and go through all of the pain that is setup... But since I've almost always got a Firefox session going, it'd not be that hard for me to open a tab to manipulate things. Ctrl+T, alt+home.

... I'm really feeling this idea.

Prototype Interface Idea

Reply #15 –
Quote
Quote
Quote
Interesting idea for a thread. I'd actually been kicking around ideas about basing the foobar UI (or, at least, the playlist part) around XML / XSL / HTML / CSS, though I'm pretty sure it'd be far too slow to implement a full XSL system whilst still retaining the speed and 'light' feeling of the UI.

arty
[a href="index.php?act=findpost&pid=286068"][{POST_SNAPBACK}][/a]

Yes, that's exactly what I was thinking...

Having tags like: <albumname> and <artist> would be great for generating HTML style templates. The css/html/xml stuff isn't all that hard to do for this sorta thing. I mean just add the hooks for <a href="blah"> to tell the player what to do.

I mean this even takes foobar as a "server" that you control via... html browser... which really isn't all that different than what we have now ya know, one's an API the other is via the network... same principle...
[a href="index.php?act=findpost&pid=286194"][{POST_SNAPBACK}][/a]

... Curse you.

You found a way to make me eat my words.
I would actually like to have something like this.

Sure, sure, if I could find a way to make MPD work on my system and go through all of the pain that is setup... But since I've almost always got a Firefox session going, it'd not be that hard for me to open a tab to manipulate things. Ctrl+T, alt+home.

... I'm really feeling this idea.
[a href="index.php?act=findpost&pid=286195"][{POST_SNAPBACK}][/a]


Only thing the browser wouldn't have is interactive stuff... like the VIS and stuff like that. There may be ways to hook into foobar and have a plugin for your browser to grab that info, but it's all up to the programmers.

Essentially loading the XML/XSLT stuff in the foobar app is the same as the web browser.

I wish i knew how to program i'd do this.

Anyone wanna get a task force together to start working on this?

and by the way... let's get some more img's up here

Prototype Interface Idea

Reply #16 –
I posted this as a potential interface idea. For this thread though, I made a mockup:



I should add that any entry in the hierarchy should be movable in and out of it, but you shouldn't be able to add entries that are not related, i.e. Sunny Day Real Estate can't go under "Radiohead"

edit: now that I think about it, I originally had it the dropdown arrow thingy as a variable (not a function, which I incorrectly described as a var in the mockup) %_tree%, which if used would add much more flexibility with stuff such as $if() statements giving different formatting for expanded/collapsed and so on.

Oh yeah, and this would be a replacement to the columns in Columns UI, but still use the same list entry controls and whatnot.

Prototype Interface Idea

Reply #17 –
Thanks Killmaster, I just borrowed an idea of you for my foobar2000 interface.  My foo_playlist_tree now looks similar to your interface.

Prototype Interface Idea

Reply #18 –
Quote
Only thing the browser wouldn't have is interactive stuff... like the VIS and stuff like that. There may be ways to hook into foobar and have a plugin for your browser to grab that info, but it's all up to the programmers.

Essentially loading the XML/XSLT stuff in the foobar app is the same as the web browser.

I wish i knew how to program i'd do this.

Anyone wanna get a task force together to start working on this?[a href="index.php?act=findpost&pid=286211"][{POST_SNAPBACK}][/a]


The way I was thinking would be that the main foobar playlist window, at least, wouldn't need to be overly dynamic as it is always going to essentially be a list. This would be a good use of quasi-XML / XSL.

However, as you point out, the main interface doesn't really lend itself well to this sort of wrapping in a traditional context. What I'd suggest is coming up with a DTD not dissimilar to MS's XAML (or, for an alternative more people are familiar with, Mozilla's XUL system) so that the whole foobar interface can be controlled with a form of XML and CSS. This would allow essentially arbitrary placement of buttons, visualisations, controls etc. in a way similar to (but foobar'd up!) Winamp 3.

What this would mean as an interesting side project is that you would be potentially able to pipe information from foobar through into a browser, because the data you're dealing with is already in a browser-friendly format, more or less.

In addition if we wanted to get fancy it would be entirely possible to code an XUL application for Mozilla Suite / Firefox that would mimic pretty closely the foobar UI from within a website, buttons, controls, menus and all. This potentially could be very nice for HTPC applications.

There are some important issues which I'm concerned about so far. One is speed; having worked quite a bit with various different XML->XSL->HTML solutions in the past I'm wary of implementing something into foobar that could potentially be very, very slow. It needs to be able to cope with a playlist of 100,000 items as well as 1,000. I've done some tests with various XSLT libraries on my main foobar playlist in XML format and they are all slow, we're talking a second or so to generate at least as I recall.

Another issue is demand. Is this feature far, far too sophisticated for the majority of users when lots of people already get confused over TAGZ, which is a very simple alternative to something like XSL? How many people really want an interface they can flexibly do ANYTHING with? I really don't want to make such a feature such hard work that only a tiny minority of users feel they can make use of it.

And then there's 'bloat'. If someone did go ahead and code something like this I'd be extremely wary of making a full XSL implementation, in particular. XML itself is relatively simple and could be wrapped quite neatly, I think, although it's hardly the most efficient system for use within an application. XSL always seems to be the weakest link in the chain to me, as I've mentioned already. I think we could adapt CSS to make a system that would be adequate for most of the things people would want or need to do in foobar without doing a full CSS implementation.

In short (), I suggest we consider how practical a lot of this stuff is and how popular it is likely to be, and where we want to go with it. Do we just want an HTML-style playlist or do we want a fully XML-controlled media player? Is XML even appropriate when a lot of the 'data transport' will be internal?

Not trying to kill the idea, of course, I'm just still unsure about how practical it would be. Give me your thoughts, please

arty

Prototype Interface Idea

Reply #19 –
Quote
Quote
Only thing the browser wouldn't have is interactive stuff... like the VIS and stuff like that. There may be ways to hook into foobar and have a plugin for your browser to grab that info, but it's all up to the programmers.

Essentially loading the XML/XSLT stuff in the foobar app is the same as the web browser.

I wish i knew how to program i'd do this.

Anyone wanna get a task force together to start working on this?[a href="index.php?act=findpost&pid=286211"][{POST_SNAPBACK}][/a]


The way I was thinking would be that the main foobar playlist window, at least, wouldn't need to be overly dynamic as it is always going to essentially be a list. This would be a good use of quasi-XML / XSL.

However, as you point out, the main interface doesn't really lend itself well to this sort of wrapping in a traditional context. What I'd suggest is coming up with a DTD not dissimilar to MS's XAML (or, for an alternative more people are familiar with, Mozilla's XUL system) so that the whole foobar interface can be controlled with a form of XML and CSS. This would allow essentially arbitrary placement of buttons, visualisations, controls etc. in a way similar to (but foobar'd up!) Winamp 3.

What this would mean as an interesting side project is that you would be potentially able to pipe information from foobar through into a browser, because the data you're dealing with is already in a browser-friendly format, more or less.

In addition if we wanted to get fancy it would be entirely possible to code an XUL application for Mozilla Suite / Firefox that would mimic pretty closely the foobar UI from within a website, buttons, controls, menus and all. This potentially could be very nice for HTPC applications.

There are some important issues which I'm concerned about so far. One is speed; having worked quite a bit with various different XML->XSL->HTML solutions in the past I'm wary of implementing something into foobar that could potentially be very, very slow. It needs to be able to cope with a playlist of 100,000 items as well as 1,000. I've done some tests with various XSLT libraries on my main foobar playlist in XML format and they are all slow, we're talking a second or so to generate at least as I recall.

Another issue is demand. Is this feature far, far too sophisticated for the majority of users when lots of people already get confused over TAGZ, which is a very simple alternative to something like XSL? How many people really want an interface they can flexibly do ANYTHING with? I really don't want to make such a feature such hard work that only a tiny minority of users feel they can make use of it.

And then there's 'bloat'. If someone did go ahead and code something like this I'd be extremely wary of making a full XSL implementation, in particular. XML itself is relatively simple and could be wrapped quite neatly, I think, although it's hardly the most efficient system for use within an application. XSL always seems to be the weakest link in the chain to me, as I've mentioned already. I think we could adapt CSS to make a system that would be adequate for most of the things people would want or need to do in foobar without doing a full CSS implementation.

In short (), I suggest we consider how practical a lot of this stuff is and how popular it is likely to be, and where we want to go with it. Do we just want an HTML-style playlist or do we want a fully XML-controlled media player? Is XML even appropriate when a lot of the 'data transport' will be internal?

Not trying to kill the idea, of course, I'm just still unsure about how practical it would be. Give me your thoughts, please

arty
[a href="index.php?act=findpost&pid=286322"][{POST_SNAPBACK}][/a]


I think we should do 2 things.

1. An HTML output component that simply takes the playlist and runs a loop with a string. Have a header and a footer. That way I can design a layout/css for the stuff.

2. An MSHTML panel. It can't be that hard to say "hey, IE, display in this little box". then it can display the stuff we want.

This is going to do some big things for us. We'll be able to start generating HTML pages for info rather than "textinfo box" and stuff like that.

Prototype Interface Idea

Reply #20 –
If you want lots of support in terms of "designs", then don't make the "language" more difficult than TAGZ/HTML/CSS. Else, you will get a handful of uber-designs by skilled coders, and thats it - no community behind it.

What made so many people create playlist-designs is because - if you dont want want to do too much - its really easy.

You don't need a i-do-everything language to create good designs. Instead focus on something which is ingeniously simple and lets you do *almost* everything... but don't fall into the "let the user tweak every single screw of the aircraft"-pit. Besides, some limitations don't necessarily translate to worse designs. Devs once got increadible wizardry out of 64kb. Some people have done the most insane things with tagz. If the framework just becomes a bit more flexible then the amount of possibilities multiplies. Sometimes it makes sense to ask oneself "is this just cool from a coder's perspektive or does it really improve the app in everyday-usage?".

Thats my personal (biased) opinion.
- Lyx
I am arrogant and I can afford it because I deliver.

Prototype Interface Idea

Reply #21 –
Quote
If you want lots of support in terms of "designs", then don't make the "language" more difficult than TAGZ/HTML/CSS. Else, you will get a handful of uber-designs by skilled coders, and thats it - no community behind it.

What made so many people create playlist-designs is because - if you dont want want to do too much - its really easy.

You don't need a i-do-everything language to create good designs. Instead focus on something which is ingeniously simple and lets you do *almost* everything... but don't fall into the "let the user tweak every single screw of the aircraft"-pit. Besides, some limitations don't necessarily translate to worse designs. Devs once got increadible wizardry out of 64kb. Some people have done the most insane things with tagz. If the framework just becomes a bit more flexible then the amount of possibilities multiplies. Sometimes it makes sense to ask oneself "is this just cool from a coder's perspektive or does it really improve the app in everyday-usage?".

Thats my personal (biased) opinion.
- Lyx
[a href="index.php?act=findpost&pid=286539"][{POST_SNAPBACK}][/a]


I agree. The XSL/XML stuff *might* have been a bit overboard, though I could fit into that "skilled coder" area you talked about. I mean XML is the "wave-of-the-future" so why not take advantage of it... but that may be something down the road. I, myself, would like to see the playlist area goto a XHTML/CSS style design for the time being. I don't think we need to reinvent the wheel either... we can use mozilla's rendering agent or use MS's... it's really up to the coders.

Prototype Interface Idea

Reply #22 –
Quote
There are some important issues which I'm concerned about so far. One is speed; having worked quite a bit with various different XML->XSL->HTML solutions in the past I'm wary of implementing something into foobar that could potentially be very, very slow. It needs to be able to cope with a playlist of 100,000 items as well as 1,000. I've done some tests with various XSLT libraries on my main foobar playlist in XML format and they are all slow, we're talking a second or so to generate at least as I recall.[{POST_SNAPBACK}][/a]
Have you tried the aXMLerate toolkit? It can generate parsers and transformers from XML Schema and XSLT specifications. Reliable source claim that it is up to ten times faster than competitive solutions that rely on interpreting the XSLT at runtime. Unfortunately, I don't know where to get this toolkit on the web; contacting one of the people associated would seem to be the best choice in case you are interested.

Despite the performance problems, I quite like the idea of a structured playlist. I have toyed around with the idea since the mid of 2004, but it wasn't until Decembre 2004 that I started implementing a prototype. I rather quickly gave up the idea of using CSS, since it would have meant investing a whole lot of time into designing and implementing a lightweight (and fast!) CSS replacement or using an existing (but slow) implementation. Around Christmas I had a working prototype that could partition and render the playlist ([a href="http://www.stud.uni-karlsruhe.de/~uzbs/fb2k/pics/coruscate.png]screenshot[/url]). (The inspiration for the codename "Coruscate" came from Merriam-Websters "Word of the day" newsletter. The later versions use the term "structured playlist view" inside foobar2000.) Here is a screenshot of a later version where foo_coruscate is used as the primary playlist view in an early alpha of foo_ui_columns 0.1.3. Note that it looks very much like Killmaster's design even though I had not seen it by that time.

The latest version is still a prototype that lacks several features (customization would be one of them...). Also the performance is horrible, since it rebuilds the entire layout when anything in the viewed playlist changes. During playback that means one update per second. For a multi-thousand item playlist, this results in a noticable CPU usage spike. Should you have another CPU intensive task running at the time (like a replaygain scan) this can make foobar2000 unusable. The best option in that case is to switch to a smaller playlist or temporarilly stop playback. Acceptable playlist sizes range from a few dozen to a few hundred items depending on your system.

The component still lacks a few other features: drag&drop, manual playlist reordering, folding of groups, and - last but not least - customization. While it is configurable deep-down, there is no interface for that. (The latest version at least has a color configuration dialog in preferences.)

Please read the following before you download the prototype below: The component is based on the idea that it still presents a playlist, i.e. a list of single items. The only way to interact with a group is to interact with all the items in the group. Example: You cannot focus a group, only individual items. By selecting a group, you select all the items it contains. Likewise, selecting all the items in a group highlights the group itself. The structure is build solely from the items in the playlist and their tags; if you want to change it (other than reordering), you have to retag the songs.
Mouse and keyboard interaction work very similar to the playlist view in the default UI (except for the aforementioned missing features). The playlist can be navigated with the following keys:
  • up, down: item-wise movement
  • page up, page down: page-wise movement
  • home, end: jump to first or last item
  • left, right: jump to the first or last item of the group. If you press left when the first item has the focus, it will jump to the first item of the enclosing group (if any); likewise for right.
The target item will always get the focus. If you don't press any modifier keys, it will also be the only selected item. Use Control to move the focus while leaving the selection unchanged. Shift extends the selection state of the current item to the target item. Space toggles the selection state of the focused item.

Warning: There is a as of now unlocated crash bug that seems to be related to untagged items. Any hints regarding this bug are welcome.

Download link
Use it at your own risk!

Why am I telling you all this and offering this prototype for download?
1) I want to find that crash bug.
2) I want to show you that the ideas in this thread at least have some chance to be implemented.

Btw: The pixel-accurate scrolling will for sure be sacrificed in favour of performance. It is one of the things that prevents building the structure incrementally (as needed).

Prototype Interface Idea

Reply #23 –
clarification: with "not more difficult than tagz/html/css" i didn't mean that one of those languages should be used, but instead that it should not be more difficult than those languages. One should be able to learn how to write a very basic playlist-layout in no more than 30mins.

- Lyx
I am arrogant and I can afford it because I deliver.

Prototype Interface Idea

Reply #24 –
Quote
Have you tried the aXMLerate toolkit? It can generate parsers and transformers from XML Schema and XSLT specifications. Reliable source claim that it is up to ten times faster than competitive solutions that rely on interpreting the XSLT at runtime. Unfortunately, I don't know where to get this toolkit on the web; contacting one of the people associated would seem to be the best choice in case you are interested.


I haven't, actually, though I have heard something about it. I think that my basic problem with XML and XSL, having used both extensively in the last year or so, is their verbosity; they are inherently built for human-readable purposes, which definitely doesn't help their speed of processing. There's simply so much 'redundant' data in your average XML file that it's not that easy a process to deal with it quickly and elegantly. The W3 know this, and that's why they are kicking about proposals for a binary version of XML about now.

I like the look of foo_coruscate in theory and will try to have a proper look at it in the next few days; thanks for posting it. My main issue with the current playlist formatting plugins (e.g. Columns UI) is that there's such a lot of duplicate data, or whitespace. Take the album name; if you have an album column you're stuck with either displaying the album name for every playlist entry (duplication) or just displaying it for track 1 and having a lot of whitespace. Neither is particularly efficient in its use of screen space.

In short, I'd like a user interface that structures my music the way I want it to, rather than just operating as a straight list (which is basically what we have at the moment). I think this is more or less the same as what you're trying to do with youre 'structured playlist' idea; the difficulty, as you say, is implementing something customisable that can refresh quickly whilst being un-clunky and easy to pick up. Columns UI is inherently easy because it's very clear what data is being processed for each table cell; as soon as you introduce any sort of tree structure things start getting tricky.

Should we look at foo_playlist_tree and how its ideas could be implemented as a playlist?

arty