[Tomahawk Integration] GSoC Report
Hi everyone, I finally managed to make Tomahawk's playlists available in Amarok. Now, It's time to give the ability, for Tomahawk, to do the same with Amarok's playlists. In spite of that, lets clarify some details first. When a new peer connects, Amarok simply shows the playlist along with the others in Saved Playlists category. It worth to mention that I'm forcing it to only load tracks that are playable. Or, in other words, that are in the peer's hard drive, since it's not part of this GSoC to provide support to other Tomahawk's resolvers. By the way, It won't be hard to do that and I plan to work towards it after this project get integrated with master. Regards, Lucas Lira Gomes (MaskMaster). P.S.: I'll update this project's branches tomorrow ^^. -- Lucas Lira Gomes (llg) Linux User #533002 Tel.: (81) 9235-0916 www.about.me/lucasliragomes ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: [Tomahawk Integration] GSoC Report
On Thu, Jul 26, 2012 at 5:39 AM, Lucas Lira Gomes x8luca...@gmail.com wrote: Hi everyone, the loading times for big collections has hugely improved. Bart's idea to get rid of MemoryMeta in favour of a custom QueryMaker really solved our problems. I also removed the need to use the Tomahawk's ViewManager in Amarok. The less indirection the better ^^. From now on, I'll be focusing on integrating Tomahawk's playlists. My tomahawk repo: https://github.com/x8lucas8x/tomahawk (amarokready branch) My amarok repo: http://quickgit.kde.org/index.php?p=clones%2Famarok%2Fgomes%2Fmaskmaster-amarok.gita=summary (tomahawk branch) That's very good news :) Looking forward to checking it out! Cheers, -- Teo Mrnjavac http://teom.org | t...@kde.org ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
[Tomahawk Integration] GSoC Report
Hi everyone, the loading times for big collections has hugely improved. Bart's idea to get rid of MemoryMeta in favour of a custom QueryMaker really solved our problems. I also removed the need to use the Tomahawk's ViewManager in Amarok. The less indirection the better ^^. From now on, I'll be focusing on integrating Tomahawk's playlists. My tomahawk repo: https://github.com/x8lucas8x/tomahawk (amarokready branch) My amarok repo: http://quickgit.kde.org/index.php?p=clones%2Famarok%2Fgomes%2Fmaskmaster-amarok.gita=summary (tomahawk branch) Regards, Lucas Lira Gomes (MaskMaster). -- Lucas Lira Gomes (llg) Linux User #533002 Tel.: (81) 9235-0916 www.about.me/lucasliragomes ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: [Tomahawk Integration] GSoC Report (plus: RFC on git work-flow guideline)
This command is mandatory for all amarok developers: git config branch.master.rebase true the result of this is that all git pull commands will do a rebase rather then a merge. Your local commits will be rewritten (parented to origin/master). The prevents the git log to become unreadable because of all the merge commits. Merge commits will only show on real branch merges. But since we don't use much branches in the repository on KDE it's should be an uncommon thing. I'll add a file to HACKING explaining this. On Tue, Jul 10, 2012 at 1:25 PM, Matěj Laitl ma...@laitl.cz wrote: On 9. 7. 2012 Lucas Lira Gomes wrote: Hi everyone, Hi Lucas, My amarok repo: http://quickgit.kde.org/index.php?p=clones%2Famarok%2Fgomes%2Fmaskmaster-ama rok.gita=summary (tomahawk branch) I've checked above repo and the master branch there is polluted with many Merge branch 'master' of git://anongit.kde.org/amarok commits. Shouldn't all these be fast-forwards? My only fear is that this will make merging your tomahawk branch into master tricky. I would advise having the master a carbon- copy of Amarok upstream master. The history of tomahawk branch itself looks fine. To all developers, contributors, GSoCers, SoKers, I think we should adopt following git work-flow rules: * upstream master branch is never _merged_ _to_ feature branches/personal clones etc. If you want to have new commits, _rebase_ your feature branch/clone on top of upstream master. (e.g. `git pull --ff-only`, `git pull --rebase` etc.) ^^^ why? Because if such feature branch is merged into master, it can result in strange things including silently reintroducing reverted commits in the worst case and pollutes the history in the best case. * merging feature branches to upstream master is fine and should be preferred over squashing the commits or making it a fast-forward. Ideally, a list of merged commits is embedded in the merge-commit, so the command should look like: `git merge --no-ff --log feature-branch`. See [1] for example. ^^^ why? Because tools like git bisect and git blame depend on fine-grained commit history. git blame (or its KDevelop integration) is very useful for why does this code line exist? type of questions, you should use it, really. Creating merge-commits makes the history more organized and allows for reverting or diff-ing whole merges. [1] http://quickgit.kde.org/index.php?p=amarok.gita=commith=8d8404a9a95d3a49026eac972783f66061675e53 Matěj ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: RFC on git work-flow guideline (was: [Tomahawk Integration] GSoC Report)
Hi all, On Tue, Jul 10, 2012 at 3:01 PM, Matěj Laitl ma...@laitl.cz wrote: On 10. 7. 2012 Edward Toroshchin wrote: G'day, On Tue, Jul 10, 2012 at 01:25:59PM +0200, Matěj Laitl wrote: I've checked above repo and the master branch there is polluted with many Merge branch 'master' of git://anongit.kde.org/amarok commits. Shouldn't all these be fast-forwards? Merge and fast-forward are not antonyms. What you (probably) wanted to say here was rebases. Lucas' repo looks like it has no his own commits in master. Therefore I wanted to say: Shouldn't all his `git pull git://anongit.kde.org/amarok master` commands performed in his master branch have resulted in fast-forwards? (that don't create the merge commit so I therefore don't call them merges) E.g. `git push` without --rebase in master may still be correct if you don't have own commits so that it results in fast-forward, that's what I wanted to say. My only fear is that this will make merging your tomahawk branch into master tricky. What you meant here was probably pushing your branch into master. Yes, pushing it to upstream master either through his master or directly. And, no, it won't make it tricky, because after a merge commit, pushing into master becomes a fast-forward operation. (...) Bad wording, I wanted to say: wouldn't that push all those Merge branch 'master' commits back to master, as it happened for example to Mamarok? [1] But now I realize that no, because upstream master is fully merged to his master. We already have rules for git, please have a look here: http://techbase.kde.org/Getting_Started/Sources/KDE_git-tutorial#Amarok_Developers In particular the Basic Development section: 90% of the time this is all that is needed: git pull --rebase #hack, compile, build. It works! git status #to check if you want to commit all the modified files git commit -a git log git push IIRC these links should be in our HACKING folder somewhere, if not, those should be added. Regards, Myriam -- Proud member of the Amarok and KDE Community Protect your freedom and join the Fellowship of FSFE: http://www.fsfe.org Please don't send me proprietary file formats, use ISO standard ODF instead (ISO/IEC 26300) ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: [Tomahawk Integration] GSoC Report
On Mon, Jul 9, 2012 at 11:15 PM, Lucas Lira Gomes x8luca...@gmail.com wrote: Hi everyone, i've been fixing bugs and improving overall performance of the tomahawk service. It's a bit lazy to load big collections(50k tracks) and I haven't figured yet how I can make its loading faster. And yes, I'm running track loading and removal in the background using Threadweaver jobs. By the way, I modified the database integrator to use SqlCollection QueryMaker, instead of a full scan, to sync tomahawk db for the first time. Although Amarok is successfully sending, to other peers, the info about what the user is listening, I still need to create a menu to change privacy modes. I guess the best way to show what others peers we're listening is in an applet. But since there are more urgent matters for now, then I'll postpone its creation. Another problem is that tracks in playlists aren't playable anymore after I restart Amarok. I've been looking for possible solutions with no success, The thing is that tomahawk tracks needs their source and it's only available when the user is connected. Does anybody know how to force playlists to solve their tracks again when a new peer becomes online? This part is for after midterm, so no hurry ^^. Hint: Check if MetaProxy::Worker::slotNewTrackProvider() is getting called. It should be if you register your TrackProvider (can happen through CollectionManager::slotNewCollection()). Last but not least, I'm writing a new blog post to show the current state of the Tomahawk service. My tomahawk repo: https://github.com/x8lucas8x/tomahawk (amarokready branch) My amarok repo: http://quickgit.kde.org/index.php?p=clones%2Famarok%2Fgomes%2Fmaskmaster-amarok.gita=summary (tomahawk branch) Regards, Lucas Lira Gomes. -- Lucas Lira Gomes (llg) Linux User #533002 Tel.: (81) 9235-0916 www.about.me/lucasliragomes On 26 June 2012 23:09, Lucas Lira Gomes x8luca...@gmail.com wrote: Hi everyone, Last two weeks weren’t the most productive of all, since some tests and a project consumed a lot of my time. In spite of that, I finally managed to play tomahawk streams in Amarok. To query others collections is working too. For those curious, tomahawk service is using capabilities, since it's the less intrusive way to play tomahawk streams in the EngineController. Right now I'm coding some logic(Creating a wrapper to AclRegistry class) to allow amarok to display dialogs showing other users requests to be able to listen to your streams. Next steps include the following: - Display tomahawk service connectivity information in the amarok diagnostics dialog. - Make other peers aware of what you're listening to. - Add a menu with options to disconnect tomahawk sips, listen music in private and etc. - Use SqlCollection QueryMaker, instead of a full scan, to sync tomahawk db for the first time. (More elegant approach ^^) The four steps above are relatively easy to implement, so no need to worry about the time line ;}. Obs.: The source in my repo will be updated as soon as I finish the AclRegistry wrapper. Regards, Lucas Lira Gomes(MaskMaster). -- Lucas Lira Gomes (llg) Linux User #533002 Tel.: (81) 9235-0916 www.about.me/lucasliragomes ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: [Tomahawk Integration] GSoC Report
On Mon, Jul 9, 2012 at 11:15 PM, Lucas Lira Gomes x8luca...@gmail.com wrote: Hi everyone, i've been fixing bugs and improving overall performance of the tomahawk service. It's a bit lazy to load big collections(50k tracks) and I haven't figured yet how I can make its loading faster. And yes, I'm running track loading and removal in the background using Threadweaver jobs. By the way, I modified the database integrator to use SqlCollection QueryMaker, instead of a full scan, to sync tomahawk db for the first time. Although Amarok is successfully sending, to other peers, the info about what the user is listening, I still need to create a menu to change privacy modes. I guess the best way to show what others peers we're listening is in an applet. But since there are more urgent matters for now, then I'll postpone its creation. Another problem is that tracks in playlists aren't playable anymore after I restart Amarok. I've been looking for possible solutions with no success, The thing is that tomahawk tracks needs their source and it's only available when the user is connected. Does anybody know how to force playlists to solve their tracks again when a new peer becomes online? This part is for after midterm, so no hurry ^^. Last but not least, I'm writing a new blog post to show the current state of the Tomahawk service. My tomahawk repo: https://github.com/x8lucas8x/tomahawk (amarokready branch) My amarok repo: http://quickgit.kde.org/index.php?p=clones%2Famarok%2Fgomes%2Fmaskmaster-amarok.gita=summary (tomahawk branch) Nice progress! Thanks for the update. Cheers, -- Teo Mrnjavac http://teom.org | t...@kde.org ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: [Tomahawk Integration] GSoC Report (plus: RFC on git work-flow guideline)
On 9. 7. 2012 Lucas Lira Gomes wrote: Hi everyone, Hi Lucas, My amarok repo: http://quickgit.kde.org/index.php?p=clones%2Famarok%2Fgomes%2Fmaskmaster-ama rok.gita=summary (tomahawk branch) I've checked above repo and the master branch there is polluted with many Merge branch 'master' of git://anongit.kde.org/amarok commits. Shouldn't all these be fast-forwards? My only fear is that this will make merging your tomahawk branch into master tricky. I would advise having the master a carbon- copy of Amarok upstream master. The history of tomahawk branch itself looks fine. To all developers, contributors, GSoCers, SoKers, I think we should adopt following git work-flow rules: * upstream master branch is never _merged_ _to_ feature branches/personal clones etc. If you want to have new commits, _rebase_ your feature branch/clone on top of upstream master. (e.g. `git pull --ff-only`, `git pull --rebase` etc.) ^^^ why? Because if such feature branch is merged into master, it can result in strange things including silently reintroducing reverted commits in the worst case and pollutes the history in the best case. * merging feature branches to upstream master is fine and should be preferred over squashing the commits or making it a fast-forward. Ideally, a list of merged commits is embedded in the merge-commit, so the command should look like: `git merge --no-ff --log feature-branch`. See [1] for example. ^^^ why? Because tools like git bisect and git blame depend on fine-grained commit history. git blame (or its KDevelop integration) is very useful for why does this code line exist? type of questions, you should use it, really. Creating merge-commits makes the history more organized and allows for reverting or diff-ing whole merges. [1] http://quickgit.kde.org/index.php?p=amarok.gita=commith=8d8404a9a95d3a49026eac972783f66061675e53 Matěj ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: [Tomahawk Integration] GSoC Report (plus: RFC on git work-flow guideline)
G'day, On Tue, Jul 10, 2012 at 01:25:59PM +0200, Matěj Laitl wrote: I've checked above repo and the master branch there is polluted with many Merge branch 'master' of git://anongit.kde.org/amarok commits. Shouldn't all these be fast-forwards? Merge and fast-forward are not antonyms. What you (probably) wanted to say here was rebases. If you wanted to say fast-forward, you'd better read more about merges, rebases, and fast-forwards; or just ask me in IRC, I'll be glad to clarify. My only fear is that this will make merging your tomahawk branch into master tricky. What you meant here was probably pushing your branch into master. And, no, it won't make it tricky, because after a merge commit, pushing into master becomes a fast-forward operation (unless someone managed to push something else, why you were at it, but it's generally unsolveable in centralized repository infrastructure). * upstream master branch is never _merged_ _to_ feature branches/personal clones etc. If you want to have new commits, _rebase_ your feature branch/clone on top of upstream master. (e.g. `git pull --ff-only`, `git pull --rebase` etc.) ^^^ why? Because if such feature branch is merged into master, it can result in strange things including silently reintroducing reverted commits in the worst case and pollutes the history in the best case. No it can't. Indeed, it creates a messy loopy history, which is generally frowned upon, because it's a structure without semantics. But it does not by itself lead to any strange things, including reintroducting reverted commits. I agree that rebasing a long-lived feature branch should be preferred to merging upstream master repeatedly into it. I would like to add also, that unless you depend on some new features being added to upstream master (like API changes, or bugfixes), you don't need to rebase often, or even at all. For example, Phalgun is working in his own directory on his Nepomuk collection. I have advised him not to rebase or merge at all, because he won't get any conflicts at the end of the development, and he does not require anything bleeding edge from amarok master. * merging feature branches to upstream master is fine and should be preferred over squashing the commits or making it a fast-forward. Ideally, a list of merged commits is embedded in the merge-commit, so the command should look like: `git merge --no-ff --log feature-branch`. See [1] for example. ^^^ why? Because tools like git bisect and git blame depend on fine-grained commit history. git blame (or its KDevelop integration) is very useful for why does this code line exist? type of questions, you should use it, really. Creating merge-commits makes the history more organized and allows for reverting or diff-ing whole merges. I should clarify here, that Matěj was referring to merge and push at the end of your feature branch life cycle (i.e. when your subproject is complete), and not something you do repeatedly during development. Cheers, -- Edward Hades Toroshchin dr_lepper on irc.freenode.org pgpk5ECgb15lQ.pgp Description: PGP signature ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
RFC on git work-flow guideline (was: [Tomahawk Integration] GSoC Report)
On 10. 7. 2012 Edward Toroshchin wrote: G'day, On Tue, Jul 10, 2012 at 01:25:59PM +0200, Matěj Laitl wrote: I've checked above repo and the master branch there is polluted with many Merge branch 'master' of git://anongit.kde.org/amarok commits. Shouldn't all these be fast-forwards? Merge and fast-forward are not antonyms. What you (probably) wanted to say here was rebases. Lucas' repo looks like it has no his own commits in master. Therefore I wanted to say: Shouldn't all his `git pull git://anongit.kde.org/amarok master` commands performed in his master branch have resulted in fast-forwards? (that don't create the merge commit so I therefore don't call them merges) E.g. `git push` without --rebase in master may still be correct if you don't have own commits so that it results in fast-forward, that's what I wanted to say. My only fear is that this will make merging your tomahawk branch into master tricky. What you meant here was probably pushing your branch into master. Yes, pushing it to upstream master either through his master or directly. And, no, it won't make it tricky, because after a merge commit, pushing into master becomes a fast-forward operation. (...) Bad wording, I wanted to say: wouldn't that push all those Merge branch 'master' commits back to master, as it happened for example to Mamarok? [1] But now I realize that no, because upstream master is fully merged to his master. [1] http://quickgit.kde.org/index.php?p=amarok.gita=commith=1795ef92a8248fa88a9986b1e63ad6d4346242d6 * upstream master branch is never _merged_ _to_ feature branches/personal clones etc. If you want to have new commits, _rebase_ your feature branch/clone on top of upstream master. (e.g. `git pull --ff-only`, `git pull --rebase` etc.) ^^^ why? Because if such feature branch is merged into master, it can result in strange things including silently reintroducing reverted commits in the worst case and (...) No it can't. Indeed, it creates a messy loopy history, which is generally frowned upon, because it's a structure without semantics. But it does not by itself lead to any strange things, including reintroducting reverted commits. Not in normal operation, but if you have merge conflicts and don't resolve them carefully, then yes. The point is that the second merge is somewhat prone to be resolved wrong in case of reverted commits, see https://github.com/strohel/failed-merge-plus-revert-showcase/network I agree that rebasing a long-lived feature branch should be preferred to merging upstream master repeatedly into it. I would like to add also, that unless you depend on some new features being added to upstream master (like API changes, or bugfixes), you don't need to rebase often, or even at all. Agreed. * merging feature branches to upstream master is fine and should be preferred over squashing the commits or making it a fast-forward. Ideally, a list of merged commits is embedded in the merge-commit, so the command should look like: `git merge --no-ff --log feature-branch`. See [1] for example. ^^^ why? Because tools like git bisect and git blame depend on fine-grained commit history. git blame (or its KDevelop integration) is very useful for why does this code line exist? type of questions, you should use it, really. Creating merge-commits makes the history more organized and allows for reverting or diff-ing whole merges. I should clarify here, that Matěj was referring to merge and push at the end of your feature branch life cycle (i.e. when your subproject is complete), and not something you do repeatedly during development. Yes, thanks. Regards, Matěj ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: RFC on git work-flow guideline (was: [Tomahawk Integration] GSoC Report)
On Tue, Jul 10, 2012 at 03:01:06PM +0200, Matěj Laitl wrote: Lucas' repo looks like it has no his own commits in master. Therefore I wanted to say: Shouldn't all his `git pull git://anongit.kde.org/amarok master` commands performed in his master branch have resulted in fast-forwards? (that don't create the merge commit so I therefore don't call them merges) E.g. `git push` without --rebase in master may still be correct if you don't have own commits so that it results in fast-forward, that's what I wanted to say. I see. There is actually commit bedfbae3ed20b0676482f601cef0607f2325586a there. I presume Lucas expected his branch master to be, as you put it, a carbon-copy, but forgot this one commit. It made all his pull operations merges. I recommend using the options --ff-only and/or --rebase more often to avoid Git doing unwanted things. Not in normal operation, but if you have merge conflicts and don't resolve them carefully, then yes. The point is that the second merge is somewhat prone to be resolved wrong in case of reverted commits, see https://github.com/strohel/failed-merge-plus-revert-showcase/network This problem can of course be avoided by getting rid of frequent merges. It is however not a direct consequence of these merges, but rather a consequence of sloppy merge conflict resolution. If you used a proper mergetool or at least had set merge.conflictstyle = diff3, you would know that this b line had been deleted in master, and you should not leave it in your merged code. And, of course, you should not do merges if you don't understand the code :) -- Edward Hades Toroshchin dr_lepper on irc.freenode.org pgpZ5SNzohVtb.pgp Description: PGP signature ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: RFC on git work-flow guideline (was: [Tomahawk Integration] GSoC Report)
On 10. 7. 2012 Edward Toroshchin wrote: On Tue, Jul 10, 2012 at 03:01:06PM +0200, Matěj Laitl wrote: E.g. `git push` without --rebase in master may still be correct if you don't have own commits so that it results in fast-forward, that's what I wanted to say. I see. There is actually commit bedfbae3ed20b0676482f601cef0607f2325586a there. Good, we've just prevented push of accidental commit to master. I presume Lucas expected his branch master to be, as you put it, a carbon-copy, but forgot this one commit. It made all his pull operations merges. I recommend using the options --ff-only and/or --rebase more often to avoid Git doing unwanted things. Exactly. Not in normal operation, but if you have merge conflicts and don't resolve them carefully, then yes. The point is that the second merge is somewhat prone to be resolved wrong in case of reverted commits, see https://github.com/strohel/failed-merge-plus-revert-showcase/network This problem can of course be avoided by getting rid of frequent merges. It is however not a direct consequence of these merges, but rather a consequence of sloppy merge conflict resolution. If you used a proper mergetool or at least had set merge.conflictstyle = diff3, you would know that this b line had been deleted in master, and you should not leave it in your merged code. Agreed. And hey, I didn't know about merge.conflictstyle, that'll make my life much easier, thanks! Matěj ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: RFC on git work-flow guideline (was: [Tomahawk Integration] GSoC Report)
Agreed. And hey, I didn't know about merge.conflictstyle, that'll make my life much easier, thanks! Anytime! Try also kdiff3 as mergetool. -- Edward Hades Toroshchin dr_lepper on irc.freenode.org ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
[Tomahawk Integration] GSoC Report
Hi everyone, i've been fixing bugs and improving overall performance of the tomahawk service. It's a bit lazy to load big collections(50k tracks) and I haven't figured yet how I can make its loading faster. And yes, I'm running track loading and removal in the background using Threadweaver jobs. By the way, I modified the database integrator to use SqlCollection QueryMaker, instead of a full scan, to sync tomahawk db for the first time. Although Amarok is successfully sending, to other peers, the info about what the user is listening, I still need to create a menu to change privacy modes. I guess the best way to show what others peers we're listening is in an applet. But since there are more urgent matters for now, then I'll postpone its creation. Another problem is that tracks in playlists aren't playable anymore after I restart Amarok. I've been looking for possible solutions with no success, The thing is that tomahawk tracks needs their source and it's only available when the user is connected. Does anybody know how to force playlists to solve their tracks again when a new peer becomes online? This part is for after midterm, so no hurry ^^. Last but not least, I'm writing a new blog post to show the current state of the Tomahawk service. My tomahawk repo: https://github.com/x8lucas8x/tomahawk (amarokready branch) My amarok repo: http://quickgit.kde.org/index.php?p=clones%2Famarok%2Fgomes%2Fmaskmaster-amarok.gita=summary (tomahawk branch) Regards, Lucas Lira Gomes. -- Lucas Lira Gomes (llg) Linux User #533002 Tel.: (81) 9235-0916 www.about.me/lucasliragomes On 26 June 2012 23:09, Lucas Lira Gomes x8luca...@gmail.com wrote: Hi everyone, Last two weeks weren’t the most productive of all, since some tests and a project consumed a lot of my time. In spite of that, I finally managed to play tomahawk streams in Amarok. To query others collections is working too. For those curious, tomahawk service is using capabilities, since it's the less intrusive way to play tomahawk streams in the EngineController. Right now I'm coding some logic(Creating a wrapper to AclRegistry class) to allow amarok to display dialogs showing other users requests to be able to listen to your streams. Next steps include the following: - Display tomahawk service connectivity information in the amarok diagnostics dialog. - Make other peers aware of what you're listening to. - Add a menu with options to disconnect tomahawk sips, listen music in private and etc. - Use SqlCollection QueryMaker, instead of a full scan, to sync tomahawk db for the first time. (More elegant approach ^^) The four steps above are relatively easy to implement, so no need to worry about the time line ;}. Obs.: The source in my repo will be updated as soon as I finish the AclRegistry wrapper. Regards, Lucas Lira Gomes(MaskMaster). -- Lucas Lira Gomes (llg) Linux User #533002 Tel.: (81) 9235-0916 www.about.me/lucasliragomes ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
[Tomahawk Integration] GSoC Report
Hi everyone, Last two weeks weren’t the most productive of all, since some tests and a project consumed a lot of my time. In spite of that, I finally managed to play tomahawk streams in Amarok. To query others collections is working too. For those curious, tomahawk service is using capabilities, since it's the less intrusive way to play tomahawk streams in the EngineController. Right now I'm coding some logic(Creating a wrapper to AclRegistry class) to allow amarok to display dialogs showing other users requests to be able to listen to your streams. Next steps include the following: - Display tomahawk service connectivity information in the amarok diagnostics dialog. - Make other peers aware of what you're listening to. - Add a menu with options to disconnect tomahawk sips, listen music in private and etc. - Use SqlCollection QueryMaker, instead of a full scan, to sync tomahawk db for the first time. (More elegant approach ^^) The four steps above are relatively easy to implement, so no need to worry about the time line ;}. Obs.: The source in my repo will be updated as soon as I finish the AclRegistry wrapper. Regards, Lucas Lira Gomes(MaskMaster). -- Lucas Lira Gomes (llg) Linux User #533002 Tel.: (81) 9235-0916 www.about.me/lucasliragomes ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
Re: [Tomahawk Integration] GSoC Report
On Wed, Jun 27, 2012 at 4:09 AM, Lucas Lira Gomes x8luca...@gmail.com wrote: Hi everyone, Last two weeks weren’t the most productive of all, since some tests and a project consumed a lot of my time. In spite of that, I finally managed to play tomahawk streams in Amarok. To query others collections is working too. For those curious, tomahawk service is using capabilities, since it's the less intrusive way to play tomahawk streams in the EngineController. Right now I'm coding some logic(Creating a wrapper to AclRegistry class) to allow amarok to display dialogs showing other users requests to be able to listen to your streams. Next steps include the following: - Display tomahawk service connectivity information in the amarok diagnostics dialog. - Make other peers aware of what you're listening to. - Add a menu with options to disconnect tomahawk sips, listen music in private and etc. - Use SqlCollection QueryMaker, instead of a full scan, to sync tomahawk db for the first time. (More elegant approach ^^) The four steps above are relatively easy to implement, so no need to worry about the time line ;}. Obs.: The source in my repo will be updated as soon as I finish the AclRegistry wrapper. Regards, Lucas Lira Gomes(MaskMaster). Thanks for the update! Nice work! Cheers, -- Teo Mrnjavac http://teom.org | t...@kde.org ___ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
