- Dillo-dev - lists.mailman3.com

Feature Request

by Beartooth＠swva.net

On Tue, 11 Nov 2008, Jorge Arellano Cid wrote: [...] > I ended installing alpine here to check this issue. > > The URL viewer is taken from .mailcap. When set properly, it > works (at least here it works with Ubuntu 8.04.1, so it's not an > alpine issue). OK, good; but you're over my head. I don't find anything named .mailcap on my machine. Neither does my search function. Since I've been running Pine for years, I have a .pinerc rather than an .alpinerc; but I don't find anything like what you say there, either. > If you have something like this in your mailcap: > (all in one line) > > text/html; /usr/local/bin/dillo -l -f '%s'; description=HTML Text; \ > test=test -n "$DISPLAY"; nametemplate=%s.html > > it works with dillo1. About now, I should probably mention that I do my email different ways from different addresses. The main one is remote. It does open links that include "http://" -- in dillo *here*, not on the remote machine -- but not ones without. The same is also true when I run Alpine against the address I'm using at this moment. > Something like: > > text/html; /usr/local/bin/dillo -l -f -x XID '%s'; description=HTML Text; \ > test=test -n "$DISPLAY"; nametemplate=%s.html I'm guessing that I should c&p that into my .pinerc somewhere, or into the interface Alpine gives me by typing M > S > C (Main menu to Setup to Configure); but I don't know where. > makes dillo1 exit, so it doesn't work. > Reason: XID should be a number containing a window ID, where dillo should > embed itself, not a literal string! Now you're way to Helen Gone over my head. Sorry. > Note: dillo2 will work with the flawed parameter because as it can't > embed itself yet, the parameter is blithely ignored! :-) -- Beartooth Oldfart, Double Retiree, Neo-Redneck, Linux Convert Remember, I have precious little idea what I am talking about.

Nov. 14, 2008

more css progress

by Johannes.Hofmann＠gmx.de

Hi, the dillo-css-prototype is now able to parse a user stylesheet from ~/.dillo/style.css if it exists. This allows to modify the appearance in various ways. Currently I have the following in my ~/.dillo/style.css: body {margin-left: 10mm; margin-top: 10mm; background-color: #F5F5F5;} :link {color: gray !important; text-decoration: none; font-weight: bolder; } :visited {color: olive !important; text-decoration: none; font-weight: bolder; } Note that I'm no designer so the result may hurt your eyes! Cheers, Johannes

Nov. 13, 2008

css progress

by Johannes.Hofmann＠gmx.de

Hi, I just pushed my latest changes to the css prototype repository. The css parser from dillo-0.8.0-css-3 is now integrated and working. The user agent style is parsed from a char buffer (see CssContext::buildUserAgentStyle() in css.cc). Of course the code is still full of bugs and missing stuff, but it shows that things basically work as expected. This is starting to be fun! Cheers, Johannes

Nov. 12, 2008

experimental patch: Re: dillo2 wrapping Chinese

by furaisanjin＠gmail.com

2008/11/12 corvid <corvid(a)lavabit.com>: > What happens to the tables? > (It's hard for me to tell when something is bad > since the characters are just shapes to me.) Here are 2 png pictures when I visit http://ja.wikipedia.org This is from original dillo2.0. http://furaisanjin.blog.so-net.ne.jp/_images/blog/_9f7/furaisanjin/1-02b9e.… Red surrounded part has a long line without line break and it doesn't fit on page width. This is from modified dillo2.0. http://furaisanjin.blog.so-net.ne.jp/_images/blog/_9f7/furaisanjin/2.png Blue surrounded part is table and rows are really narrow. Regards, furaisanjin

Nov. 12, 2008

experimental patch: Re: dillo2 wrapping Chinese

by corvid＠lavabit.com

furaisanjin wrote: > 2008/11/12 corvid <corvid(a)lavabit.com>: > > dillo people: It turns out that dillo handles Chinese quite badly because the > > text doesn't contain whitespace (BUG 827). It looks like Japanese is that > > way as well. > > Yes, dillo doesn't handle Japanese either when a line is long and > doesn't have break on it. > > I modified html_process_word so that each Japanese word is added by > addText. In this way appearance is better but sometimes table looks > bad. What happens to the tables? (It's hard for me to tell when something is bad since the characters are just shapes to me.)

Nov. 12, 2008

experimental patch: Re: dillo2 wrapping Chinese

by furaisanjin＠gmail.com

Hello corvid, 2008/11/12 corvid <corvid(a)lavabit.com>: > dillo people: It turns out that dillo handles Chinese quite badly because the > text doesn't contain whitespace (BUG 827). It looks like Japanese is that > way as well. Yes, dillo doesn't handle Japanese either when a line is long and doesn't have break on it. I modified html_process_word so that each Japanese word is added by addText. In this way appearance is better but sometimes table looks bad. Regards, furaisanjin

Nov. 11, 2008

experimental patch: Re: dillo2 wrapping Chinese

by corvid＠lavabit.com

dillo people: It turns out that dillo handles Chinese quite badly because the text doesn't contain whitespace (BUG 827). It looks like Japanese is that way as well. 1) People using East Asian languages: Does this do roughly the right thing? I've read that there are picky rules about certain individual characters, but I just mean in general here. 2) Thoughts on optimization are welcomed. littlebat: For some reason, I was thinking that whitespace was required between words in dillo, but I misremembered. littlebat wrote: > Hi, > Thanks for the work on Dillo. > > I think it isn't a good idea to resolve long chinese line wrapping > problem by inserting space after punctuation mark("?" or "?" or "?", > etc..). > > Here is a "Dillo2 Wrap Long Chinese Line Test" page: > http://www.learndiary.com/en/dillo2-wrap-long-chinese-line-test.htm . > Open it with Firefox or IE, then open it with Dillo2, You will see the > different of wrapping long chinese line between them. > > Note, unlike english, there is no space between Chinese characters. So, > it should be wrapped after any Chinese character which has reached the > end of a line. I don't know the technique detail about this, but, I > think, let the Chinese characters function as (english) commas or > periods is a good idea, so, a new line can be started after any Chinese > charcter which character has reached the end of a line. > > littlebat > > http://www.learndiary.com/en/ > > > corvid wrote: > >Would it make things better or worse than it is now if I inserted a > >space when encountering a "?" or "?" so that dillo would know > >that it can wrap there? If that doesn't show up properly, > >I mean the characters that function as commas and periods. > > > >(I'm trying to think of something simple that will at least help you > > somewhat without having to make big changes right now :) > > I realize that it _should_ be able to wrap after most CJK characters, > > but...) > > > >It could be worse because > >1) Those spaces would still be there if you were copying and pasting > > the text to something else. > >2) If you wanted to search a page for "text?text", you would have to > > enter "text? text" with a space in there.

Nov. 11, 2008

Feature Request

by jcid＠dillo.org

On Sun, Nov 09, 2008 at 10:27:11AM -0500, me at swva wrote: > 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? I ended installing alpine here to check this issue. The URL viewer is taken from .mailcap. When set properly, it works (at least here it works with Ubuntu 8.04.1, so it's not an alpine issue). If you have something like this in your mailcap: (all in one line) text/html; /usr/local/bin/dillo -l -f '%s'; description=HTML Text; \ test=test -n "$DISPLAY"; nametemplate=%s.html it works with dillo1. Something like: text/html; /usr/local/bin/dillo -l -f -x XID '%s'; description=HTML Text; \ test=test -n "$DISPLAY"; nametemplate=%s.html makes dillo1 exit, so it doesn't work. Reason: XID should be a number containing a window ID, where dillo should embed itself, not a literal string! Note: dillo2 will work with the flawed parameter because as it can't embed itself yet, the parameter is blithely ignored! :-) HTH. -- Cheers Jorge.-

Nov. 11, 2008

the Http_must_use_proxy change in CVS

by jcid＠dillo.org

On Tue, Nov 11, 2008 at 12:00:29AM +0000, corvid wrote: > Is something missing? I miss some rest! :-) > It gives me a warning because we're sending it a char* now. My fault, this is a bug! I was working on an old patch and made the mistake. David: the problem was that the no_proxy preference had whitespace around the equal sign in dillorc. The current CVS extends the parser to accept this syntax. Please test and send feedback. The other patch "worked" by chance ;). -- Cheers Jorge.-

Nov. 11, 2008

Greetings! -- With Patches :-)

by jcid＠dillo.org

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(a)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.-

Nov. 11, 2008