Jason Tackaberry wrote: > On Sun, 2005-04-17 at 13:19 +0200, Dirk Meyer wrote: >> Hi, > > Hi Dischi. How've you been? Seems a bit has changed since I last > looked at freevo. :)
Hi, welcome back!
>> applications may also use it. This involves storing all thumbnails in
>> the large dir (128x128 is too small for us) as png with meta
>> informations.
>
> Unfortunately the spec doesn't allow for formats other than png. I
> agree that using epeg is a performance gain that can't be ignored. But
> the common use-case is probably a lot of jpegs and a system with epeg
> installed, in which case pyimlib2's current thumbnail code will not
> adhere to the specs. So other applications won't be able to benefit
> from the thumbnails, which pretty well obviates the whole point of using
> ~/.thumbnails.
The idea of using jpg files isn't mine. I stole it from enlightenment.
So they would reuse our thumbnails and maybe the freedesktop.org
change the spec some day.
> On the other hand, it also seems like quite a reasonable extension under
> the circumstances. And the fallback (non epeg) code does generate a
> spec-compliant thumbnail. There should, of course, be some logic
> elsewhere that cleans up deprecated thumbnails.
Yes, the helper should check all files if they point to a valid
image (IIRC Thumb::URL).
> My first instinct is this really isn't pyimlib2 territory, since it's
> not specifically Imlib2. But it _is_ image library territory, and with
> the shmem stuff in pyimlib2, I really set the stage for pyimlib2 to be a
> more general purpose, kitchen sink thing anyway. :)
Yes, it should be something else, but that tiny little epeg and png
code doesn't hurt :)
> My only objection to pyimlib2 now is the indentation style. Replaced by
> spaces? My tabs! My beautiful tabs! Oh, woe! :) It is, however,
> maintainer's prerogative. :)
Nothing against tabs, but setting tabs to 4, no that's bad. Your
indention style is still there.
>> Right now my version here supports both, the old vfs and the
>> .thumbnails style. But do we need both? To keep the code cleaner, I
>> want to remove the vfs way of thumbnailing. Comments on that?
>
> Ignoring issues of code stability in current cvs (since I have no idea
> where Freevo is now in that respect), I think it makes perfect sense to
> remove thumbnailing from the vfs.
CVS should be stable enough for some testing. I have it at daily use
and it feels ok.
>> And two questions remain: First, what to do with rom drives? A disc
>> can change the drive, so the thumbnailer won't find it. I was
>> thiunking of VFS/disc/DISC_NAME/.thumbnails as a solution for the
>> problem.
>
> This seems reasonable. Another approach might be to put the thumbnails
> in the regular ~/.thumbnails directory but include the CD name in the
> hash, but I think your suggestion is better. Either way, the current
> thumbnail code in pyimlib2 doesn't allow for repositories in different
> locations.
I would add that if needed, yes. The current thumbnail code is only a
test.
>> Second: do we need creating thumbnails with the cache helper?
>
> Why not? Can't it just reuse current code? I think having this in the
> cache helper is nice. Some users probably run freevo cache in a cron at
> night or something, just to index files they might have added but
> haven't browsed in Freevo yet.
OK, yes the old code is still working. I guess an extra parameter to
turn thumbnailing on or off is ok.
> I've been completely revamping the vfs code in mebox. It supports
> live queries and auto-indexing of any new file in the repository (so
> long as the system supports inotify), a feature inspired from the
> Beagle project. By live queries I mean you can do
> vfs.query("artist='Vangelis'") and it will return a vfs directory of
> files matching that query. You can attach callbacks to a monitor on
> that directory that gets signaled when a new file is added to user's
> library that matches that query. Since it uses inotify, the
> feedback is pretty immediate. Very cool stuff. :)
WOW, I want that, too. :) It looks like a merge between by new mediadb
and the vfs with some database features. How fast is it?
> The client can start using 'foo' now as if it were local. Any mutable
> objects (instances, lists, dicts, whatever) passed back and forth
> between client and server either via return values or arguments are
> automatically referenced (rather than copied). Things just work. This
> really isn't anything magical if you're familiar with Python, but I do
> think it's really cool.
I guess we will stick to mbus but maybe make the iterface more look
like that.
> But the most significant stuff I've been working on remains how I'm
> going to do the display for MeBox. Mevas was the answer, but now I'm
> not so sure. I've been doing some fiddling with evas (from the
> Enlightenment project) and it seems viable.
NOOOOO, mevas is working so good and you are telling me that you are
doing an eval port for python and it is even better? You know I can't
resist playing with that :)
So what is the interface? It would be cool to have a mevas like
interface to your pyevas so I don't need to rewrite everything.
> So we have an mplayer video that is a canvas object. (You might be
> asking why not use Emotion, but the short answer is that I want to use
> mplayer, and mplayer cannot be used as an application library.) But the
> cool thing is that since this is an evas canvas object, we can
> manipulate it like any other. We can move it around, scale it, change
> its alpha value, apply a color map to it, whatever. The COOLER part is
> that with evas's opengl acceleration, this is not only slick, but really
> fast. This means I can do MCE-style fade/slide/scale effects of video
> that's very smooth. And since I've got enough of the evas API wrapped
> in pyevas (which I'll release independently at some point), all this is
> written in Python and looking very good.
I want a mevas like interface, please. This would be so cool to have
in Freevo.
> At some point I will have some sort of technology demo of this. MeBox
> is still vaporware, however. And I still use Freevo. :) But maybe
> Freevo can continue to benefit from my work in some way.
I sure hope so.
> Ok, back to reality. Dischi, I'd like to make some changes to pyimlib2.
> Specifically, I'd like to add Py_BEGIN_ALLOW_THREADS /
> Py_END_ALLOW_THREADS to various places, to make threading performance
> better.
I prefer not to use threads at all, use pynotifier. Threading will add
too much side effects. But if you need Py_BEGIN_ALLOW_THREADS, feel
free to add it.
> Do I still have write-access to the repository?
Yes, and feel free to add pyevas in libs :)
Dischi
--
printk("autofs: Out of inode numbers -- what the heck did you do??\n");
2.0.38 /usr/src/linux/fs/autofs/root.c
pgp4xKRmnmNiy.pgp
Description: PGP signature
