Hi,

> Some feedback from the top of my head.
> About Multimedia:
> 
> http://doc.qt.nokia.com/qtmobility-1.1.0/qml-multimedia.html
> 
> This should tell whether you can use something apart from an URL. E.g.
> how would you hook up gstreamer to this, now or in the future? 

You wouldn't, Audio and Video are self contained media playback elements.  

> Or is this entirely off topic for Qt Mobility Multimedia?
 
> Can 'source' be something more abstract than an url? Should there be a
> separate "MediaSource" qml component that would be referred to instead
> of url string?

The only current means to specify a non-url source in the multimedia API at the 
moment is with a QIODevice.  Considering that you'd be writing C++ code to 
implement that interface anyway at the same time you could write your QML 
element that wrapped both your source and QMediaPlayer.  That's perhaps more 
work, but I think it will be a rare enough need to justify not complicating the 
API for everyone else.

> About Gallery:
> 
> http://doc.qt.nokia.com/qtmobility-1.1.0/qml-gallery.html
> 
> The filter structure seems way too declararative to me. Could it have
> an alternative api where filter was just a javascript function:
> 
>          filter: GalleryWildcardFilter {
>              property: "fileName";
>              value: "*.jpg";
>          }
> 
> =>
> 
> filter: function (elem) {
>   return elem.fileName.match(/.*jpg/);
> 
> }
> 
> This would be more natural to most programmers, and it makes debugging
> easier (you can use console.log etc. in the function).
> 
> I realize the declarative way can be optimized in the query level in
> the backend, but a slow-but-easy api would be nice for development
> phase.

While I appreciate that the filter elements are more verbose than they ideally 
could be they are fundamentally declarative.   The almost universal way of 
implementing the filter is to translate them into some native query language 
which is often executed out of process, discarding that to execute some 
javascript function on every potential match would be a massive performance 
loss.

> Same probably applies to Messaging.

Andrew

_______________________________________________
Qt-mobility-feedback mailing list
[email protected]
http://lists.trolltech.com/mailman/listinfo/qt-mobility-feedback

Reply via email to