Hello everyone, My name is Justin M. Wray, and I am the Project Owner for metashell. Sorry that is has taken me a few days to respond, I have been following along via my Blackberry, but haven't really had a chance to sit down and formulate a response yet. Also, let me thank 'Pysco' for the publicity of the project, and I am glad to see users are enjoying it... All this being said, I feel that the current conversation is going in an entirely unneeded direction, and that there is a lack of communication between the metashell project and Ubuntu, thus the goals are not clearly being defined. Remember this is an Open Source project, not necessarily a "Ubuntu" project. Below is my comments, to the different aspects being discussed. <div>On 1/27/08, Forest Bond <<a href="mailto:forest@alittletooquiet.net">forest@alittletooquiet.net</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Hi, On Mon, Jan 28, 2008 at 12:33:55AM +0000, Fergal Daly wrote: > On 27/01/2008, Forest Bond <<a href="mailto:forest@alittletooquiet.net">forest@alittletooquiet.net</a>> wrote: >> Are you advocating the creation of a program called "open"? > > No, I said "alternatives-based". That is, using the Debian > alternatives system to provide access to one preferred tool from > amongst many similar tools. Okay, I follow you now, although I think alternatives is for managing different binaries that have the same capabilities, not just the same name... >> Perhaps I was not clear before. What you are looking for already exists, >> and it is called "see" (or, perhaps more appropriately, "edit"). These >> tools pull data from mailcap.</blockquote><div> 'see' or 'edit' are external (ie not part of the shell) binaries, that must be installed on the system to work, and rely on external applications and preferences to perform the tasks. The goal of metashell is to integrate these functionalities into the environment the user is working within, the shell. Thus no external dependencies, nor will the user need to know these 'commands' to simply open a file. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> > You were perfectly clear, however there is definitely some > miscommunication. In my last mail _I_ mentioned that see reads from > mailcap and now for some reason you are explaining exactly that to me > (it was in the part you snipped). Indeed, I misread. Apologies. > So let me rephrase my points > > 1 there are multiple tools which do roughly the same thing - see, > gnome-open and probably k-something-or-other and no unified location > for preferences for these tools</blockquote><div> Exacly, there are plenty of ways to determine a mime-type, and plenty of other ways to open a file in a default application. But I think everyone is missing the point. I'll break it down, these functionalities are not built into the shell and require package X, and setting X, to work, something a "new" user may not know about, or better yet even have installed and configured. I'll use gnome-open as an explain as it was specifically mentioned. This obviously requires gnome to be installed. What if the user is on a KDE based system? Maybe not even Ubuntu? What if they use XFCE, Flux, or the best example CLI only? How is a user on a non-gui system going to obtain the benefits of gnome-open? What is gnome-open going do for you when X fails? But even funnier, the gnome-open example just doesn't fit. It is an application that doesn't REALLY do the same thing. Maybe from a real high-level it appears to obtain the same solution to a problem, but that is only true if the metashell configuration resembles the freedesktop (.desktop ) configuration. Specifically mentioned was that gnome-open can also open directories. Can someone explain to me why anyone would open a CLI shell, and then use gnome-open <directory> to open a directory in nautilus? So do you mean an application which goes from CLI-GUI does the same thing as a shell with the ability to (based on your configuration) to open a pre-set application, based on file type, and can change directories, without the need for command 'cd'? Sure typing 'cd' is not a big deal (and you can us 'cd' in metashell), but that isn't my point, the point is you don't need 'cd', and gnome-open doesn't do the same thing. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Right, now I understand; integration has always been a sore spot for open-source software. Competition is a good thing, except when its happening on one machine (especially when that machine happens to be your desktop). :) > 2 multiple tools which do roughly the same thing is no problem</blockquote> <div> Agreed, nano and vi? There are plenty of tools that do the same thing, each with its own pros and cons. Everyone has their own preference of the best tool to complete a task. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > > 3 multiple locations for the same preferences is a bad thing and while > sometimes necessary, should be avoided where possible ></blockquote><div> Same preferences? I don't believe that preferences for your default CLI applications are the same as preferences for your default GUI applications. metashell is used to maneuvers in a CLI environment, and the configurations should reflect such. The defaults shipped do rely on GUI applications, but that by no means is a requirement, you can simply change gedit to nano or vi, and use metashell on a system that doesn't even contain X (as in Xorg). </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> 4 if you don't already know the name of the tool, you are unlikely to > be able to find it</blockquote><div> Agreed, and this is a really good point. Why should we assume that Ms Joan next door is going to know to prepend 'o', 'open', 'see' or even 'gnome-open' before a file name? You have no idea how many times I have seen someone just simply type a file name, when I ask them to open a file. Or cat the file first, to determine the type, and then open with whatever application. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Agreed up to this point. > 5 "open" seems to be the obvious name for such a tool. It was the > first thing I tried, it's what's left when you remove "gnome-" from > "gnome-open", it's the verb that appears under every File menu I've > ever seen. It seems quite discoverable. "edit" is also quite > discoverable however if you're just trying to open something to see > it, you're unlikely to try "edit"</blockquote><div> Doesn't matter why someone trys, if the default for the file to just open, we get past all of this "command-blank" completes this and "command-this" does thats, so on and so-forth. metashell is not a project that is to provide a way to simply open a file, but it is instead a project aimed at making the shell a friendlier place, without taking the power out of the users-hands, a hard balance to strike. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Well, these are all arbitrary verbs that make sense from one perspective or another (and I noticed you even used the verb "see" here). It seems like one is as good as any other, and that's why I don't think "open" is self-evidently better than "see", "edit", etc... > 6 open is currently a symlink to /usr/bin/openvt - the fact that it's > a symlink and that "man open" talks about "openvt" not "open" makes me > thing that it's ripe for reclamation. I always assumed there was some historical reason for this symlink, but it's difficult to get a useful search result indicating that. > So I am suggesting that Ubuntu would be improved by reclaiming > /usr/bin/open from the console-tools package and replacing it with an > alternatives-based link to a file opener, on Ubuntu -gnome-open, on > Kubuntu - k-something etc etc. Ideally they would all have the same > interface but even without that it would be good. > > It would also be great to have a central mime-type -> action database. > I think that's part of freedesktop but unless see and edit pay > attention to it, the problem is not fully solved,</blockquote><div> This is absolutely untrue. A central type-to-action preference, would assume that a user always want to use such action. When I open up my home-folder in nautilus, I want gedit to open any text file I double-click on, but 90% of the time, when I use a text file on the command line I am using nano or vi, and the other 10% cat. I very rarely use gedit from a command-line. If we follow this logic, we can take out every application that preforms the same task, and give the users no choice, slap a (photo of a 'Super-Key') on the box, and sell it for far more then is worth. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Here's where I definitely agree. Other systems have this, to some extent. It seems like the desktop-specific systems ought to manage mailcap, doesn't it? Or is mailcap too outdated to be practically useful on the desktop?</blockquote><div> I would agree that a type-to-action database should be present per enviroment, one for CLI based settings, one for each WM, etc. But not for the entire system. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">-Forest -- Forest Bond <a href="http://www.alittletooquiet.net">http://www.alittletooquiet.net</a> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHnT5ZRO4fQQdv5AwRAtdNAKCeVVGtSBcFOds5zIgVlVdXS0uBnACfSc+d JRYE47aTvDUngIHwY+Y+jP4= =b6zx -----END PGP SIGNATURE----- </blockquote> </div> The point of all of my comments is this: metashell is not a project with a goal simply to "open" files. It is a project with the ideas of creating a user-friendly command-line environment. That uses intuitive commands (or lack there of) to complete tasks. While all at the same time allowing the well-versed *nix admins complete complex tasks without hesitating. I really hope after reading this email, everyone better understand the goals of metashell, and the diffrence of usings it verses an external application like 'see'. I would like to thank everyone for their comments on metashell, and look forward to hearing more. So far the response to metashell has been good, I hope to continue to make the CLI an easier, less intimidating place, for new users. If there are any questions or comments, please do not hesitate to email me, or the metashell lists. For more information, please checkout the metashell website, <a href="http://themetashell.com">themetashell.com</a> -- Thanks, Justin M. Wray Project Owner Website: <a href="http://www.themetashell.com">http://www.themetashell.com</a> Support: <a href="http://www.themetashell.com/index.php/Help:Contents">http://www.themetashell.com/index.php/Help:Contents</a>