elisa-developers team mailing list archive

[Peter <peter@xxxxxxxxxxxxxxxxxxxxx>]

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?

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?

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

Thanks,

Peter