GSoC Application Review

[Matěj Laitl]

On 30. 4. 2013 Anmol Ahuja wrote:
> On Tue, Apr 30, 2013 at 3:56 AM, Matěj Laitl <matej at laitl.cz> wrote:
> > Right, although I'd remove the "porting popular A 1.4 scripts" - there are
> > more useful things you'll be able to do, like promoting Amarok scripting,
> 
> I'm not certain about how I would promote Amarok scripting.

Basically I meant that you would publish your weekly reports in a public blog 
(that we'll aggregate on Planet KDE and Planet Amarok) where you would 
actively encourage feeback from script owners, tell about new features, 
provide ideas for new script possibilities etc.

Inspiration: http://strohel.blogspot.com/search/label/gsoc

> > getting feedback on scripting interface from existing script authors etc.
> 
> I am interested in knowing what the Amarok scripting community wants. Can I
> find Amarok scripters on #amarok?

Perhaps some of them, but non-interactive channels are perhaps better. Think 
of amarok at kde.org and Amarok Forum.

> Can I set up an Amarok Script feature request poll on the Amarok website?

Perhaps the Amarok Forum would be even better place -- it already supports 
creating polls. You'd link the polls from your blog etc.

> > Yeah, transcoding may end up just as some parameter of a method in
> > CollectionLocation, although it may be useful
> 
> I can see uses for a transcoding controls in Amarok Script. For instance,
> you can have a script that uploads any song you love on Last.FM to be
> uploaded to your Google Music account, transcoded to MP3 if, say, it is
> FLAC or Apple Lossless, not otherwise. This sort of stuff is not
> configurable from the main interface, not yet at least.

Right, it would be "nice to have", but not critical. Perhaps give it low 
priority.

> > >  - Synchronization Job
> > 
> > Do you mean statistics synchronization? Perhaps even more useful would be
> > to expose "Track matching job" is some way.
> 
> Okay, I'll include Track matching job in the next revision. The
> SynchronizationJob is for playlist synchronization and stuff,
> though admittedly I'm not too familiar with that part of Amarok.

Me neither. So maybe don't mention the SynchronizationJob at all - it doesn't 
mean you cannot work on it if you find it could be useful during the summer.

> > > Add suspend inhibition to AmarokScript
> > 
> > Hmmm, I don't think we should support this - the inhibition is pretty much
> > defined by the playback.
> 
> This is to allow scripts to inhibit suspend, for example, when they are
> downloading something. Or is that actually bad? Maybe we should have  a
> popup show up in case a script is inhibiting suspend so as not to perplex
> users?

Hmmm, I think this would be a misuse of suspend inhibition - for example I 
don't want my Firefox to suspend inhibition when it is downloading something. 
I just want the download to continue on resume.

The desperate scripts that would really need this can use QtScript DBus 
bindings to directly call power management deamon to do this. But let's not 
encourage scripts to do it -> don't provide binding for it in Amarok Script 
API.

> >  - Bug 205509 <https://bugs.kde.org/show_bug.cgi?id=205509>:
> > Add dbus functions to update podcasts and download podcast tracks
> > 
> > These are for the D-Bus API instead, but yes, perhaps the reported would
> > be happy with the Javascript API.
> 
> I was actually planning on adding those to the D-BUS too. Should I keep it
> out of my proposal?

Well, I really think these methods would be much more suited for scripts than 
D-Bus API. You may ask the reporter. D-Bus should be really used when 
communicating with other existing programs, not as a way to extend Amarok.

The thing is that we cannot simply implement everything what users request - 
we must question it whether it fits the purpose of the component, whether it is 
general and reusable enough, who will do the maintenance...

> > > 2. AmarokEngineScript
> > > stopped(); paused(); // needed? can be inferred from
> > > playbackStateChanged();
> > 
> > I'd preserve these for convenience.
> 
> They don't already exist, I was wondering whether I should add them, since
> they can be inferred from engineState(), which already exists (not
> playbackStateChanged() signal as mentioned above, that's erroneous). I'll
> add them as properties. (The implementation details only list properties
> and signals/ slots that don't already exist)

Hmm. UMO redundant signals are fine (ie. having all of playbackStateChanged() 
and stopped(), paused()), redundant properties seem convoluted to me, so I'd 
just leave the engineState property and add the 2 convenience signals.

> > > 3. AmarokEqualizerScript
> > 
> > Needs some more thinking, no need to do it in the proposal.
> 
> Is this unnecessary? I can't think of much use for the scriptable equalizer
> either, except for things like mood scripts and switching equalizer preset
> on inserting headphones (headphone detection isn't in the Amarok code yet,
> either, and I'm not even sure if it's possible with Solid). But there
> was a feature
> request <https://bugs.kde.org/show_bug.cgi?id=279701> for this, and it
> seems pretty reasonable to expose it.

Well, Ryan McCoskrie <ryan.mccoskrie at gmail.com> seems to want this - perhaps 
contact him to see what is the rationale.

> > >  public:
> > >         enum Type
> > >         {
> > >         
> > >             UmsCollection,
> > >             IpodCollection,
> > >             (...)
> > 
> > No no no, this is artificial and no such enum actually exists in C++ code.
> > Instead, there should be just a method to get a list of collections
> > (please
> > hide the distinction between viewable and whatever else, just return the
> > "active" collections).
> 
> Okay. I'll just use a type field so script authors can identify the type of
> collection.

No, we don't have a concept of collection "types". A collection has an id, 
pretty name, and an icon. That must suffice. Some collections have historical 
ids like "localCollection", but this shouldn't be depended on.

> Okay.
> Can I move Script Creator to the bottom of the priority list? I won't waste
> too many lines of the proposal on it either.

Yes. Or perhaps you can have a soft goal of rewriting the Script Console in 
C++ (as you've already mentioned) so that it can have more features (well, 
this is perhaps what it is meant by Script Creator). That would be fine as a 
soft-goal with low priority.

	Matěj