GSoC first week
by Paweł Blokus
I am going to spend the first coding week refactoring the tree view
code. With the work I've done in the past few days I realised that it
would be useful to get the global history from riscos available for
other platforms in order to have a testing ground for the widget. The
code needed little changes to work at all but still might need some
better insight. Although it extends the time needed for this part of
my project it's something I would have to do anyway later, so I think
it's a better solution than writing code used solely for testing.
At the end of the week I would like to have done the following things:
- the treeview history working on any platform
- platform dependent code from tree view reduced to a minimum
- sorting option for a tree node
13 years, 11 months
Re: r7627 MarkieB - /branches/MarkieB/upload/gtk/gtk_window.c
by John Tytgat
In message <courier.4A2029A1.000068BF(a)atlanta.semichrome.net> you wrote:
> Author: MarkieB
> Date: Fri May 29 13:29:53 2009
> New Revision: 7627
>
> URL: http://source.netsurf-browser.org?rev=7627&view=rev
> Log:
> turn magic numbers into relevant quantity
>
> Modified:
> branches/MarkieB/upload/gtk/gtk_window.c
>
> Modified: branches/MarkieB/upload/gtk/gtk_window.c
> URL: http://source.netsurf-browser.org/branches/MarkieB/upload/gtk/gtk_window....
> ==============================================================================
> --- branches/MarkieB/upload/gtk/gtk_window.c (original)
> +++ branches/MarkieB/upload/gtk/gtk_window.c Fri May 29 13:29:53 2009
> @@ -265,16 +265,17 @@
> time, gpointer data)
> {
> char *filename;
> + int offset = strlen("file://");
> filename = strdup((gchar *)(selection->data));
> - filename[strlen("file://")] = '\0';
> + filename[offset] = '\0';
> if (strcmp(filename, "file://") == 0) {
> - filename[7] = '/';
> - filename += 7;
> + filename[offset] = '/';
> + filename += offset;
> printf("filename %s\n", filename);
> /* then add filename to gadget */
>
> gtk_drag_finish(cont, TRUE, FALSE, time);
> - filename -= 7;
> + filename -= offset;
> }
> free(filename);
> }
Extra bonus point to be gained when using
"size_t offset = sizeof("file://")-1;" instead of the using the strlen()
runtime function. I expect most today's compilers this won't make a
difference but still...
John.
--
John Tytgat
joty(a)netsurf-browser.org
14 years
Wiki migration
by Daniel Silverstone
Hello,
Several people have raised issues regarding the current
wiki.netsurf-browser.org which is a fairly locked down instance of
nanoki. It's not terribly stable and it's hard to allow people access
etc.
As such, we need to migrate to a new wiki. There any many options out
there but unless someone has a really good reason for discounting the
three I will present herein, or a really good alternative option, then
we need to choose between these three.
Option 1: Trac
--------------
Trac is actually a multi-faceted tool which would provide us with
viewsvn-like functionality, a simple issue tracker, a wiki, a
dev-document manager, and various other bits and bobs.
Pros: Written in python, will run on pepperfish[1], provides integrated
behaviour for issues, a wiki etc.
Cons: Hard to modify for our users' issue-reporting requirements, needs
filesystem access to the SVN for the viewsvn-like functionality (could
be a mirror, or we could move svn to pepperfish)
Option 2: Mediawiki
-------------------
Mediawiki is a very popular and well-known wiki engine. Used by
Wikipedia and various other sites, it is richly featured but unlike
trac, it is just a wiki engine.
Pros: Only a wiki engine, so we're free to implement the other features
in other ways without confusion. Already has an example instance on the
machine which currently runs our SVN.
Cons: Only a wiki engine. Written in PHP which means we cannot ever
consolidate its functions onto pepperfish (where the rest of the
websites are). Is complex and backs onto MySQL which is yet another
failure point.
Option 3: Moin
--------------
Moin is a popular wiki engine written in python. Used by many sites
(including in its early days www.ubuntu.com) Moin's syntax is well known
and like Mediawiki, moin incorporates plenty of ACL management etc.
Pros: Only a wiki engine, easy to set up instances, can run on
pepperfish, runs entirely from filesystem and thus can be moved between
hosts and can be backed up easily.
Cons: Only a wiki engine. Theming can be "interesting" in the chinese
proverb sense.
Personally I don't care which of the three options we choose, I just
want a consensus of opinion. I'm personally against PHP because of what
it has done to machines in the past and quite how many security issues
tend to arise because of it, but as it isn't hosted on Pepperfish,
that's not a concern I need to have.
I would raise the following issues as important:
1. Reliability
2. Reachability (people have expressed concern over the reachability of
our svn in the past)
3. Backup-ability
4. Relocatability (in case of hosting failure)
5. Maintainability (how many people have access to the underlying
instance - i.e. can SSH in and change config etc)
Please, start to chime in.
D.
--
Daniel Silverstone http://www.netsurf-browser.org/
PGP mail accepted and encouraged. Key Id: 2BC8 4016 2068 7895
14 years
Continue to the dom_string design
by Bo Yang
Hi jmb and Kinnson,
After some work on the libDOM string type conversion, I come
across some new thoughts and I think this may impact how we design the
dom_string.
In the center of the dom_string problems is whether we should one
type of string or two distinct types of strings.
After some programming, I found that I usually get trapped into
that whether this field should be a lwc_string or dom_cdata_string.
Take the Node interface for example, I change the nodeName to
lwc_string, when I came across the nodeValue, I change it to the
lwc_string, too. But later, when I read the W3C DOM Core level 3
document, I find that the nodeValue should be a dom_cdata_string,
because that the nodeValue attribute act like a "virtual attribute". I
mean when the Node is an Attr node, the nodeValue is equal to the
attirubte's value, which is a lwc_string. But when the Node is a Text
node, the nodeValue is equal to the Text.data, which is a
dom_cdata_string. So, the only solution is to make this field a
dom_cdata_string. The whole DOM interface only take all string as one
type, but we split it into two distinct types, I think this will bring
us some problems like above in later.
And for the DOM test suite, there are problems too. The test case
may declare:
<var type="DOMString" value="div"/>
How should we deal with this declaration? Creating a lwc_string or
creating a dom_cdata_string? Somebody may argued that we should
creating a lwc_string because the string's value is "div", which is a
tag name. But creating different types of string accroding to their
content is not a good thing, I think. So, maybe the best way is to
create a cdata_string first and when this string will be used as
tagname or attribute name or element id, we intern it then.
Not only DOM Test Suite, think about when we support JavaScript, if
the user write:
var name = "div";
How do we deal with this string, too? I think it should be exactly the
same with the above one.
And that is my point: We use two distinct string in DOM internally,
but only one type of string in the DOM public interfaces, and convert
from cdata_string to an interned string whenever necessary. And the
conversion work is done in the corresponding API.
So, we still provide the dom_string and hide the lwc_string
entirely from the DOM public API. The dom_string will look like:
struct dom_string {
void *ptr; /**< Pointer to string data or the
lwc_string * */
int len; /**< Byte length of string */
lwc_context *ctx; /** < The lwc_context of this string is
the string is lwc_string */
dom_alloc alloc; /**< Memory (de)allocation function */
void *pw; /**< Client-specific data */
uint32_t refcnt; /**< Reference count */
};
I think the above struct is self-explained.
Doing this way, our clients never need to know something like
lwc_context. He can just call:
dom_string *str;
dom_string_create("div", 3, &str);
dom_document_get_element_by_id(str, &ele);
dom_characterdata_append_data(cdata, str);
And in the dom_document_get_element_by_id, the function will detect
whether the str contain a lwc_string, if not the function will intern
the string data and create one. But in function
dom_characterdata_append_data, it just extract the char * from the
dom_string and then append it to the cdata...
And we should provide dom_string_cmp and many other helper function to
leverage the lwc_string in the dom_string to accelerate the
comparison.
And, internally we can use two distinct types of strings. I mean,
we declare the various fields of DOM interfaces as whether lwc_string
or dom_string. For the ones, we are sure we should intern them, we
declare them as lwc_string, and for them like nodeValue or something
we did not want to intern, we declare them as dom_string.
This way, we keep an consistent interface with the DOM spec
interface and maintain our performance as well as keep flexible
internally. We can change some interned string to cdata_string or
inversely without any disturbing of our clients. And because we hide
lwc_*, we can determine how many lwc_context should we use. I mean,
maybe one const lwc_context for all tag names & attribute names & enum
attribute values, another lwc_context for ids & class names &
something other... Of course, just some quick simple thought about
that small lwc_context may accelerate our matching. :)
Oh, having write so long an English article is really not an easy
job. I just want to make our API simple and make our code base simple,
please shot me with your questions as many as you can. Please point
out any mistake I made freely, thanks for your advice!
Regards!
Bo
14 years
assert on www.bahn.de
by Chris Young
I was just trying to fix another problem with www.bahn.de, but I'm
getting this now:
assertion "box->float_container" failed: file "render/layout.c", line 1219
Not sure if it is a site or NetSurf change which has caused a
different problem - is this reproducable?
Chris
14 years
Re: Translating Netsurf into Japanese
by WP Blatchley
>> So if I were to translate the necessary files, someone could at least give
>> me a screenshot of it running on RO5?
> I expect so, yes.
Excellent.
>> That would be satisfying! I'll have to try to get R05 running under
>> emulation on Windows at least, so I can see my translation in action!
> There's not yet a complete RO5 ROM image for emulation.
No, I tried RPCEmu yesterday with the ROOL IOMD RO5.15 image. I was quite impressed, actually! But it's a fair way off being usable, you're right.
> It occurs to me that it's likely that the Wimp doesn't even inspect
> strings to be drawn -- it just throws them at the Font Manager, having
> opened the desktop font without an explicit encoding specifier, so it'll
> use whatever the system alphabet is set to. Perhaps, therefore, the Font
> Manager should attempt to fix this case up.
It does seem like the Font Manager would be the place to tackle this. Perhaps it could have a sort of 'intelligent' mode where it tries to detect if strings being sent to it are properly encoded, and alter the encoding if it detects otherwise. I suppose it would have to be quite simple logic, though, or the overheads would be too great. Hmm...another tricky situation arising to try to keep legacy code running as the OS moves forward!
>> Any pointers as to where to start with the translation files?
> Copy !NetSurf.Resources.en.Messages to !NetSurf.Resources.ja.Messages,
> translate the strings, and send use the resulting file. That's about it.
> The text at the top of the Messages file describes what the format is.
> Modern Zap can edit UTF-8 encoded files quite happily -- you may have to
> tell it that a file is UTF-8 encoded; I can't remember, off hand.
Thanks for the pointers (and thanks Michael for the Zap version info). I'm running Zap 1.47 at the moment, and have a bitmap font containing a good deal of the glyphs necessary for Japanese. Sadly, I think I'll be doing this on Windows though, as without an input engine, Zap can't help me much ;-)
I'll get back to you once I have something useful.
Thanks,
wpb
14 years
Re: Translating Netsurf into Japanese
by WP Blatchley
>> Could an Iyonix owner tell me if RISC OS 5 can properly display
>> UTF-8 encoded messages in windows and menus?
> The RO5 Wimp speaks Unicode. If you set your system alphabet to UTF8,
> then it will display such strings correctly. The downside, however, is
> that most applications have no knowledge of UTF-8, so their menu text
> will likely come out garbled (invariably, it's the shift arrow which
> confuses matters).
> My understanding is that for the embedded RO boxes shipped in Japan, the
> system alphabet was set to UTF8 by default. I suspect it's likely that
> you will need to softload ROOL International and InternationalKeyboard
> modules to be able to set the system alphabet to UTF8. I suspect that
> it's unwise to attempt to softload the ROOL Wimp on a ROL OS, however.
So if I were to translate the necessary files, someone could at least give me a screenshot of it running on RO5? That would be satisfying! I'll have to try to get R05 running under emulation on Windows at least, so I can see my translation in action!
It's a shame that setting the system alphabet to UTF8 will break a lot of applications' menus (and slightly ironic, seeing as UTF8 was designed to slot into non-Unicode aware systems without causing problems). Perhaps there could be a hack written that tries to assess whether a Messages file is UTF8-encoded or Latin-1-encoded, and transcode the strings accordingly on the fly... Still, that's a discussion for another mailing list, I suppose.
Any pointers as to where to start with the translation files? I think there used to be some information about this on the Netsurf website, but I can't find it now.
Thanks,
wpb
14 years
Translating Netsurf into Japanese
by WP Blatchley
Hello,
I'd like to make a Japanese translation of the Netsurf resource files.
What I'd like to know is, could Netsurf on RISC OS take advantage of it if I did? I have an a9home running the ROOL UCS Font Manager, and Japanese text displays just fine in web pages, but the rendering of the menus etc. of the Netsurf GUI is presumably carried out by the OS. I tried setting my system font to Cyberbit, but on my a9home at least, that doesn't look pretty!
Could an Iyonix owner tell me if RISC OS 5 can properly display UTF-8 encoded messages in windows and menus?
Thanks,
wpb
14 years
2.1 release
by John-Mark Bell
Afternoon,
It's time for another bunch of jumping through hoops. I've done my bit,
can the platform maintainers (i.e. AmigaOS, BeOS and Haiku) provide a
suitable release archive built from the 2.1 tag, please.
For those who are worried; we've no intention of releasing this often in
general -- this one is mostly down to some nastiness in the GTK options
code that should never have been released in 2.0.
Cheers,
J.
14 years
