GSoC Application Review

Thu May 2 16:45:10 UTC 2013

On Thu, May 2, 2013 at 6:32 AM, Matěj Laitl <matej at laitl.cz> wrote:

> 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

Kk, I've been planning to start a personal blog for quite a while now :D

>
> > > 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.
>

Okay.

>
> > 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.
>

I ought to join the forum already.

>
> > > 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.
>

Okay.

>
> > > >  - 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.
>
>
Okay.

> > > > 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.
>

Okay.

>
> > >  - 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...
>

Okay.

>
> > > > 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.
>

Okay.

>
> > > > 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.
>

Would it be appropriate emailing him? I'm asking in the bug report for now.

>
> > > >  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.

>
> > 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.

Okay.

Thanks :)

---
Anmol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20130502/2322abcc/attachment-0001.html>