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.-