- Dillo-dev - lists.mailman3.com

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

[patch] consistent file save UI behaviour for overwriting files

by onepoint＠starurchin.org

corvid wrote: > Jeremy wrote: > > These two patches move the UI logic from the downloads DPI into > > Dillo. This puts all the UI logic in the same place and ensures > > consistent behaviour for "Save link as file" whether or not the > > URL is cached. > > Seems good to have the logic in dillo. OK, it's in. > I imagine a later step would be to teach UIcmd_save_file_check() > about file permissions, errno possibilities, etc. I guess so, although in the case of the file not existing you would want to check whether the missing component was the last one in the path or not. Regards, Jeremy Henty

Jan. 8, 2013

dillo3.0.2 Irix

by corvid＠lavabit.com

Jan wrote: > Nothing new with this patch. I found out it is not random, it > depends on the length: > > I can open: > > file:/tmp/12345678901234567890123.jpg > > but > > file:/tmp/123456789012345678901234.jpg > > returns a 404 32-byte limit? The first thing that popped into my mind was that sufficiently ancient systems would have path length limits like 32, but I don't see why that would apply here... dpi/file.c's File_normalize_path() has a "Dstr *ds = dStr_sized_new(32)". You could change the number and see whether anything happens. Although if Dstr should have problems resizing itself on irix, I'd be very surprised that dillo could even run at all.

Jan. 8, 2013