by popular request

[T.R.Shashwath]

On Wednesday 21 February 2007 00:32, Gábor Lehel wrote:
> - WRT qt3support, I don't think we should do a big directed purge of
> it, as very large parts of the app will get refactored/rewritten
> anyways -- just don't include it in any new code, and we'll see what's
> still left afterwards.

I agree, except for the major, glaring things, and whenever kdelibs breaks 
something that we're using. But when we have a more or less stabliized 2.0, 
maybe we could have a sort of q3-hunt, where we go and smash all remaining 
q3. :-)

> - I agree that most of amarok sitting in src/ isn't ideal, but how
> could we organize it otherwise? There aren't enough files belonging to
> individual components like the playlist and various browsers to make
> that approach worthwhile. One idea could be separating it by QtCore
> and QtGui dependency, maybe other things like QtSql or TagLib.

Looking at the sources, I think that probably separate UI elements (browsers, 
config, playlist,...) should get their own directories, but then again, many 
of these things also cross over. This probably needs some thought.

> - Phononwise, I think we should write it as an engine, and make it
> default, maybe even remove the option to configure it otherwise from
> the GUI. In the code, though, this option is the least invasive, and
> we wouldn't gain anything by replacing the whole engines system with
> Phonon, just lose flexibility.

Not to mention, there are many people who would want to use Amarok with as few 
KDE dependancies as possible, and who might have problems with Phonon. I 
think it's good to have other engines supported, especially if we're looking 
towards portability.

> - I'm sceptical regarding plugins, but this might be because I've
> never really done a plugin interface, and I have no clue how one might
> look like in amarok's case. Some concrete ideas would go a long way in
> letting me form an opinion about this. The Krita guys seem good with
> plugin systems (they use a lot of them), but then a painting
> application is a lot more modular in concept (tools, colorspaces,
> filters, palettes, etc etc), than an audio player, as far as I can
> tell. Addendum: The browsers do seem like a good candidate, however.

I like the idea of plugins, and it would be interesting, but then again, we 
really don't want to be writnig the GNU Emacs of audio players (don't get me 
wrong, I like emacs, but it's not an audio player).

On the other hand, it seems almost essential that we have some sort of plugin 
support. I'd actually like to separate out the media devices and such into 
plugins - they truly are optional, and dependant on the user having that 
particular device. There are other parts, the browsers as you rightly point 
out, and so on. If we do anything of this sort, I think we should also have 
some "default plugins" which are actually part of the distribution itself 
(like the context browser, say?) and probably coded in C++ instead of a 
scripting language. These would use the same architecture as the plugins so 
as to not have multiple special cases, but would be "official Amarok 
plugins", which really define Amarok.

One potential problem I see with plugins is that we have exactly one chance to 
get the API right. Once it's out in public, it's too late to change it 
(unless you're Linus).

> - I think UI redesigns should invariably go in branches (unless we
> have complete consensus, which is impossible), because people have
> wildly varying tastes in these things, and giving them the new UI in
> an unfinished state would only exacerbate it. Once the creator of the
> new UI thinks it's about done, that's the point when it's worth
> getting feedback, imho.

If we all design our own ideas of UIs, we'll just end up with 20 different UIs 
to choose from, half of which will be combined into a UI that's half way 
between them all. Ultimately, usability nightmare. I suggest that we come up 
with a basic UI, and then everyone experiment with the features they want, 
which we'll finally pick and choose from. (by basic UI, i mean more than 
just "we have one playlist and some browsers - a real spec for the UI - 
probably a mockup using the one mcxl made as a starting point?).

> - Major refactorings should either be worked on in branches or
> locally, either way breakage in trunk should be minimised, and it
> should only see commits once they're in an "it works
> as-far-as-I-can-tell" state.

Agreed... :-)

Shash
-- 
'Would you tell me, please, which way I ought to go from here?'
 'That depends a good deal on where you want to get to,'
 'I don’t know where. . .'
 'Then it doesn’t matter which way you go,'
--Lewis Carroll, Alice in wonderland