- Dillo-dev - lists.mailman3.com

[patch]: bind Ctrl-{PageUp, PageDown} to {lleft, right}-tab
by obeythepenguin＠gmail.com Oct. 31, 2011

Oct. 31, 2011

Jorge wrote: > > Jeremy Henty wrote: > > >> > Another case of "let's be like the other browsers". See: > > >> > > http://www.google.com/support/forum/p/Chrome/thread?tid=16c23e5647c48367&hl… > ... yeah some term emulators default to Ctrl+{PgUp,PgDn} > It looks OK to me. > Comments? > -- Cheers > Jorge.- I don't have a problem with the patch, but I do question the reasoning. Dillo is a web browser, so most users will logically expect it to behave like other web browsers they have used. Following Chrome, for instance, is quite logical since it's a well-known browser many users are probably familiar with. On the other hand, most users *don't* expect Dillo to behave like a terminal emulator, which is a different kind of program entirely. It's the same thing as with the input box keys. At best it's mildly confusing, and if it conflicts with the expected behavior, it can cause a great deal of frustration. Frustration hurts usability and drives away potential users. So let's keep it if Chrome does it, but I wouldn't worry about Konsole and GNOME Terminal and Terminal.app and mxterm and aterm and GNU screen and whatever else people are using to run /bin/sh. If you really think Dillo should act like a Unix shell, you have your personal keysrc. Just my two cents, ~Benjamin

4 3

view src
by corvid＠lavabit.com Oct. 30, 2011

Oct. 30, 2011

I viewed source, edited the page, reloaded, and view source keeps showing me the old source. I thought this used to work.

3 7

[patch]: bind Ctrl-{PageUp, PageDown} to {left, right}-tab
by onepoint＠starurchin.org Oct. 30, 2011

Oct. 30, 2011

Another case of "let's be like the other browsers". See: http://www.google.com/support/forum/p/Chrome/thread?tid=16c23e5647c48367&hl… This will require an update to the help page on the web site. Congratulations on the keysrc code, it was very easy to understand and modify. Next I was going to look at binding Ctrl-[1-8] to "go to the <n>-th tab" and Ctrl-9 to "go to the rightmost tab" for the same reasons as this patch - the other browsers do it. Comments? Regards, Jeremy Henty

3 4

Mailing list outage?
by onepoint＠starurchin.org Oct. 28, 2011

Oct. 28, 2011

Did the mailing lists go down this week? A message I sent on Monday has only just appeared. It seems to be working OK now. Regards, Jeremy Henty

3 3

suggest next page feature
by itsme_410＠yahoo.com Oct. 27, 2011

Oct. 27, 2011

midori has a nice feature which really would be a nice addition to dillo. From the midori webpage: "Many people don't know about a nitfy feature in Midori, which is going Forward to the next page. From now on you can hit Space at the bottom of a page to go to the next page, just like in a mail client. Note that this depends on the page. Pages with links labelled "Next" or similar will be recognized. Ideally ?rel="next"? is used in the HTML so Midori knows what the next page is." It would be nice if dillo had it too, on low-end systems where using mouse is at a premium. Alternatively, can keybindings be made to mimic this (and similar features)? Many thanks, T

1 0

[test]: Am I getting through?
by onepoint＠starurchin.org Oct. 26, 2011

Oct. 26, 2011

Test, please ignore. I thought I emailed the list on Monday and nothing has appeared so I am just checking it still works for me. Regards, Jeremy Henty

1 0

Dillo on Cygwin/X
by obeythepenguin＠gmail.com Oct. 22, 2011

Oct. 22, 2011

I should probably resist the bait here, but... Jorge wrote: > > Is there any interest to support this target on a source code basis? > I'd like to have a way to run dillo on Win*, but not sacrificing > current portability [2], nor having to write a completely different > code path for Win*. I'll just say patches 2, 6, 7, 8, 9, 11, and maybe 14 will get you 85% of that, without sacrificing *any* existing portability, and with only minimal changes to the existing Dillo code: http://dillo-win32.sourceforge.net/dillo/dillo3-patches.php Patches 7 and 8, the sockets abstraction layer, are the big ones; the rest of them are small tweaks. The remaining 29 patches are things like UI tweaks and moving DPIs back into the browser, which you are free to leave out. Oh, and I do regularly test my code on Unix, if you're wondering: http://obeythepenguin.users.sourceforge.net/openbsd/files/screenshot.png http://dillo-win32.sourceforge.net/dillo/screenshots.php?closeup=unix-openb… > An API that works in both would be a good solution. For instance, > we know that some dpi servers already work in Win* (with cygwin). > There may even be a way to achieve it natively, and I seem to > recall the FLTK3 team had this in mind. It would be more than > worth to ask them about their plans on the subject. > Again, as I'm not a Win* developer, I don't qualify > to lead this effort on the Win* side. > HTH. Well, frankly I don't think most of the current DPIs belong outside the browser in the first place, as I've explained here: http://dillo-win32.sourceforge.net/dillo/dpi.php (If I have any technical details about the implementation wrong, please let me know.) I have started work on a native Windows DPI patch if you'd like to see it, though I'm afraid it's not functional yet, and it's *very* ugly code. Regards, ~Benjamin

1 0

Address bar keys (bug #1012)
by obeythepenguin＠gmail.com Oct. 22, 2011

Oct. 22, 2011

Rogutes wrote: > Benjamin Johnson (2011-10-21 00:03): > > >> >Having it consistent over all text inputs and configurable > > >via> >keysrc sounds reasonable to me. I don't know the keysrc > > >details> >though, so I might miss something.> >Cheers,> > > >>JohannesHaving input/insert mode and macros in keysrc would be > > >interesting, if nottoo complex. > Look how indecipherable your quotations are. Sorry about that. My mail client (Opera Mail) seems to mangle things from time to time, but frankly I'm not too sure why. > Other than that, I have to agree with most points, because you seem to > have done more homework than I have. I lose sleep over this sort of thing. It's the little things that make or break a user interface; big problems aren't as bad, because if they're obvious enough you can learn to work around them. (Not that I mean that to imply anything about Dillo's UI!) > Shift-{Left,Right} doesn't do anything here and I would expect it to > select text [I guess conventionally]. > Ctrl-A selects all text in other FLTK apps, so dillo must have most > input > boxes covered with the CustInput class. > ---- Rogut?s Sparnuotos Looking through the code, there appear to be three(!) different classes: - CustInput in src/ui.cc - CustInput2 in src/dialog.cc - CustInput3 in dw/fltkui.cc Thanks for mentioning that -- I hadn't noticed the other two. Somehow, it seems just a little excessive... ~Benjamin

1 0

mailing list trivia (Re: [REPOST] Re: Dillo Win32
by rogerx.oss＠gmail.com Oct. 21, 2011

Oct. 21, 2011

Thoughts) Reply-To: In-Reply-To: <20111021073336.GA12742 at local> > On Fri, Oct 21, 2011 at 07:33:36AM +0000, corvid wrote: > >I see what the problem was now with the strange little chunk of a msg. >When Roger wrote: >> [...] >> required either. >> >> From here, mintty's code is likely an excellent resource to figure how they >> worked around the Window's issues with mouse copy & pasting. > >Pipermail saw a blank line followed by "From ", and thought "new msg!" and >got all confused when generating the archive. IIRC, mail(1) always had a hard >time with that one as well. This is explicitly Google's fault then. I use mutt with gmail, and I find GMail likes blank lines on copy & paste. There might be something within my muttrc causing this too, but I doubt it as I never seen so many problems with blank lines and extended long lines after pasting within a Mutt session. (Only using Mutt with GMail IMAP have I seen this! Never in an ordinary local Mutt session. I also use VIM as the editor: set editor = '/usr/bin/vim --noplugin +/^$' # default: '(empty)' I think it happens during the IMAP session, IMAP/terminal are interpretting newlines incorrectly on paste. As to why this occurred within the From: field makes this even more strange as copy/paste would likely not have occurred there. Personally, I consider this a GMail bug. -- Roger http://rogerx.freeshell.org/

1 0

Address bar keys (bug #1012)
by obeythepenguin＠gmail.com Oct. 21, 2011

Oct. 21, 2011

Rogutes Sparnuotos wrote: > Benjamin Johnson (2011-10-20 15:56):How should dillo behave when a user > binds Ctrl-A? It should perform the action bound to Ctrl-A, of course. Just to clarify, the only thing I want to change is the key bindings when the user is typing in the URL input box. Specifically, I'm talking about the CustInput::handle() function in ui.cc: http://hg.dillo.org/dillo/file/e82663b3c477/src/ui.cc#l96 Dillo intercepts several key bindings normally handled by the input box itself. The problem is, some of these key bindings conventionally have different meanings than Dillo assigns (see below). Not all the bindings are bad. I'd keep the binding for Ctrl-L, for example, which rehighlights the input text when you're typing in the box. That's pretty intuitive, and matches the behavior of other browsers. On the other hand, most users aren't familiar with Unix command line bindings, and even those who are usually don't expect that behavior in a graphical application such as Dillo. It might be convenient, but usability isn't always about convenience; it's about doing what users *expect*. Basically, a good interface is one an unwitting mere mortal could figure out without ever reading the manual, or even thinking too hard. Joel Spolsky explains it a lot better than I do: http://www.joelonsoftware.com/uibook/fog0000000249.html > > >Having it consistent over all text inputs and configurable via> > >keysrc sounds reasonable to me. I don't know the keysrc details> > >though, so I might miss something.> >Cheers,> >JohannesHaving > input/insert mode and macros in keysrc would be interesting, if nottoo > complex. It would be interesting, but it certainly would be complex, and I'm not sure the benefits outweigh the costs. I suspect most users are probably fine with just the basic key bindings FLTK already provides. There's also the matter of consistency, not just within Dillo, but between Dillo and other FLTK applications. Part of the advantage of using a toolkit *is* the consistency; that was the original motivation behind KDE, for example. > > I was thinking just a simple boolean option in dillorc -- and turn> it > OFF by default (i.e., no Unix keys), because it's not typical GUI> > behavior, and anyone who wants it on can quite easily set it in his> or > her own dillorc.Would be a strange dillorc option. A real patch would > implement this inkeysrc :) Hard-coding is much stranger than either of those, and much uglier, too. The dillorc option would actually make sense here, because these particular bindings usually go together as a group (it seems weird to do the Unix Ctrl-A, but not the others). Though it would make more sense still just to leave well enough alone, since there's no real need to change the input box's behavior. > Somehow I failed to notice that Ctrl-A for select all is "typical GUI > behavior", perhaps I am not using GUIs enough... > [...snip...] >Here, Ctrl-A goes to the beginning of the line in all the input boxes > ("find text", "web search", <input> in forms). Ctrl-A is conventionally used for select all, and at least on Windows, FLTK binds it to select all in input boxes. It may be that FLTK uses the Unix bindings (Ctrl-A for beginning of line, Ctrl-E for end, etc.) on those platforms, in which case Dillo's hard-coding that behavior is pointless and redundant. I haven't booted into Unix in a while, so offhand I haven't checked. Now, I know there will likely never be Windows support in mainline Dillo, and so you're probably wondering why Windows' key bindings should matter to you. While Unix doesn't have any formal standards for graphical user interface design -- indeed, the X Window System was deliberately designed that way -- most toolkits tend to follow what Windows does. Windows has explicit formal standards for command names, menu layouts, shortcut keys, etc., and not only are they standardized (at least on that platform), they're also well known since roughly 97% of desktop computer users run a Windows operating system. (Microsoft also helped design Motif, if anyone remembers that -- which is kind of weird for me to say, since I was roughly two years old at the time. Moving on...) For reference, here's FLTK's human interface guidelines, which borrow "common elements from the CDE/Motif, GNOME, KDE, MacOS, and Windows environments": http://www.fltk.org/hig.php And here's a list of standard accelerator keys from Qt's documentation, which explicitly recommends following Microsoft's recommendations: http://doc.qt.nokia.com/5.0-snapshot/accelerators.html To get back on topic, what does all this mean for Dillo? My own opinion is, the toolkit designers put a lot of thought into this stuff, and probably know more about how their widgets should behave than you and I do. So personally, I don't think we should override that behavior at all unless there's a really good reason to do so. > > Although I will add, the Shift-{Left,Right} bindings in the address> > bar *have* to go. They're fine elsewhere, if a bit quirky, but in> the > address bar they interfere with text selection. Ctrl-Tab and> > Ctrl-Shift-Tab are much more logical and convenient, anyway.> ~Benjamin > Are we using different versions of dillo? Shift-{Left,Right} doesn't do > anything here. I'm talking about this block of code right here: http://hg.dillo.org/dillo/file/e82663b3c477/src/ui.cc#l117 Pressing Shift-{Left,Right} in the address bar moves between tabs, rather than selecting text as expected. (Maybe something left over from dillo2?) > For the arguments sake, how would having to press Ctrl-Shift-Tab be more > "logical and convenient" than Shift-Left? It's a matter of taste (habit). > In my opinion, both bindings have a disadvantage: Ctrl-Shift-Tab is > difficult for the fingers, Shift-Left is unusual to most people. That's > why it is configurable, isn't it?---- Rogut s Sparnuotos Well, Ctrl-Tab's nice because of the obvious mnemonic; because it's really easy to type; and (you can probably guess what's coming) because it's familiar, since lots of other browsers use it. In contrast, the Shift-{Left,Right} keys are much harder to type, especially on a cramped laptop keyboard where your fingers are right on top of each other. And of course, it's a bit weird because I (and probably most users) associate those keys with "select text," not "change tabs." Basically, what all this boils down to is that consistency is key. Yes, it may be the hobgoblin of little minds, but when faced with an unfamiliar interface, *every* user has a little mind. So anyway, there's my rant for tonight. :-) Regards & cheers, ~Benjamin

2 1