Re: QML Context View queries

2012-03-15 Thread Teo Mrnjavac
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

2012-03-15 Thread Saurabh Sood
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

2012-03-15 Thread Teo Mrnjavac

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