January 2013 - Dillo-dev - lists.mailman3.com

White on white for the active tab

by onepoint＠starurchin.org

corvid wrote: > Jeremy wrote: > > I am getting white text on a white background for the active tab. I > > haven't changed any colours form the defaults. Why would this be? > > Fixed :) Thanks! Jeremy Henty

Jan. 10, 2013

White on white for the active tab

by corvid＠lavabit.com

Jeremy wrote: > I am getting white text on a white background for the active tab. I > haven't changed any colours form the defaults. Why would this be? Fixed :)

Jan. 10, 2013

White on white for the active tab

by onepoint＠starurchin.org

I am getting white text on a white background for the active tab. I haven't changed any colours form the defaults. Why would this be? Regards, Jeremy Henty

Jan. 10, 2013

Patch for xembed updated

by podarcis＠lavabit.com

> > When porting dillo to fltk we had to implement xembed on our own or > break support for the claws-mail plugin. > That's why we added xembed.cc. > Thank you for the infos. Keeping compatability is of course a main goal... Nevertheless I am still not really certain, what the current xembed protocol implementation does - or does *NOT*. Please have a look at the enclosed diff 'xembed_removed_demo.diff', that removes the *WHOLE* xembed protocol implementation and only keeps the window creation. Still embedding with 'tabbed' works as before. This really makes me wonder... > I would prefer a minimal fltk-based example program in the test > directory, that implements the embedder side of xembed. > It shouldn't be too hard to do (e.g. by looking at the tabbed > sources). > It would be cool if you would like to work on that. Sorry, but I don't feel able to do this proper. Looking at the xembed protocol specification makes me consider that as an extremely time-consuming task. One idea, which could make us both happy: I have again updated my patch, so that using the xembed protocol can be specified by the application. If using it (and that's the default of course) will run the current xembed code effectively unchanged. This way there should be no compatabiliy issues (The way I have designed that option is only an outline, maybe this can be done better). Only if running with xembed protocol disabled my patch comes into action. --> xembed_patch_xembed_protocol_set.diff --> dembed.cxx Cheers, Podarcis

Jan. 9, 2013

font_factor

by corvid＠lavabit.com

Johannes wrote: > On Tue, Jan 08, 2013 at 11:55:42PM +0000, corvid wrote: > > > > I wrote: > > > In styleengine, we use font_factor for calculation of larger and x-small > > > and so forth, but we don't apply it when given an ordinary font size like > > > 11px. > > > > Just to double-check: That's not intended behaviour, right? > > > > sorry for the delay... > This is intentional, but we know that there is a usability issue. > In CSS px, mm, pt etc. define absolute sizes [1]. > So if we want to adhere to the CSS spec strictly I think we can't > just scale them. > On the other hand web designers just use px without thinking about > the implications. Also other browsers allow scaling of those fonts > afaik. > I think we have the following options: > > * ignore CSS and apply font_factor also to absolute font sizes > * implement a zoom feature that displays everything larger (also > images etc. > * check other browsers for more alternatives Applying font_factor seems much more usable to me. A zoom feature would be cool, though. I wonder whether there's some level where we could get cheap and halfway tolerable zooming by throwing some of fltk's matrix transformation stuff at what we're drawing.

Jan. 9, 2013

drawing areas with negative coordinates

by corvid＠lavabit.com

Just something I noticed. There aren't an overwhelming number of them, so it seems like...not too big of a deal. I have the impression that it generally means that something is being drawn while an allocation somewhere is still (-1, -1, 1, 1). diff -r 35fb41bd0cdb dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Wed Jan 09 16:40:25 2013 +0000 +++ b/dw/fltkviewbase.cc Wed Jan 09 17:17:36 2013 +0000 @@ -431,8 +431,14 @@ void FltkViewBase::queueDraw (core::Rectangle *area) { - drawRegion.addRectangle (area); - damage (FL_DAMAGE_USER1); + static int counter = 0; + if (area->y < 0) { + MSG("%d let's not draw (%d,%d) w %d h %d\n", counter++, area->x, area->y, + area->width, area->height); + } else { + drawRegion.addRectangle (area); + damage (FL_DAMAGE_USER1); + } } void FltkViewBase::queueDrawTotal ()

Jan. 9, 2013

[patch] dClose

by jcid＠dillo.org

On Wed, Jan 09, 2013 at 05:27:55PM +0400, p37sitdu at lavabit.com wrote: > Merged a_Misc_close_fd, Dpi_close_fd and Http_socket_close into dClose > and moved it into dlib. Replaced close calls with calls to dClose. Good! Committed. -- Cheers Jorge.-

Jan. 9, 2013

[patch] dClose

by p37sitdu＠lavabit.com

Merged a_Misc_close_fd, Dpi_close_fd and Http_socket_close into dClose and moved it into dlib. Replaced close calls with calls to dClose.

Jan. 9, 2013

drawing highlighting

by sgeerken＠dillo.org

On Tue, Jan 08, corvid wrote: > > I was looking at draw() calls for the view, and I saw how there was a > call for every time that the mouse moved when highlighting even though > the text highlighted didn't necessarily change. > > Here's quick code to demonstrate that there are plenty of redundant ones. > I don't know the iterator code well enough to know whether that's the > right place to do anything about it, though... Your patch makes sense, and I've committed it (slightly changed). The purpose of Iterator::highlight is to change a state, and so it should be checked, whether the state has changed at all. Sebastian

Jan. 9, 2013

font_factor

by johannes.hofmann＠gmx.de

On Tue, Jan 08, 2013 at 11:55:42PM +0000, corvid wrote: > > I wrote: > > In styleengine, we use font_factor for calculation of larger and x-small > > and so forth, but we don't apply it when given an ordinary font size like > > 11px. > > Just to double-check: That's not intended behaviour, right? > sorry for the delay... This is intentional, but we know that there is a usability issue. In CSS px, mm, pt etc. define absolute sizes [1]. So if we want to adhere to the CSS spec strictly I think we can't just scale them. On the other hand web designers just use px without thinking about the implications. Also other browsers allow scaling of those fonts afaik. I think we have the following options: * ignore CSS and apply font_factor also to absolute font sizes * implement a zoom feature that displays everything larger (also images etc. * check other browsers for more alternatives [1] http://www.w3.org/TR/CSS21/fonts.html#font-size-props

Jan. 9, 2013