@andreas_k

I finally understood you mockup i think.

Based on this I have several ideas:

1) We could build a collection manager like an interface (no UI) and above that create QML views that could be your mockup or whatever else. The only thing is that they should speak the same "language".

2) Here goes further than 1) in the direction of doing a sort of specification of how the collection manager should behave. We would develop have 3 modules: a player, a collection, an interface (4 if we separate the collection from the database). The player is based on VLC... or whatever else if we do the things correctly.

3) If all what I said is too complex, and we stick to something easy which will be YetAnotherPlayer (but a KDE one) and we need to define what happens when the user click on each feature. Example: If I click on artists (left panel), what appears in the middle? Let's say a list of artists. Now I click on the artist Artist1, how do the middle change?

Cheers

Is the mockup an image or is there already a QML base?

Real question: If I want to follow your mockup, should I begin from scratch and try to achieve something that looks similar?

If we can begin on to work on this, I think we should already begin to plan: I opened a [EDIT] wiki page [1] [/EDIT] to explain what should everything do, and to design the database.

[1] https://community.kde.org/Playground/MediaPlayer

If I remember correctly there was some work on the qml being done on github, but it was never merged with any of our repos.

I like the idea of developing 3 modules plus a general interface exposed to qml. From my perspective, the interface will mainly provide a set of object types and properties. Qml + javascript is powerful enough to handle some sortingsearching capabilities.

I made some additions to the etherpad. I believe we should try to round up the team properly while we're planning, I know there was a thread on the mailinglists where there were some offers to support/test/code but I haven't the slightest clue about the outcome.

I updated the etherpad.

I've beginned to work on the *database only*. When this will be there, we can begin to work on the collection and mockup, because the database will be always the same.

What I propose is that the database is only called from a DatabaseManager (or call it as you want) which would be like a module whom you speak like an API:

Code: Select all

database->getAllArtists();
database->getOneArtistById(3);
database->getOneArtistByName("Led Zeppelin")
database->getArtistsByAny(searchWord);
database->getTracksByArtist(Artist); // Artist is either the Artist::id or Artist class
database->getTracksByAlbum(Album);
....


I saw that in some frameworks (Symfony2 for instance, in php) and I find it really good for the abstraction. And I've never seen something really better (putting SQL requests in the whole code makes no sense).

I can give you my scratch-repo: https://quickgit.kde.org/?p=scratch/och ... Player.git

If someone wants to give me a hand: please go head. If we manage to do something fast, we'll move it to playground.

I've revised the etherpad and pushed some code into your repo, however the foreign key relationships have not been defined as yet because there some semantics still left undecided in the notes.

It seems to me, that you start the database design from scratch? Did you look at the db designs of Amarok, JuK, Baloo, ...? And maybe talked to the maintainers. I would suggestion to reuse a design that is already implemented and proven, instead of designing another new one.

Here are is the link to amaroks db schema
https://community.kde.org/Amarok/Develo ... ase_Schema

Yeah, i partly used Amarok one. However for historical reason, there are some infoemation that are saved in multiple tables of the databade. This can be avoided by only being inspired and not directly copying.

Furthermore, Amarok scheme is there do do way more than what we *first* intend to do.

Hi to all...
this is a Mock-up I made some time ago... this is for Ubuntu Vlc Control app.. but this is great (IMHO) for a Music Player..
tell me what you think...

Link for the image

If you see, there is a 50% on the cover... this appear when you long click on the cover image and you scroll up or down, to increase or decrease the Volume

delsa wrote:Hi to all...
this is a Mock-up I made some time ago... this is for Ubuntu Vlc Control app.. but this is great (IMHO) for a Music Player..
tell me what you think...

Link for the image

If you see, there is a 50% on the cover... this appear when you long click on the cover image and you scroll up or down, to increase or decrease the Volume

This is really nice! I hope you could work with alake about this.

ochurlaud wrote:This is really nice! I hope you could work with alake about this.

Really thanks

I'm currently using QuodLibet and it's the first time I find something so feature-full. It's really great and can be extended with python plugins.

It's a gtk3 soft, written in Python. I wonder if it can be ported or something like this. For now, I must admit that I don't see how we can do something as good in a few time....

Considering the above and the exam period approaching, I won't be able to contribute a lot in the next 2 months. However feel free to push some code on my repo. I'll still be able to work on the "meta" part (discussions and reflections)

I moved the etherpad to https://community.kde.org/Playground/MediaPlayer

It's easier to follow thanks to the "watch" button. Please continue the discussion there!