let's begin with two

Marco Martin notmart at gmail.com
Thu Oct 13 21:16:30 UTC 2011


On Thursday 13 October 2011, Thomas Pfeiffer wrote:
> 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).

yup, just wanted to reiterate that ;)

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

it would probably have to be possible to start it as a separathe thing.. 
however what i would like is to have it as a component, ie a big piece of ui 
that even tough with some customizations, is put in all places where needed, 
looking and behaving all the same ;)


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

anyways we first need such ui, after there is something working, i can see if 
i can stuff it as file selector dialog as well, or if the way to have it there 
is really too fugly ;)

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

yeah, i think it would be mostly the case.. only notable exceptions probably 
are photo and most important mp3 collections that could grow quite big ;) 
there shouldn't be hundreds of changes in the entries tough
and another good news is that those are files that never get modified, so once 
strigi indexed them once that should be forever until they get deleted


Cheers,
Marco Martin


More information about the Active mailing list