You can subscribe to this list here.
2007 |
Jan
(8) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Justin W. <wra...@th...> - 2008-01-30 12:03:04
|
Hey Daniel: Comments inline, below. On 1/29/08, Daniel Hollocher <dan...@gm...> wrote: > > Hello all, > I had an idea for metashell this morning, that takes into account some of > the dialog on this list. So, to restate, right now, metashell offers users > the value of MIME-types and application associations, whatever, via the same > interface that see or open uses. You just feed in the file name, and it > tries to open the file with the correct application. > I personally felt a little lackluster toward that, because it doesn't > teach you anything. Agree. And part of the project is not only to help make the environment easier to understand and use, but to also teach the users. > > My inspiration this morning was to offer the same value of MIME-types and > application associations through a tab completion like interface. Right now > (in my shell anyway), tab completion offers suggestions on how to complete > the end of your command, or, if there is only one natural choice, it fills > in what it can. You could have shift+tab completion for the front of your > command. So when the user types in the filename, they hit "SHIFT-TAB" and nano/vi or which ever default application is added to the front of the line, and then executed? That way not only is the filename associated to a default application, the user can see how the commands are derived, and learn to use the CLI? So, a user, with tab completion, can locate a file, and get its name typed > into the terminal. Then, the user can hit shift+tab, and then a menu shows > up offering various commands that make sense for that file. If its a > .tar.gz file, maybe F1 will insert tar xvzf into the front of the line. Or, > you could hit F5, and it opens up a more general menu, for moving or copying > files, or even ftp, whatever. (please use your imagination to picture an > appropriate console ui) Whatever selection you make, it inserts the correct > command into the terminal. By menu, do you mean something like, ncurses? This would actually match the current behavior of a gnome-desktop or windows > user. You find files, and then figure out what you want to do with the > file. You use a file browser, and then double clicking, right-clicking, > drag and drop, whatever. Agree, part of the point of metashell. Let someone with no CLI knowledge, maneuver in the shell, while not being completely lost. If making the CLI easier to learn is an interesting topic to you, then I > would like to shamelessly plug my project at https://launchpad.net/climl. I call it climl for short, standing for Command Line Markup Language, or > Command Line Buddy as the long name. Love to idea of the project, keep up the good work. This project offers a new way to document the CLI. Right now, most > documentation is in the form of sonnets and novels written by programmers > (and... at MY college, you could get out of your single writing class > requirement by taking a class in software design). With climl, you would > instead document a task with an html like format. GUIs are then generated > from that documentation which can perform said CLI tasks, and in plain view > of/for the user. Two windows are opened, one with buttons that can execute > commands, and another with the default shell running. Pressing a button > just sends a text string over to the shell. In a sense, you could criticize > the project for being an over-glorified copy-and-paster. I would restrain from calling this a copy-and-pastier. For someone with experience, it is a lot of over-kill. But for a new user, seeing a "verbose" shell output, a GUI, and a tutorial all at once, will be a benefit. So, with one document, you get documentation of the task, a GUI for the > task, and a tutorial for the task regarding how to perform it on the command > line. > > Thanks for listening, bye. > > Dan > > > > -- > In science and in mind, the impossible and the hasn't-happened-yet are > indistinguishable. -- Thanks, Justin M. Wray Project Owner Website: http://www.themetashell.com Support: http://www.themetashell.com/index.php/Help:Contents |
From: Justin W. <wra...@th...> - 2008-01-30 11:53:59
|
Fergal: On 1/29/08, Fergal Daly <fe...@es...> wrote: > > On 29/01/2008, Justin Wray <wra...@th...> wrote: > > 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. > > Assuming the goal is to make it easier to open files from the command > line then there are 2 approaches. > > 1 Write a shell scratch that has the ability built in This is the approach of metashell, but remember metashell has other goals too. metashell is not only attempting to make opening files easier (with the support of mime-types), but is attempting to make the shell easier (for new-users, etc). 2 Have a good command with a good name that people can discover > without already knowing it This obviously would be a great choice for an experienced Linux user, but will have no benefit for someone who is struggling with the entire concept of the CLI. The conversation started with #1 but has moved to #2. Probably because Agree, the conversation has shifted. I stress again, metashell is not only opening files, there is more to the project, please check it out for yourself. 1 switching shells is a reasonably disruptive experience if you've > been building up configuration over the years True to an extent, but all shell scripts (including bash) will work within metashell. Therefore I cannot think of any configurations (assume we are talking shell wise?) that would now be unusable within metashell. If you have an example, please let me know, so we can address the issue, as well consider that a bug. 2 the new shell will almost certainly be missing some or many of the > features which you love I'll agree with this one. I like Thunderbird over Evolution, for a number of reasons. When forced to use Evolution, I almost undoubtedly find a feature missing. I am sure you have plenty of applications that you are biased towards. And undoubtedly, you find features missing in all of the rest? Linux verse Windows? OSX verse Windows? But on the same token, metashell strives to contain the same feature of your tradition shells, while also offering the user-friendly features. And if there is something missing, we would love to hear about it, so that it can be considered for a new release, etc. However, if you still seem to be missing something, and obviously know your way around CLI, metashell may not be for you. Lets not forget the audience here. 3 the new shell has an unknown security/bug status The shell is currently in beta. At this time one security flaw has been found, and patched within the next release (two days later). The flaw was the very same issue found on every Windows release, and reproducible in any shell, by adding a dot (.) to your PATH. Other then the project being in beta, and the one addressed security flaw. How is this unknown? 4 being non-standard, the new shell is unlikely to be install on > random-unix-like-box that you encounter day to day so you will be back > to your old shell for this situation Poor argument I fear. What if see isn't installed? What if your other solutions aren't installed. Ever come across a system that didn't even have bash installed? They exist. 5 it breaks the unix philosphy of do one thing and do it well which > implies that a tool which combines 2 unrelated functions would > probably be better if it was 2 separate tools Partially, obviously metashell is combing multiple functions, but that doesn't mean that it doesn't do them well, nor does it mean that the "one thing" is really bringing multiple benefits together. There are plenty of tools that do multiple things (emacs), and some are amazing and installed on thousands of distros, but that doesn't mean they break the unwritten code. 6 what about the executable bit in the file permissions? Really good point. Let me note however, that the executable flag must be set, or the file will not be executed. metashell respects the normal file permissions. #6 is really fun - "hey n00b, edit this text file - ~fergal/great-story.txt" > > n00b does types > > ~fergal/great-story.txt > > and has his homedir nuked because > > cat ~fergal/great-story.txt > #! /bin/bash > > rm -rf ~ This has been discussed plenty of times. It was originally worse, when your working directly was queried before your typical PATH, but has since been fixed (at least from that standpoint). A few ideas have been proposed. 1. Force the user to indicate the working directory (./) when addressing executable within the directory. Using a message like, this is an executable, if you are sure you wish to run this file, please add a ./ to the beginning of the filename. While idea one sounds okay, it does veer away from the user-friendliness. And trust me, I am asked all the time, why do I have to put ./ in front of everything, as it is. 2. Prompt the user when an executable is in the working directory. This file is an executable and may contain malicious code, are you sure you wish to run this executable? (yes/no) Or something along those lines. But this will quickly become distracting. The thought at this point is to go with option two, and then simply allow the notice/prompt to be turned off via a configuration entry. Nonetheless, this is a system-wide issue and more importantly a user-awareness issue, and has no more to do with metashell then any other shell or environment. But this issue is of utmost importance to the team. Any ideas on the situation would be greatly appreciated. So in my opinion, writing an entire shell saves you 2 characters of > typing (or 5 if you only have "open" and not "o") but has enormous > drawbacks. So it seems like a non-starter to me. It isn't about saving keystrokes (although the additional two characters do add up). It's about being user friendly, there is more here then simply opening a file based on association. I have addressed some of the other items below. Ditto... > Below is my comments, to the different aspects being discussed. > > > > On 1/27/08, Forest Bond <fo...@al...> wrote: > > > Hi, > > > > > > On Mon, Jan 28, 2008 at 12:33:55AM +0000, Fergal Daly wrote: > > > > On 27/01/2008, Forest Bond <fo...@al...> 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. > > > > '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. > > You still have to install metashell. Does meta shell also provide a > full posix shell - as would be needed for all of the system scripts? > If it does, why should I trust it when bash is widely used, well > supported etc. Yes, it is a full (POSIX) shell, requiring no other shell be installed on the system. That includes bash. So all system scripts would still work. This has nothing to do with trust. If you don't trust it, look at the code, or just use BASH. Your missing the point. If you are more worried about "support" or an already established community, over new features, then BASH is the right choice for you. It is all about choices. And on top of that, you obviously have no issues finding your way around the CLI, so metashell has little advantage for you. Could you use it? Yes. Would there be any learning curve. No. Would it do the same exact thing as your current shell. Yes. Does every command that works within BASH work in metashell, yes. But that doesn't matter to you, so continue to use metashell. Again I ask you to consider the audience, and more important that fact that there is more to this project then simple file association. The point is that I will still need bash + something else, in one case > it's "see", in another it's "metashell" so the argument of fewer > dependencies is not really correct. Also, see is used by other things > on the system, finally it's Ubuntu, you'll be installing hundreds of > packages anyway, + or - one is not a huge issue. Untrue, explain to me why you would "still" need "bash + something else", I may have miss your point, or you may be mistaken. metashell will still work on the system even if bash is not installed. The only time you will have a dependency on bash is when you are running bash-scripts (surprise-surprise right?) > > > > > > > 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 > > > > 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. > > Agreed. > > > 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. > > You can only makes these arguments because you chose gnome-open. If > you had chosen "see" then none of the above applies, it is a console > app with minimal dependencies and a simple text-file config. Okay, true, but it seemed as if "gnome-open" was the option of choice. As for 'see', it would obviously be an option if you plan to continue to use BASH, or another shell alternative. For those looking to have a more user friendly shell, and a better learning environment, I see this as less of an option. But it is all perspective. > 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. > > I think you must be making some other point here but I don't > understand it. If you don't want to open directories in a GUI > file-browser then don't. I don't want to open a Terminal window, and then use gnome-open /home/myusername/work/ and have the directory open in nautilus. You're right! The point is, that is what using gnome-open would do. In metashell you type in a directory, and it will chdir() you to that directory. The point was gnome-open is not REALLY a viable solution on a CLI system, or when you want to work within the CLI only. > > 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 > > > > > > 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. > > > > > > > > > > 3 multiple locations for the same preferences is a bad thing and > while > > > > sometimes necessary, should be avoided where possible > > > > > > > > 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). > > I don't want multiple locations for the preferences. Whether I can > different behaviour in GUI more vs console mode is an entirely > different matter. If I can configure it make a distinction, it should > also be in the same location. Agreed, a central configuration (possible through freedesktop) that allows you to specify default applications for GUI and defaults for CLI is much preferred over multiple configuration locations. If such a "standard" was to be implemented, where you could distinguish between CLI and GUI (and change such configurations from CLI), then metashell will use such standards, and ad hear to such configurations. But this is a different issue, right? > > > 4 if you don't already know the name of the tool, you are unlikely to > > > > be able to find it > > > > 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. > > You have left out "open" which is what I've been advocating and it > seems like a pretty obvious choice to me. Sure, just typing the name > on it's own is nice but see #6 way up above. I did include "open" there. And although I am sure the normal (unfamiliar person) is still going to try the filename first, they may try adding open the second go-around. Although, we are both coming from people who understand how a shell works. Some people may not realize you even add commands before filenames, or that commands exist, what about them? Is Ms Joan going to be like, "Oh! Duh! I need a command first, in front of the filename I wish to open. I bet "open" would be the command to use to OPEN something. And I am sure the command syntax is simply, "open <filename>". I doubt it, now would she come to that conclusion before, vi <filename>, sure. > > 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" > > > > 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. > > > [snip] > > > > > 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, > > > > 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. > > Again, you are conflating "a central location for file-action > preferences" with "a single preference for every file type". Yes, I misunderstood. As stated above, a central configuration location would be ideal. As long as you can designate actions based on the environment. Ideally I would be able to specify with a --flag, request to > interactively choose or have it automatically determined based on my > environment. This makes perfect sense, although isn't the case at the moment, and again is a problem outside of the scope of the project. While metashell would benefit from this problem being solved, metashell is not here to solve this problem. Maybe we should poll freedesktop for this solution? And then not only can metashell benefit, but see, edit, gnome-open, xdg-open, o, or open can all also benefit. That way, no matter what your preference, the problem from this end, is solved. However I do not agree that I want 1 set of prefs from the cmdline and > 1 set from X because I almost always run my cmdline _in_ X. So using 2 > separate databases for prefs 1 for metshell, one for gnome, doesn't > actually solve that problem. Hmm... I run a terminal within X as well, but I don't open text files from the command-line in gedit. That's the point of the menus, the mouse, and all the other fancy stuff X provides. If I am working in a shell (even if it is a window on my desktop, in my wm), I want to stay in a shell while doing so. In addition, what if you are not currently in X? > 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. > > Given that I've already said multiple tools for the job are a good > thing, I don't know how you can derive this conclusion. You may agree with the philosophy, but somehow it seems you are closed minded to the idea of a "new" shell alternative, that is striving to make the CLI a friendlier place. A project no-one is even forcing you to use. > > 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? > > > > 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. > > Again, if my CLI is running inside my WM, I don't want my PDF file in > a text console! That is you, and with metashell you have that choice. With a central configuration, you have that choice. Choices, choices, choices! When I have a shell on my WM, I am working in the shell for a reason, and therefore I want my PDF in a shell, period. (This is coming from someone who likes the CLI far more then GUI applications though, so I may be a niche market.) But I'll assume plenty of others like to keep the shell environment separate from the GUI. If not, they still have a choice. F > > > > -Forest > > > -- > > > Forest Bond > > > http://www.alittletooquiet.net > > > > > > -----BEGIN PGP SIGNATURE----- > > > Version: GnuPG v1.4.6 (GNU/Linux) > > > > > > > > iD8DBQFHnT5ZRO4fQQdv5AwRAtdNAKCeVVGtSBcFOds5zIgVlVdXS0uBnACfSc+d > > > JRYE47aTvDUngIHwY+Y+jP4= > > > =b6zx > > > -----END PGP SIGNATURE----- > > > > > > > > > > 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, > > themetashell.com > > > > -- > > Thanks, > > > > Justin M. Wray > > Project Owner > > > > Website: http://www.themetashell.com > > Support: > > http://www.themetashell.com/index.php/Help:Contents > -- Thanks, Justin M. Wray Project Owner Website: http://www.themetashell.com Support: http://www.themetashell.com/index.php/Help:Contents |
From: Justin W. <wra...@th...> - 2008-01-30 10:38:57
|
Forest: On 1/29/08, Forest Bond <fo...@al...> wrote: > Hi, > > On Mon, Jan 28, 2008 at 10:38:11PM -0500, Justin Wray wrote: > > 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. > > Any decent Linux distribution ought to update mailcap automatically when > new > programs are installed. Debian and Ubuntu do. > > Further, your argument that people should install metashell seems to be > based on > the assumption that installing metashell is easier than installing > mime-support. > Is that the case? That isn't the point. metashell is another alternative. It is just as easy to install metashell as any other Linux application (in theory -- which becomes ever so true if it is packaged or distributed within the distribution in question). > 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'. > > Does metashell currently support features other than opening files based > on MIME > type? If not, it is a "see" competitor trapped in a shell's body, and it > thus > makes sense to compare metashell to "see". Yes, metashell acts a full supported shell, with many shell features, including tab-completion, aliases, and much more. Also remember that metashell is only in beta, and therefore there are plenty of ideas yet implemented. If you must compare metashell to another project, it would be safer to compare it to fish, as it is an attempt to make the CLI an easier, friendlier place for new-comers to Linux. Do you have other ideas, of features that could be of use to a new-user, helping ease the experience, and allow them to learn at the same time? Nothing is wrong with simply using bash and then see/edit/gnome-open/xdg-open/insert-mime-handling-application, nor is there anything wrong with using metashell. -Forest > -- > Forest Bond > http://www.alittletooquiet.net > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFHnyC2RO4fQQdv5AwRAu3hAJ4hu2Qusi57nfN5j6qIh/WBU9yslACgqR8N > S8V5f8HchacDuOcrHPrgW0A= > =KG1q > -----END PGP SIGNATURE----- > > -- Thanks, Justin M. Wray Project Owner Website: http://www.themetashell.com Support: http://www.themetashell.com/index.php/Help:Contents |
From: Justin W. <wra...@th...> - 2008-01-29 03:38:17
|
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. On 1/27/08, Forest Bond <fo...@al...> wrote: > > Hi, > > On Mon, Jan 28, 2008 at 12:33:55AM +0000, Fergal Daly wrote: > > On 27/01/2008, Forest Bond <fo...@al...> 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. '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. > > > 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 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. 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 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. > > > 3 multiple locations for the same preferences is a bad thing and while > > sometimes necessary, should be avoided where possible > > 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). > 4 if you don't already know the name of the tool, you are unlikely to > > be able to find it 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. 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" 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. 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, 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. 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? 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. -Forest > -- > Forest Bond > http://www.alittletooquiet.net > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFHnT5ZRO4fQQdv5AwRAtdNAKCeVVGtSBcFOds5zIgVlVdXS0uBnACfSc+d > JRYE47aTvDUngIHwY+Y+jP4= > =b6zx > -----END PGP SIGNATURE----- > > 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, themetashell.com -- Thanks, Justin M. Wray Project Owner Website: http://www.themetashell.com Support: http://www.themetashell.com/index.php/Help:Contents |
From: Pysco <nat...@gm...> - 2008-01-27 01:05:34
|
Hello Fellow Ubuntu Users: I hope these are the correct lists to post to, for this type of information. I posed to; ubuntu-desktop, ubuntu-server, ubuntu-users, ubuntu-devel, ubuntu-devel-discuss, and ubuntu-universe-sponsors. In addition I posted the very same information on the Ubutu Fourms, which can be found at - http://ubuntuforums.org/showthread.php?p=4212284, in case you would like to continue the discussions there as well. I am posting to this lists as well, as they seem a bit more active amongst the developers, and used far more in discussion making, if this is an incorrect assumption, or any of the mention listed the incorrect place to post, please let me know. The important part, after the jump. I found this project, "metashell" on Freshmeat/Source Forge. I wanted to share it with the Ubuntu community. Directly from the metashell <http://www.themetashell.com/> website: *metashell is a lightweight, heavy punch, interactive, intelligent command-line shell. The amazing difference with metashell lies in its ability to determine a file's datatype, and automatically run your desired applications. metashell uses file datatypes (mime types) to determine a files type, and then using user defined applications automatically opens the files. Making the user experience in a shell easier and more user-friendly, while adding robust power to the CLI gurus of yesterday, today, and tomorrow. STATUS: Beta (Beta has been released) * As you can see the project is still only is Beta, but development seems to be active (at least since the initial beta release). I've also been using the shell for the past few days, and am currently using the latest version ( 0.03b). Minus a minor installation bug, and a dependency not included in the Ubuntu repository, everything seems to work great. And it does seem like it could be (albeit with a bit of work) a replacement as mine (and hopefully) your shell. The shell is honestly extremely user-friendly, but still contains the normal *nix power. It just makes execution and file management a breeze. You can still pipe commands, redirect output, background and union commands, etc. The ground-breaking feature is really the way you work with files. You simply type in a filename, and based on its mimetype (and your configuration) the file is automatically open/executed through the default application (based on your ~/.msh_apps setting). No more do you have to cat a file, or look through its contents. The shell makes this an easy and seamless process. It even will change directory, without you typing 'cd' (although you can still use 'cd' if desired). All of your normal commands/applications will function, (ls, cd, nano, cat, rm, mv, ln, cp, etc). But you can now move around, and manage files a bit easier. I feel this will make the shell a far less "scary" place for new Linux users. (I'll refrain from using the term noob, as I too am new to Linux). It will allow them to use it to open and edit files, without learning an absurd amount of information before hand. Allowing them to get the task done, and learn at a later time. And although I feel learning is important, and they will eventually need to know the "hard way" this should be a good start. This seems to also be the direction Ubuntu is traveling, thus the reason I am posting this here. Ubuntu is "Linux for human beings" and metashell seems to be "The Linux Shell for human beings". Things "Just Work (tm?)". Just like double-clicking, you enter a filename and things happen, no questions asked. The other cool part, is the default settings shipped, are for Ubuntu (Gnome), therefore Gnome GUI applications are opened for each filetype. I really think Ubuntu users will benefit from this project. All that being said, beyond just telling you about the project, I have a question. What are the chances of something like this shell or another user-friend shell making it into the Ubuntu distribution? Even if not as a default? Please take a look, and give your feedback. The Project Owner, is rather responsive, via email. Plus let me know what you think, and the possibility of inclusion into Ubuntu. Information: Website: http://www.themetashell.com Source Forge: http://metashell.sf.net Thanks, Pysco (As a side note, I have CC'd the project developer and the project's mailing lists -- as mentioned the project owner is quick to respond to emails, etc). |
From: Justin W. <wra...@th...> - 2007-01-10 20:43:46
|
Okay, good. In addition replies goto the list, unless you otherwise specify. Thanks again, Justin M. Wray On 1/10/07, Mark Reinsfelder <rei...@th...> wrote: > > howdy doodie > > On 1/10/07, Justin Wray <wra...@th...> wrote: > > > Email addresses were being hidden, which is counter productive as we do > > not know who is saying what. > > > > This has been updated. > > > > If you have any questions, please feel free to contact me. > > > > Thanks, > > Justin M. Wray > > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share > > your > > opinions on IT & business topics through brief surveys - and earn cash > > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > > > _______________________________________________ > > metashell-devel mailing list > > met...@li... > > https://lists.sourceforge.net/lists/listinfo/metashell-devel > > > > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > metashell-devel mailing list > met...@li... > https://lists.sourceforge.net/lists/listinfo/metashell-devel > > > |
From: Mark R. <rei...@th...> - 2007-01-10 20:42:31
|
howdy doodie On 1/10/07, Justin Wray <wra...@th...> wrote: > > Email addresses were being hidden, which is counter productive as we do > not know who is saying what. > > This has been updated. > > If you have any questions, please feel free to contact me. > > Thanks, > Justin M. Wray > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > metashell-devel mailing list > met...@li... > https://lists.sourceforge.net/lists/listinfo/metashell-devel > > > |
From: Justin W. <wra...@th...> - 2007-01-10 20:39:29
|
Email addresses were being hidden, which is counter productive as we do not know who is saying what. This has been updated. If you have any questions, please feel free to contact me. Thanks, Justin M. Wray |
From: metashell D. M. L. <met...@li...> - 2007-01-10 20:32:39
|
Seems like it sends, but the sender does not get a copy. On 1/10/07, metashell Developer Mailing List < met...@li...> wrote: > > Testing > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > metashell-devel mailing list > met...@li... > https://lists.sourceforge.net/lists/listinfo/metashell-devel > > > |
From: metashell D. M. L. <met...@li...> - 2007-01-10 20:31:30
|
Testing |
From: metashell D. M. L. <met...@li...> - 2007-01-07 20:19:43
|
Hello all, This is yet again another test. Messages seems to end up in archive but never go to subscribers.. Lets see what happens... Thanks, Justin M. Wray |
From: metashell D. M. L. <met...@li...> - 2007-01-05 02:04:50
|
This is a test of the metashell-devel list. Thanks, Justin M. Wray |
From: metashell D. M. L. <met...@li...> - 2007-01-05 01:49:03
|
This is the first post to the metashell-devel mailing list. This message can be considered a test. Thanks, Justin M. Wray |