- Dillo-dev - lists.mailman3.com

patch: prefs.vw_fontname as fltk ui's default font

by jcid＠dillo.org

On Wed, Oct 22, 2008 at 05:27:42PM +0200, Johannes Hofmann wrote: > On Wed, Oct 22, 2008 at 02:27:23PM +0000, corvid wrote: > > I was changing the font in a few more places that > > can take arbitrary user text -- and then having > > to change it for neighbouring things so that > > the difference isn't too jarring -- and I reached > > the point where it seemed like it may be best > > just to change the font for everything. > > > > I like it! > We could also remove the places where the font has been set already. Committed. > PS: In case someone needs it we could add a ui font option in dillorc > and default to fw_fontname. An ui_font_factor may be necessary. More in a next post... -- Cheers Jorge.-

Nov. 10, 2008

patch: click elsewhere on page, fltk widget loses focus

by jcid＠dillo.org

On Sun, Oct 19, 2008 at 12:33:05PM +0000, corvid wrote: > {my usual dw disclaimer}, but it's been working just fine so far. Committed. -- Cheers Jorge.-

Nov. 10, 2008

Greetings! -- With Patches :-)

by corvid＠lavabit.com

Jon wrote: > "corvid" wrote: > > Jon wrote: > Also, there's no mention on "MList.html" on if we're supposed to reply > to sender as well as the mailing list, or just reply to the list? The convention is just to send to the list. > > > The above patch does not take into consideration font size, so the > > > result can be microscopic/unreadable fonts. I've added the code to > > > scale the font in the same way as you scale other fonts in dillo. > > > > I had considered it, but didn't know whether I should. I ended up > > leaving it alone, reasoning that at least it would be no worse than > > before. Why was it causing them to be microscopic? > > It's a resolution issue. A 14 point font on *my* system is microscopic > and the cause is running extremely high resolutions. Okay, so it was already microscopic. I thought maybe I had made things worse somehow. > With GTK, you can control many aspects of the toolkit such as font > names/sizes on all applications through the system-wide or > user-level .gtkrc files. I wonder whether this is why dillo has historically used prefs.font_factor instead of a prefs.fontsize (where FontSizes in html.cc would be generated from it).

Nov. 10, 2008

Greetings! -- With Patches :-)

by list-jcr＠designtools.org

First of all, sorry about the long lines. I'm working on a fresh OS install with an entirely new (to me) email client. With luck, I should have it configured properly now. Also, there's no mention on "MList.html" on if we're supposed to reply to sender as well as the mailing list, or just reply to the list? On Sun, 9 Nov 2008 22:34:42 +0000 "corvid" <corvid(a)lavabit.com> wrote: > Jon wrote: > > I guess the best way to show up on a development list is with > > patches, > > Yes! People who arrive with "I want to help!" but without patches > rarely ever show up again. > There's a big difference between wanting to help and helping. :-) > > There was no mention on the site about the preferred diff format > > It's mentioned in developer.html and cvs.html. > I blatantly missed it, twice. Unfortunately, I've run out of good excuses today, so you'll need to chalk up the mistake to not paying enough attention. I will admit that while reading cvs.html, I questioned, and to a degree, discounted, the instructions given since (to me) it makes little sense to maintain multiple copies of the source tree. > > The first is to fix an over-sight in the following post/patch > > posted to this mailing list: > > http://article.gmane.org/gmane.comp.web.dillo.devel/6248 > > > > The above patch does not take into consideration font size, so the > > result can be microscopic/unreadable fonts. I've added the code to > > scale the font in the same way as you scale other fonts in dillo. > > I had considered it, but didn't know whether I should. I ended up > leaving it alone, reasoning that at least it would be no worse than > before. Why was it causing them to be microscopic? It's a resolution issue. A 14 point font on *my* system is microscopic and the cause is running extremely high resolutions. If you run really high resolutions (i.e. greater than 1600x1000, 1600,1280), finding microscopic fonts on some applications is a partially self-inflicted wound, but the real cause is developers not realizing they have no control over display hardware, instaled fonts, or system configurations. --Web site developers are absolutely notorious for this mistake, but applications developers also make it. It was a pleasure to see dillo handles the web page font size problem by providing scaling of fonts. Of course, every application will need a "default" font and "default" font size, but both font and size must be configurable by the user or the program will be unusable on many systems. Dillo is no exception, uses a default font size of 14 points, and worse, it's hard coded in a number of places in the source. I'll look into this as time allows. There are also similar font size issues with the "X of Y images," "X KB" size, and the labels of tabs, since all of them use fonts *smaller* than 14 points. I'll try to look into them as well. Though some would claim that fashion is my only conscience, :-) improving the font handling in dillo will make sure the program is usable on a much wider number of system types and configurations. Also, font handling is actually a very important issue for the visually impaired due to their use of screen readers (magnifiers), and specialized hardware. With GTK, you can control many aspects of the toolkit such as font names/sizes on all applications through the system-wide or user-level .gtkrc files. If there is a user/system equivalent for controlling FLTK globally, I haven't found it yet. --If you know of something similar for FLTK, please drop-kick me in the direction of the proper documentation. :-) Kind Regards, Jon -- J.C. Roberts

Nov. 10, 2008

Greetings! -- With Patches :-)

by corvid＠lavabit.com

Jon wrote: > I guess the best way to show up on a development list is with patches, Yes! People who arrive with "I want to help!" but without patches rarely ever show up again. > There was no mention on the site about the preferred diff format It's mentioned in developer.html and cvs.html. > The first is to fix an over-sight in the following post/patch posted to this mailing list: > http://article.gmane.org/gmane.comp.web.dillo.devel/6248 > > The above patch does not take into consideration font size, so the result can be microscopic/unreadable fonts. I've added the code to scale the font in the same way as you scale other fonts in dillo. I had considered it, but didn't know whether I should. I ended up leaving it alone, reasoning that at least it would be no worse than before. Why was it causing them to be microscopic?

Nov. 9, 2008

Greetings! -- With Patches :-)

by list-jcr＠designtools.org

Hi list, I guess the best way to show up on a development list is with patches, so I've attached two of them. The diffs were created against cvs with: $ cd /home/jcr/dillo-src/dillo2 $ cvs -d$CVS_DILLO diff -u There was no mention on the site about the preferred diff format, but since I found a few patches in the list archives using "universal" I figured it was the safest bet. Though I've read the docs on dillo.org about submitting bug reports first, and then patches, the first of the patches below is to a feature that has not yet been committed. The first is to fix an over-sight in the following post/patch posted to this mailing list: http://article.gmane.org/gmane.comp.web.dillo.devel/6248 The above patch does not take into consideration font size, so the result can be microscopic/unreadable fonts. I've added the code to scale the font in the same way as you scale other fonts in dillo. Though I've read enough of the dillo docs and code to grasp the basics of formatting, I'm unsure if my formatting of the continuation (split line) is "correct" according to your standards. There are other places in the dillo UI where font handling is still incorrect and can result in unreadable fonts. Some of this is the fault of fltk, since as far as I know there is no ~/.gtkrc equivalent to set defaults for the tool kit. With luck, I'll find and fix them. The second patch is for BUG #832 --If I read things correctly, I'm supposed to file a bug report first, assign it to myself, and then send in patches. Unfortunately, I screwed up pasting my email address in the "submitter" section due to the fact that dillo doesn't actually copy selected text in a form (i.e. with the select/paste of the plain old X Window System). If you want to correct the submitter on the bug to my email address, it would be appreciated. There was no way I could correct it myself. On all popup menus in dillo, you have a non-typical and non-functional "label" (or better said "title") on the displayed popup menu. This was my first adventute into fltk, but according to the fltk2 docs, if you set the "label" of the popup menu to NULL, the "label" will not be shown. You can do it one of two ways, (1) setting the lable to NULL in the instantiation of the class or (2) using the ->label() member function to set the label to NULL. I opted for the former because it's more clean than the latter. Though there were "Accelerator" key bindings in the labels (such as "&PAGE OPTIONS" to get enable win32 meun-ish "<ALT>-P" activation), they don't actually work since the popup menu type ("POPUP123") means they are completely hidden until activated by the mouse buttons. There is still a popup menu placement issue (annoyance) with the Bug Meter when running dillo in full screen (or to the bottom edge of your screen) but it seems to be caused by the fltk "remember last selected" option. It does not properly realize the bottom edge of the screen/window, so some popup menu options are off-screen and you need a mouse-wheel movement to access them. Anyhow, I hope this helps. Kind Regards, Jon Index: src/dillo.cc =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/src/dillo.cc,v retrieving revision 1.15 diff -u -r1.15 dillo.cc --- src/dillo.cc 10 Oct 2008 20:39:34 -0000 1.15 +++ src/dillo.cc 9 Nov 2008 19:43:45 -0000 @@ -21,9 +21,10 @@ #include <stdio.h> #include <unistd.h> #include <stdlib.h> +#include <math.h> /* for rint() */ #include <time.h> #include <signal.h> - +#include <fltk/Font.h> #include <fltk/Window.h> #include <fltk/TabGroup.h> #include <fltk/run.h> @@ -108,6 +109,16 @@ // WORKAROUND: sometimes the default pager triggers redraw storms fltk::TabGroup::default_pager(fltk::PAGER_SHRINK); + // Fix UI Fonts + fltk::Font *dfont = fltk::font(prefs.vw_fontname, 0); + if (dfont) { + fltk::Widget::default_style->textfont(dfont); + fltk::Widget::default_style->textsize( + (int) rint(14.0 * prefs.font_factor)); + fltk::Widget::default_style->labelfont(dfont); + } + + // Create a new UI/bw pair BrowserWindow *bw = a_UIcmd_browser_window_new(0, 0, NULL); Index: src/menu.cc =================================================================== RCS file: /sfhome/cvs/dillo/dillo2/src/menu.cc,v retrieving revision 1.23 diff -u -r1.23 menu.cc --- src/menu.cc 22 Oct 2008 18:05:38 -0000 1.23 +++ src/menu.cc 9 Nov 2008 19:43:46 -0000 @@ -308,7 +308,7 @@ if (!pm) { Item *i; - pm = new PopupMenu(0,0,0,0,"&PAGE OPTIONS"); + pm = new PopupMenu(0,0,0,0,NULL); pm->begin(); i = new Item("View page Source"); i->callback(Menu_view_page_source_cb); @@ -360,7 +360,7 @@ popup_url = a_Url_dup(url); if (!pm) { Item *i; - pm = new PopupMenu(0,0,0,0,"&LINK OPTIONS"); + pm = new PopupMenu(0,0,0,0,NULL); //pm->callback(Menu_link_cb, url); pm->begin(); i = new Item("Open Link in New Window"); @@ -404,7 +404,7 @@ if (!pm) { Item *i; - pm = new PopupMenu(0,0,0,0,"&IMAGE OPTIONS"); + pm = new PopupMenu(0,0,0,0,NULL); pm->begin(); i = new Item("Isolate Image"); i->callback(Menu_open_url_cb); @@ -478,10 +478,10 @@ new Divider(); i = new Item("Exit Dillo", ALT+'q', filemenu_cb, (void*)"ed"); pm->type(PopupMenu::POPUP123); + pm->label(wid->visible() ? NULL : "File"); pm->end(); } - pm->label(wid->visible() ? NULL : "File"); a_Timeout_add(0.0, Menu_popup_cb2, (void *)pm); } @@ -498,7 +498,7 @@ popup_url = a_Url_dup(url); if (!pm) { Item *i; - pm = new PopupMenu(0,0,0,0,"&BUG METER OPTIONS"); + pm = new PopupMenu(0,0,0,0,NULL); pm->begin(); i = new Item("Validate URL with W3C"); i->callback(Menu_bugmeter_validate_w3c_cb); @@ -536,9 +536,9 @@ dFree(history_list); if (direction == -1) { - pm = new PopupMenu(0,0,0,0, "&PREVIOUS PAGES"); + pm = new PopupMenu(0,0,0,0,NULL); } else { - pm = new PopupMenu(0,0,0,0, "&FOLLOWING PAGES"); + pm = new PopupMenu(0,0,0,0,NULL); } // Get a list of URLs for this popup

Nov. 9, 2008

Feature Request

by Beartooth＠swva.net

On Sun, 9 Nov 2008, Jorge Arellano Cid wrote: >> I don't thing it will be that hard to get FLTK & Dillo2 into >> Fedora, the thing is that no one did it till now :). (And I ma >> pretty busy at work & uni :) ). > > Thanks a lot for the explanation! > > Although it may be difficult to get a FLTK2 package in the distro > because FLTK2 doesn't have a stable release yet. I mean, if > policies mandate not to include alpha or beta libraries, we're > out... > > It'd be good to know this (for Fedora, Ubuntu and Debian at > least). That way we can ask the FLTK team about their schedule > plans. I hate to be taking up so much time from people I know are working so hard already, but let me ask just one more : should I be taking this up with Alpine people? Or is one of you going to do that? (You could certainly do it a lot better.) Or have you determined that the trouble is in Fedora and not in Alpine? -- Beartooth Oldfart, Double Retiree, Neo-Redneck, Linux Convert Remember, I have precious little idea what I am talking about.

Nov. 9, 2008

Feature Request

by Beartooth＠swva.net

On Sun, 9 Nov 2008, Andreas Kemnade wrote: > The interesting question here is which 0.8.6? the official one or > the inofficial dillo-i18n one? At least debian does not ship the > official one. If that's about the dillo-i18n stuff (and not > reproducable with official dillo), then the problem should go to > the corresponding team. Definitely the official. Fedora offers both, and I always choose against the one with the funny name -- one more topic that life is too short to learn all about. -- Beartooth Oldfart, Double Retiree, Neo-Redneck, Linux Convert Remember, I have precious little idea what I am talking about.

Nov. 9, 2008

Feature Request

by Beartooth＠swva.net

On Sun, 9 Nov 2008, Johannes Hofmann wrote: >> I run Alpine 2.0; it is set to launch the default browser, which is >> dillo -- and URLs in emails are what I use a default browser for. >> >> Does this mean something in my Alpine settings (and my Pine 4.64 >> settings, which it took over) is wrong? My Fedora default browser setting >> is simply "dillo %s"; my Alpine setting is something I'll have to dig >> for, as it's buried way deep. > > I don't know what Alpine exactly does, but if I do > dillo google.com > on the command line, it works fine with both dillo 2.0 and 0.8.6. Yes, that looked normal; here, fwiw, are the messages : [btth@Hbsk2 ~]$ dillo google.com Gtk-WARNING **: Failed to load module "libgnomebreakpad.so": libgnomebreakpad.so: cannot open shared object file: No such file or directory Nav_open_url: Url=>about:splash< Nav_open_url: Url=>http://google.com< Type check: [Srv: text/html Det: text/html] Type check: [Srv: text/html; charset=UTF-8 Det: text/html] Nav_open_url: Url=>http://www.google.com/< Type check: [Srv: text/html; charset=ISO-8859-1 Det: text/html] Type check: [Srv: image/gif Det: image/gif] Dillo: normal exit! [btth@Hbsk2 ~]$ -- Beartooth Oldfart, Double Retiree, Neo-Redneck, Linux Convert Remember, I have precious little idea what I am talking about.

Nov. 9, 2008

Feature Request

by jcid＠dillo.org

On Sun, Nov 09, 2008 at 01:12:01PM +0100, Michal Nowak wrote: > Jorge Arellano Cid wrote: >> On Sat, Nov 08, 2008 at 10:58:43PM +0100, Michal Nowak wrote: >>> me at swva wrote: >>>> I think I'm being unclear, in two ways. >>>> >>>>>> Just to check, I did this as root : >>>>>> >>>>>> [root@Hbsk2 btth]# rpm -q dillo >>>>>> dillo-0.8.6-7.fc9.i386 >>>>>> [root@Hbsk2 btth]# yum update dillo >>>> ^^^^^^^^^^^^^^^^ >>>>>> Loaded plugins: refresh-packagekit >>>>>> updates-newkey | 2.3 kB 00:00 >>>>>> updates | 2.6 kB 00:00 >>>>>> fedora | 2.4 kB 00:00 >>>>>> Setting up Update Process >>>>>> No Packages marked for Update >>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>>>>> [root@Hbsk2 btth]# >>>> On Sat, 8 Nov 2008, Johannes Hofmann wrote: >>>> >>>>> dillo-0.8.6 is no longer supported and you should consider to >>>>> upgrade to dillo-2.0. >>>>> But nevertheless for me it also works with dillo-0.8.6. >>>> For those who run other OSs, what the emphasized lines mean is >>>> the 0.8.6 is what Fedora has, period. (I run F9, the latest >>>> release.) Any idea why it's so far behind?? I didn't realize 1.0 >>>> had become official, let alone 2.0 >>>> >>> That's life. In Fedora, nor even Rawhide, isn't Dillo v2.0. Two reasons: >>> >>> 1) No one packed FLTK 2.x, check repository there's still 1.1.9. >>> 2) Because of (1) no Dillo 2. >>> >>> Although Fedora is usually fresh, in case of Dillo it's still on >>> Dillo 0.8.6 mainline. Feel free to file bug (bugzilla.redhat.com) >>> against Dillo and Package Review for FLTK2, but be aware that having >>> unstable FLTK 2.x in Fedora might be quite fight. (Believe me I am >>> Fedora packager.) >> >> Dillo2 doesn't need an FLTK2 package installed! >> It can be statically linked in. One package, that's it. >> (this is the default BTW). >> > > Sure I am aware of that, but wrt Fedora, it's something neat forbidden > > https://fedoraproject.org/wiki/PackagingDrafts/StaticLibraryPolicy > > unless necessary (and this is not the case). > >> Now, if distros need to also provide source packages by policy, >> then that's a different story. >> > > Correct. FLTK can't just be present in compile time, somehow, toolchain > has to be clear and for everyone from day0. > >> Please clarify me because I've read that complaint a few times, >> and don't yet know whether it's my fault not making the statical >> linking clear enough to packagers, or if there's a packaging >> policy issue I don't know of. :) >> > > From my POV, in distros we don't want static built packages; security > flaws in linked-in libraries is the main concern. One has to rebuild all > apps with those libraries, not just the library (obvious). > > I don't thing it will be that hard to get FLTK & Dillo2 into Fedora, the > thing is that no one did it till now :). (And I ma pretty busy at work & > uni :) ). Thanks a lot for the explanation! Although it may be difficult to get a FLTK2 package in the distro because FLTK2 doesn't have a stable release yet. I mean, if policies mandate not to include alpha or beta libraries, we're out... It'd be good to know this (for Fedora, Ubuntu and Debian at least). That way we can ask the FLTK team about their schedule plans. -- Cheers Jorge.-

Nov. 9, 2008