On Thu, May 2, 2013 at 6:32 AM, Matěj Laitl <ma...@laitl.cz> wrote: > On 30. 4. 2013 Anmol Ahuja wrote: > > On Tue, Apr 30, 2013 at 3:56 AM, Matěj Laitl <ma...@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 ama...@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.mccosk...@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
_______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
