- Dillo-dev - lists.mailman3.com

[patch] modified a_Dialog_choice5 to accept any number alternatives

by jcid＠dillo.org

On Sun, Jan 06, 2013 at 02:57:48AM +0400, p37sitdu at lavabit.com wrote: > -5 LOC, nothing is changed visually Committed. -- Cheers Jorge.-

Jan. 11, 2013

namespace comments in dw/*

by corvid＠lavabit.com

p37sitdu wrote: > Copied comments are almost in every source file. Committed.

Jan. 11, 2013

Patch for xembed updated

by podarcis＠lavabit.com

> 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... Update: I just tested Claws Mail (writing this mail with it) from the Ubuntu 12.04 distribution together with the 'Dillo_Viewer' plugin (which was not so easy to get, because it is not longer in this distribution - I had to take it from another distibution, openSuse-12.2) Result: dillo with the *removed xembed support* (see previous posting) integrates perfectly (including resizing) into the Claws Mail preview window! Also does dillo with *my patch*. Just to let you know.. Cheers, podarcis

Jan. 11, 2013

patches

by p37sitdu＠lavabit.com

Just added man-pages.patch that adds dpid.1 and dpidc.1 man pages.

Jan. 11, 2013

patches

by p37sitdu＠lavabit.com

I have uploaded some of my patches that were not commited (yet) to http://www.inventati.org/noname/dillo/ so it is easier to track them. Descriptions are embedded inside.

Jan. 11, 2013

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