- Dillo-dev - lists.mailman3.com

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