<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 2, 2013 at 6:32 AM, Matěj Laitl <span dir="ltr"><<a href="mailto:matej@laitl.cz" target="_blank">matej@laitl.cz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 30. 4. 2013 Anmol Ahuja wrote:<br>
> On Tue, Apr 30, 2013 at 3:56 AM, Matěj Laitl <<a href="mailto:matej@laitl.cz">matej@laitl.cz</a>> wrote:<br>
</div><div class="im">> > Right, although I'd remove the "porting popular A 1.4 scripts" - there are<br>
> > more useful things you'll be able to do, like promoting Amarok scripting,<br>
><br>
> I'm not certain about how I would promote Amarok scripting.<br>
<br>
</div>Basically I meant that you would publish your weekly reports in a public blog<br>
(that we'll aggregate on Planet KDE and Planet Amarok) where you would<br>
actively encourage feeback from script owners, tell about new features,<br>
provide ideas for new script possibilities etc.<br>
<br>
Inspiration: <a href="http://strohel.blogspot.com/search/label/gsoc" target="_blank">http://strohel.blogspot.com/search/label/gsoc</a></blockquote><div><br></div><div style>Kk, I've been planning to start a personal blog for quite a while now :D<br>
</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<div class="im"><br>
> > getting feedback on scripting interface from existing script authors etc.<br>
><br>
> I am interested in knowing what the Amarok scripting community wants. Can I<br>
> find Amarok scripters on #amarok?<br>
<br>
</div>Perhaps some of them, but non-interactive channels are perhaps better. Think<br>
of <a href="mailto:amarok@kde.org">amarok@kde.org</a> and Amarok Forum.<br></blockquote><div><br></div><div style>Okay.</div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> Can I set up an Amarok Script feature request poll on the Amarok website?<br>
<br>
</div>Perhaps the Amarok Forum would be even better place -- it already supports<br>
creating polls. You'd link the polls from your blog etc.<br></blockquote><div><br></div><div style>I ought to join the forum already.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> > Yeah, transcoding may end up just as some parameter of a method in<br>
> > CollectionLocation, although it may be useful<br>
><br>
> I can see uses for a transcoding controls in Amarok Script. For instance,<br>
> you can have a script that uploads any song you love on Last.FM to be<br>
> uploaded to your Google Music account, transcoded to MP3 if, say, it is<br>
> FLAC or Apple Lossless, not otherwise. This sort of stuff is not<br>
> configurable from the main interface, not yet at least.<br>
<br>
</div>Right, it would be "nice to have", but not critical. Perhaps give it low<br>
priority.<br></blockquote><div><br></div><div style>Okay.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> > > - Synchronization Job<br>
> ><br>
> > Do you mean statistics synchronization? Perhaps even more useful would be<br>
> > to expose "Track matching job" is some way.<br>
><br>
> Okay, I'll include Track matching job in the next revision. The<br>
> SynchronizationJob is for playlist synchronization and stuff,<br>
> though admittedly I'm not too familiar with that part of Amarok.<br>
<br>
</div>Me neither. So maybe don't mention the SynchronizationJob at all - it doesn't<br>
mean you cannot work on it if you find it could be useful during the summer.<br>
<div class="im"><br></div></blockquote><div><br></div><div style>Okay.</div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> > > Add suspend inhibition to AmarokScript<br>
> ><br>
> > Hmmm, I don't think we should support this - the inhibition is pretty much<br>
> > defined by the playback.<br>
><br>
> This is to allow scripts to inhibit suspend, for example, when they are<br>
> downloading something. Or is that actually bad? Maybe we should have a<br>
> popup show up in case a script is inhibiting suspend so as not to perplex<br>
> users?<br>
<br>
</div>Hmmm, I think this would be a misuse of suspend inhibition - for example I<br>
don't want my Firefox to suspend inhibition when it is downloading something.<br>
I just want the download to continue on resume.<br>
<br>
The desperate scripts that would really need this can use QtScript DBus<br>
bindings to directly call power management deamon to do this. But let's not<br>
encourage scripts to do it -> don't provide binding for it in Amarok Script<br>
API.<br></blockquote><div><br></div><div style>Okay.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> > - Bug 205509 <<a href="https://bugs.kde.org/show_bug.cgi?id=205509" target="_blank">https://bugs.kde.org/show_bug.cgi?id=205509</a>>:<br>
> > Add dbus functions to update podcasts and download podcast tracks<br>
> ><br>
> > These are for the D-Bus API instead, but yes, perhaps the reported would<br>
> > be happy with the Javascript API.<br>
><br>
> I was actually planning on adding those to the D-BUS too. Should I keep it<br>
> out of my proposal?<br>
<br>
</div>Well, I really think these methods would be much more suited for scripts than<br>
D-Bus API. You may ask the reporter. D-Bus should be really used when<br>
communicating with other existing programs, not as a way to extend Amarok.<br>
<br>
The thing is that we cannot simply implement everything what users request -<br>
we must question it whether it fits the purpose of the component, whether it is<br>
general and reusable enough, who will do the maintenance...<br></blockquote><div><br></div><div style>Okay.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> > > 2. AmarokEngineScript<br>
> > > stopped(); paused(); // needed? can be inferred from<br>
<div class="im">> > > playbackStateChanged();<br>
> ><br>
> > I'd preserve these for convenience.<br>
><br>
> They don't already exist, I was wondering whether I should add them, since<br>
> they can be inferred from engineState(), which already exists (not<br>
> playbackStateChanged() signal as mentioned above, that's erroneous). I'll<br>
> add them as properties. (The implementation details only list properties<br>
> and signals/ slots that don't already exist)<br>
<br>
</div>Hmm. UMO redundant signals are fine (ie. having all of playbackStateChanged()<br>
and stopped(), paused()), redundant properties seem convoluted to me, so I'd<br>
just leave the engineState property and add the 2 convenience signals.<br></blockquote><div><br></div><div style>Okay.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> > > 3. AmarokEqualizerScript<br>
> ><br>
> > Needs some more thinking, no need to do it in the proposal.<br>
><br>
> Is this unnecessary? I can't think of much use for the scriptable equalizer<br>
> either, except for things like mood scripts and switching equalizer preset<br>
> on inserting headphones (headphone detection isn't in the Amarok code yet,<br>
> either, and I'm not even sure if it's possible with Solid). But there<br>
> was a feature<br>
</div>> request <<a href="https://bugs.kde.org/show_bug.cgi?id=279701" target="_blank">https://bugs.kde.org/show_bug.cgi?id=279701</a>> for this, and it<br>
<div class="im">> seems pretty reasonable to expose it.<br>
<br>
</div>Well, Ryan McCoskrie <<a href="mailto:ryan.mccoskrie@gmail.com">ryan.mccoskrie@gmail.com</a>> seems to want this - perhaps<br>
contact him to see what is the rationale.<br></blockquote><div><br></div><div style>Would it be appropriate emailing him? I'm asking in the bug report for now.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> > > public:<br>
> > > enum Type<br>
> > > {<br>
> > ><br>
> > > UmsCollection,<br>
> > > IpodCollection,<br>
> > > (...)<br>
> ><br>
> > No no no, this is artificial and no such enum actually exists in C++ code.<br>
> > Instead, there should be just a method to get a list of collections<br>
> > (please<br>
> > hide the distinction between viewable and whatever else, just return the<br>
> > "active" collections).<br>
><br>
> Okay. I'll just use a type field so script authors can identify the type of<br>
> collection.<br>
<br>
</div>No, we don't have a concept of collection "types". A collection has an id,<br>
pretty name, and an icon. That must suffice. Some collections have historical<br>
ids like "localCollection", but this shouldn't be depended on.<br></blockquote><div><br></div><div style>Okay.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> Okay.<br>
> Can I move Script Creator to the bottom of the priority list? I won't waste<br>
> too many lines of the proposal on it either.<br>
<br>
</div>Yes. Or perhaps you can have a soft goal of rewriting the Script Console in<br>
C++ (as you've already mentioned) so that it can have more features (well,<br>
this is perhaps what it is meant by Script Creator). That would be fine as a<br>
soft-goal with low priority.</blockquote></div><div class="gmail_extra"><br></div>Okay.</div><div class="gmail_extra"><br></div><div class="gmail_extra" style>Thanks :)</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>
---</div><div class="gmail_extra" style>Anmol</div><div class="gmail_extra" style><br></div></div>