- Dillo-dev - lists.mailman3.com

experimental patch: zero width space (Thai, Lao, Cambodian...)

by corvid＠lavabit.com

Johannes wrote: > On Tue, Sep 29, 2009 at 08:03:53AM +0000, corvid wrote: > > I just learned that some languages don't use spaces but can only > > break in certain places, and that they tend to insert > > Zero Width Space to make life easier for software that > > doesn't know the complex rules. > > > > So here's a quick little patch for them: > > http://www.dillo.org/test/zero_width_space.patch > > Looks good to me, but do we really need to add a space? > Wouldn't it be enough to just start a new word? > At least dw-example seems to wrap words with > textblock->addSpace(wordStyle); commented out. I was thinking that it would be good to remember that it's there so that the iterator could be made to do the right thing for copying and pasting text, but maybe that's too much of a picky corner case akin to soft hyphens. (And maybe stripping them out would make life simpler for findtext anyway.) > > > > > > PS I did just start trying to move the ideographic test to dw, > > but I got stuck when I realized that I can't exactly call fltk's > > utf8decode() directly in Textblock, and am not excited by the > > idea of calling it through Layout. > > > > I think we could make the utf8 methods in fltkplatform.cc static > members. In this case, that would save us... carrying along a this pointer that we weren't using? Does it save an indirection? (in any case, maybe I should static-ize all of our current fltkplatform functions that just call fltk functions)

Sept. 29, 2009

What's the status of USE_TABLES?

by jcid＠dillo.org

On Tue, Sep 29, 2009 at 07:30:47PM +0100, Jeremy Henty wrote: > On Tue, Sep 29, 2009 at 12:53:44PM -0400, Jorge Arellano Cid wrote: > > On Mon, Sep 28, 2009 at 08:01:19PM +0100, Jeremy Henty wrote: > > > > > > ... is USE_TABLES obsolete or not? ... > > > > OK remove it. > > Patch attached. Committed. -- Cheers Jorge.-

Sept. 29, 2009

What's the status of USE_TABLES?

by onepoint＠starurchin.org

On Tue, Sep 29, 2009 at 12:53:44PM -0400, Jorge Arellano Cid wrote: > On Mon, Sep 28, 2009 at 08:01:19PM +0100, Jeremy Henty wrote: > > > > ... is USE_TABLES obsolete or not? ... > > OK remove it. Patch attached. Jeremy Henty

Sept. 29, 2009

experimental patch: zero width space (Thai, Lao, Cambodian...)

by Johannes.Hofmann＠gmx.de

On Tue, Sep 29, 2009 at 08:03:53AM +0000, corvid wrote: > I just learned that some languages don't use spaces but can only > break in certain places, and that they tend to insert > Zero Width Space to make life easier for software that > doesn't know the complex rules. > > So here's a quick little patch for them: > http://www.dillo.org/test/zero_width_space.patch Looks good to me, but do we really need to add a space? Wouldn't it be enough to just start a new word? At least dw-example seems to wrap words with textblock->addSpace(wordStyle); commented out. > > > PS I did just start trying to move the ideographic test to dw, > but I got stuck when I realized that I can't exactly call fltk's > utf8decode() directly in Textblock, and am not excited by the > idea of calling it through Layout. > I think we could make the utf8 methods in fltkplatform.cc static members. Cheers, Johannes

Sept. 29, 2009

What's the status of USE_TABLES?

by jcid＠dillo.org

On Mon, Sep 28, 2009 at 08:01:19PM +0100, Jeremy Henty wrote: > > This came up as an aside to the meta refresh discussion in another > thread: is USE_TABLES obsolete or not? If it is, we should remove it, > if not, it should be hooked to a configure flag. I'll submit a patch > as soon as someone tells me which way to go. OK remove it. I hesitated because it was useful long ago. OTOH it's broken and a custom CSS template seems a better solution for the problem it tried to solve. -- Cheers Jorge.-

Sept. 29, 2009

experimental patch: zero width space (Thai, Lao, Cambodian...)

by corvid＠lavabit.com

I just learned that some languages don't use spaces but can only break in certain places, and that they tend to insert Zero Width Space to make life easier for software that doesn't know the complex rules. So here's a quick little patch for them: http://www.dillo.org/test/zero_width_space.patch PS I did just start trying to move the ideographic test to dw, but I got stuck when I realized that I can't exactly call fltk's utf8decode() directly in Textblock, and am not excited by the idea of calling it through Layout.

Sept. 29, 2009

Bug: ScrollLock modifier messes up mouse input [was: Typing Bug ...]

by rogutes＠googlemail.com

higuita (2009-09-28 21:49): > hi all > > On Sun, 27 Sep 2009 20:39:45 +0300, Rogut?s Sparnuotos <rogutes(a)googlemail.com> wrote: > > Whenever this bug is triggered, the keyboard behaves as if a modifier > > was stuck: > > seens like the numlock problem i had... try to play with it > and other modifiers, like scrool-lock, meta, shifts, etc Thanks for the hint, but I wasn't able to trigger the bug with stuck modifiers while trying out various combinations of them. But I have found a different problem with ScrollLock: whenever the ScrollLock LED is switched on, mouse input behaves as if the first mouse button was pressed (i.e. the mouse becomes unusable). I use ScrollLock with XKB: it is lit when I switch keyboard layouts, and it is configured with this line in xorg.conf: Option "XkbOptions" "grp_led:scroll" -- -- Rogut?s Sparnuotos

Sept. 28, 2009

Typing Bug when moving Dillo on DWM's Virtual Desktops

by higuita7＠yahoo.co.uk

hi all On Sun, 27 Sep 2009 20:39:45 +0300, Rogut?s Sparnuotos <rogutes(a)googlemail.com> wrote: > Whenever this bug is triggered, the keyboard behaves as if a modifier > was stuck: seens like the numlock problem i had... try to play with it and other modifiers, like scrool-lock, meta, shifts, etc good luck higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Sept. 28, 2009

What's the status of USE_TABLES?

by onepoint＠starurchin.org

This came up as an aside to the meta refresh discussion in another thread: is USE_TABLES obsolete or not? If it is, we should remove it, if not, it should be hooked to a configure flag. I'll submit a patch as soon as someone tells me which way to go. Regards, Jeremy Henty

Sept. 28, 2009

[patch]: fix the meta-refresh warning code

by jcid＠dillo.org

On Mon, Sep 28, 2009 at 07:22:29PM +0100, Jeremy Henty wrote: > On Mon, Sep 28, 2009 at 06:18:00PM +0200, Johannes Hofmann wrote: > > > I fully agree, but > > > > a_Dialog_msg > > a_Dialog_choice3 > > a_Dialog_choice5 > > a_Dialog_user_password > > a_Dialog_input > > a_Dialog_passwd > > > > should all use the same look and feel (and code) either popup window > > or popup bar based. BTW. How could we handle multiple popupbars? > > Don't forget that one page can pop up multiple simultaneous dialogs > (because although the modal dialog locks the GUI, it doesn't stop the > IO callbacks from running). That's not a problem when each call to > a_Dialog_*() pops up its own dialog, but what happens when several of > them want to use the same popup bar? I guess each popup bar will have > to manage a list of concurrent requests instead of just one. Yes, it comes with effort. I'd say let's have the popup bar for META refresh (and faulty XHTML) and keep the popup dialogs. Now, if someone ;), comes with a better idea, with implementation, it'd be good to look into. BTW, I'm working on the dpi/dpip part (lots of things). Hopefully I'll come up with a solution for the dialog bombing among the bunch of patches/code-changes in my queue. -- Cheers Jorge.-

Sept. 28, 2009

[patch]: fix the meta-refresh warning code

by onepoint＠starurchin.org

On Mon, Sep 28, 2009 at 06:18:00PM +0200, Johannes Hofmann wrote: > I fully agree, but > > a_Dialog_msg > a_Dialog_choice3 > a_Dialog_choice5 > a_Dialog_user_password > a_Dialog_input > a_Dialog_passwd > > should all use the same look and feel (and code) either popup window > or popup bar based. BTW. How could we handle multiple popupbars? Don't forget that one page can pop up multiple simultaneous dialogs (because although the modal dialog locks the GUI, it doesn't stop the IO callbacks from running). That's not a problem when each call to a_Dialog_*() pops up its own dialog, but what happens when several of them want to use the same popup bar? I guess each popup bar will have to manage a list of concurrent requests instead of just one. Regards, Jeremy Henty

Sept. 28, 2009

[patch]: fix the meta-refresh warning code

by corvid＠lavabit.com

Johannes wrote: > a_Dialog_msg > a_Dialog_choice3 > a_Dialog_choice5 > a_Dialog_user_password > a_Dialog_input > a_Dialog_passwd > > should all use the same look and feel (and code) either popup window > or popup bar based. > BTW. How could we handle multiple popupbars? Yeah, that might require a little more cleverness than we would really prefer to implement -- although when I was playing with same_domain with image loading on, I did get one of those ssl warning bombings, and boy are they definitely no fun at all as separate windows.

Sept. 28, 2009

[patch]: fix the meta-refresh warning code

by Johannes.Hofmann＠gmx.de

On Sun, Sep 27, 2009 at 04:14:29PM -0400, Jorge Arellano Cid wrote: > > I agree on consistency, and hopefully a reduced number of concepts. > > > * window title > Most probably unnoticed and no way to put a link there. > * status bar > Too ephemeral and no link too. > * popup Window > IMHO: Too intrusive for the user. > > The popup bar is the same concept as for findtext and the > control panel. > > In this case we're reducing the number of concepts by taking > out one UI element (injected HTML) and replacing it with a popup > bar. > > > > Maybe it would be nice if popup windows turned into something like > > a popup bar. > > This could reduce the number of concepts even further, but not > for "Open file", "save page", "save page as...", and downloads. I fully agree, but a_Dialog_msg a_Dialog_choice3 a_Dialog_choice5 a_Dialog_user_password a_Dialog_input a_Dialog_passwd should all use the same look and feel (and code) either popup window or popup bar based. BTW. How could we handle multiple popupbars? > > It requires some thought (on the possible gain/loss/effort)... One drawback of the popup bar is the additional resize / redraw of the rendering area. Cheers, Johannes

Sept. 28, 2009

[patch]: fix the meta-refresh warning code

by Johannes.Hofmann＠gmx.de

On Sun, Sep 27, 2009 at 03:52:38PM +0000, corvid wrote: > Johannes wrote: > > You proposed a popup bar similar to the search bar, right? > > Do we really need to create a completly new mechansim for user > > notifications? Currently we have: > > > > * window title > > * status bar > > * popup Windows (from dpi's) > > > > I think we should try to keep the UI simple and consistent by > > reducing the number of concepts. > > Maybe it would be nice if popup windows turned into something like > a popup bar. Sounds good to me. So we would just have alternative implementations for a_Dialog_msg a_Dialog_choice3 a_Dialog_choice5 a_Dialog_user_password a_Dialog_input a_Dialog_passwd > > > > PS: I recently tried http://surf.suckless.org/ and I'm rather > > impressed by the minimal UI. > > I read a little about surf and uzbl recently, but then webkit > was too big for me to want to download. Yes, it's quite large. > > (Surprised a person would intentionally name a browser 'surf' > nowadays. I had thought of web "surfing" as a term as thankfully > dead and buried as "information superhighway" or "cyberspace".) good point :-)

Sept. 28, 2009

[patch]: fix the meta-refresh warning code

by jcid＠dillo.org

On Sun, Sep 27, 2009 at 03:52:38PM +0000, corvid wrote: > Johannes wrote: > > On Fri, Sep 25, 2009 at 05:11:35PM -0400, Jorge Arellano Cid wrote: > > > On Fri, Sep 25, 2009 at 06:15:05PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Fri, Sep 25, 2009 at 07:16:12AM -0400, Jorge Arellano Cid wrote: > > > > > > On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote: > > > > > > > On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote: > > > > > > > > On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote: > > > > > > > > > > > > > > > > Would it be less trouble to have this widget as a child of the UI > > > > > > > > > instead of in the rendering area? (I sort of had the impression > > > > > > > > > that was the plan... > > > > > > > > > > > > > > > > That's exactly the plan. > > > > > > > > > > > > > > > > A simple fltk widget that hides/shows (as the findext bar) and > > > > > > > > that gives a text message. It should also support a fake HTML link > > > > > > > > (underlined word that reacts to left click). > > > > > > > > > > > > > > Ah, I think I misunderstood the reference to "custom widget" in the TO > > > > > > > DO note. I was fixated on the Dillo Widget system and didn't realise > > > > > > > it was talking about a new FLTK widget. Maybe my patch isn't the way > > > > > > > to go. Still, it would be nice for the custom widget to be properly > > > > > > > CSS-styled. Maybe it be could another FltkViewport? > > > > > > > > > > > > As this is part of the UI, I'd suggest to use Xdefaults as > > > > > > Johannes suggested for colors some time ago. > > > > > > > > > > Ehmmm, by "Xdefaults", I mean the default X resource files. > > > > > > > > ISTR that the latest was that Johannes was trying > > > > to get the FLTKers to enable the relevant code that > > > > had been commented out (rather than having dillo > > > > do it directly), but nothing happened on the fltk side. > > > > > > FLTK2 is dead (that's almost official). > > > > > > Progress will happen in 1.3.x branch (or whatever they chose to > > > call a new branch merging FLTK2 and 1.3.x [1]). > > > > > > In the meanwhile, I'd be OK with a non-themeable warning widget > > > with the same colors it used to have. ;-) > > > > > > FWIW: the patch should implement an fltk widget as described in > > > a previous email. So, no further work on the proposed patch is > > > necessary. > > > > You proposed a popup bar similar to the search bar, right? > > Do we really need to create a completly new mechansim for user > > notifications? Currently we have: > > > > * window title > > * status bar > > * popup Windows (from dpi's) > > > > I think we should try to keep the UI simple and consistent by > > reducing the number of concepts. I agree on consistency, and hopefully a reduced number of concepts. * window title Most probably unnoticed and no way to put a link there. * status bar Too ephemeral and no link too. * popup Window IMHO: Too intrusive for the user. The popup bar is the same concept as for findtext and the control panel. In this case we're reducing the number of concepts by taking out one UI element (injected HTML) and replacing it with a popup bar. > Maybe it would be nice if popup windows turned into something like > a popup bar. This could reduce the number of concepts even further, but not for "Open file", "save page", "save page as...", and downloads. It requires some thought (on the possible gain/loss/effort)... -- Cheers Jorge.-

Sept. 27, 2009

Typing Bug when moving Dillo on DWM's Virtual Desktops

by jcid＠dillo.org

On Sun, Sep 27, 2009 at 05:59:47PM +0000, corvid wrote: > Rogut??s wrote: > > Johannes Hofmann (2009-09-27 15:31): > > > On Sat, Sep 26, 2009 at 08:46:38AM -0400, Jorge Arellano Cid wrote: > > > > Hi Roger, > > > > > > > > On Fri, Sep 25, 2009 at 10:52:11PM -0800, Roger wrote: > > > > > I'm finally tackling a typing bug with Dillo, and have found it occurs > > > > > when moving the Dillo browser to DMW's other virtual desktops. > > > > > > > > > > It doesn't occur when Dillo is first started. > > > > > > > > > > Nothing, if anything at all, shows within gdb. > > > > > > > > > > > > > > > And, I can't really get to the debug output of DWM as I'm running nvidia > > > > > proprietary drivers which blanks the terminal once X is started. I do > > > > > have a laptop for which I can further investigate the DWM debug data, > > > > > but figured I should post what I know to see if any of you notice > > > > > similar. > > > > > > > > > > > > > > > The basic bug scenario, move the Dillo browser to another Virtual > > > > > Desktop within DWM and start typing (within the url field or within the > > > > > Google search field.) I notice only certain keys type their characters > > > > > and most others will either type nothing or may clear the entire field > > > > > (ie. clear line) > > > > > > > > > > Possible a meta key sticks when moving the browser to another desktop?? > > > > > > > > It could be a bug in dwm, fltk2 or dillo. > > > > > > > > I assume you're using dillo2 (the FLTK2-based one). The dillo > > > > UI widgets you describe to fail are plain FLTK2 objects, so > > > > please do the following test: > > > > > > > > * Get to the fltk2 compilation directory and run test/input > > > > program, and then try to reproduce the bug as with dillo. > > > > > > I quickly tried to reproduce the problem as I also use dwm, but > > > could not see any problem until now. > > > I opened dillo, focused the url field, send dillo to another tag > > > with e.g. Alt-Shift 2, then went activated tag 2 with Alt 2, and > > > continued typing. This seems to work here. > > > Are you using the mouse maybe? > > > > I've mentioned this bug some months ago and corvid seemed to confirm > > seeing it. Unfortunately, I still haven't found any way to reliably > > reproduce it, and what Roger writes doesn't trigger it here. I've seen > > this bug under dwm and xmonad, haven't used other WM's with dillo. > > > > Whenever this bug is triggered, the keyboard behaves as if a modifier > > was stuck: keyboard input seems to generate no response, until one tries > > to type in input boxes (e.g. the location bar). There, typing 'a' goes > > to the beginning of the line, 'e' goes to the end, etc., as if some > > modifier was pressed (e.g. try pressing <Ctrl>u, or <Alt>u, or <Mod4>u > > in the location bar with some text). > > Yeah, I can still get into the situation if I play around with > modifiers and switching virtual desktops (fvwm) with enough > determination and persistence, but it's no longer easy, > and when I repeat what I think just made it break, it'll > fail to break again. Hmmm, if it's reproduceable with the test/input program, it's something in FLTK2. If test/input doesn't show the bug, a good test would be to make the location an fltk::Input (instead of CustInput) and try it. If there's no bug, it may be CustInput::handle(). If the bug shows then I'd blame fltk2, but who knows? :-) -- Cheers Jorge.-

Sept. 27, 2009

Typing Bug when moving Dillo on DWM's Virtual Desktops

by corvid＠lavabit.com

Rogut?s wrote: > Johannes Hofmann (2009-09-27 15:31): > > On Sat, Sep 26, 2009 at 08:46:38AM -0400, Jorge Arellano Cid wrote: > > > Hi Roger, > > > > > > On Fri, Sep 25, 2009 at 10:52:11PM -0800, Roger wrote: > > > > I'm finally tackling a typing bug with Dillo, and have found it occurs > > > > when moving the Dillo browser to DMW's other virtual desktops. > > > > > > > > It doesn't occur when Dillo is first started. > > > > > > > > Nothing, if anything at all, shows within gdb. > > > > > > > > > > > > And, I can't really get to the debug output of DWM as I'm running nvidia > > > > proprietary drivers which blanks the terminal once X is started. I do > > > > have a laptop for which I can further investigate the DWM debug data, > > > > but figured I should post what I know to see if any of you notice > > > > similar. > > > > > > > > > > > > The basic bug scenario, move the Dillo browser to another Virtual > > > > Desktop within DWM and start typing (within the url field or within the > > > > Google search field.) I notice only certain keys type their characters > > > > and most others will either type nothing or may clear the entire field > > > > (ie. clear line) > > > > > > > > Possible a meta key sticks when moving the browser to another desktop?? > > > > > > It could be a bug in dwm, fltk2 or dillo. > > > > > > I assume you're using dillo2 (the FLTK2-based one). The dillo > > > UI widgets you describe to fail are plain FLTK2 objects, so > > > please do the following test: > > > > > > * Get to the fltk2 compilation directory and run test/input > > > program, and then try to reproduce the bug as with dillo. > > > > I quickly tried to reproduce the problem as I also use dwm, but > > could not see any problem until now. > > I opened dillo, focused the url field, send dillo to another tag > > with e.g. Alt-Shift 2, then went activated tag 2 with Alt 2, and > > continued typing. This seems to work here. > > Are you using the mouse maybe? > > I've mentioned this bug some months ago and corvid seemed to confirm > seeing it. Unfortunately, I still haven't found any way to reliably > reproduce it, and what Roger writes doesn't trigger it here. I've seen > this bug under dwm and xmonad, haven't used other WM's with dillo. > > Whenever this bug is triggered, the keyboard behaves as if a modifier > was stuck: keyboard input seems to generate no response, until one tries > to type in input boxes (e.g. the location bar). There, typing 'a' goes > to the beginning of the line, 'e' goes to the end, etc., as if some > modifier was pressed (e.g. try pressing <Ctrl>u, or <Alt>u, or <Mod4>u > in the location bar with some text). Yeah, I can still get into the situation if I play around with modifiers and switching virtual desktops (fvwm) with enough determination and persistence, but it's no longer easy, and when I repeat what I think just made it break, it'll fail to break again.

Sept. 27, 2009

Typing Bug when moving Dillo on DWM's Virtual Desktops

by rogutes＠googlemail.com

Johannes Hofmann (2009-09-27 15:31): > On Sat, Sep 26, 2009 at 08:46:38AM -0400, Jorge Arellano Cid wrote: > > Hi Roger, > > > > On Fri, Sep 25, 2009 at 10:52:11PM -0800, Roger wrote: > > > I'm finally tackling a typing bug with Dillo, and have found it occurs > > > when moving the Dillo browser to DMW's other virtual desktops. > > > > > > It doesn't occur when Dillo is first started. > > > > > > Nothing, if anything at all, shows within gdb. > > > > > > > > > And, I can't really get to the debug output of DWM as I'm running nvidia > > > proprietary drivers which blanks the terminal once X is started. I do > > > have a laptop for which I can further investigate the DWM debug data, > > > but figured I should post what I know to see if any of you notice > > > similar. > > > > > > > > > The basic bug scenario, move the Dillo browser to another Virtual > > > Desktop within DWM and start typing (within the url field or within the > > > Google search field.) I notice only certain keys type their characters > > > and most others will either type nothing or may clear the entire field > > > (ie. clear line) > > > > > > Possible a meta key sticks when moving the browser to another desktop?? > > > > It could be a bug in dwm, fltk2 or dillo. > > > > I assume you're using dillo2 (the FLTK2-based one). The dillo > > UI widgets you describe to fail are plain FLTK2 objects, so > > please do the following test: > > > > * Get to the fltk2 compilation directory and run test/input > > program, and then try to reproduce the bug as with dillo. > > I quickly tried to reproduce the problem as I also use dwm, but > could not see any problem until now. > I opened dillo, focused the url field, send dillo to another tag > with e.g. Alt-Shift 2, then went activated tag 2 with Alt 2, and > continued typing. This seems to work here. > Are you using the mouse maybe? I've mentioned this bug some months ago and corvid seemed to confirm seeing it. Unfortunately, I still haven't found any way to reliably reproduce it, and what Roger writes doesn't trigger it here. I've seen this bug under dwm and xmonad, haven't used other WM's with dillo. Whenever this bug is triggered, the keyboard behaves as if a modifier was stuck: keyboard input seems to generate no response, until one tries to type in input boxes (e.g. the location bar). There, typing 'a' goes to the beginning of the line, 'e' goes to the end, etc., as if some modifier was pressed (e.g. try pressing <Ctrl>u, or <Alt>u, or <Mod4>u in the location bar with some text). -- -- Rogut?s Sparnuotos

Sept. 27, 2009

[patch]: fix the meta-refresh warning code

by corvid＠lavabit.com

Johannes wrote: > On Fri, Sep 25, 2009 at 05:11:35PM -0400, Jorge Arellano Cid wrote: > > On Fri, Sep 25, 2009 at 06:15:05PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Fri, Sep 25, 2009 at 07:16:12AM -0400, Jorge Arellano Cid wrote: > > > > > On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote: > > > > > > On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote: > > > > > > > On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote: > > > > > > > > > > > > > > Would it be less trouble to have this widget as a child of the UI > > > > > > > > instead of in the rendering area? (I sort of had the impression > > > > > > > > that was the plan... > > > > > > > > > > > > > > That's exactly the plan. > > > > > > > > > > > > > > A simple fltk widget that hides/shows (as the findext bar) and > > > > > > > that gives a text message. It should also support a fake HTML link > > > > > > > (underlined word that reacts to left click). > > > > > > > > > > > > Ah, I think I misunderstood the reference to "custom widget" in the TO > > > > > > DO note. I was fixated on the Dillo Widget system and didn't realise > > > > > > it was talking about a new FLTK widget. Maybe my patch isn't the way > > > > > > to go. Still, it would be nice for the custom widget to be properly > > > > > > CSS-styled. Maybe it be could another FltkViewport? > > > > > > > > > > As this is part of the UI, I'd suggest to use Xdefaults as > > > > > Johannes suggested for colors some time ago. > > > > > > > > Ehmmm, by "Xdefaults", I mean the default X resource files. > > > > > > ISTR that the latest was that Johannes was trying > > > to get the FLTKers to enable the relevant code that > > > had been commented out (rather than having dillo > > > do it directly), but nothing happened on the fltk side. > > > > FLTK2 is dead (that's almost official). > > > > Progress will happen in 1.3.x branch (or whatever they chose to > > call a new branch merging FLTK2 and 1.3.x [1]). > > > > In the meanwhile, I'd be OK with a non-themeable warning widget > > with the same colors it used to have. ;-) > > > > FWIW: the patch should implement an fltk widget as described in > > a previous email. So, no further work on the proposed patch is > > necessary. > > You proposed a popup bar similar to the search bar, right? > Do we really need to create a completly new mechansim for user > notifications? Currently we have: > > * window title > * status bar > * popup Windows (from dpi's) > > I think we should try to keep the UI simple and consistent by > reducing the number of concepts. Maybe it would be nice if popup windows turned into something like a popup bar. > PS: I recently tried http://surf.suckless.org/ and I'm rather > impressed by the minimal UI. I read a little about surf and uzbl recently, but then webkit was too big for me to want to download. (Surprised a person would intentionally name a browser 'surf' nowadays. I had thought of web "surfing" as a term as thankfully dead and buried as "information superhighway" or "cyberspace".)

Sept. 27, 2009

[patch]: fix the meta-refresh warning code

by Johannes.Hofmann＠gmx.de

On Fri, Sep 25, 2009 at 05:11:35PM -0400, Jorge Arellano Cid wrote: > On Fri, Sep 25, 2009 at 06:15:05PM +0000, corvid wrote: > > Jorge wrote: > > > On Fri, Sep 25, 2009 at 07:16:12AM -0400, Jorge Arellano Cid wrote: > > > > On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote: > > > > > On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote: > > > > > > On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote: > > > > > > > > > > > > Would it be less trouble to have this widget as a child of the UI > > > > > > > instead of in the rendering area? (I sort of had the impression > > > > > > > that was the plan... > > > > > > > > > > > > That's exactly the plan. > > > > > > > > > > > > A simple fltk widget that hides/shows (as the findext bar) and > > > > > > that gives a text message. It should also support a fake HTML link > > > > > > (underlined word that reacts to left click). > > > > > > > > > > Ah, I think I misunderstood the reference to "custom widget" in the TO > > > > > DO note. I was fixated on the Dillo Widget system and didn't realise > > > > > it was talking about a new FLTK widget. Maybe my patch isn't the way > > > > > to go. Still, it would be nice for the custom widget to be properly > > > > > CSS-styled. Maybe it be could another FltkViewport? > > > > > > > > As this is part of the UI, I'd suggest to use Xdefaults as > > > > Johannes suggested for colors some time ago. > > > > > > Ehmmm, by "Xdefaults", I mean the default X resource files. > > > > ISTR that the latest was that Johannes was trying > > to get the FLTKers to enable the relevant code that > > had been commented out (rather than having dillo > > do it directly), but nothing happened on the fltk side. > > FLTK2 is dead (that's almost official). > > Progress will happen in 1.3.x branch (or whatever they chose to > call a new branch merging FLTK2 and 1.3.x [1]). > > In the meanwhile, I'd be OK with a non-themeable warning widget > with the same colors it used to have. ;-) > > FWIW: the patch should implement an fltk widget as described in > a previous email. So, no further work on the proposed patch is > necessary. You proposed a popup bar similar to the search bar, right? Do we really need to create a completly new mechansim for user notifications? Currently we have: * window title * status bar * popup Windows (from dpi's) I think we should try to keep the UI simple and consistent by reducing the number of concepts. Cheers, Johannes PS: I recently tried http://surf.suckless.org/ and I'm rather impressed by the minimal UI.

Sept. 27, 2009

Weird chars bug

by Johannes.Hofmann＠gmx.de

On Fri, Sep 25, 2009 at 06:04:10PM +0000, corvid wrote: > Jorge wrote: > > Since dillo-2.1, enabled-CSS makes funny chars in this page: > > > > http://blogdrake.net/node/14916 > > > > Screenshot: > > > > http://www.dillo.org/test/weirdChars.jpg > > > > Disabling it from the tools button solves the problem. > > Does anybody know what's the problem here? > > I suspect it has something to do with the > font: 76% Trebuchet MS, Verdana, Arial, Helvetica, sans-serif; > in http://blogdrake.net/themes/lightdrake/style.css > > Of course with my general paucity of fonts, it looks fine to me :) Looks ok here too. Somehow dillo seems to pick some weird font on your system, that can't properly display the characters. There are quite a few open issues in the font selection code of dillo. Cheers, Johannes

Sept. 27, 2009

Typing Bug when moving Dillo on DWM's Virtual Desktops

by Johannes.Hofmann＠gmx.de

On Sat, Sep 26, 2009 at 08:46:38AM -0400, Jorge Arellano Cid wrote: > Hi Roger, > > On Fri, Sep 25, 2009 at 10:52:11PM -0800, Roger wrote: > > I'm finally tackling a typing bug with Dillo, and have found it occurs > > when moving the Dillo browser to DMW's other virtual desktops. > > > > It doesn't occur when Dillo is first started. > > > > Nothing, if anything at all, shows within gdb. > > > > > > And, I can't really get to the debug output of DWM as I'm running nvidia > > proprietary drivers which blanks the terminal once X is started. I do > > have a laptop for which I can further investigate the DWM debug data, > > but figured I should post what I know to see if any of you notice > > similar. > > > > > > The basic bug scenario, move the Dillo browser to another Virtual > > Desktop within DWM and start typing (within the url field or within the > > Google search field.) I notice only certain keys type their characters > > and most others will either type nothing or may clear the entire field > > (ie. clear line) > > > > Possible a meta key sticks when moving the browser to another desktop?? > > It could be a bug in dwm, fltk2 or dillo. > > I assume you're using dillo2 (the FLTK2-based one). The dillo > UI widgets you describe to fail are plain FLTK2 objects, so > please do the following test: > > * Get to the fltk2 compilation directory and run test/input > program, and then try to reproduce the bug as with dillo. I quickly tried to reproduce the problem as I also use dwm, but could not see any problem until now. I opened dillo, focused the url field, send dillo to another tag with e.g. Alt-Shift 2, then went activated tag 2 with Alt 2, and continued typing. This seems to work here. Are you using the mouse maybe? Cheers, Johannes

Sept. 27, 2009

Typing Bug when moving Dillo on DWM's Virtual Desktops

by jcid＠dillo.org

Hi Roger, On Fri, Sep 25, 2009 at 10:52:11PM -0800, Roger wrote: > I'm finally tackling a typing bug with Dillo, and have found it occurs > when moving the Dillo browser to DMW's other virtual desktops. > > It doesn't occur when Dillo is first started. > > Nothing, if anything at all, shows within gdb. > > > And, I can't really get to the debug output of DWM as I'm running nvidia > proprietary drivers which blanks the terminal once X is started. I do > have a laptop for which I can further investigate the DWM debug data, > but figured I should post what I know to see if any of you notice > similar. > > > The basic bug scenario, move the Dillo browser to another Virtual > Desktop within DWM and start typing (within the url field or within the > Google search field.) I notice only certain keys type their characters > and most others will either type nothing or may clear the entire field > (ie. clear line) > > Possible a meta key sticks when moving the browser to another desktop?? It could be a bug in dwm, fltk2 or dillo. I assume you're using dillo2 (the FLTK2-based one). The dillo UI widgets you describe to fail are plain FLTK2 objects, so please do the following test: * Get to the fltk2 compilation directory and run test/input program, and then try to reproduce the bug as with dillo. -- Cheers Jorge.-

Sept. 26, 2009

Typing Bug when moving Dillo on DWM's Virtual Desktops

by rogerx＠sdf.lonestar.org

I'm finally tackling a typing bug with Dillo, and have found it occurs when moving the Dillo browser to DMW's other virtual desktops. It doesn't occur when Dillo is first started. Nothing, if anything at all, shows within gdb. And, I can't really get to the debug output of DWM as I'm running nvidia proprietary drivers which blanks the terminal once X is started. I do have a laptop for which I can further investigate the DWM debug data, but figured I should post what I know to see if any of you notice similar. The basic bug scenario, move the Dillo browser to another Virtual Desktop within DWM and start typing (within the url field or within the Google search field.) I notice only certain keys type their characters and most others will either type nothing or may clear the entire field (ie. clear line) Possible a meta key sticks when moving the browser to another desktop?? -- Roger http://rogerx.freeshell.org

Sept. 26, 2009

[patch]: fix the meta-refresh warning code

by jcid＠dillo.org

On Fri, Sep 25, 2009 at 06:15:05PM +0000, corvid wrote: > Jorge wrote: > > On Fri, Sep 25, 2009 at 07:16:12AM -0400, Jorge Arellano Cid wrote: > > > On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote: > > > > On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote: > > > > > On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote: > > > > > > > > > > Would it be less trouble to have this widget as a child of the UI > > > > > > instead of in the rendering area? (I sort of had the impression > > > > > > that was the plan... > > > > > > > > > > That's exactly the plan. > > > > > > > > > > A simple fltk widget that hides/shows (as the findext bar) and > > > > > that gives a text message. It should also support a fake HTML link > > > > > (underlined word that reacts to left click). > > > > > > > > Ah, I think I misunderstood the reference to "custom widget" in the TO > > > > DO note. I was fixated on the Dillo Widget system and didn't realise > > > > it was talking about a new FLTK widget. Maybe my patch isn't the way > > > > to go. Still, it would be nice for the custom widget to be properly > > > > CSS-styled. Maybe it be could another FltkViewport? > > > > > > As this is part of the UI, I'd suggest to use Xdefaults as > > > Johannes suggested for colors some time ago. > > > > Ehmmm, by "Xdefaults", I mean the default X resource files. > > ISTR that the latest was that Johannes was trying > to get the FLTKers to enable the relevant code that > had been commented out (rather than having dillo > do it directly), but nothing happened on the fltk side. FLTK2 is dead (that's almost official). Progress will happen in 1.3.x branch (or whatever they chose to call a new branch merging FLTK2 and 1.3.x [1]). In the meanwhile, I'd be OK with a non-themeable warning widget with the same colors it used to have. ;-) FWIW: the patch should implement an fltk widget as described in a previous email. So, no further work on the proposed patch is necessary. [1] http://fltk.org/newsgroups.php?s7257+gfltk.development+v7263+T0 -- Cheers Jorge.-

Sept. 25, 2009

[patch]: fix the meta-refresh warning code

by corvid＠lavabit.com

Jorge wrote: > On Fri, Sep 25, 2009 at 07:16:12AM -0400, Jorge Arellano Cid wrote: > > On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote: > > > On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote: > > > > On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote: > > > > > > > > Would it be less trouble to have this widget as a child of the UI > > > > > instead of in the rendering area? (I sort of had the impression > > > > > that was the plan... > > > > > > > > That's exactly the plan. > > > > > > > > A simple fltk widget that hides/shows (as the findext bar) and > > > > that gives a text message. It should also support a fake HTML link > > > > (underlined word that reacts to left click). > > > > > > Ah, I think I misunderstood the reference to "custom widget" in the TO > > > DO note. I was fixated on the Dillo Widget system and didn't realise > > > it was talking about a new FLTK widget. Maybe my patch isn't the way > > > to go. Still, it would be nice for the custom widget to be properly > > > CSS-styled. Maybe it be could another FltkViewport? > > > > As this is part of the UI, I'd suggest to use Xdefaults as > > Johannes suggested for colors some time ago. > > Ehmmm, by "Xdefaults", I mean the default X resource files. ISTR that the latest was that Johannes was trying to get the FLTKers to enable the relevant code that had been commented out (rather than having dillo do it directly), but nothing happened on the fltk side.

Sept. 25, 2009

Weird chars bug

by corvid＠lavabit.com

Jorge wrote: > Since dillo-2.1, enabled-CSS makes funny chars in this page: > > http://blogdrake.net/node/14916 > > Screenshot: > > http://www.dillo.org/test/weirdChars.jpg > > Disabling it from the tools button solves the problem. > Does anybody know what's the problem here? I suspect it has something to do with the font: 76% Trebuchet MS, Verdana, Arial, Helvetica, sans-serif; in http://blogdrake.net/themes/lightdrake/style.css Of course with my general paucity of fonts, it looks fine to me :)

Sept. 25, 2009

[patch]: fix the meta-refresh warning code

by jcid＠dillo.org

On Fri, Sep 25, 2009 at 07:16:12AM -0400, Jorge Arellano Cid wrote: > On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote: > > On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote: > > > On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote: > > > > > > Would it be less trouble to have this widget as a child of the UI > > > > instead of in the rendering area? (I sort of had the impression > > > > that was the plan... > > > > > > That's exactly the plan. > > > > > > A simple fltk widget that hides/shows (as the findext bar) and > > > that gives a text message. It should also support a fake HTML link > > > (underlined word that reacts to left click). > > > > Ah, I think I misunderstood the reference to "custom widget" in the TO > > DO note. I was fixated on the Dillo Widget system and didn't realise > > it was talking about a new FLTK widget. Maybe my patch isn't the way > > to go. Still, it would be nice for the custom widget to be properly > > CSS-styled. Maybe it be could another FltkViewport? > > As this is part of the UI, I'd suggest to use Xdefaults as > Johannes suggested for colors some time ago. Ehmmm, by "Xdefaults", I mean the default X resource files. -- Cheers Jorge.-

Sept. 25, 2009

Weird chars bug

by jcid＠dillo.org

Hi, Since dillo-2.1, enabled-CSS makes funny chars in this page: http://blogdrake.net/node/14916 Screenshot: http://www.dillo.org/test/weirdChars.jpg Disabling it from the tools button solves the problem. Does anybody know what's the problem here? -- Cheers Jorge.-

Sept. 25, 2009

[patch]: fix the meta-refresh warning code

by jcid＠dillo.org

On Thu, Sep 24, 2009 at 06:04:15AM +0100, Jeremy Henty wrote: > On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote: > > On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote: > > > > Would it be less trouble to have this widget as a child of the UI > > > instead of in the rendering area? (I sort of had the impression > > > that was the plan... > > > > That's exactly the plan. > > > > A simple fltk widget that hides/shows (as the findext bar) and > > that gives a text message. It should also support a fake HTML link > > (underlined word that reacts to left click). > > Ah, I think I misunderstood the reference to "custom widget" in the TO > DO note. I was fixated on the Dillo Widget system and didn't realise > it was talking about a new FLTK widget. Maybe my patch isn't the way > to go. Still, it would be nice for the custom widget to be properly > CSS-styled. Maybe it be could another FltkViewport? As this is part of the UI, I'd suggest to use Xdefaults as Johannes suggested for colors some time ago. -- Cheers Jorge.-

Sept. 25, 2009

[patch]: fix the meta-refresh warning code

by onepoint＠starurchin.org

On Tue, Sep 22, 2009 at 02:25:47PM -0400, Jorge Arellano Cid wrote: > On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote: > > Would it be less trouble to have this widget as a child of the UI > > instead of in the rendering area? (I sort of had the impression > > that was the plan... > > That's exactly the plan. > > A simple fltk widget that hides/shows (as the findext bar) and > that gives a text message. It should also support a fake HTML link > (underlined word that reacts to left click). Ah, I think I misunderstood the reference to "custom widget" in the TO DO note. I was fixated on the Dillo Widget system and didn't realise it was talking about a new FLTK widget. Maybe my patch isn't the way to go. Still, it would be nice for the custom widget to be properly CSS-styled. Maybe it be could another FltkViewport? Regards, Jeremy Henty

Sept. 24, 2009

[patch]: fix the meta-refresh warning code

by jcid＠dillo.org

On Tue, Sep 22, 2009 at 04:35:28PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Sep 22, 2009 at 07:47:09AM +0100, Jeremy Henty wrote: > > > On Mon, Sep 21, 2009 at 11:58:09PM -0400, Jorge Arellano Cid wrote: > > > > > > > > * The HTML parser in table.cc does not create table widgets if > > > > > USE_TABLES is not defined. Perhaps this code should do the > > > > > same? > > > > > > > > Not necessary. That was an old feature for narrow displays. > > > > > > In that case, shouldn't we remove USE_TABLES entirely? > > > > > > > > * It would be nice if the widgets and the redirect link were > > > > > styled from the User Agent style in css.cc . ... > > > > > > > > AFAIS, the warning widget needs its own scheme, like the rest of > > > > the panel. > > > > > > Perhaps we could extend the default style in css.cc with clauses like > > > "dillo meta-refresh-warning redirect { color: ... }", using "dillo" > > > as a reserved CSS class for internal use? Then all of the style > > > information would be in CSS and none of it would be hard-coded in the > > > parser, which is how it should be. > > > > Yes, this would be possible. Other browsers also have similar > > extensions. They seem to start with a '-' usually ("-webkit...", > > "-moz..."). > > But generally if we generate messages in the rendering area, we > > can't avoid that someone fakes them on his webpage. > > Would it be less trouble to have this widget as a child of the UI > instead of in the rendering area? (I sort of had the impression that > was the plan, but maybe that was the xhtml one, or maybe I'm just > mixed up.) That's exactly the plan. A simple fltk widget that hides/shows (as the findext bar) and that gives a text message. It should also support a fake HTML link (underlined word that reacts to left click). Sorry for not having the time yet to test the code... -- Cheers Jorge.-

Sept. 22, 2009

[patch]: fix the meta-refresh warning code

by corvid＠lavabit.com

Johannes wrote: > On Tue, Sep 22, 2009 at 07:47:09AM +0100, Jeremy Henty wrote: > > On Mon, Sep 21, 2009 at 11:58:09PM -0400, Jorge Arellano Cid wrote: > > > > > > * The HTML parser in table.cc does not create table widgets if > > > > USE_TABLES is not defined. Perhaps this code should do the > > > > same? > > > > > > Not necessary. That was an old feature for narrow displays. > > > > In that case, shouldn't we remove USE_TABLES entirely? > > > > > > * It would be nice if the widgets and the redirect link were > > > > styled from the User Agent style in css.cc . ... > > > > > > AFAIS, the warning widget needs its own scheme, like the rest of > > > the panel. > > > > Perhaps we could extend the default style in css.cc with clauses like > > "dillo meta-refresh-warning redirect { color: ... }", using "dillo" > > as a reserved CSS class for internal use? Then all of the style > > information would be in CSS and none of it would be hard-coded in the > > parser, which is how it should be. > > Yes, this would be possible. Other browsers also have similar > extensions. They seem to start with a '-' usually ("-webkit...", > "-moz..."). > But generally if we generate messages in the rendering area, we > can't avoid that someone fakes them on his webpage. Would it be less trouble to have this widget as a child of the UI instead of in the rendering area? (I sort of had the impression that was the plan, but maybe that was the xhtml one, or maybe I'm just mixed up.)

Sept. 22, 2009

[patch]: fix the meta-refresh warning code

by Johannes.Hofmann＠gmx.de

Hi Jeremy, On Tue, Sep 22, 2009 at 07:47:09AM +0100, Jeremy Henty wrote: > On Mon, Sep 21, 2009 at 11:58:09PM -0400, Jorge Arellano Cid wrote: > > > > * The HTML parser in table.cc does not create table widgets if > > > USE_TABLES is not defined. Perhaps this code should do the > > > same? > > > > Not necessary. That was an old feature for narrow displays. > > In that case, shouldn't we remove USE_TABLES entirely? > > > > * It would be nice if the widgets and the redirect link were > > > styled from the User Agent style in css.cc . ... > > > > AFAIS, the warning widget needs its own scheme, like the rest of > > the panel. > > Perhaps we could extend the default style in css.cc with clauses like > "dillo meta-refresh-warning redirect { color: ... }", using "dillo" > as a reserved CSS class for internal use? Then all of the style > information would be in CSS and none of it would be hard-coded in the > parser, which is how it should be. Yes, this would be possible. Other browsers also have similar extensions. They seem to start with a '-' usually ("-webkit...", "-moz..."). But generally if we generate messages in the rendering area, we can't avoid that someone fakes them on his webpage. > > I still haven't worked out how to apply the CSS stylesheets to the > widgets I create (the style engine mechanism isn't being applied > because I create the widgets directly instead of from HTML). I tried > adding calls to styleEngine->{startElement,endElement}() but nothing > happened. I'm clearly still missing something. I'll have another > look, but any tips will be welcome! That should work. You need those styleEngine->{startElement,endElement}() calls and then use styleEngine->style() for your widgets. See plain.cc for an example. And of course you need to specify corresponding css either in the user agent style in css.cc or for testing just in your ~/.dillo/style.css file. Regards, Johannes

Sept. 22, 2009

[patch]: fix the meta-refresh warning code

by onepoint＠starurchin.org

On Mon, Sep 21, 2009 at 11:58:09PM -0400, Jorge Arellano Cid wrote: > > * The HTML parser in table.cc does not create table widgets if > > USE_TABLES is not defined. Perhaps this code should do the > > same? > > Not necessary. That was an old feature for narrow displays. In that case, shouldn't we remove USE_TABLES entirely? > > * It would be nice if the widgets and the redirect link were > > styled from the User Agent style in css.cc . ... > > AFAIS, the warning widget needs its own scheme, like the rest of > the panel. Perhaps we could extend the default style in css.cc with clauses like "dillo meta-refresh-warning redirect { color: ... }", using "dillo" as a reserved CSS class for internal use? Then all of the style information would be in CSS and none of it would be hard-coded in the parser, which is how it should be. I still haven't worked out how to apply the CSS stylesheets to the widgets I create (the style engine mechanism isn't being applied because I create the widgets directly instead of from HTML). I tried adding calls to styleEngine->{startElement,endElement}() but nothing happened. I'm clearly still missing something. I'll have another look, but any tips will be welcome! Regards, Jeremy Henty

Sept. 22, 2009

[patch]: fix the meta-refresh warning code

by jcid＠dillo.org

Hi Jeremy, Good to see you around! On Sat, Sep 19, 2009 at 11:32:19PM +0100, Jeremy Henty wrote: > > Long time no post! Here's a fix for an outstanding TODO in html.cc. > It replaces the code that creates the HTML META REFRESH warning (which > sends HTML to Html_write_raw()) with a function that creates the > widgets directly. Hopefully I'll review it in the next days. > There are still a few issues: > > * The HTML parser in table.cc does not create table widgets if > USE_TABLES is not defined. Perhaps this code should do the same? Not necessary. That was an old feature for narrow displays. > > * The new widgets do not have 'width="100%"' set, so the horizontal > layout is slightly different. > > * The redirect link colour does not reflect whether the link URL has > been visited. > > * It would be nice if the widgets and the redirect link were styled > from the User Agent style in css.cc . I couldn't figure out how > to do that so I just copied a few things like the link colour and > text decoration. If someone tells me how to do this properly I'll > revise the code. AFAIS, the warning widget needs its own scheme, like the rest of the panel. > Please comment! More in the next days... -- Cheers Jorge.-

Sept. 22, 2009

[patch]: fix the meta-refresh warning code

by onepoint＠starurchin.org

Long time no post! Here's a fix for an outstanding TODO in html.cc. It replaces the code that creates the HTML META REFRESH warning (which sends HTML to Html_write_raw()) with a function that creates the widgets directly. There are still a few issues: * The HTML parser in table.cc does not create table widgets if USE_TABLES is not defined. Perhaps this code should do the same? * The new widgets do not have 'width="100%"' set, so the horizontal layout is slightly different. * The redirect link colour does not reflect whether the link URL has been visited. * It would be nice if the widgets and the redirect link were styled from the User Agent style in css.cc . I couldn't figure out how to do that so I just copied a few things like the link colour and text decoration. If someone tells me how to do this properly I'll revise the code. Please comment! Jeremy Henty

Sept. 20, 2009

Textblock::drawLine() split

by Johannes.Hofmann＠gmx.de

Hi corvid, this split was overdue! Thanks a lot for the cleanup. Cheers, Johannes

Sept. 19, 2009

experimental patch: image loading options "same domain", "same host"

by corvid＠lavabit.com

Johannes wrote: > On Tue, Sep 15, 2009 at 07:21:32PM +0000, corvid wrote: > > Johannes wrote: > > > Hm... With "same_host" many sites no longer work because they seem > > > to use redirects (e.g. heise.de -> www.heise.de) > > > And once I have entered heise.de, www.heise.de doesn't work either. > > > > I have also found same_host not to have any value. > > > > > Generally, is it really a problem if we load url's from other > > > hosts/domains? > > > > Sites have no right to redirect me to unrelated sites, and > > sites have no right to subject me to images from unrelated sites. > > I tend to agree. With your patch I noticed that many popular sites > contain 1x1 images from some statistics gathering companies. > However I think these images do not really leak additional information as > the sites could report your IP address behind the scenes as well. I think the term "user agent" for a browser is very apt. These companies ask dillo to serve as an accomplice as they violate the user's right to privacy.

Sept. 17, 2009

experimental patch: image loading options "same domain", "same host"

by Johannes.Hofmann＠gmx.de

On Tue, Sep 15, 2009 at 07:21:32PM +0000, corvid wrote: > Johannes wrote: > > Hm... With "same_host" many sites no longer work because they seem > > to use redirects (e.g. heise.de -> www.heise.de) > > And once I have entered heise.de, www.heise.de doesn't work either. > > I have also found same_host not to have any value. > > > Generally, is it really a problem if we load url's from other > > hosts/domains? > > Sites have no right to redirect me to unrelated sites, and > sites have no right to subject me to images from unrelated sites. I tend to agree. With your patch I noticed that many popular sites contain 1x1 images from some statistics gathering companies. However I think these images do not really leak additional information as the sites could report your IP address behind the scenes as well. Cheers, Johannes

Sept. 17, 2009

View page source suggestions

by jcid＠dillo.org

On Wed, Sep 16, 2009 at 03:48:06PM +0000, corvid wrote: > Dennis wrote: > > Currently, the "View page source" right-click context menu isn't > > available below the rendered html -- so if the actual html page is very > > small and/or dillo's window is very big, right clicking the bottom half > > (for example) of the browser does nothing :\. > > This one happens to have some complexity. > > The problem is that there aren't any widgets down there and they are > what send the signals to trigger the menus. Maybe it would be possible > to increase a layout's top-level widget's size to fill a viewport > (if the layout isn't inside a button [if there's a way to check that] > and the widget is a textblock), or maybe that would break something. Yes. Maybe adding an empty widget at the bottom may solve this. > > Also, is there a way to have the source viewed in one's preferred text > > editor? :b (read: gvim) > > Only the usual way :) The idea for "View source" is to handle it with a dpi so we we can reuse dillo (it's faster and has a search function). Once this is done (which needs a review of dpip), it would be simple to adapt the dpi program to use an external editor (because a dpi program is an independent process, that in this case, would receive the source contents). I'm currently working deep in the dpi-framework. Hopefully some good news may come at the end of the month... -- Cheers Jorge.-

Sept. 16, 2009

View page source suggestions

by corvid＠lavabit.com

Dennis wrote: > Currently, the "View page source" right-click context menu isn't > available below the rendered html -- so if the actual html page is very > small and/or dillo's window is very big, right clicking the bottom half > (for example) of the browser does nothing :\. This one happens to have some complexity. The problem is that there aren't any widgets down there and they are what send the signals to trigger the menus. Maybe it would be possible to increase a layout's top-level widget's size to fill a viewport (if the layout isn't inside a button [if there's a way to check that] and the widget is a textblock), or maybe that would break something. (I actually wonder whether the signaling could be routed back through the layout or something [perhaps making handling the case easier from fltkviewbase], since all of the connectLink()s always seemed redundant to me. That might go against Dw philosophy, though, whatever that might be exactly.) > Also, is there a way to have the source viewed in one's preferred text > editor? :b (read: gvim) Only the usual way :)

Sept. 16, 2009

View page source suggestions

by dennisn＠dennisn.dyndns.org

Currently, the "View page source" right-click context menu isn't available below the rendered html -- so if the actual html page is very small and/or dillo's window is very big, right clicking the bottom half (for example) of the browser does nothing :\. Also, is there a way to have the source viewed in one's preferred text editor? :b (read: gvim)

Sept. 16, 2009

experimental patch: image loading options "same domain", "same host"

by corvid＠lavabit.com

Johannes wrote: > Hm... With "same_host" many sites no longer work because they seem > to use redirects (e.g. heise.de -> www.heise.de) > And once I have entered heise.de, www.heise.de doesn't work either. I have also found same_host not to have any value. > Generally, is it really a problem if we load url's from other > hosts/domains? Sites have no right to redirect me to unrelated sites, and sites have no right to subject me to images from unrelated sites. > Or would it be enough to not send cookies or HTTP authentication > data when loading such "unsafe" urls?

Sept. 15, 2009

experimental patch: image loading options "same domain", "same host"

by Johannes.Hofmann＠gmx.de

On Tue, Sep 15, 2009 at 08:08:06PM +0200, Joerg Sonnenberger wrote: > On Tue, Sep 15, 2009 at 07:36:31PM +0200, Johannes Hofmann wrote: > > Or would it be enough to not send cookies or HTTP authentication > > data when loading such "unsafe" urls? > > Cookies have an explicit domain part if they are supposed to apply to > more than the current host. HTTP authentication is URL specific or at > most host specific. Not sure if that helps here. If the user has a cookie set that authenticates him at www.hisbank.com and a page on www.badguy.com contains an image with the url http://www.hisbank.com?transfer_to_badguy=100000 the browser would happily send the cookie to www.hisbank.com to authenticate him. Of course www.hisbank.com should have additional checks installed that prevent such misuse. Cheers, Johannes

Sept. 15, 2009

experimental patch: image loading options "same domain", "same host"

by joerg.sonnenberger＠web.de

On Tue, Sep 15, 2009 at 07:36:31PM +0200, Johannes Hofmann wrote: > Or would it be enough to not send cookies or HTTP authentication > data when loading such "unsafe" urls? Cookies have an explicit domain part if they are supposed to apply to more than the current host. HTTP authentication is URL specific or at most host specific. Joerg

Sept. 15, 2009

experimental patch: image loading options "same domain", "same host"

by Johannes.Hofmann＠gmx.de

On Tue, Sep 15, 2009 at 07:54:44PM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Johannes Hofmann wrote: > > Hello, > > > > On Sat, Sep 12, 2009 at 02:08:48AM +0000, corvid wrote: > >> Jorge wrote: > >>> On Sun, Sep 06, 2009 at 11:17:25PM +0000, corvid wrote: > >>>> I just put together a somewhat hacky patch to > >>>> add "same host" and "same domain" for image loading > >>>> from the tools button (or dillorc) > >>>> http://www.dillo.org/test/img_loading_options.patch > >>>> > >>>> I ran on it as long as I could tolerate images over > >>>> dialup (not long :), so here it is, and I will clean > >>>> it up if there is interest shown in getting it into > >>>> dillo. > >>> Good! I've had a similar idea for a long time. > >>> > >>> Since before the url filtering thread, I believe a simple > >>> blocking scheme based on same host/domain cuts most of the > >>> problem (bandwidth, privacy, tracking, web bugs etc). > >>> > >>> I'd suggest to add the filtering function in Capi. This is > >>> to make a_Capi_open_url() call a check function, e.g. > >>> > >>> if (Capi_filters_check_url(...) < 0) > >>> /* abort */ > >>> > >>> (you may add a ParentUrl DilloUrl to the webstructure). > >>> > >>> The point is to be able to reuse and improve the filter. > >>> (e.g. for CSS urls, sound streams, etc). > >>> > >>> > >>>> (I would probably want to change the names of the > >>>> dillorc choices for image loading, make the internal > >>>> value into an enum, look at the loadImages/autoload_image > >>>> code duplication, etc., etc... Oh, and look up how > >>>> to fix the tools menu width...) > >>> Something like: > >>> > >>> filter_remote_resources = {LOAD_ALL, SAME_HOST, SAME_DOMAIN} > >>> > >>> should be enough to get started. > >> I made a new one: > >> http://www.dillo.org/test/filtering.1.patch > >> > >> It doesn't have the menu stuff, so you have to > >> set the preference. > > > > Hm... With "same_host" many sites no longer work because they seem > > to use redirects (e.g. heise.de -> www.heise.de) > > And once I have entered heise.de, www.heise.de doesn't work either. > > > > Generally, is it really a problem if we load url's from other > > hosts/domains? > > > > Or would it be enough to not send cookies or HTTP authentication > > data when loading such "unsafe" urls? > If you're trying to protect dillo users from {X,C}SRF attacks then > stripping http authentication and cookies is a first step but it won't > protect users of intranet applications that rely on the users ip address > for authentication (think home routers with web interface). Ouch. Is there some general agreement on what web browsers should do in this regard?

Sept. 15, 2009

experimental patch: image loading options "same domain", "same host"

by 4winter＠informatik.uni-hamburg.de

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Johannes Hofmann wrote: > Hello, > > On Sat, Sep 12, 2009 at 02:08:48AM +0000, corvid wrote: >> Jorge wrote: >>> On Sun, Sep 06, 2009 at 11:17:25PM +0000, corvid wrote: >>>> I just put together a somewhat hacky patch to >>>> add "same host" and "same domain" for image loading >>>> from the tools button (or dillorc) >>>> http://www.dillo.org/test/img_loading_options.patch >>>> >>>> I ran on it as long as I could tolerate images over >>>> dialup (not long :), so here it is, and I will clean >>>> it up if there is interest shown in getting it into >>>> dillo. >>> Good! I've had a similar idea for a long time. >>> >>> Since before the url filtering thread, I believe a simple >>> blocking scheme based on same host/domain cuts most of the >>> problem (bandwidth, privacy, tracking, web bugs etc). >>> >>> I'd suggest to add the filtering function in Capi. This is >>> to make a_Capi_open_url() call a check function, e.g. >>> >>> if (Capi_filters_check_url(...) < 0) >>> /* abort */ >>> >>> (you may add a ParentUrl DilloUrl to the webstructure). >>> >>> The point is to be able to reuse and improve the filter. >>> (e.g. for CSS urls, sound streams, etc). >>> >>> >>>> (I would probably want to change the names of the >>>> dillorc choices for image loading, make the internal >>>> value into an enum, look at the loadImages/autoload_image >>>> code duplication, etc., etc... Oh, and look up how >>>> to fix the tools menu width...) >>> Something like: >>> >>> filter_remote_resources = {LOAD_ALL, SAME_HOST, SAME_DOMAIN} >>> >>> should be enough to get started. >> I made a new one: >> http://www.dillo.org/test/filtering.1.patch >> >> It doesn't have the menu stuff, so you have to >> set the preference. > > Hm... With "same_host" many sites no longer work because they seem > to use redirects (e.g. heise.de -> www.heise.de) > And once I have entered heise.de, www.heise.de doesn't work either. > > Generally, is it really a problem if we load url's from other > hosts/domains? > > Or would it be enough to not send cookies or HTTP authentication > data when loading such "unsafe" urls? If you're trying to protect dillo users from {X,C}SRF attacks then stripping http authentication and cookies is a first step but it won't protect users of intranet applications that rely on the users ip address for authentication (think home routers with web interface). Justus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqv1OQACgkQoPmwNWhsaZb+FACghNtaYfxcboMp1ovLmBZoy7LK MW4An08UfIfzcU2ktLqtmTLmfivzrECR =NrPe -----END PGP SIGNATURE-----

Sept. 15, 2009

experimental patch: image loading options "same domain", "same host"

by Johannes.Hofmann＠gmx.de

Hello, On Sat, Sep 12, 2009 at 02:08:48AM +0000, corvid wrote: > Jorge wrote: > > On Sun, Sep 06, 2009 at 11:17:25PM +0000, corvid wrote: > > > I just put together a somewhat hacky patch to > > > add "same host" and "same domain" for image loading > > > from the tools button (or dillorc) > > > http://www.dillo.org/test/img_loading_options.patch > > > > > > I ran on it as long as I could tolerate images over > > > dialup (not long :), so here it is, and I will clean > > > it up if there is interest shown in getting it into > > > dillo. > > > > Good! I've had a similar idea for a long time. > > > > Since before the url filtering thread, I believe a simple > > blocking scheme based on same host/domain cuts most of the > > problem (bandwidth, privacy, tracking, web bugs etc). > > > > I'd suggest to add the filtering function in Capi. This is > > to make a_Capi_open_url() call a check function, e.g. > > > > if (Capi_filters_check_url(...) < 0) > > /* abort */ > > > > (you may add a ParentUrl DilloUrl to the webstructure). > > > > The point is to be able to reuse and improve the filter. > > (e.g. for CSS urls, sound streams, etc). > > > > > > > (I would probably want to change the names of the > > > dillorc choices for image loading, make the internal > > > value into an enum, look at the loadImages/autoload_image > > > code duplication, etc., etc... Oh, and look up how > > > to fix the tools menu width...) > > > > Something like: > > > > filter_remote_resources = {LOAD_ALL, SAME_HOST, SAME_DOMAIN} > > > > should be enough to get started. > > I made a new one: > http://www.dillo.org/test/filtering.1.patch > > It doesn't have the menu stuff, so you have to > set the preference. Hm... With "same_host" many sites no longer work because they seem to use redirects (e.g. heise.de -> www.heise.de) And once I have entered heise.de, www.heise.de doesn't work either. Generally, is it really a problem if we load url's from other hosts/domains? Or would it be enough to not send cookies or HTTP authentication data when loading such "unsafe" urls? Cheers, Johannes

Sept. 15, 2009

organizational boundaries [Re: [Dillo-dev] experimental patch: image loading options "same domain", "same host"]

by corvid＠lavabit.com

Looking around some more for information on how to deal with the fact that, e.g., www.dillo.org and hg.dillo.org are one thing and bbc.co.uk and theregister.co.uk aren't. (I'd like a better name for this than the "same domain" that I've been using.) And I discovered http://publicsuffix.org Perhaps someday we could let people stuff this big long list into .dillo/ if they want to.

Sept. 12, 2009