Check this out (mpeg4, VMware video codec). Ahh yeah. David’s putting together some awesome code for tagging functionality in nautilus using Leaftag. Hopefully we’ll get it out into a release before long.
Check this out (mpeg4, VMware video codec). Ahh yeah. David’s putting together some awesome code for tagging functionality in nautilus using Leaftag. Hopefully we’ll get it out into a release before long.
That looks amazing. This is the first thing that I have seen that actually addresses the problem of collecting the information for these fancy searching programs to use.
How does this stuff work with the existing emblems in nautilus?
Off Topic, can I use that vmware codec on linux? I have a purchased copy of workstation.
Please post your videos as ogg theora. We are never going to solve the codec/patent issue unless we actually start using the codecs.
Until I have a tool that makes it as easy to convert to theora as mpeg4 (which in thise case required two seconds to copy some command line arguments from the enxamples section of the mencoder man page), it’s not going to happen. I have better ways to spend my time than digging through mountains of poor transcoder documentation trying to find the magic command line options to make it not look like crap.
Now as long as the information is put somewhere in the extended attributes or put right into the metadata so that programs like f-spot, beagle and the like can access it.
Corey: It’s up in MPEG-4 (for convenience) and VMware’s native video format (for efficiency). VMware’s format is basically VNC, and mplayer has an open source decoder for it. Unless you can find some patent issues in VNC, it’s probably clean. Theora is great and all, but it really isn’t what you want to be using for screen captures.
Arcterex, please see the comments on http://www.chipx86.com/blog/?p=140
Ugh.. I guess I should add that “theoretically” the vmware video format is more efficient. I have no idea why, even after gzip, it’s 1.8MB compared to the MPEG-4’s 400k. Are there actually any formats out there (besides Flash, or raw VNC dumps) that are good for screen capture data? Even if Theora gets similar performance to MPEG-4 on this stream, that really isn’t saying much.
Thanks, it’s nice to read things are coming into shape, i’d like to add my note though:
Leaftag has the potential to merge the “Emblems” and “Notes” features, already present in GNOME’s file properties dialog, into one single dialog. That would be preceived as a natural evolution, this is a big chance to simplify & improve the property dialog.
Please see the work at http://home.exetel.com.au/harvey/epiphany/bookmark/ and http://home.exetel.com.au/harvey/epiphany/bookmark/using_entry.gif
The screenshots there are slightly out-of-date, but the text is pretty much accurate. Email me if you are interested in using any of the work there. It is in Epiphany CVS HEAD and will be in the coming release.
It looks like the Nautilus tagger is taking a very different approach UI-wise as the new topic selector in Epiphany.
(Read more on http://home.exetel.com.au/harvey/epiphany/bookmark/). It might be nice to combine efforts here!
Man this is awesome. Die emblems, die!
Pingback: Fudeblog by Cesar Cardoso » Aqui e ali
In reality, this dialog and epiphany’s aren’t that different.
Take a look at this: http://home.exetel.com.au/harvey/epiphany/bookmark/list2.png
Both have a text entry, which is meant to be the “primary” mode of interaction. Both have a list of your existing tags. The difference is that leaftag will have bundles (like del.icio.us), and potentially hundreds of tags per user. As discussed with the previous fstaglib nautilus screenshot, the big list of check-boxes just doesn’t scale. It’s my hope that with bundles (imagine more expander boxes below “all tags”), this UI can elegantly handle that many.
The most interesting thing is how the topics are used to construct the bookmarks menu. Also how the same algorithm defines the ordering of topics in our list.
While the UI suggested for Nautilus does pack more tags into the screen, it might be worthwhile to try using Epiphany’s heuristic for automatically identifying topics the user will want to use. For example, “currently selected” tags at the top, “suggested/related” tags immediately beneath, and “all” tags below.
Our animation isn’t as slick, but you can see roughly how the “suggested” tags work by watching this a few times:
http://home.exetel.com.au/harvey/epiphany/bookmark/using_list.gif
Have just uploaded a better version of that animation. It shows how a user can use multiple paths to select the same set of topics, and how we “suggest” topics based on the user’s existing topic/bookmark arrangements:
http://home.exetel.com.au/harvey/epiphany/bookmark/using_list.avi
404 on that .avi link
After thinking about this, I’m a little reticent to have things “move around.” Unless it behaves perfectly (unlikely given the nature of humans), anything other than alphabetical order can make things unpredictable and difficult to find, especially in a list of hundreds of tags.
I am, however, very interested in the “suggested/related” heuristic. Having another synthetic bundle at the front for suggestions would be very nice 🙂
Seems that my ISP doesn’t like “potentially copyrighted forms of files”. I’ve placed it on my uni page instead.
http://www.dsl.uow.edu.au/~harvey/using_list.avi
I agree that the idea of an auto-generated bundle would be nice, if you are really going to have a huge number of tags. We may even leverage that in Epiphany later, if users start having >100 topics. But this is Epiphany’s answer to bookmark hierarchies, and so ensuring it scales well to reasonably large topic/bookmark collections was important to us as well.
By the way, why use space as a separator? You’re ruling out the user’s option to have space in their tag/topic names. You can’t write “Open Source” or “Jack’s Birthday” easily with space separators. Basically, I’m wondering why not use commas?
Also note that Epiphany requires an explicit “Create New Topic”, though this is negotiable. We did it to ensure that users don’t accidentally write “Opne Source” and end up very confused. It was also easier to implement that way given our current codebase. 🙂