Greetings! -- With Patches :-)
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
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?
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@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
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).
On Mon, 10 Nov 2008 04:59:50 +0000 "corvid" <corvid@lavabit.com> wrote:
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).
This is actually boils down to a "personal preference" issue. Some people believe it's a good thing for a web page to have fonts of multiple sizes. Being that I can be somewhat difficult, I disagree strongly, and think all text should be rendered in the exact same font size... --But of course, that's *my* "personal preference." :-) For example, header tags in HTML (i.e. H1, H2, H3, ...) typically use a larger font. If the dillo developers used prefs.fontsize, the result would be what *I* like, namely all fonts would be forced to use the exact same size. By using prefs.font_factor, the dillo developers made a wise choice because it both prevents web developers from using microscopic font sizes but still allows for variations in font size within a web page. The fonts used in the dillo user interface (menus and such), are a different beast. The older dillo (pre 2.0) used GTK which allows the user to configure user interface fonts. With the new dillo ( > 2.0), the new FLTK graphic toolkit does not allow (as far as I know) for system/user wide configuration. This means the hard coded UI fonts are stuck at the specified sizes. -- J.C. Roberts
Jon wrote:
On Mon, 10 Nov 2008 04:59:50 +0000 "corvid" wrote:
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).
This is actually boils down to a "personal preference" issue. Some people believe it's a good thing for a web page to have fonts of multiple sizes. Being that I can be somewhat difficult, I disagree strongly, and think all text should be rendered in the exact same font size... --But of course, that's *my* "personal preference." :-)
For example, header tags in HTML (i.e. H1, H2, H3, ...) typically use a larger font. If the dillo developers used prefs.fontsize, the result would be what *I* like, namely all fonts would be forced to use the exact same size.
By using prefs.font_factor, the dillo developers made a wise choice because it both prevents web developers from using microscopic font sizes but still allows for variations in font size within a web page.
Right, what I meant here is prefs.fontsize as the default as well as umm...h4, iirc, and then figuring out what h1-3,5-6 should be based on that value.
On Sun, Nov 09, 2008 at 12:16:42PM -0800, J.C. Roberts wrote:
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:
Good! Welcome aboard.
[...] 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.
This raises an interesting issue. It may be necessary to add "ui_font_factor" to dillorc. With the patch "as is" things get broken here. The popup menus get incomplete titles. Looking at the result, I realized my personal preference is to have smaller fonts in the UI, than in rendered pages. This led me to the "ui_font_factor" solution. CVS has now a similar patch that doesn't scale the font (submitted by corvid some time ago). It'd be good to have a patch that takes all the UI elements into account. Unfortunately, a patch that scales UI fonts may also need to scale the UI panel and this could take some effort. Scaling the UI font without scaling the UI panel may be easier, and also serve the purpose.
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.
Yeah, but we haven't been strict on that.
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.
I like those menu title labels in place. They even help me! They also help newcomers to grasp Dillo's UI. Does anybody else feel like those labels are better out? (if YES, a preference may be added)
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's a FLTK STR on this.
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.
This may be a bug in FLTK, but I'm not sure. BTW, it's good to see new developers around. Please check a bit the latest activity in dillo-dev and you'll find other FLTK/UI issues waiting for a patch. -- Cheers Jorge.-
Jorge wrote:
On Sun, Nov 09, 2008 at 12:16:42PM -0800, J.C. Roberts wrote:
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.
I like those menu title labels in place. They even help me! They also help newcomers to grasp Dillo's UI.
Does anybody else feel like those labels are better out? (if YES, a preference may be added)
I think I like having the labels.
On Mon, 10 Nov 2008 15:08:43 -0300 Jorge Arellano Cid <jcid@dillo.org> wrote:
[...] 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.
This raises an interesting issue.
It may be necessary to add "ui_font_factor" to dillorc.
With the patch "as is" things get broken here. The popup menus get incomplete titles.
By this I assume you mean the text with the new/larger font size in the title/label on the popup menus does not fit within the provided space? I saw this behavior as well. The fact things work without the patch is really a matter of luck, and not a matter of correctness. The correct way to deal with it is to always calculate the size of the text string (with the specified font), and adjust the size of the label/title accordingly. I remember reading in the fltk docs about a member function to calculate X,Y size but since dillo is my first adventure into fltk, I simply cannot recall the function name. --It's one of those "I know I saw it... but where the heck did I see it?" type of things. ;-)
Looking at the result, I realized my personal preference is to have smaller fonts in the UI, than in rendered pages. This led me to the "ui_font_factor" solution.
CVS has now a similar patch that doesn't scale the font (submitted by corvid some time ago).
It'd be good to have a patch that takes all the UI elements into account. Unfortunately, a patch that scales UI fonts may also need to scale the UI panel and this could take some effort.
Scaling the UI font without scaling the UI panel may be easier, and also serve the purpose.
Keeping the UI usable/readable across a multitude of systems and configurations is a different problem than keeping the displayed web pages usable/readable. It's best to address each problem individually, rather than lumping them together. Though it would be a serious change, and require a lot of patching, I think the best solution is to have a two pronged approach: 1.) Font Factor (scaling) 2.) Font Size If only Font_Size is stated, it would be used verbatim. If only Font_Factor is stated, it would scale the font. if both were stated, Font_Factor would take precedence. This would give you prefs for: vw_font_name vw_font_size vw_font_factor ui_font_name ui_font_size ui_font_factor Ummm... with all due respect, I think the currently used "fontname" in the prefs is against the coding conventions stated on the dillo site. Of course, it really doesn't matter to a compiler, but if I'm going to dig into augmenting this code, I need to know the "right" (TM)(C)(R) way to fix it. :-)
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.
I like those menu title labels in place. They even help me! They also help newcomers to grasp Dillo's UI.
Does anybody else feel like those labels are better out? (if YES, a preference may be added)
Having an option might work, but I'm typically against having knobs just for the sake of having knobs. Keeping things simple and usable is far more important, and this includes keeping the code simple. I tend to follow the path of least surprise. :-) Since I cannot think of another application which has a label/title on Right-Click popup menus, I think having them would surprise new users more than not having them. By having label/title bars on menus, you're treating them like windows, and hence, the behavior is non-typical, inconsistent and unexpected. As for *my* personal opinion, I hate label/title bars since (to me) they serve no purpose. I'm actually running the cwm window manager so even windows don't waste space on unnecessary, non-functional title bars.
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's a FLTK STR on this.
Bummer! It would be sweet if we could activate the popups throught he keyboard. Hopefully this will get fixed.
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.
This may be a bug in FLTK, but I'm not sure.
BTW, it's good to see new developers around. Please check a bit the latest activity in dillo-dev and you'll find other FLTK/UI issues waiting for a patch.
Thanks. I'll try to read the archives a bit more. -- J.C. Roberts
On Mon, Nov 10, 2008 at 11:09:16AM -0800, J.C. Roberts wrote:
On Mon, 10 Nov 2008 15:08:43 -0300 Jorge Arellano Cid <jcid@dillo.org> wrote:
[...] This raises an interesting issue.
It may be necessary to add "ui_font_factor" to dillorc.
With the patch "as is" things get broken here. The popup menus get incomplete titles.
By this I assume you mean the text with the new/larger font size in the title/label on the popup menus does not fit within the provided space?
Yes.
[...] I remember reading in the fltk docs about a member function to calculate X,Y size but since dillo is my first adventure into fltk, I simply cannot recall the function name. --It's one of those "I know I saw it... but where the heck did I see it?" type of things. ;-)
measure(). IIRC, used in: the progress widgets, the download dpi, others.
Looking at the result, I realized my personal preference is to have smaller fonts in the UI, than in rendered pages. This led me to the "ui_font_factor" solution.
CVS has now a similar patch that doesn't scale the font (submitted by corvid some time ago).
It'd be good to have a patch that takes all the UI elements into account. Unfortunately, a patch that scales UI fonts may also need to scale the UI panel and this could take some effort.
Scaling the UI font without scaling the UI panel may be easier, and also serve the purpose.
Keeping the UI usable/readable across a multitude of systems and configurations is a different problem than keeping the displayed web pages usable/readable. It's best to address each problem individually, rather than lumping them together.
That's what I meant.
Though it would be a serious change, and require a lot of patching, I think the best solution is to have a two pronged approach:
1.) Font Factor (scaling) 2.) Font Size
If only Font_Size is stated, it would be used verbatim. If only Font_Factor is stated, it would scale the font. if both were stated, Font_Factor would take precedence.
This would give you prefs for:
vw_font_name vw_font_size vw_font_factor
ui_font_name ui_font_size ui_font_factor
Looks OK. Code for handling those extra prefs is OK. Lots of code to recalculate widget sizes to acomodate larger fonts in the UI is not the goal. Simple code that solves the problem is welcomed.
Ummm... with all due respect, I think the currently used "fontname" in the prefs is against the coding conventions stated on the dillo site. Of course, it really doesn't matter to a compiler, but if I'm going to dig into augmenting this code, I need to know the "right" (TM)(C)(R) way to fix it. :-)
Sorry, I don't understand. -- Cheers Jorge.-
participants (3)
-
corvid＠lavabit.com -
jcid＠dillo.org -
list-jcr＠designtools.org