let's begin with two
Thomas Pfeiffer
colomar at autistici.org
Thu Oct 13 21:04:56 UTC 2011
On Mi, 2011-10-12 at 22:03 +0200, Marco Martin wrote:
> you are both right.. there are things of the main ui that still need clean up.
> but, for the ui polishing part, i would keep it pretty minimum, last thing we
> want at this point is turning upside down..
Turning things upside down is not what Fania wants either ifaik, it's
more like having her original designs fully implemented plus some tweaks
here and there like further work on SLC, which is currently more like
"have something in there that works somehow" instead of something really
thought through (which was okay for PA1, but should be improved for
PA2).
> also on the file management is right..
> I hoped in the beginning that it would have been possible getting away by
> completely hiding the filesystem.. mybe is still possible, i don't know.
That was our plan as well. We still need to get stuff from and to the
device and organize it semantically by tagging and rating and things,
though, and that's what the resource management interface is for (I
intentionally avoid calling it "application" because it should really be
seamlessly integrated in the system instead of being started as a
separate app).
> anyways, what i want to achieve with my priority, "componentization", is to
> a) have a proper model for nepomuk queries, and that makes this a tad more
> robust and useful,
> b) bindings for other models such as krunner and kfileplacesmodel (a
> kfileplaces primitive binding is already present in the image app, since is
> possible to view photos from pendrives already)
I've noticed this feature in the image app and it looks pretty neat :)
> c) some maybe primitive but functional ui components (ie, used around
> applications, always the same) for the above models, and that would allow for
> a basic exploring/copying around both of the filesystem or nepomuk stuff, like
> tags or activities
Yes, standard UI components would definitely be needed (that's what I
mean by "seamless integration") so Active apps could easily access files
in a standardized way.
> i hope also to be able to replace the file selection dialog with that thing,
> even tough without patching qt or kdelibs seems is possible to do only with a
> rather convoluted loophole by setting a global static function pointer in the
> qstyle, ouch ;)
It would of course be awesome to have that so users will never have to
see the file system even when they use legacy apps, but "convulted
loophole" doesn't sound like an elegant thing to do ;)
> > not being indexed because Strigi is suspended since it would have to
> > handle
> > addition to the Nepomuk database in order to work anyway.
>
> as for strigi, battery consumption or not here it should be always running, no
> matter what.
Since users probably won't have loads of data on their mobile devices,
if Strigi doesn't consume too much battery once it has indexed all files
and does not re-index unless something changes, I agree that it should
be always running.
More information about the Active
mailing list