2006/11/15, Michael Pujos <<a href="mailto:pujos.michael@laposte.net">pujos.michael@laposte.net</a>>:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Leo Franchi a écrit :<br>> On Tuesday 14 November 2006 16:55, Michael Pujos wrote:<br>><br>>>> Ultra high configurability is absolutely not what we are striving for. I<br>>>> believe it's the task of the developer to provide a good GUI, not the
<br>>>> user's.<br>>>><br>>> This is a valid design decision while a bit disappointing but I can see why<br>>> you'd want to retain a fixed, controllable UI. It's disappointing because<br>>> it's a bit conservative and some advanced users might want a different
<br>>> customized UI to their needs or preferences. However on a development point<br>>> of view it's probably simplier.<br>>><br>><br>> The reasoning begind our decision has much less to do with developmental
<br>> complexity and much more about user experience. We want amarok to be easy,<br>> fun, and powerful to use. We don't cater to the 1% of users who each want a<br>> certain thing to work their own exact way. We care about making a functional
<br>> powerful media player that 99% of users can love and enjoy from the very<br>> first second---not after hours of downloading plugins and scouring forums.<br>><br>> leo<br>><br>I still think you can do both: present a sensible default UI without
<br>having to go after plugins, while being highly componentized.</blockquote><div><br>I see it like this: have a good, light, hard coded GUI but use plugins to provide the content, like context, wiki, shop, lyrics; and other plugins to provide playlists: smart, dynamic, podcasts, ... And yet others to sync with/copy to mediadevices, browse remote collections and so one.
<br>Plugins should be kept as independent from the gui code as possible and separately distributable, preferably in a scrpting language. This will mean less code to maintain/debug for us yet more and easier to implement functionality.
<br><br>But I don't feel we need a configurable GUI.<br><br>Stecchino <br></div><br></div><br>