October 2011 - Dillo-dev - lists.mailman3.com

Horizontal scrolling with mouse buttons
by jcid＠dillo.org Aug. 7, 2012

Aug. 7, 2012

On Mon, Aug 15, 2011 at 02:18:33PM -0400, saulgoode(a)flashingtwelve.brickfilms.com wrote: > Quoting Jorge Arellano Cid <jcid(a)dillo.org>: > > > Please try dillo-3.0-pre, following these directions [1]. > >Then report back how it goes. > > > > [1] http://www.dillo.org/source.html > > With that build, the horizontal scroll buttons are inactive. To my > mind this is satisfactory behavior as it does not interfere with the > vertical scrolling of the mouse wheel (previously the only way to > restore vertical wheel scrolling was to restart the program). Good! This looks like an issue with fltk-1.3. FWIW, inside fltk-1.3 src/Fl_x.cxx:1443, there's no code to handle those buttons. Having something like the following may be worth a try (if you're a coder): if (xevent.xbutton.button == Button4) { Fl::e_dy = -1; // Up event = FL_MOUSEWHEEL; } else if (xevent.xbutton.button == Button5) { Fl::e_dy = +1; // Down event = FL_MOUSEWHEEL; + } else if (xevent.xbutton.button == Button6) { + Fl::e_dx = -1; // Left + event = FL_MOUSEWHEEL; + } else if (xevent.xbutton.button == Button7) { + Fl::e_dx = +1; // Right + event = FL_MOUSEWHEEL; } else { Fl::e_state |= (FL_BUTTON1 << (xevent.xbutton.button-1)); event = FL_PUSH; checkdouble(); } > Thank you for your response. :) -- Cheers Jorge.-

3 2

use C locale for LC_CTYPE
by corvid＠lavabit.com Nov. 10, 2011

Nov. 10, 2011

If you've been following along on fltk.general, you'll know we've been in discussion over some unpleasantness regarding Turkic locales and strcasecmp/toupper/tolower where 'i' and 'I' are different letters. ( http://en.wikipedia.org/wiki/Dotted_and_dotless_I ) The typical solution is to make sort of ASCIIfied versions where you force i<->I. I think that, for our purposes, we can just use the ordinary POSIX locale and save ourselves the trouble. To see this behaviour: export LC_ALL=tr_TR and then look at: these letters should be big This text should be italic

4 28

[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