On Wed, Jul 19, 2006 at 10:49:53PM EDT, Miciah Dashiel Butler Masters wrote: > On Wed, Jul 19, 2006 at 09:44:41PM -0400, cga2000 wrote: [..] > > > > Not that I'm particularly happy with the keyboard either. The > > traditional typewriter keyboard was bad enough but what IBM did to it is > > beyond words.. > > What did IBM do? > Hehe.. took the antiquated and non-ergonomic typewriter layout and slapped a bunch of 'computer' keys in impossible-to-reach spots..
All to please the tiny minority of typists, most of whom wouldn't use computers for years to come.. How's that? I had bookmarked a useful article on the subject in mozilla at some point that enlarged on the above and more technical aspects.. while introducing some alternative layouts.. but I'm afraid I don't have that any more and I'll have to google for it. Naturally I have my own ideas re the perfect personal computer keyboard layout but cannot discuss further.. haven't mailed in those patent application forms yet.. > > Only solace I find in a keyboard-only environment is its relative > > simplicity (as compared with keyboard+mouse) .. Even a fairly large > > number of inconsistant keyboard shortcuts across applications is in my > > case a tad more efficient than switching action mode every other second. > > I prefer to be able to form my environment to myself, you know, like a > human. That's the other 'main' reason I dumped mozilla.. what did it was that my beloved 'Ctrl-U' used to clear a data entry field in sane environments suddenly changed its behavior when I upgraded to a more current version: instead it now brings up a new window with the html source version of the page.. drove me nuts.. mind you, there may be a way to switch back to the *nix-type 'normal' behavior.. but that was the last straw.. didn't bother to find out.. .. curiously, I was thinking along the same lines as your 'I prefer to be able to form my environment to myself, you know, like a human.' .. like what absolutely stinks about the gui is that while it poses as a user-friendly device when all is told it really boils down to restricting your freedom. Hey.. maybe my decision to dump the gui was not just a matter of personal convenience after all.. Shades of Huxley, perhaps? > Using GNU Screen, my Web browser, E-mail, IRC client, shells, > editors, music player, &c. are each exactly one keypress away. Each > program is customised (mostly) with comfortable (for me) keybindings. .. not so trivial, though.. I've never really had the time - or maybe I'm just too lazy.. to take an earnest look at the keybindings in the applications I frequently use and try to define a consistent scheme. Changing them without a clear plan can be awkward.. like Elinks says .. "oh.. but this key is already bound to something else.." .. so you have to bind the "something else" to another key that might tickle your fancy.. but that - unfortunately - is yet bound to another action.. etc. ad nauseam. > > > > > Oh.. and as to developers being 'whimsical' relative to > > > > enhancements, I think not.. That's exactly why I barged into > > > > your thread.. The list is really the place where you can voice > > > > an opinion.. and since this caching behavior was something that > > > > struck me as being fundamentally different from the other > > > > browser.. Not sure it's a bad thing, though.. I briefly > > > > mentioned it but Miciah has a good point.. when the server is > > > > unresponsive it's OK I guess if you explicitly ask for a > > > > reload.. Maybe less so when the reload is done on a transparent > > > > basis every time you hit the back button (eg.). > > > > > > I guess "whims" was a bad word to use. > > > > so far they haven't objected... > > How offensive, implying that we have whims! In fact, developers have > itches and occasional fancies, but none of this whim nonsense. > > > > I just wanted to explain that I understand it's open source and > > > that the developers can do what they like. > > > > I don't think they may.. or can. > > > > Whatever they may state in their disclaimers they just cannot pull > > the plug on a piece of software that has some degree of following... > > > > And in fact they very rarely do so.. one of the nice things about > > OSS is that when it happens someone else will step in.. if the > > software is worth the effort.. that is.. (?) > > Guess how ELinks got started? See <http://elinks.cz/history.html>. > The impetus for ELinks was largly that it looked like Links had been > abandoned. I read the document a few months back and something must have stuck. > > > As to *being able* to do what they like.. it's pretty much the same > > thing.. too much change that turns out to be unsatisfactory and the > > user community will just not take it.. someone forks the project.. etc. > > ELinks was forked also because Links's developer was very strict with > regard to patches. > > > .. like .. I'm a vim user/fan.. now Bram Moolenaar et al. all of a > > sudden see the light and the next version of Vim turns out to be an MS > > Word clone... how 'bout that? > > It is getting there, but at least Vim still runs on the terminal. > > > I do hope someone will implement/improve CSS rendering some time soon, > > though.. Not that I spend much time on commercial web sites.. but a > > growing number are getting hard to read. > > The developers hope for that too. However, most of them work, most of > them are students, and better CSS support requires DOM support and a box > model and stuff that all requires a lot of coding effort. We would all > like to get this done, but don't get your hopes too high. > > > Yeah.. that's how you eventually get them to pay attention.. > > > > .. moan consistently on the list with a bunch of other troublemakers > > until they really get sick of it.. > > > > OK.. fixed in CVS - GIT, I mean.. > > > > now p*ss off.. > > > > :-) > > We require reminders sometimes, but CSS is well at the tops of > everybody's minds, I do believe. We all want it, but it will be > difficult. > > > > Sure, having a discussion on this list is one way to convince them that > > > your way is the right way! (So here goes:) > > > > > > > > As for the cache issue, I think the current method is not good from a > > > usability standpoint. It sounds like he and I use ELinks in different > > > ways so he doesn't run into this problem often, plus he places a lot of > > > value on speed. I think if Mozilla or Firefox worked the same way, the > > > majority of users would be up in arms! > > > > .. interesting point.. but then they have been conditioned by years of > > IE (& Netscape) abuse in so many ways.. > > > > So that may or may not be an argument.. > > > > I found this behavior a bit disconcerting at first but after a couple of > > weeks I've grown used to it. > > > > As mentioned in an earlier post, and provided I fully understand the > > issue, this would appear to be something that can be customized in > > mozilla.. don't know about FF, though. > > I like ELinks largely because it is very fast. same here.. it is unacceptable to have to wait longer for a page to render than briefly glancing at it to locate one particular link that you will follow.. wait what feels like another eon for the next page to render.. etc. With mozilla it got to the point where I had a feeling I was spending more time waiting than actually doing something worthwhile.. when on dial-up I would put up with it thinking it was my connection.. then I went to broadband.. same sh*t.. so I thought.. must be the DNS, then.. had to switch to Elinks to realize that most of the waiting was due to mozilla's slow rendering.. > This is one of many > little things that would take away from that lovely feeling of literal > instantaneousness in response. > sums it up very nicely.. excellent wording! > However, I have found some support for the If-Modified-Since HTTP header > in the code. I'm having trouble getting to work, tho. > > > > So if I was in charge of ELinks > > > development, I'd make the Mozilla "compare automatically" (or whatever it > > > is) be the default but put in Mozilla's other settings as options. Then > > > everyone could be happy. > > > > .. and call the option something else rather than 'compare'.. So you > > compare.. OK.. and then what? > > We could call it 'Always check for updated document'. The new behaviour > would be that when the user loads a document that is in cache, ELinks > would first send a request with If-Modified-Since to the server. The > server would reply with either a 304 Not Modified, a 200 OK with the > updated document, or an error if the request was bad. In the first case, > ELinks would have wasted a little time and a tiny bit of bandwidth (new > behaviour) but saved the bandwidth that transferring the entire document > would have taken (as with aggressive caching); in the second case, > ELinks would show an updated document (new behaviour); and in the third > case, ELinks would show an error message (shouldn't normally happen if > the document was cached, unless the server gave a bad date or has some > bug to cause it to reject a request that it previously considered > valid). > > I wonder whether there are many servers that don't support > If-Modified-Since? In that case, this feature could waste a fair bit of > bandwidth with such servers, unless we did something complicated with > HEAD requests, which might be just as likely to be unimplemented. > > The standards are there, precedent is apparently there, and some code is > there in ELinks, but somebody needs to figure out how to get that code > to work. Thanks for the technical explanation. I was guessing things worked that way but it's nice to know for a fact.. especially since I had found this behavior of Elinks' rather intriguing. Thanks cga _______________________________________________ elinks-users mailing list [email protected] http://linuxfromscratch.org/mailman/listinfo/elinks-users
