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

Mouse Wheel 80-90% slower then Seamonkey?

by rogerx.oss＠gmail.com

> On Thu, Feb 03, 2011 at 04:01:03PM -0900, Roger wrote: >Anybody else notice the mouse wheel is slow within Dillo? > >Comparing dillo_port1.3 to Seamonkey, dillo_port1.3 is almost 80-90% slower >compared to Seamonkey. > >Comparing dillo_port1.3 to dillo, dillo_port1.3 is slower by approx. 50%. I've found a better solution then modifying the code concerning mouse scroll speed. IMWheel http://imwheel.sourceforge.net/ file: /home/roger/.imwheelrc "^Dillo" None, Up, Button4, 25 None, Down, Button5, 25 "^GNU Screen" None, Up, Button4, 15 None, Down, Button5, 15 "^SeaMonkey" None, Up, Button4, 9 None, Down, Button5, 9 You can find your wheel/scroll buttons by using "imwheel -c" Prevent detach/daemon mode by using "imwheel -d" and use "imwheel -D" for debugging. Or use both options. I can now see the issues with different scrolls speeds between applications and the reason why one scroll speed within xorg.conf won't solve much. As such, it's an application specific issue but IMWheel solves this quite well! -- Roger http://rogerx.freeshell.org/

Sept. 26, 2011

Another occurrence of "2.2" found: doc/dillo.1

by corvid＠lavabit.com

Axel wrote: > just noticed that the manpage doc/dillo.1 still has "version 2.2" in > its headers. *removes version number*

Sept. 24, 2011

3.0.1 released [Re: release candidate for dillo-3.0.1 ready for testing]

by onepoint＠starurchin.org

corvid wrote: > It's official now :) > > http://www.dillo.org/download/dillo-3.0.1.tar.bz2 > http://www.dillo.org/download/dillo-3.0.1.tar.bz2.asc BLFS wiki page updated: http://wiki.linuxfromscratch.org/blfs/wiki/dillo3 Regards, Jeremy Henty

Sept. 24, 2011

Another occurrence of "2.2" found: doc/dillo.1

by abe＠deuxchevaux.org

Hi, just noticed that the manpage doc/dillo.1 still has "version 2.2" in its headers. Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Sept. 24, 2011

release candidate for dillo-3.0.1 ready for testing

by obeythepenguin＠gmail.com

By the way, just to clarify on FL_NORMAL_SIZE: On Windows (and modern X toolkits like GTK+ and Qt), user interface fonts are a system setting, like colors. It's not perfect by a long shot, since fonts are still hard-coded in many applications and a number of other places, but it at least provides some level of consistency. More importantly, if the fonts are too small in your applications, you can adjust it once system-wide, rather than having to tweak each individual application's settings. This is not new stuff; Windows, for example, has been doing it since at least 1995. I really miss FLTK2, which actually used the system font settings rather than hard-coding the default fonts -- which, coincidentally, don't really match anything except old Motif apps and look-alikes, and who the hell still uses Motif? But now I digress. ~Benjamin

Sept. 24, 2011

release candidate for dillo-3.0.1 ready for testing

by obeythepenguin＠gmail.com

On 9/23/11, corvid <corvid at lavabit.com> wrote: > I think I'm with Axel on not liking to waste pixels on the tabs, Take another look at this screenshot: http://dillo-win32.sourceforge.net/dillo/screenshots.php?closeup=Z02-dillo3… If there's any wasted space in that window, it's in the File menu and location bar, not in the tabs. A couple extra pixels in the tab bar height is *not* wasted space if it improves the tabs' appearance and readability; you wouldn't say books waste valuable inches with their margins, would you? > and, as for FL_NORMAL_SIZE, I'll likely commit the patch that > changes it based on font_factor, so if you have your font_factor > small, you may get your wish. (As for me, I'm happy with 14px.) If you're typing a document in a word processor and you zoom in, does the entire interface zoom with it? Of course not. The font face and size used in the user interface should be independent of the fonts used for page rendering. Of course, I suppose Unix is still a lawless wasteland, but professionally-developed modern desktop systems like Windows and OS X have guidelines for this sort of thing (and the higher-end toolkits like Qt even suggest following those guidelines, even if you don't develop for those specific platforms). Fortunately, by now I'm no stranger to patching either Dillo or FLTK... ~Benjamin

Sept. 23, 2011

release candidate for dillo-3.0.1 ready for testing

by corvid＠lavabit.com

Benjamin wrote: > maybe set FL_NORMAL_SIZE a bit smaller, since the 14px default is > frankly ridiculous.) I think I'm with Axel on not liking to waste pixels on the tabs, and, as for FL_NORMAL_SIZE, I'll likely commit the patch that changes it based on font_factor, so if you have your font_factor small, you may get your wish. (As for me, I'm happy with 14px.)

Sept. 23, 2011

3.0.1 released [Re: release candidate for dillo-3.0.1 ready for testing]

by corvid＠lavabit.com

Johannes wrote: > due to some important privacy fixes we decided to make a > bugfix release. > http://www.dillo.org/download/dillo-3.0.1-rc1.tar.bz2 > is available for download now and want's to be tested. > Please give it a try and report back. If everything goes smoothly, > this will become dillo-3.0.1.tar.bz2 on Friday. It's official now :) http://www.dillo.org/download/dillo-3.0.1.tar.bz2 http://www.dillo.org/download/dillo-3.0.1.tar.bz2.asc

Sept. 23, 2011

release candidate for dillo-3.0.1 ready for testing

by obeythepenguin＠gmail.com

On Fri, 23 Sep 2011 15:47:37 -0400, Axel Beckert <abe at deuxchevaux.org> wrote: > Ehm, I thought the screenshot was without the added four pixels as you > wrote something like making them the same height like the File menu > and on that screenshot the tabs still have less height than the File > menu. > > Kind regards, Axel No, that screenshot's with the added four pixels (which is still less than the height of the File menu on panel_size=medium). By the way, I use Dillo regularly on a laptop with an 800x600 screen. Setting small icons and panel_size=small more than makes up for a couple extra pixels on the tab bar. ~Benjamin

Sept. 23, 2011

release candidate for dillo-3.0.1 ready for testing

by abe＠deuxchevaux.org

On Fri, Sep 23, 2011 at 03:35:50PM -0400, Benjamin Johnson wrote: >> Four pixels are already quite a lot on todays "HD" screens which just >> have a screen height of 768 pixels. And quite some low-end netbooks >> just have 600 or 480 pixels screen height. There, fource pixels do >> matter. >> >> But OTOH: Why not make it configurable if we disagree? >> >>> It's hardly a dramatic change, yet it dramatically improves the tab >>> appearance and readability: >>> http://dillo-win32.sourceforge.net/dillo/screenshots.php?closeup=Z02-dillo3… >> >> Looks perfect and readable for me. > > You say it's wasting space, yet you agree it helps the readability. Ehm, I thought the screenshot was without the added four pixels as you wrote something like making them the same height like the File menu and on that screenshot the tabs still have less height than the File menu. Kind regards, Axel -- /~\ Plain Text Ribbon Campaign | Axel Beckert \ / Say No to HTML in E-Mail and News | abe at deuxchevaux.org (Mail) X See http://www.asciiribbon.org/ | abe at noone.org (Mail+Jabber) / \ I love long mails: http://email.is-not-s.ms/ | http://noone.org/abe/ (Web)

Sept. 23, 2011