Re: QML Context View queries
On Thu, Mar 15, 2012 at 10:09, Saurabh Sood saurabhsoo...@gmail.com wrote: Hi, I have some queries regarding the distribution of context applets in the 'Qmlify Context View' gsoc project. I am currently doing research on libattica, and trying out sample code as given in the kde documentation. saidinesh5 on #kde-in IRC channel suggested that I should keep it very simple, with the entire context applet distributed as a zip file. I wanted to know if this would be ok here. Sounds good. Also, do I keep in mind the distribution part, as I try out PoC implementations for the project? So far, I have just tried out sample implementations using StringList, and AbstractListModel, not considering the distribution aspects. Not sure if I understand the question. As long as you're doing proofs of concept you can do whatever you wish. The real project will have to include a distribution method, but what you do as exercises outside of the GSoC coding period is up to you. Another query is regarding my timeline in my proposal, which I had submitted recently. You had mentioned that it should be more descriptive. I have understood the requirements of the project well, but am still not very clear, on what part I should pursue when, and how much time it could be expected to take. Could you shed some advice on that, so I could better frame the timeline aspect of my proposal). I would love to advise you more, and as a mentor I would do so with my student during the GSoC coding period, but right now we (the Amarok team) need to evaluate prospective students based on certain criteria - the ability to structure the project sequentially in manageable bits is one of those criteria. So right now I can only advise you to think hard about it and try to define the requirements that need to be fulfilled. Lastly, I wanted to know how much I should pursue sparql. I have gone through sample sparql queries, but not tried any implementation with respect to my project. Please advise me on that. The SPARQL language and QtSparql would certainly be very important in this project as the preferred way of getting the data you wish to display. If you get selected, you'll have to learn it I guess. Cheers, -- Teo ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
QML Context View queries
Hi, I have some queries regarding the distribution of context applets in the 'Qmlify Context View' gsoc project. I am currently doing research on libattica, and trying out sample code as given in the kde documentation. saidinesh5 on #kde-in IRC channel suggested that I should keep it very simple, with the entire context applet distributed as a zip file. I wanted to know if this would be ok here. Also, do I keep in mind the distribution part, as I try out PoC implementations for the project? So far, I have just tried out sample implementations using StringList, and AbstractListModel, not considering the distribution aspects. Another query is regarding my timeline in my proposal, which I had submitted recently. You had mentioned that it should be more descriptive. I have understood the requirements of the project well, but am still not very clear, on what part I should pursue when, and how much time it could be expected to take. Could you shed some advice on that, so I could better frame the timeline aspect of my proposal). Lastly, I wanted to know how much I should pursue sparql. I have gone through sample sparql queries, but not tried any implementation with respect to my project. Please advise me on that. Regards,. Saurabh Sood ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: Review Request: Rework transcoding: remember encoder, transcode on move, cleaner code
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104213/#review11442 --- Ship it! I believe it is completely justified to introduce a capability for this. Nice work! Also, thanks for documenting your code :) I've given it a spin and it seems to work, it's a ship it from me. - Teo Mrnjavac On March 9, 2012, 11:31 p.m., Matěj Laitl wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104213/ --- (Updated March 9, 2012, 11:31 p.m.) Review request for Amarok and Teo Mrnjavac. Description --- Rework transcoding: remember encoder, transcode on move, cleaner code This is a major rework of transcoding feature that brings following user-visible changes to Amarok: * Amarok can remember preferred transcoding configuration per each collection that supports transcoding. Therefore, the Use default configuration work-around can go away and the Transcode or copy? dialog can (and is) be one-step now. This preference can be changed in configuration. * Transcoding is now supported even during the move operation. No worries, only successfully transcoded tracks are removed from their original location. * Only formats playable on the target collection are offered. Already used tested in yet-to-be-merged iPod collection rewrite. * The Organize Tracks dialog title and progress bar operation name now more verbosely describe actual operation to prevent user mistakes. * Double-transcode when ripping audio CDs that caused failures is avoided. (ChangeLog entry for this was miscredited to my earilier commit) Technically, following changes are made: * many methods that accepted optional TranscodingConfiguration now either have it mandatory or not at all. * TranscodingConfiguration's NULL_CODEC was splitted to JUST_COPY and INVALID along with convenience methods isValid() and isJustCopy(). This simplifies logic in many methods. * CollectionLocation::prepare{Copy,Move}() now don't have optional TranscodingConfiguration parameter. Depending on target collection, CollectionLocation determines it automatically or asks user in showSourceDialog() (overridable). AudioCdCollectionLocation already overrides it. * Collections that support transcoding now should expose TranscodeCapability which is used to a) indicate that transcoding is supported; b) query which file formats are playable on target collection; c) read save unset preferred transcoding parameters. Why the hell the new Capability? Many Amarok devs dislike the concept of capabilities[1]. Why the hell I introduced the new one? In ideal world Amarok would be able to transcode everything regardless of the target collection. This is however not doable witch current copyUrlToCollection() design - target collection needs to do non-trivial things such as re-reading file tags, accounting for different file name and space requirements etc. See my comments in [1]. We therefore need a way for target collection to indicate it supports transcoding (in order not to fool user). Some collection locations such as TrashCollectionLocation should even intentionally disallow transcoding. Additionally, we want to be able to query supported destination file formats, to save preferred transcoding paremeters etc. I simply didn't want to pollute already over-crowded CollectionLocation with three more methods used by only a few subclasses. On the other hand, TranscodeCapability is not the central idea of this patch and I can factor it into CollectionLocation should there be a voice supporting it. [1] https://git.reviewboard.kde.org/r/103752/ FEATURE: 280526 FEATURE: 264681 CCBUG: 291722 BUG: 263775 FIXED-IN: 2.6 REVIEW: TODO DIGEST: Feature: much improved transcoding -- Next commit squelched for the purpose of review board -- Transcoding::Property: remove NUMERIC, LIST, TEXT types These types were not used since Teo reworked all encoders to use the TRADEOFF type. Remove them and associated code to make codebase cleaner so that new code doesn't need to introduce case statements in switches that will be never used, thus error-prone. Individual types can be resurrected from this commit if there is a need for them in future. -- Next commit squelched for the purpose of review board