tag:blogger.com,1999:blog-15496001.post116139860453787306..comments2023-06-14T07:30:39.379+02:00Comments on triky Concepts: MehtaHurdantrikhttp://www.blogger.com/profile/01281194707003363203noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-15496001.post-42456992114819952472010-12-20T05:33:13.996+01:002010-12-20T05:33:13.996+01:00Well, that comment is quite on the spot: I origina...Well, that comment is quite on the spot: I originally meant to follow up this post with one about extended attributes. (But never got around to it...)<br /><br />My Position on xattrs is rather ambivalent: On one Hand, they seem a good fit for storing the extra information used by the Mehta-translator and similar use cases. On the other hand, they are rather intransparent and awkward to use.<br /><br />Ideally, we would have a special Hurd filesystem, which can store hierarchical data in an efficient native representation, and present it upon demand either as a filesystem tree; in a serialized form (as an XML file or tarball); and perhaps also in special representations like main file+xattrs.<br /><br />Of course we would still have to consider how to represent the Mehta-Objects when saving them on a traditional filesystem for compatibility with other operating systems...antrikhttps://www.blogger.com/profile/01281194707003363203noreply@blogger.comtag:blogger.com,1999:blog-15496001.post-14711531684225740542010-12-04T01:27:40.065+01:002010-12-04T01:27:40.065+01:00@antrik "to extend the standard filesystem me...@antrik "to extend the standard filesystem mechanisms [..] would allow to attach all necessary information to the files themself, instead of putting them as additional items in a special directory.<br /><br />I think, a lot of what you're asking for is doable with extended file attributes: http://en.wikipedia.org/wiki/Extended_file_attributes#LinuxIkemhttps://www.blogger.com/profile/13192982197895876155noreply@blogger.comtag:blogger.com,1999:blog-15496001.post-86589679470948284802010-12-04T01:02:54.749+01:002010-12-04T01:02:54.749+01:00@antrik "I've never used DeepaMehta mysel...@antrik "I've never used DeepaMehta myself, so I can't tell."<br /><br />There's a demo: http://www.deepamehta.de/install/client/demos.htmlIkemhttps://www.blogger.com/profile/13192982197895876155noreply@blogger.comtag:blogger.com,1999:blog-15496001.post-14870326371996918772009-10-05T21:28:50.717+02:002009-10-05T21:28:50.717+02:00I'm just reading this now, but I think you cou...I'm just reading this now, but I think you could be interested in the concepts behind Étoilé [http://etoileos.com/]. They combine some concepts from DeepaMehta and they approach them in a manner more similar to (what I think) you describe.<br /><br />PS: Sadly, looking at the website they don't seem to describe the most interesting concepts in much detail. You can probably find more about that in the beginnings of the etoile-discuss ML.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15496001.post-6339758625435626082007-08-01T14:57:00.000+02:002007-08-01T14:57:00.000+02:00I didn't know dasher so far, but it looks interest...I didn't know dasher so far, but it looks interesting -- thanks for the link! I generally believe that in many cases a more dynamic interface can feel more friendly and be more efficient than traditional static GUIs. (Though one needs to be careful not to overdo it -- it can be distracting as well...) Dasher takes that to extreme.<BR/><BR/>Regarding your proposal, there seem to be two ideas in there. One is for the file chooser dialog instead of being limited to traditonal filesystem navigation, to have some kind of integrated search/advanced navigation facility. I guess this can indeed improve file choosers; however, I believe file choosers are a fundamentally flawed concept. As explained in the article in reference to DeepaMehta, the navigation facility should rather be the main view; and only once an object to act upon has been selected there, you launch some action on it -- rather than first running an action and only later selecting the object in a file chooser.<BR/><BR/>Which leads back to the main question, about efficient filesystem/object navigation. Your suggestion sounds like some kind of incremental search facility, where you narrow down the search bit by bit, giving more and more criteria. I don't know whether this is new (never worked with beagle and the likes), but it sounds like a good idea in any case.<BR/><BR/>Whether to use a zooming interface like dasher, or some more traditional kind of interface for that, I'm not sure. I said that I'd like some more dynamic way to navigate DeepaMehta-like relations, and some kind of zooming interface sounds like an interesting approach to explore...antrikhttps://www.blogger.com/profile/01281194707003363203noreply@blogger.comtag:blogger.com,1999:blog-15496001.post-19809226645450290872007-07-25T08:26:00.000+02:002007-07-25T08:26:00.000+02:00I know this is an old post, but I'm intrigued. I t...I know this is an old post, but I'm intrigued. I took a brief look at DeepaMehta and blah... stupid java is horrible. But the idea is cool. And your comments about using Hurd style translators and an extendable filesystem are great. <BR/><BR/>I was thinking about user interface and the potentially overwhelming amount of relationships betwene objects... what about a <A HREF="http://www.inference.phy.cam.ac.uk/dasher/" REL="nofollow">dasher</A> like interface? Not one that looks like dasher, which is pretty ugly IMO, but one that acts like dasher -- revealing options as they develop. <BR/><BR/>So for example, a file-picker dialog could have have a list of recently used files in one pane for quick access and then another pane with a text entry widget and then a display of relations that match. The user begins to enter some keyword that relates to whatever they're searching for. The display adjusts in real-time providing the closest fit options based on whats typed so far... once the user gets close to, or narrows down the options, a keystroke highlights the desired relation and the process starts over with either more relations to narrow down further or actual files if you've got it narrowed down enough. So the user doesn't need to know the filename, just have an idea of what the thing is and how it relates to what they're currently doing.... hmmm... letter... utility bills... overcharge... got it, January 12 2006 letter to electric company about overcharge and desire for a refund... make sense?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-15496001.post-1164460814292507362006-11-25T14:20:00.000+01:002006-11-25T14:20:00.000+01:00Well, I've never used DeepaMehta myself, so I can'...Well, I've never used DeepaMehta myself, so I can't really tell. But the idea is that in a map, you always only visualize these parts that you actually need for the task at hand; ant this should be quite manageable.<BR/><BR/>As I mentioned in the article, for some tasks the static map approach seems inconvenient, and some more dynamic navigation method could be necessary. Some sort of zooming mechanism might actually be helpful here. I don't see the benefit of a 3D representation over a simple zoomable 2D representation, though...<BR/><BR/>Also, judging from the screenshots, it seems that Topicscape uses a hierarchical structure and a fixed layout. This however is not really appropriate for most situations. The goal of DeepaMehta's navigation approach is precisely to replace unnatural fixed hierarchies by arbitrary associations and a free map layout.antrikhttps://www.blogger.com/profile/01281194707003363203noreply@blogger.comtag:blogger.com,1999:blog-15496001.post-1164438479459635952006-11-25T08:07:00.000+01:002006-11-25T08:07:00.000+01:00This is great but everything gets clogged up once ...This is great but everything gets clogged up once the map gets large enough to be meaningful. I don't know if you've looked at Topicscape (topicscape.com) have you? It works in 3D and allows many more topics to be associated with one another. The 3D landscape view lets you see much more and you can fly around the landscape and zoom in and out.Anonymousnoreply@blogger.com