- Dillo-dev - lists.mailman3.com

Close dillo with multiple tabs open

by rogutes＠googlemail.com

Benjamin Johnson (2011-09-18 13:33): <...> > Even if you're just viewing static HTML pages, a browser session is > not *itself* a static thing: it is the unique result of a long chain > of user interactions. If you close a text editor, all you lose is a > single file, which is very easy to re-open. If you close a browser, > you lose not only the open pages, but also their history, and for > dynamic pages, the interactions and form posts that generated them > -- in short, the pages' context. And that's much more difficult to > recover, even in the most sophisticated modern browsers. Add the scrolling position to this list, which applies to both, long text files and long HTML pages :) -- -- Rogut?s Sparnuotos

Sept. 18, 2011

Close dillo with multiple tabs open

by obeythepenguin＠gmail.com

On Sun, 18 Sep 2011 13:05:31 -0400, Roger <rogerx.oss at gmail.com> wrote: > You answered this one yourself. The default option for VIM on quit, is > to only > ask if it should quit when the file in the buffer has been modified. > Other > then this, if the file buffer is unmodified, no prompt before quitting is > issued. > > As such, should a browser do the same; only when forms or HTML > composer/editor > has a current editing session, or associated email composition has been > edited, > should a browser ask when to quit? The only thing likely editable > within Dillo > are bookmarks and some forms. > > When you think about it, all data being viewed within the browser is > static to > it's original location. The only information lost is the original > entered URL, > which usually can be found via Google, hence, no information is at > threat of > being lost. I beg to differ; it's no longer 1994, and a good bit of the web -- in fact, I'd dare say most of it -- is no longer static content. In the absence of anything to indicate otherwise, it's better to assume *all* information displayed in a browser could potentially be lost. A couple weeks ago, one of my professors had to take an online exam for certification. Her printer was out, so she had to send it through the department printer. Long story short, somehow the print job got lost in transmission. She'd already closed the browser, and it didn't save her session, so she had to take the entire 4+ hour exam again. Bear in mind, the page she was trying to print -- and subsequently closed out of -- didn't have any HTML forms. Basically it was just an image and some text to say she had successfully completed the exam. Granted, it was *generated* from form data, but it was not itself a "current editing session". Even if you're just viewing static HTML pages, a browser session is not *itself* a static thing: it is the unique result of a long chain of user interactions. If you close a text editor, all you lose is a single file, which is very easy to re-open. If you close a browser, you lose not only the open pages, but also their history, and for dynamic pages, the interactions and form posts that generated them -- in short, the pages' context. And that's much more difficult to recover, even in the most sophisticated modern browsers. In short, the *data* may be static, but the larger browser session is not. Don't confuse the two. ~Benjamin

Sept. 18, 2011

Close dillo with multiple tabs open

by rogerx.oss＠gmail.com

> On Sat, Sep 17, 2011 at 06:00:35PM -0400, Benjamin Johnson wrote: >On Sat, 17 Sep 2011 17:08:52 -0400, Roger <rogerx.oss at gmail.com> wrote: > >> However, how would you like a prompt on your vehicle every time you >> pressed the >> brakes? Do you really want to stop? Or, how about every time you start >> your >> vehicle and you're within an emergency situation and get, "Do you really >> want >> to start your car?" With real world applications, security of preventing >> accidental quitting is application response to users intentions. > >I don't know much about cars, but I do know it's pretty hard to >accidentally start one. And computers are, in terms of physical >interactions, much more difficult to use than most real-world objects (and >less predictable, as well). That's why usability is so tricky to get >right, and why most programs' interfaces tend to follow established >standards and conventions. > >By the way, it's worth noting that vim prompts you to prevent accidental >quitting, BSD vi prompts you to prevent accidental quitting, even freaking >*ed* prompts you to prevent accidental quitting. I find it pretty >annoying sometimes, too, but there have been many times when that prompt >has saved me from far greater frustration. You answered this one yourself. The default option for VIM on quit, is to only ask if it should quit when the file in the buffer has been modified. Other then this, if the file buffer is unmodified, no prompt before quitting is issued. As such, should a browser do the same; only when forms or HTML composer/editor has a current editing session, or associated email composition has been edited, should a browser ask when to quit? The only thing likely editable within Dillo are bookmarks and some forms. When you think about it, all data being viewed within the browser is static to it's original location. The only information lost is the original entered URL, which usually can be found via Google, hence, no information is at threat of being lost. -- Roger http://rogerx.freeshell.org/

Sept. 18, 2011

how to open links etc

by itsme_410＠yahoo.com

--- On Sun, 9/18/11, Benjamin Johnson <obeythepenguin at gmail.com> wrote: > From: Benjamin Johnson <obeythepenguin at gmail.com> > Subject: Re: [Dillo-dev] how to open links etc > To: dillo-dev at dillo.org > Date: Sunday, September 18, 2011, 10:05 AM > On Sun, 18 Sep 2011 00:48:37 -0400, > Walter Dnes <waltdnes at waltdnes.org> > wrote: > > >???Can we have 3 options? > > 1) The "out-of-the-box" default is to ask what to do > > 2) Save to disk > > 3) Specify a helper application.? Allow to > specify parameters as required. > > That's exactly what I was thinking.? Good; that > probably means neither of us is crazy.? (Or else we're > *both* crazy, but at least neither of us is crazy alone!) > > >???And for number 3; puhleeeese don't > "pull a Firefox" by de-referencing > > symlinks.? For instance... > > > > $ ll /usr/bin/abiword > > lrwxrwxrwx 1 root root 11 Sep? 3 02:53 > /usr/bin/abiword -> abiword-2.8 > > > >???When you tell Firefox to use abiword > for *.doc files, it de-references > > the symlink and uses /usr/bin/abiword-2.8.? So a > few weeks from now, an > > update upgrades me to abiword-2.9 and Firefox whines > about not being > > able to find /usr/bin/abiword-2.8 when I click on a > link to a *.doc > > file.? See also https://bugzilla.mozilla.org/show_bug.cgi?id=176486 > > Warning, some strong language from annoyed > users.? See especially > > comments 46, 47, and 48. > > What's the point of dereferencing symlinks, anyway?? > Symlinks in /usr/bin are usually there for a reason, and > dereferencing them would actually take *more* code than > not. > > I'm tempted to fire up my Unix machine and just start > coding now... and yes, I do keep an OpenBSD install and > unpatched mainline sources handy, in case anyone thinks I > only code for the one platform :-) Great!! Let me encourage you, Benjamin!! This will, of course, be a great help! Best wishes. T

Sept. 18, 2011

how to open links etc

by obeythepenguin＠gmail.com

On Sun, 18 Sep 2011 00:48:37 -0400, Walter Dnes <waltdnes at waltdnes.org> wrote: > Can we have 3 options? > 1) The "out-of-the-box" default is to ask what to do > 2) Save to disk > 3) Specify a helper application. Allow to specify parameters as > required. That's exactly what I was thinking. Good; that probably means neither of us is crazy. (Or else we're *both* crazy, but at least neither of us is crazy alone!) > And for number 3; puhleeeese don't "pull a Firefox" by de-referencing > symlinks. For instance... > > $ ll /usr/bin/abiword > lrwxrwxrwx 1 root root 11 Sep 3 02:53 /usr/bin/abiword -> abiword-2.8 > > When you tell Firefox to use abiword for *.doc files, it de-references > the symlink and uses /usr/bin/abiword-2.8. So a few weeks from now, an > update upgrades me to abiword-2.9 and Firefox whines about not being > able to find /usr/bin/abiword-2.8 when I click on a link to a *.doc > file. See also https://bugzilla.mozilla.org/show_bug.cgi?id=176486 > Warning, some strong language from annoyed users. See especially > comments 46, 47, and 48. What's the point of dereferencing symlinks, anyway? Symlinks in /usr/bin are usually there for a reason, and dereferencing them would actually take *more* code than not. I'm tempted to fire up my Unix machine and just start coding now... and yes, I do keep an OpenBSD install and unpatched mainline sources handy, in case anyone thinks I only code for the one platform :-) ~Benjamin

Sept. 18, 2011

how to open links etc

by waltdnes＠waltdnes.org

On Wed, Sep 14, 2011 at 07:34:33PM -0800, Roger wrote > >Easy solution: ask the user whether to open the file, or just save it to > >disk. > > So, the prompt saves my butt 5% of the time, the other 95% of the time I'm > harassed by a prompt like in Windows. > > IMO, configuring for the fewest clicks possible is best. And like > you said, provide a file with an option to to link in external apps if > the user so wishes. (ie mutt's $HOME/.mutt/mailcap is a good example) > > Keeping a file type pointing to null or commented, gets default > (download) action? Can we have 3 options? 1) The "out-of-the-box" default is to ask what to do 2) Save to disk 3) Specify a helper application. Allow to specify parameters as required. And for number 3; puhleeeese don't "pull a Firefox" by de-referencing symlinks. For instance... $ ll /usr/bin/abiword lrwxrwxrwx 1 root root 11 Sep 3 02:53 /usr/bin/abiword -> abiword-2.8 When you tell Firefox to use abiword for *.doc files, it de-references the symlink and uses /usr/bin/abiword-2.8. So a few weeks from now, an update upgrades me to abiword-2.9 and Firefox whines about not being able to find /usr/bin/abiword-2.8 when I click on a link to a *.doc file. See also https://bugzilla.mozilla.org/show_bug.cgi?id=176486 Warning, some strong language from annoyed users. See especially comments 46, 47, and 48. -- Walter Dnes <waltdnes at waltdnes.org>

Sept. 18, 2011

how to open links etc

by itsme_410＠yahoo.com

--- On Thu, 9/15/11, Benjamin Johnson <obeythepenguin at gmail.com> wrote: > From: Benjamin Johnson <obeythepenguin at gmail.com> > Subject: Re: [Dillo-dev] how to open links etc > To: dillo-dev at dillo.org > Date: Thursday, September 15, 2011, 1:21 PM > On Wed, 14 Sep 2011 23:34:33 -0400, > Roger <rogerx.oss at gmail.com> > wrote: > > >> On Wed, Sep 14, 2011 at 08:16:43PM -0400, Benjamin > Johnson wrote: > > > >> Easy solution: ask the user whether to open the > file, or just save it to > >> disk. > > > > So, the prompt saves my butt 5% of the time, the other > 95% of the time I'm > > harassed by a prompt like in Windows. > > > > IMO, configuring for the fewest clicks possible is > best.? And like you said, > > provide a file with an option to to link in external > apps if the user so > > wishes.? (ie mutt's $HOME/.mutt/mailcap is a good > example) > > > > Keeping a file type pointing to null or commented, > gets default (download) > > action? > > > > I didn't want to say much more without being able to > help code it, but I don't > > want to see another prompt popping-up. (ie. Dillo quit > prompt) :-/ > > Then add a "Remember this choice" option so it won't prompt > you again. > > I disagree that all prompts are automatically bad.? > After a while they do get annoying (and there should be some > way to disable them), but for new users the verbosity can be > helpful.? More importantly, it avoids surprising the > user when the program doesn't behave as expected -- it opens > instead of downloads, or vice-versa -- and of course, > different users will have different expectations for which > behavior is "correct." > > (In my own software, I always err on the side of verbosity, > no matter how annoying it is to me personally -- because as > the developer, I know how to disable it on my own machine!) > > ~Benjamin > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev Is it possible to consider providing the option on how to open links, etc.....i don't mind having it in some preferences file....i understand it may be some work, but this would certainly be very useful to have....? thanks very much!!

Sept. 18, 2011

Close dillo with multiple tabs open

by itsme_410＠yahoo.com

--- On Sat, 9/17/11, Jorge Arellano Cid <jcid at dillo.org> wrote: > From: Jorge Arellano Cid <jcid at dillo.org> > Subject: Re: [Dillo-dev] Close dillo with multiple tabs open > To: dillo-dev at dillo.org > Date: Saturday, September 17, 2011, 3:56 PM > On Sat, Sep 17, 2011 at 09:19:42AM > -0700, Globe Trotter wrote: > > > > > > --- On Sat, 9/17/11, Jorge Arellano Cid <jcid at dillo.org> > wrote: > > > > > From: Jorge Arellano Cid <jcid at dillo.org> > > > Subject: Re: [Dillo-dev] Close dillo with > multiple tabs open > > > To: dillo-dev at dillo.org > > > Date: Saturday, September 17, 2011, 12:09 PM > > > On Sat, Sep 17, 2011 at 11:20:29AM > > > +0200, Johannes Hofmann wrote: > > > > On Sat, Sep 17, 2011 at 05:04:49AM +0000, > corvid > > > wrote: > > > > > Roger wrote: > > > > > > >> > you mean, "confirm > to exit > > > prompt".? Ditto.? Rarely, if ever accidentally > > > quit. > > > > > > >> > > > > > > >> I wasn't sure what my > opinion was > > > on this at first, but now I think an > > > > > > >> option sounds > reasonable. > > > > > > > > > > > > > >Why not, if there is demand > for it and > > > the default is safe > > > > > > >(i.e.? off). > > > > > > > > > > > > Ditto. I've never accidentally > quit. > > > > > > > > > > > > Oh, I've used File > Quit once > in a > > > while, but with that many key sequences or > > > > > > clicks, it's tough to > accidentally > > > quit.? Also, few options under the File > > > > > > menu.? Most times, I just halt > -p. > > > > > > > > > > Just occurred to me that everyone's > been saying > > > that they don't need this > > > > > dialog box. I checked firefox and it > doesn't warn > > > when quitting. Maybe we > > > > > don't need it at all. > > > > > > > > Safari has it and given the fact that we > only recently > > > switched from > > > > Ctrl-Q to Crtl-W for closing tabs, people > might > > > accidentally hit > > > > Ctrl-Q when they want to close just the tab. > It > > > happend to me at > > > > least. So for now I would keep it. > > > > > > ? Same for me. > > > > > > ? Now, if somebody wants to add a preference for > that, > > > could be, > > > but the default should be to ask. > > > > I see no harm in this: put in a default but make it > configurable. > >? While I don't have the urge to use ctrl-q much, > I am still stumped why alt-q > >? does? not work now to close dillo, as I had > conditioned myself to. i usually > > immediately rebound and go with the new action.... > > ? ctrl-q is considered more used across apps. (that > made it the default) > > ? You can set alt-q in keysrc if you want. Thanks, i was not complaining, just saying that my mind had become conditioned to using alt-q when exiting dillo (only)....

Sept. 18, 2011

Close dillo with multiple tabs open

by obeythepenguin＠gmail.com

On Sat, 17 Sep 2011 17:08:52 -0400, Roger <rogerx.oss at gmail.com> wrote: > However, how would you like a prompt on your vehicle every time you > pressed the > brakes? Do you really want to stop? Or, how about every time you start > your > vehicle and you're within an emergency situation and get, "Do you really > want > to start your car?" With real world applications, security of preventing > accidental quitting is application response to users intentions. I don't know much about cars, but I do know it's pretty hard to accidentally start one. And computers are, in terms of physical interactions, much more difficult to use than most real-world objects (and less predictable, as well). That's why usability is so tricky to get right, and why most programs' interfaces tend to follow established standards and conventions. By the way, it's worth noting that vim prompts you to prevent accidental quitting, BSD vi prompts you to prevent accidental quitting, even freaking *ed* prompts you to prevent accidental quitting. I find it pretty annoying sometimes, too, but there have been many times when that prompt has saved me from far greater frustration. ~Benjamin

Sept. 17, 2011

Close dillo with multiple tabs open

by rogerx.oss＠gmail.com

>Safari has it and given the fact that we only recently switched from >Ctrl-Q to Crtl-W for closing tabs, people might accidentally hit >Ctrl-Q when they want to close just the tab. It happend to me at >least. So for now I would keep it. Elinks uses CTRL-C to close tabs. It's kind of tough to think CTRL-Q closes a tab to begin with. Mistake for "close qab" just doesn't sound right to begin with. However, if CTRL-C was mapped to quit, aka "close application", well that would be confusing. Or if "CTRL-Q" were on a keyboard layout next to the "CTRL-C" But still, ELinks does ask to quit before quiting. But this is because I keep typing ":q" (VIM quit), and 'q' is mapped to quit in ELinks. (But this is user error, as I start thinking I'm within VIM at times due to all the console text.) So, some good examples when there's no conflict, and some examples where there is a conflict. Really, when asking, you're just trying to prevent user error. However, how would you like a prompt on your vehicle every time you pressed the brakes? Do you really want to stop? Or, how about every time you start your vehicle and you're within an emergency situation and get, "Do you really want to start your car?" With real world applications, security of preventing accidental quitting is application response to users intentions. <shrugs> I'm sure this has been debated quite a bit, and with Windows, I get so many prompts that I become non-productive & frustrated. -- Roger http://rogerx.freeshell.org/

Sept. 17, 2011