a) Who cares about screenshots? "I'm going to the pub on Thursday" suffers from exactly the same issue.
b) Nonsense. Of course relative dates are machine readable. But anyway, web rendering != API.
c) These examples are not ambiguous, they are merely less precise
And less precision is, indeed, often what a user wants. That's why we don't print "posted 124568080nanoseconds ago". Simplifying to a reasonable unit, appropriate to the application, reduces cognitive load on the user. Most people struggle to tell you today's date, let alone knowing how long ago an arbitary timestamp was.
I like twitter (who maintain a relative date on the top-right of the feed entry) and gmail exactly the way they are.
"I'm going to the pub on Thursday" isn't likely to be archived and referenced at some future date.
Unless you Tweet it. In which case, your statement (and the relative, human-parsable time) and the timestamp (absolute, machine readable) are both present.
Repetition and redundancy can increase robustness and strength.
This would be a valid argument for not persisting dates as relative values.
It isn't an valid argument against presenting dates this way.
The OP's POV seems, to my eye, driven by the fact that primitive screen-scrapers can't just run a simple "toDate" function to provide it, API style, to some back-end. But it doesn't mean that it's not possible to convert them - it's not even that hard.
Fortunately, UI designers care more about their actual users than satisfying 3rd party leeches.
I'll second this. I tried setting one up on an Amazon micro instance, but in the end I had to use a small instance instead. Jenkins needs a lot of resources for that it does.
In my experience, micro instances get throttled pretty harshly if the cpu bursts for very long. I think a CI instance wouldn't be the best fit for micro.
I had a similar idea about 10 years ago, but never got around to implementing it.
I'm amazed at the amount of hatred directed towards this - as if the terminal could in NO WAY be improved?!. But clearly it can. For example - wouldn't it be nice to have a terminal status bar with your CWD / git branch / etc in, without cluttering up space before $? Yep, you can use screen, and that destroys your ability to use the scrollbars.
Or, consider filename completion. Wouldn't it be nice to show the intended completions in a popup as you're typing (like web browsers do) ?
Why, when I do 'ls', can I not drag & drop one of the files to another finder window? Why is the terminal forever isolated?
Why when I run 'mvn install', which generates umpteen bazillion lines of output, can the result not be folded into a single line showing the summary, that I could expand if I wished?
There's lots of scope for this kind of thing. My main concern would be whether a single WebKit control is the right way to go - it'd be nice to, for example, embed custom controls within the shell (but this might also be possible).
"I'm amazed at the amount of hatred directed towards this - as if the terminal could in NO WAY be improved?!"
Improve it all you want, I'm totally into that. The problem is that once your "terminal" ceases to be a terminal emulator then you lose so much it's pretty unrecoverable.
Most of the things that you suggest are very much technically possible for a shell (perhaps zsh with some extensions) running in xterm. You'd be left with some sort of unholy combination of a rather modernized `mc` and an otherwise modern shell, but it'd be a very interesting product.
tl;dr: We're not opposed to improving the 'terminal'. I'm opposed to 1) mistaking "improving the terminal" with "improving the shell" and 2) losing the terminal.
A terminal emulator running on an object-oriented system like Termkit could run vt100-friendly filters to convert everything to text before it is sent down the line to the user. Users who did not know they were connecting to such a system might not notice the difference.
Although I am not entirely sure what you are attempting to communicate, what I will say is this:
If you do not provide direct user access to a pseudo terminal through a terminal emulator, then you will undoubtedly lose functionality. You need both the pseudo-terminal and the terminal emulator. If you do provide direct user access to the pty through a terminal emulator, then what the hell is the rest of the crap there for?
> Wouldn't it be nice to show the intended completions in a popup as you're typing (like web browsers do)?
This can probably be written as an extension to bash/tcsh/zsh to use the pop-up completion facilities of vim. If you want nice webapp-looking ones, you might be able to get away with terminal escape codes and use a perl script (this is how rxvt lets you click on http links automatically).
> can the result not be folded into a single line showing the summary, that I could expand if I wished?
An interesting point, and I was going to counter with a small one-liner using 'tee,' but I couldn't think of a good one quickly that does what you really want: 'auto-collapse.' The problem with this is that often with giant lines of output you really only want to look at the last few to see what happened. Otherwise your output is typically some kind of streaming log (you do not want auto-collapse for this) or a poorly written program. "walls of text" suck and are usually an indication of something you expect to have a lot of output (looooong makefile) and can do a less accordingly, or an unexpected error. If it's an error you want to see what it is, so you're going to click on the 'expand' button -- an extra click every time on an all-typing interface kind of sucks.
I also think this is a great implementation of a useful idea.
Why all the haters? Surely the next step is a MIXED-MODE console where you can have both the power features shown, and a simple mode for the die-hard traditionalists.
Again... stirling work and I'm looking forward to it.
There's lots of scope for this kind of thing. My main concern would be whether a single WebKit control is the right way to go - it'd be nice to, for example, embed custom controls within the shell (but this might also be possible).
Yes, that's possible. Webkit embeds JS, and you can do the craziest of controls in JS, communicating with your process through JSON packets (at least, that's how I understand the article). This would need some extension mechanism at the side of the shell, though, but that's not rocket science.
Ditto to that. I admit predisposition to liking Termkit because I also had a similar idea in the past and I had neither the time nor talent to go anywhere with it. Kudos to this guy for producing something that looks like a very large step in the direction of improved usability and a potential step towards improved performance if programs can be made to pass each other common structures without needing to serialize and reparse the data until it needs to be seen by a user.
In addition to the frontend and pipe changes, I also imagined changing the way files are accessed. Some subsystem could put indexes and attributes on certain data files so you could run something like:
and you would get the desired set of information without needing to write potentially buggy regex scripts. If there was a new type of file that you wanted to get data from in a few different ways, you could write only one buggy regex script to use as a filter and then query the file with the shell's normal query methods to pull down any information you might need. In the example of pulling users from a file, the shell could know from the attribute metadata that you are looking at a list of users and it could show the results as widgets that you could right-click to get the user's properties.
This all implies rewriting every utility in the system to accept recordsets instead of text, adding custom code for every different targeted data file, and making sure it all works with existing tools that have not been converted yet. That could be difficult, or at least time-consuming.
man, if you had to operate daily hundreds of files you will forget quickly about drag'n'dropping, scrollbars and all that annoyances. about the popup is useless on a keyboard controlled interface as the number of keystrokes needed are the same. the problem you have, is that you think that your terminal application is badly-glued into your graphic system, when in fact your graphic system is badly-glued on terminal applications
The trademark issue meant that it didn't matter what the community wanted, it could be 1,000,000 : 1 against, if the 1 was Oracle, they could stop (or force) anything they wanted.
Commercial interests had wanted to move to Eclipse before. Most developers see the Eclipse process as overly bureaucratic and unfriendly - and therefore were -1 on that.
The whole process has been an attempt to try to force-feed the development community into eclipse, whether they like it or not. Because they hold the trademark, they have the control.
Well, thing is, eclipse was disliked before, and it is disliked now. I seriously doubt any devs will be considering it.
I'm assuming the parent was talking about publicly available patches, not internally developed Red Hat ones. In that case, you could determine B and C out of a list of possible values by brute-forcing.
a) Who cares about screenshots? "I'm going to the pub on Thursday" suffers from exactly the same issue. b) Nonsense. Of course relative dates are machine readable. But anyway, web rendering != API. c) These examples are not ambiguous, they are merely less precise
And less precision is, indeed, often what a user wants. That's why we don't print "posted 124568080nanoseconds ago". Simplifying to a reasonable unit, appropriate to the application, reduces cognitive load on the user. Most people struggle to tell you today's date, let alone knowing how long ago an arbitary timestamp was.
I like twitter (who maintain a relative date on the top-right of the feed entry) and gmail exactly the way they are.