- Dillo-dev - lists.mailman3.com

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<I>::FltkToggleButtonResource::isActivated () ^ cc-1443 CC: ERROR File = fltkui.cc, Line = 782 "dw::fltk::ui::FltkToggleButtonResource<I>::FltkToggleButtonResource" is not a class template. bool FltkToggleButtonResource<I>::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