- Dillo-dev - lists.mailman3.com

CustChoice

by jcid＠dillo.org

On Sat, Jan 26, 2013 at 04:55:53PM +0000, corvid wrote: > Jorge wrote: > > On Wed, Jan 16, 2013 at 08:03:31PM +0000, corvid wrote: > > > > > > I was looking into why the search dialog would no longer let me tab to > > > the search engine list and press down arrow to switch between them... > > > It seems that, once Jorge added a CustChoice in fltkui.cc, the dialog code > > > started to use _that_ one and not its own. > > > > Funny how this also annoys me, while thinking it was one of your > > patches that changed the behaviour! ;-) > > > > Of course I'm not sure, and will review the issue, but *feel* > > happy about not being alone in longing for the old bahaviour. > > Perhaps we could have one CustChoice that everything uses, although I > don't know where we'd put it. Yes, I'm also looking on that... Well, at least I have code to "fix" the dialog issue and also let FORM options also work as the search dialog. I'm yet to find out why the compiler/linker *seems* to be picking the wrong CustomChoice class. I focused on fixing the practical problem first. Patch soon. -- Cheers Jorge.-

Jan. 28, 2013

Another SGI compiler problem

by csoren＠isd.net

> > Any problem if you change > bool FltkToggleButtonResource::FltkToggleButtonResource::isActivated () > to > bool FltkToggleButtonResource::isActivated () > ? > Thanks that worked!

Jan. 27, 2013

CustChoice

by corvid＠lavabit.com

Jorge wrote: > On Wed, Jan 16, 2013 at 08:03:31PM +0000, corvid wrote: > > > > I was looking into why the search dialog would no longer let me tab to > > the search engine list and press down arrow to switch between them... > > It seems that, once Jorge added a CustChoice in fltkui.cc, the dialog code > > started to use _that_ one and not its own. > > Funny how this also annoys me, while thinking it was one of your > patches that changed the behaviour! ;-) > > Of course I'm not sure, and will review the issue, but *feel* > happy about not being alone in longing for the old bahaviour. Perhaps we could have one CustChoice that everything uses, although I don't know where we'd put it.

Jan. 26, 2013

CustChoice

by jcid＠dillo.org

On Wed, Jan 16, 2013 at 08:03:31PM +0000, corvid wrote: > > I was looking into why the search dialog would no longer let me tab to > the search engine list and press down arrow to switch between them... > It seems that, once Jorge added a CustChoice in fltkui.cc, the dialog code > started to use _that_ one and not its own. Funny how this also annoys me, while thinking it was one of your patches that changed the behaviour! ;-) Of course I'm not sure, and will review the issue, but *feel* happy about not being alone in longing for the old bahaviour. -- Cheers Jorge.-

Jan. 26, 2013

Another SGi compiler problem

by corvid＠lavabit.com

Chris wrote: > Fourteen files compiled so far but then this happened in > fltkflatview.cc: > > ---------------------------------------------- > cc-3168 CC: ERROR File = fltkui.cc, Line = 782 > A name followed by "::" must be a class or namespace name. > > bool > FltkToggleButtonResource::FltkToggleButtonResource::isActivated > () > ^ > > cc-1443 CC: ERROR File = fltkui.cc, Line = 782 > > "dw::fltk::ui::FltkToggleButtonResource::FltkToggleButtonResource" > is not a > class template. > > bool > FltkToggleButtonResource::FltkToggleButtonResource::isActivated > () > ^ > > 2 errors detected in the compilation of "fltkflatview.cc". > ----------------------------------------------- > > Thoughts? Any problem if you change bool FltkToggleButtonResource::FltkToggleButtonResource::isActivated () to bool FltkToggleButtonResource::isActivated () ?

Jan. 24, 2013

Another SGi compiler problem

by csoren＠isd.net

> > > > Greets all, > > > > I'm trying to compile on Silicon Graphics (IRIX O.S.) > > using their MIPSPro 7.4 > > compiler, but getting this error in dialog.cc: > > > > <pre> > > cc-1028 CC: ERROR File = dialog.cc, Line = 180 > > The expression used must have a constant value. > > > > memset(pm, '\0', sizeof(Fl_Menu_Item[n_it+1])); > > ^ > > </pre> > > > > Thoughts? > > You may try something like: > > memset(pm, '\0', (n_it+1)*sizeof(Fl_Menu_Item)); > > -- > Cheers > Jorge.- Thanks Jorge that worked! :) Fourteen files compiled so far but then this happened in fltkflatview.cc: ---------------------------------------------- cc-3168 CC: ERROR File = fltkui.cc, Line = 782 A name followed by "::" must be a class or namespace name. bool FltkToggleButtonResource::FltkToggleButtonResource::isActivated () ^ cc-1443 CC: ERROR File = fltkui.cc, Line = 782 "dw::fltk::ui::FltkToggleButtonResource::FltkToggleButtonResource" is not a class template. bool FltkToggleButtonResource::FltkToggleButtonResource::isActivated () ^ 2 errors detected in the compilation of "fltkflatview.cc". ----------------------------------------------- Thoughts?

Jan. 24, 2013

[patch] dCalloc

by p37sitdu＠lavabit.com

dNew macro hides multiplication and can lead to integer overflows. Patch implements dCalloc and replaces dNew with dCalloc wrapper so no integer overflows are possible: http://www.inventati.org/noname/dillo/dlib/dcalloc.patch dwrite.patch is moved to http://www.inventati.org/noname/dillo/dlib/

Jan. 23, 2013

_t suffix

by p37sitdu＠lavabit.com

Suffix _t is reverved by POSIX and should not be used: <http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html> I have made patches that remove _t suffix from some modules: http://www.inventati.org/noname/dillo/_t/

Jan. 23, 2013

line wrap for Japanese

by furaisanjin＠gmail.com

2013/1/23 Sebastian Geerken <sgeerken at dillo.org>: > Ah, ideographic characters again. Should be fixed, please check the > latest commit. Thanks. The problem is fixed. Regards, furaisanjin

Jan. 23, 2013

dereferencing type-punned pointer warning

by sgeerken＠dillo.org

On Mon, Jan 14, Johannes Hofmann wrote: > line 135 in lout object.cc: > return ((int*)&value)[0] ^ ((int*)&value)[1]; > > causes the following error on 64bit systems for me: > > warning: dereferencing type-punned pointer will > break strict-aliasing rules > > Can we replace it like this: [...] Committed, and tested with an amd64 system. Actually, this code is never used in dillo, but in objman-test, for which I fixed a bug in this method. Sebastian

Jan. 22, 2013

line wrap for Japanese

by sgeerken＠dillo.org

On Mon, Jan 21, furaisanjin wrote: > It seems that change set de05508cbbbd causes the line wrap problem for > Japanese. Certain lines become very long and I don't see appropriate > line wrap in the middle. Ah, ideographic characters again. Should be fixed, please check the latest commit. Sebastian

Jan. 22, 2013

[patch] Scrollbar thickness from dillorc

by corvid＠lavabit.com

Johannes wrote: > On Sun, Jan 20, 2013 at 04:01:11PM +0100, podarcis wrote: > > Scrollbars currently have the hardcoded thickness 15. This can be too > > small to operate dillo on large screens or with fingers on a touch > > screen. > > > > The supplied patch does the following: > > > > - Adds the prefence "scrollbar_tickness" to dillorc. > > > > - Reads the value into the prefences > > (Note: added a type UINT32 to prefsparse.cc) > > > > - Sets this value to the FltkViewport with the new > > method FltkViewport::setScrollbarThickness(). > > > > Note: I deliberately did no check for value 0, which can therefore be > > used to make the scrollbars invisible. Scrolling can then still be > > achieved with the cursor keys. This could be called a feature. > > I like the idea and want to commit this if no one objects. > Some issues I see with the current patch: > > * I would rather drop PREFS_UINT32 and simply use > PREFS_INT32 instead. But if we want to keep it, it should warn if > a negative value is assigned to a PREFS_UINT32 variable. > * Similarily in dw/* I would use int instead of size_t. We also use > int for width and height as does fltk. > * In C++ code we use camel cased variables and paramters, so it > should be scrollbarThickness in dw/*. > * I'd make the scrollbarThickness member in FltkViewport non-static > and it should be private. No objection to having the preference, although I note that, with the patch as it is: - if I set the thickness to something like fifty, there is text hidden under the scrollbar that I can see if I drag the page. Putting the setScrollbarThickness() earlier in UIcmd_tab_new() seems to fix it. - if I set the thickness to a negative number, dragging can make the page unreadable if the page is narrow enough that it wants a horizontal scrollbar (not that we'd permit negative values).

Jan. 21, 2013

[patch] Scrollbar thickness from dillorc

by Johannes.Hofmann＠gmx.de

On Sun, Jan 20, 2013 at 04:01:11PM +0100, podarcis wrote: > Scrollbars currently have the hardcoded thickness 15. This can be too > small to operate dillo on large screens or with fingers on a touch > screen. > > The supplied patch does the following: > > - Adds the prefence "scrollbar_tickness" to dillorc. > > - Reads the value into the prefences > (Note: added a type UINT32 to prefsparse.cc) > > - Sets this value to the FltkViewport with the new > method FltkViewport::setScrollbarThickness(). > > Note: I deliberately did no check for value 0, which can therefore be > used to make the scrollbars invisible. Scrolling can then still be > achieved with the cursor keys. This could be called a feature. I like the idea and want to commit this if no one objects. Some issues I see with the current patch: * I would rather drop PREFS_UINT32 and simply use PREFS_INT32 instead. But if we want to keep it, it should warn if a negative value is assigned to a PREFS_UINT32 variable. * Similarily in dw/* I would use int instead of size_t. We also use int for width and height as does fltk. * In C++ code we use camel cased variables and paramters, so it should be scrollbarThickness in dw/*. * I'd make the scrollbarThickness member in FltkViewport non-static and it should be private. I especially like that one can set scrollbar_thickness to 0 in dillorc. Cheers, Johannes

Jan. 21, 2013

line wrap for Japanese

by furaisanjin＠gmail.com

Hello all. It seems that change set de05508cbbbd causes the line wrap problem for Japanese. Certain lines become very long and I don't see appropriate line wrap in the middle. Regards, furaisanjin

Jan. 21, 2013

[patch] Scrollbar thickness from dillorc

by podarcis＠lavabit.com

> Just curious whether you've experimented with incorporating > Fl::scrollbar_size() into this. > My initial idea was indeed to just set Fl::scrollbar_size() from the prefences and use it from the rest of the code. But then I decided against, because of several reasons: - there is code in FltkViewport that (though unused) tries to make different vertical/horizontal scrollbar widths possible. - the current code seems not to use any of the FLTK scrollbar_size() methods, not even Fl_Scrollbar::scrollbar_size(), so I thought this is intentional. - anyway I wanted the change to be small and close to the existing implementation. > Aside: A few years ago, there was a little bit of discussion now and > then about improving the UI for touch, but unfortunately it would all > die down without us getting much further than "Hmm, that's an > interesting idea..." > Yes, of course, if you want to make the rest of the UI also fit for touchscreen then there's much to do. All those tiny buttons are unsuitable. I mostly intend to use dillo in fullscreen mode, where all controls are hidden, so scrollbars are nearly the only problem. Cheers, podarcis _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Jan. 20, 2013

[patch] Scrollbar thickness from dillorc

by corvid＠lavabit.com

podarcis wrote: > Scrollbars currently have the hardcoded thickness 15. This can be too > small to operate dillo on large screens or with fingers on a touch > screen. > > The supplied patch does the following: > > - Adds the prefence "scrollbar_tickness" to dillorc. > > - Reads the value into the prefences > (Note: added a type UINT32 to prefsparse.cc) > > - Sets this value to the FltkViewport with the new > method FltkViewport::setScrollbarThickness(). > > Note: I deliberately did no check for value 0, which can therefore be > used to make the scrollbars invisible. Scrolling can then still be > achieved with the cursor keys. This could be called a feature. Just curious whether you've experimented with incorporating Fl::scrollbar_size() into this. Aside: A few years ago, there was a little bit of discussion now and then about improving the UI for touch, but unfortunately it would all die down without us getting much further than "Hmm, that's an interesting idea..."

Jan. 20, 2013

[patch] Scrollbar thickness from dillorc

by podarcis＠lavabit.com

Scrollbars currently have the hardcoded thickness 15. This can be too small to operate dillo on large screens or with fingers on a touch screen. The supplied patch does the following: - Adds the prefence "scrollbar_tickness" to dillorc. - Reads the value into the prefences (Note: added a type UINT32 to prefsparse.cc) - Sets this value to the FltkViewport with the new method FltkViewport::setScrollbarThickness(). Note: I deliberately did no check for value 0, which can therefore be used to make the scrollbars invisible. Scrolling can then still be achieved with the cursor keys. This could be called a feature. Cheers, podarcis

Jan. 20, 2013

drawing highlighting

by corvid＠lavabit.com

For highlighting in a single word:

Jan. 19, 2013

[patch] disable SSLv2 support

by Johannes.Hofmann＠gmx.de

On Fri, Jan 18, 2013 at 01:57:49AM +0400, p37sitdu at lavabit.com wrote: > http://www.inventati.org/noname/dillo/https-no-SSLv2.patch > > I have found HTTPS server that Dillo was unable to connect to. > > After defining SILENT to 0 in https.c I found that SSL_connect > failed. Adding ERR_print_errors_fp(stderr) showed error > "SSL23_GET_SERVER_HELLO:unknown protocol". > > Disabling SSLv2 support fixed the problem for me. And SSLv2 is > insecure so it must be disabled anyway. committed! Thanks, Johannes

Jan. 18, 2013

[patch] dWrite

by p37sitdu＠lavabit.com

http://www.inventati.org/noname/dillo/dwrite.patch Removed Dpi_blocking_write from src/IO/dpi.c and moved similar code to dlib. Also fixes ckd_write in dpid/dpid_common.c: it handled EINTR, but did not handle situation when number of bytes written is less then requested. Now it uses dWrite.

Jan. 18, 2013

[patch] disable SSLv2 support

by p37sitdu＠lavabit.com

http://www.inventati.org/noname/dillo/https-no-SSLv2.patch I have found HTTPS server that Dillo was unable to connect to. After defining SILENT to 0 in https.c I found that SSL_connect failed. Adding ERR_print_errors_fp(stderr) showed error "SSL23_GET_SERVER_HELLO:unknown protocol". Disabling SSLv2 support fixed the problem for me. And SSLv2 is insecure so it must be disabled anyway.

Jan. 17, 2013

chain.c cleanup

by p37sitdu＠lavabit.com

http://www.inventati.org/noname/dillo/chain-cleanup.patch 1. Replaced dNew with dMalloc and dNew0 with dMalloc0. This way it is possible to use (sizeof *var) instead of repeating variable type. By the way, when 'count' is constant, dMalloc is easier to use, and when count is not constant, integer overflow can happen in dNew during multiplication. It looks like there are no such errors, but I think check should be added or, better, dCalloc can be introduced so libc checks for such cases. 2. Replaced #defines with enums and made them uppercase so it is easier to distinguish them from variables. This style is already used in most modules. IO should be fixed too, probably. 3. Moved duplicate code from a_Chain_fcb and a_Chain_bcb to Chain_cb. Anonymous structures for connections (forward or backward) are introduced in ChainLink structure for this purpose. 4. Removed unused a_Chain_unlink function. Chain links are just dFreed instead. Anyway, there is no function to connect existing links back, so disconnected link can only be dFreed. 5. Replaced AtoB_branch and BtoA_branch parameters of a_Chain_link_new with single Branch parameter. They were always equal anyway, and using different branch identifiers for one connection makes no sense, as branch ID is used to distinguish between Answer and Query chains. Branch parameter can be eliminated completely by separating existing CCC callbacks into answer and query callbacks. Currently instead of two functions we have one with if (Branch == 1) { ... } else { ... }

Jan. 17, 2013

CustChoice

by corvid＠lavabit.com

I was looking into why the search dialog would no longer let me tab to the search engine list and press down arrow to switch between them... It seems that, once Jorge added a CustChoice in fltkui.cc, the dialog code started to use _that_ one and not its own. (I would've expected something to complain about there being two CustChoice::handle()s in that case...) Would it be considered incorrect in any way if fltkui.cc's CustChoice and CustInput2 were put inside dw::fltk::ui?

Jan. 16, 2013

[patch] a_Dpip_send_cmd

by p37sitdu＠lavabit.com

I have fixed the patch and reread it. Link is the same: http://www.inventati.org/noname/dillo/dpip-send-cmd.patch

Jan. 15, 2013

tooltip in the way when typing

by corvid＠lavabit.com

With fltk's built-in tooltip system, Fl::handle_(), upon receipt of a FL_KEYBOARD event, calls Fl_Tooltip::enter((Fl_Widget*)0); to hide the tooltip. Once in a while, after giving a text input focus, I'm careless with the mouse, moving it away and then back over the input, putting a tooltip over what I'm typing. (And presumably textareas could have that happen as well...) Here's one way that it could be dealt with:

Jan. 15, 2013

dereferencing type-punned pointer warning

by Johannes.Hofmann＠gmx.de

Hi, line 135 in lout object.cc: return ((int*)&value)[0] ^ ((int*)&value)[1]; causes the following error on 64bit systems for me: warning: dereferencing type-punned pointer will break strict-aliasing rules Can we replace it like this: diff -r dd6f2d1eb15a lout/object.cc --- a/lout/object.cc Mon Jan 14 10:26:37 2013 -0300 +++ b/lout/object.cc Mon Jan 14 21:56:46 2013 +0100 @@ -21,6 +21,7 @@ #include "object.hh" #include <stdio.h> +#include <stdint.h> #include <config.h> namespace lout { @@ -132,7 +133,7 @@ // Combine both parts of the pointer value *itself*, not what it // points to, by first referencing it (operator "&"), then // dereferencing it again (operator "[]"). - return ((int*)&value)[0] ^ ((int*)&value)[1]; + return ((intptr_t)value >> 32) ^ ((intptr_t)value); #endif } Cheers, Johannes

Jan. 14, 2013

[patch] a_Dpip_send_cmd

by jcid＠dillo.org

Hi, On Sun, Jan 13, 2013 at 01:41:37AM +0400, p37sitdu at lavabit.com wrote: > http://www.inventati.org/noname/dillo/dpip-send-cmd.patch > > Patch adds a_Dpip_send_cmd and helper function a_Dpip_vbuild_cmd. > > This way common pattern > > d_cmd = a_Dpip_build_cmd(format, ...); > st = a_Dpip_dsh_write_str(sh, flush, d_cmd); > dFree(d_cmd); > > can be replaced with > > st = a_Dpip_send_cmd(sh, flush, format, ...); The idea looks good, and after applying it, the patch doesn't compile; the problem is trivial but it makes me hesitate. Please at least check the patch compiles, and that the functionality it changes/modifies works for every case, before submitting. TIA. -- Cheers Jorge.-

Jan. 14, 2013

mare patches for dpid

by jcid＠dillo.org

On Sat, Jan 12, 2013 at 10:39:54PM +0400, p37sitdu at lavabit.com wrote: > http://www.inventati.org/noname/dillo/dpid-dclose.patch > http://www.inventati.org/noname/dillo/dpid-no_dotfiles.patch Committed. -- Cheers Jorge.-

Jan. 14, 2013

Patch for xembed updated

by higuita7＠yahoo.co.uk

Hi > I don't know if the claws plugin is still used by anyone, but I > don't want to remove the code, that proved to be working. I use both dillo and claws-mail, where i load the dillo plugin... so, yes, it is still used, at least by me :) Thanks for dillo :) 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

Jan. 14, 2013

Patch for xembed updated

by Johannes.Hofmann＠gmx.de

On Fri, Jan 11, 2013 at 06:17:08PM +0100, podarcis wrote: > > > 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.. I know that it works partly with just simple reparenting, but it has problems. We went through all this see the thread starting with: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-May/006453.html and the final success messages from claws-mail people here: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-June/006533.html I don't know if the claws plugin is still used by anyone, but I don't want to remove the code, that proved to be working. Cheers, Johannes

Jan. 13, 2013

ui colors again

by corvid＠lavabit.com

http://www.dillo.org/test/color_themes.diff I was just playing around with making themes selectable. I typed in some color themes that Jorge has suggested, and typos in them are possible. I tried using some of the fltk color indices for our tab colors and button highlight color in order to make the code more uniform, placing the #defines in prefs for lack of an obviously good location. It has code to fix the deactivated icons when the background color changes, but I'm still not very pleased with it.

Jan. 13, 2013

font_factor

by Johannes.Hofmann＠gmx.de

On Fri, Jan 11, 2013 at 05:24:51PM -0300, Jorge Arellano Cid wrote: > On Wed, Jan 09, 2013 at 09:16:08AM +0100, Johannes Hofmann 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 > > I'd apply font_factor, especially if that's what other browsers do. > > > * implement a zoom feature that displays everything larger (also > > images etc. > > Scaling images may hurt (think of PDAs). > An image_factor may help for those (just a wild thought). > > > * check other browsers for more alternatives > > Should check before making a decision. My Firefox has a zoom option, that zooms all text and images and an additional option to zoom text only. I also tend to a apply font_factor to all text. Cheers, Johannes

Jan. 12, 2013

[patch] a_Dpip_send_cmd

by p37sitdu＠lavabit.com

http://www.inventati.org/noname/dillo/dpip-send-cmd.patch Patch adds a_Dpip_send_cmd and helper function a_Dpip_vbuild_cmd. This way common pattern d_cmd = a_Dpip_build_cmd(format, ...); st = a_Dpip_dsh_write_str(sh, flush, d_cmd); dFree(d_cmd); can be replaced with st = a_Dpip_send_cmd(sh, flush, format, ...);

Jan. 12, 2013

mare patches for dpid

by p37sitdu＠lavabit.com

http://www.inventati.org/noname/dillo/dpid-dclose.patch http://www.inventati.org/noname/dillo/dpid-no_dotfiles.patch

Jan. 12, 2013

[patch] list.h cleanup

by p37sitdu＠lavabit.com

http://www.inventati.org/noname/dillo/list.h.patch

Jan. 12, 2013

Intermitent internet access

by jcid＠dillo.org

Hi, FYI, I'm away from home and with intermitent Internet connection. -- Cheers Jorge.-

Jan. 11, 2013

font_factor

by jcid＠dillo.org

On Wed, Jan 09, 2013 at 09:16:08AM +0100, Johannes Hofmann 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 I'd apply font_factor, especially if that's what other browsers do. > * implement a zoom feature that displays everything larger (also > images etc. Scaling images may hurt (think of PDAs). An image_factor may help for those (just a wild thought). > * check other browsers for more alternatives Should check before making a decision. -- Cheers Jorge.-

Jan. 11, 2013

White on white for the active tab

by jcid＠dillo.org

On Thu, Jan 10, 2013 at 08:26:44PM +0000, Jeremy Henty wrote: > > 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! BTW, # # Gray theme (traditional) # ui_fg_color=black ui_main_bg_color=silver ui_text_bg_color=#bfdabf # ui_selection_color # ui_button_highlight_color ui_tab_active_bg_color=#87aca7 ui_tab_bg_color=#b7beb7 # ui_tab_active_fg_color # ui_tab_fg_color -- Cheers Jorge.-

Jan. 11, 2013

[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

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