elisa-developers team mailing list archive

[Florian Boucault <florian@xxxxxxxxxxxx>]

On 29/06/2010 19:41, Peter wrote:
> On Tue, Jun 29, 2010 at 12:19 PM, Florian Boucault <florian@xxxxxxxxxxxx> wrote:
>>>>
>>>> Today, the best open source solution that satisfies all these criteria
>>>> is Qt Quick [12]. It is a set of Qt technologies focused on creating 2D
>>>> canvas-based, highly animated, pixel perfect, user interfaces. It
>>>> features a user interface description language (QML) natively integrated
>>>> with JavaScript and a GUI to visualise and edit the user interface
>>>> called Qt Creator [13]. It is completely cross-platform (Windows,
>>>> MacOS/X, Linux) and also targets smartphones. It has been developed by
>>>> Nokia for over a year and they are heavily investing on it. It has a
>>>> very shallow learning curve. It is in beta right now and the first
>>>> stable release should happen anytime now.
>>>>
>>>> Why not Clutter or Pigment 0.5 or toolkit X/Y/Z?
>>>> The ideal UI toolkit should feature a declarative user interface
>>>> description language in order to have a graphical tool to create and
>>>> edit GUIs. That IDL should support natively:
>>>> - animations
>>>> - the creation of reusable components
>>>> - variable binding
>>>> - signal programming
>>>> - a scripting language to write more complex UI logic
>>>>
>>>> The idea candidate should allow to write most of the product only using
>>>> that language.
>>>> Note: there are some other more obvious feature requirements that the
>>>> toolkit should satisfy: use of hardware acceleration, media framework
>>>> integration, support for scalable and pixel-perfect UIs and more.
>>>>
>>>> Drawbacks of Qt Quick: the major issue today is the very limited support
>>>> of 3D even though the developers are working towards it.
>>>
>>> I apologise if the next bit seems a bit strong - I don't want this to seem
>>> like a personal attack - I recognise you have far more time invested
>>> in the project than I do, and I really am an outsider. Consider this as
>>> the Devil's advocate if you like ;)
>>
>> Don't apologise, it's good to have everyone's point of view.
> 
> OK :)
> 
>>> I am surprised to see you seriously suggest another tool kit switch
>>> (to Qt Quick) given as you say the user interface has previously
>>> been rewritten 3 times.
>>
>> You are confusing things. The past rewrites of the user interface were
>> mainly about creating a new UI. This time it is not about creating a new
>> one but merely replicating the current one.
>> Additionally it is not about rewriting the toolkit/widgets either like
>> we did so many times in the past, it's about reusing an existing one.
> 
> I can see the distinction you are making - but you are still advocating
> "throwing away" the Python+Pigment code to be replaced by new
> code using Qt Quick (which aims to recreate the same UI). As we
> discuss below, this may still be the best way forward (and you are
> in a position to make this judgement).
> 
>>> Isn't there a branch of Moovida using Pigment 0.5 already? Wouldn't
>>> that be a worth while thing to pursue? What I don't know (and didn't
>>> get a clear answer from on the official Moovida development list) was
>>> what is the status of Pigment 0.5 - for example will it ever be officially
>>> released?
>>
>> Yes there is such a branch, I wrote it :)
>> Pigment 0.5 will not be developed further inside the company that
>> originally created it. I do not know the plans of a community supported
>> Pigment 0.5. Loďc can certainly comment on that.
>> Pigment 0.5 is a great piece of code that can do very cool things.
>>
>> However:
>> 1) Qt Quick has quite a different focus compared to Pigment 0.5
>> 2) Pigment 0.5 provides things we need less right now (like 3D support)
>> and does not provide some things we need more (like a solid widgets
>> architecture)
>>
>>>
>>> Clearly you know much more about the internals of the current
>>> (pigment based) UI than I do. Presumably in your judgement a
>>> re-write is better than trying to fix this?
>>>
>>
>> Yes. That's what I tried to outline in the list starting with "The
>> following fundamental code-only issues were particular annoyances:"
> 
> Given you wrote the branch of Moovida/Elisa using Pigment 0.5,
> I'm quite happy to accept your technical judgement favouring
> Qt Quick.
> 
>>> I'm also surprised you think a graphical tool to create and edit GUIs
>>> is needed. I may be thinking like a coder rather than a designer, and
>>> perhaps my ambitions for Moovida/Elisa are not so big, but the core
>>> UI elements appear to all be done (scrollable lists, photo grid, on
>>> screen keyboard, OSD), providing the essential building blocks for
>>> simple plugins etc with a consistent UI.
>>
>> The building blocks are not all there unfortunately. A lot is missing. A
>> lot is buggy.
>>
>> As for the GUI to design, it's not just for designers. It's also
>> immensely helpful for developers for 2 reasons:
>> - being able to see *immediately* the effects of your UI changes makes
>> you gain a lot of time. That we proved with automatic CSS reloading in
>> Moovida (if you remember that David) that made us save considerable time
>> while implementing Moovida's UI.
>> - breaking the wasteful cycle of going back and forth between developer
>> and designer is an absolute *must* to anyone who cares about efficiency.
>>
>> I care a lot about efficiency. I do not like spending one more minute
>> than necessary to achieve anything.
>>
>> On top of all that, I believe empowering non developers into creating UI
>> bits is very worthwhile.
>>
> 
> OK - as I suspected, you have in mind non-trivial UI changes, rather
> than tweaking the current UI elements.
> 
>>> As I said before, maybe I'm not thinking big, but I would expect
>>> Elisa 1.0.x to continue from Moovia 1.0.x with the UI more of less
>>> unchanged, and maybe switch to Pigment 0.5 for Elisa 1.1.x. There
>>> is a good product here and it can be improved incrementally IMHO.
>>
>> It is not about thinking big. Quite the contrary, it's all about lazyness :)
>>
>> It's really an amount of effort required thing.
>> I firmly believe that it's less work to get Elisa in Qt to the level of
>> Moovida with Pigment 0.5. That belief comes from my experience and
>> knowledge of the code as well as some factual evidence I partly outlined
>> in that e-mail.
>> You should really look at Elisa in Qt's code to realise how much of a
>> difference in efficiency writing code for it there is.
> 
> I'll take your word for it - I never really grokked the Python+Pigment
> UI code.
> 
>>>> *Media Scanning*
>>>>
>>>> There are existing solutions which most of the time only lack the
>>>> ability to recognise films and TV series. So far the most promising one
>>>> is Tracker [14]. It is quite fast and reliable, based on RDF and has a
>>>> good support from a number of companies.
>>>>
>>>> Drawbacks: it is not readily ported to other platforms than Linux. I am
>>>> sure that would be doable and in the meantime it is certainly possible
>>>> to integrate with similar technologies built-in the other operating systems.
>>>
>>> Interesting - and yes, media scanning of TV and films is a big problem
>>> (loosing Windows support would be a big downside though).
>>
>> It is a big problem, yes and no because I know how to integrate that
>> into Tracker already.
>>
>>> However I would have said Moovida 1.0.x needed most work on photos
>>> (e.g. tags and albums) where the alternative plan of using an existing
>>> photo DB makes some sense (e.g. iTunes, DigiKam, F-Sport, what ever).
>>> I had given up on using Moovida for looking at my photo collection.
>>
>> Being a big user of photographs myself, I quite agree with you. Rejoice,
>> Tracker has support for tags already integrated. You are a 10 minutes
>> hack away from having it displayed in Elisa Qt.
> 
> So the idea would be to separate the UI (using Qt Quick) from the media
> database (using Tracker)? If you don't mind a few technical questions
> (and I don't mind being told its done in the Elisa Qt prototype, look at file
> X)...
> 
> For album covers, DVD posters, etc, where would code for spotting them
> as local files, or downloading them go? As part of the Elisa Qt code, or
> part of the database backend stuff?
> 

For now I would simply have that in Elisa Qt. I am still in the process
of experimenting with that. However Tracker in theory does allow for
such things to be done.

> Where would code for inferring a music album from a set of tracks, or
> an event from a set of photos, or a TV series from a set of video files
> go? I'm assuming here that tracker just operates at the single file level,
> trying to make the point that we need to deal with collections of linked
> files (even if just at the simplest level of files being in the same folder
> on disk). Would we still have our own SQLite media database?

Ideally, no local SQLite database should be needed. Storing everything
in Tracker's RDF store is much more empowering. However there are a few
things to be done still:
- augmenting Tracker's RDF schemas to support the features we need video
wise (TV Series, Films)
- extending tracker probably by adding what is called a miner to do what
you say: "inferring a music album from a set of tracks, or an event from
a set of photos, or a TV series from a set of video files"


> 
> If we wanted to take advantage of a media database in a 3rd party
> tool (e.g. Music in Rhythmbox or iTunes, Photos in F-Spot or iTunes,
> videos in Miro 3, or whatever), could this be handled as a tracker
> plugin? The idea here is not just to find the media files themselves
> (which is easy to do by searching a folder) but rather to get at any
> metadata not in the files themselves (e.g. played count, ratings).
> 

I believe the concept of miner is here for that. One could write a miner
that imports data from a foreign software's database.

Basically, all these things need to be experimented with. From what I
could gather from my discussion with a Tracker developer it seemed all
doable. Question is now: who's up for the challenge?

> Thanks,
> 
> Peter