On Wed, Jul 19, 2006 at 09:44:41PM -0400, cga2000 wrote: > On Wed, Jul 19, 2006 at 05:31:42PM EDT, Reid Rivenburgh wrote: > > On Wed, Jul 19, 2006 at 05:10:42PM -0400, cga2000 wrote: > > > I've also heard that the SpiderMonkey - the new mozilla has marked > > > improvements in the area. But slow rendering was only one of the > > > issues. I have switched to a keyboard-only text-mode 'desktop' - > > > interface, I should say and I am a much happier man. > > > > Nice. I don't think I could get by with text-only in my main browser.... > > FYI, I think there's a Firefox extension that is aimed at keyboard-only > > use. Never used it, though. > > I'll look it up.. Although I'm sceptical.. Microsoft did a very good job > of making gui's navigable via the keyboard but you cannot change the > fact that the gui designer was thinking *mouse* when he designed the > layout.. etc. Just and example.. in many guis I have seen you may have > to drill down three.. four.. five..? levels of dialog/popup boxes the > size of a postage stamp (some of them you'll even have to reach for that > scrollbar so you can get to what you're looking for..) before you > eventually get to the particular flag or whatever that you want to > change.. While this is perfectly suitable with the inherent slowness of > the mouse, it becomes rather annnoying when you use a considerably > faster interface like the keyboard.
This is why why have keyboard accelerators. > > > Drop the mouse man..! Charles Darwin is categorical.. You'll never > > > grow a third arm in your lifetime. > > > > Oh it's no problem, I use my tail to control the mouse! :) > > > :-) > > 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? > 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. 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. > > > 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. > 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. This is one of many little things that would take away from that lovely feeling of literal instantaneousness in response. 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. -- Miciah Masters <[EMAIL PROTECTED]> / <[EMAIL PROTECTED]> _______________________________________________ elinks-users mailing list elinks-users@linuxfromscratch.org http://linuxfromscratch.org/mailman/listinfo/elinks-users
