We always assumed that the keycode type was 32bits wide, anyway. wchar_t isn't guaranteed to be that big, so isn't remotely portable.
svn path=/trunk/netsurf/; revision=4165
Do not change the locale globally, else things will break in weird and
wonderful ways.
Introduce utils/locale.[ch], which provide locale-specific wrappers for various
functions (currently just the <ctype.h> ones).
Fix up the few places I can see that actually require that the underlying
locale is paid attention to.
Some notes:
1) The GTK frontend code has not been touched. It is possible that reading of
numeric values (e.g. from the preferences dialogue) may break with this
change, particularly in locales that use something other than '.' as their
decimal separator.
2) The search code is left unchanged (i.e. assuming a locale of "C").
This may break case insensitive matching of non-ASCII characters.
I doubt that ever actually worked, anyway. In future, it should use
Unicode case conversion to achieve the same effect.
3) The text input handling in the core makes use of isspace() to detect
word boundaries. This is fine for western languages (even in the C locale,
which it's currently assuming). It will, however, break for CJK et. al.
(this has always been the case, rather than being a new issue)
4) text-transform uses locale-specific variants of to{lower,upper}. In future
this should probably be performing Unicode case conversion. This is the
only part of the core code that makes use of locale information.
In future, if you require locale-specific behaviour, do the following:
setlocale(LC_<whatever>, "");
<your operation(s) here>
setlocale(LC_<whatever>, "C");
The first setlocale will change the current locale to the native environment.
The second setlocale will reset the current locale to "C".
Any value other than "" or "C" is probably a bug, unless there's a really
good reason for it.
In the long term, it is expected that all locale-dependent code will reside in
platform frontends -- the core being wholly locale agnostic (though assuming
"C" for things like decimal separators).
svn path=/trunk/netsurf/; revision=4153
+ Fix redraw bug where parts of old selections would get left behind
+ Enable selection of list marker boxes (bullet points and numbers)
+ Improve formatting of copied-to-clipboard or saved text selections
+ Select click anywhere outside current selection now clears current selection
svn path=/trunk/netsurf/; revision=4079
Aside from a number of instances of const being cast away (mostly relating to the urldb, which is correct to only export const data) this now builds warning-free with GCC 4 on x86, which is nice.
svn path=/trunk/netsurf/; revision=3868
Optionally allow url_compare to ignore fragments in comparison
Fix handling of url_compare result in a few places
Fix redirects which contain fragments in the Location header
svn path=/trunk/netsurf/; revision=3826
Redirect handling is now transparent to clients of fetchcache.
The new scheme works as follows:
1) Request content for URL (fetchcache()
2) Start fetch of content (fetchcache_go()
3) If no redirect, continue through LOADING, READY, DONE etc. states as before
If redirect, receive NEWPTR for each redirect that occurs, then continue
through LOADING, READY, DONE etc. states as before.
The upshot of this is that redirects result in extra contents being created. It also means that, until LOADING has been received, the content (and thus the URL being fetched) may change. Therefore, fetchcache clients should expect to have to deal with transient data prior to LOADING occurring.
As a necessary side-effect of this, the HTML object URLs and CSS @import URLs are no longer stored alongside the relevant contents. These URLs can be accessed by interrogating the url member of struct content anyway, so it was a rather redundant scheme before.
svn path=/trunk/netsurf/; revision=3787
* Tested on Solaris Express: Developer Edition,
which is between Solaris 10 and 11.
* Used gcc, libmng etc packages using pkg-get and blastwave's resources.
* Had to build lemon and re2c manually.
svn path=/trunk/netsurf/; revision=3350
NetSurf includes are now done with ""s and other system includes with <>s as C intended.
The scandeps tool has been updated to only look for ""ed includes, and to verify that the
files exist in the tree before adding them to the dependency lines. The depend rule has
therefore been augmented to make sure the autogenerated files are built before it is run.
This is untested under self-hosted RISC OS builds. All else tested and works.
svn path=/trunk/netsurf/; revision=3307
