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

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