Ian Monroe wrote:

hds wrote:

Marcel wrote:d) script playlist2html still not fixed.

Worksforme.

i doubt that. the TrackNumber is not shown. field is empty.
i had this fixed manually in the source and posted it here.

token wrote:Although I still like the 'old' style better, I do believe changing to the new look by default, but leaving the old look as an option would be a good way to go, it'd let us 'oldies' give the new look time to mature. I think the new look can be good if it had time to grow, but it was just such a quick change, and it seemed 'too' quick. Lots of things with the new look weren't considered. If you're not still working on the new look, don't stop! It needs more time to mature, and I think thats most of the reason people didn't like it.. It wasn't very mature at all.

The devs don't like options. Putting an option in (kind of) means they did a bad feature that most people don't want...

The new look has been put aside for now, but it will probably come back for the 2.0 series, together with a better CSS theme. I was one of the guys who worked on the horizontal context browser (mostly fixing bugs and issues in the tabs widget), and the reason for it not being "mature" was that most of the work was spent on the stuff around the browser itself. Noone thought fixing the CSS was fun enough... (Except muesli that fixed some of the layout on the "no playing" page.)

Jocke "Firetech" Andersson wrote:

token wrote:Although I still like the 'old' style better, I do believe changing to the new look by default, but leaving the old look as an option would be a good way to go, it'd let us 'oldies' give the new look time to mature. I think the new look can be good if it had time to grow, but it was just such a quick change, and it seemed 'too' quick. Lots of things with the new look weren't considered. If you're not still working on the new look, don't stop! It needs more time to mature, and I think thats most of the reason people didn't like it.. It wasn't very mature at all.

The devs don't like options. Putting an option in (kind of) means they did a bad feature that most people don't want...

you are not serious. are you?
options are to satisfy plenty people. some like it blue, some like it red.
some like art, some like xine, and some like gstreamer.
same with layouts and whatnot.

hds wrote:

Jocke "Firetech" Andersson wrote:The devs don't like options. Putting an option in (kind of) means they did a bad feature that most people don't want...

you are not serious. are you?
options are to satisfy plenty people. some like it blue, some like it red.
some like art, some like xine, and some like gstreamer.
same with layouts and whatnot.

To many options >> To many things on screen >> one big mess

http://www.icefox.net/articles/kdeosx.php >> "3. Applications present simple default views"

So good interface don't need many options. At least not in media player application.

patpi wrote:To many options >> To many things on screen >> one big mess

http://www.icefox.net/articles/kdeosx.php >> "3. Applications present simple default views"

So good interface don't need many options. At least not in media player application.

Oh yes, it does. There's nothing to say against a simple _default_ view, as long as it's configurable for "advanced" users. If I wanted others to dictate the way I handle and configure things, I'd use GNOME.

To be more serious: There is no "one size fits all", especially not with a media player application like Amarok. The more features, the more different ways to use them. The more information and contexts available, the more different ways to display them. That's something a simple CSS layout change won't achieve for Amarok. While it's a good thing to think about usabitliy, it's a bad thing to confuse it with uniformity. And even if the adressbook of OS X is more usable than it's  KDE counterpart, there are things that KDE does better: Amarok kicks iTunes **** in terms of usability (at least from my POV). Keep it that way!

A good interface needs options. At least the button labeled "Advanced Settings". That one won't mess with a simple default view. I totally agree with you that most of KDE's applications could need a more uncluttered, more tidy interface. But certainly not by cutting off functionality, flexibility or the ability to customize an environment to individual  needs.

I have to agree, the new context menu location causes too much scrolling where there was no scrolling before.  You cannot look "at a glance" to see the similar tracks, suggested, icons, etc.  And if you're using lyrc?  I prefer to have it full height along side the playlist, and not scroll around.

I did not really like the new layout but it was great to see context browser and collection at one time. I think we could do it this way:
http://thenktor.dyndns.org/bilder/amarok-gui.png

Context browser always in top of collection/playlist/files.

I don't like the new interface, definately. It should allow us to choose the window layout as we like. Just placing different tabs on different places.

Jocke "Firetech" Andersson wrote:The devs don't like options. Putting an option in (kind of) means they did a bad feature that most people don't want...

but this is not a feature. it's a layout.
extermining options is ok if the result is acceptable compromise (or the Ideal Solution).
unfortunately the 'new' layout was unusable on smaller screens (1024x768), which resulted in a choice between playlist & context browser.
these both are important parts of amarok (and context browser being one of the selling points). meking them fight one another is a bad thing.
on the other hand, i can see how horizontal layout would be better on large screens.
unless there is a plan to give out large screen with each copy of amarok, a choice between horizontal/vertical layout would be very, very welcome.

It looks like the layout option is still lacking and I definitively  support people asking for it, using amarok with less than 1024 horizontal resolution is very hard, and my 1280x700 pivot monitor suffer a lot of this forced horizontal layout.

Thanks for developing
Roberto