> Can one do general-purpose GUI application development with Mozilla/XULrunner--using JavaScript instead of Python or Tcl as the programming language?
Yes. And the hope is that soon you will be able to use JavaScript _or_ Python as the programming language.
> 2. Does developing with this environment require one to do hacking in C++? (I'm not interested in hacking with C++.)
The idea is that it should not. Some things are still not easily (or at all) doable without using C++, of course. Writing device drivers in JavaScript may not work, say.;)
> (Plus, closures that contain DOM objects leak memory. This is "WONTFIX" because IE does it too.)
I'm sorry, but you have no clue what you're talking about. This bug was fixed on the Gecko trunk back in September 2005 (as in, 4 months ago). The fix will be in Gecko 1.9 (and Firefox 3). It _might_ end up in Gecko 1.8.1 (and Firefox 2) if the remaining regressions are resolved fast enough.
On a more general level, "IE sucks and has this bug" is not necessarily a reason not to fix the bug.
If a specific page causes a memory leak, please file a bug! With a reproducible testcase, it should be fixable.
Re:Yeah, I've been saying it for months.
on
The Future of HTML
·
· Score: 2, Informative
> "Um...how to make text bigger? h1,h2,h3,h4,... > but we'll use "big" tags here.
, etc are not "make text bigger" -- they're "This is a heading". HTML as originally designed didn't have a concept of "make text bigger" at all -- the assumption was that HTML would have logical markup (headings, paragraphs, quotes, etc) and that the renderer would choose the best way to actually present that markup.
Then browser makers started introducing all sorts of presentational markup ( is an example, as are , etc).
> TADA!!! The entire html of the current page (save the HTML element > itself)
No, that's a serialization of the DOM, not what was actually sent over the wire (which is what users saving HTML only want to save). In particular, the innerHTML can be affected by scripts...
The key difference is that the monkeys have to get their code reviewed and accepted by someone competent _before_ it makes its way into the general codebase.
> We haven't really noticed the effects because all > the attention has been shifted to Firefox
All the media and pr attention has shifted to firefox. The core developers are working on the core as they have been; just check out the list of layout checkins on the trunk in the 6 months since firefox branched.
It's an error in some min-width computation code in Gecko.
> (b) why it only happens occasionally
Because it's only an error in the incremental reflow code; if the initial layout happens early enough, the problem is not hit.
> (c) whether anyone is working on fixing it?
It's been fixed in trunk Gecko since April. It's not fixed on the stable Firefox branch yet, and probably won't be because the fix leads to problems of its own on some sites.
> XForms is easy and useful enough that it can be > efficiently implemented in much less time than > the argument takes.
Mozilla is looking for someone to implement XForms efficiently. So far, no patches have been posted to the bug. The people who have looked into it have decided that it is in fact not easily implementable efficiently.
I'm not sure why people think of highlight-and-middle-click as pasting. It's more like a drag-and-drop operation except that you don't have to keep the left mouse button down during the drag and you can rearrange windows before you drop. Apart from that, all the behavior is exactly identical to drag-and-drop.
Control-C and Control-V are copy and paste (and use the CLIPBOARD). They work just like Windows (or like the Mac clipboard). If an app doesn't work right with these, it's just broken. File a bug on the app.
> The author makes the usual MS are trying to take > over the world but provides no proof or > indication of how this will actually happen
Here's some proof and indication:
1) The W3C is having a workshop on web applications 2) Participants had to submit position papers on how they think web applications should work. 3) Microsoft's position paper is at http://www.w3.org/2004/04/webapps-cdf-ws/papers/mi crosoft.html
(note the space Slashdot inserted in the damn url). Read that paper carefully (all 5 lines of it). The article author is actually spot-on with the "future of the web" thing, and a number of W3C people agree...
> And sentences like "[o]ne of the purposes of > Longhorn is to destroy the web as we know it." > aren't going to engage anyone in a rational > debate.
Unfortunately, that's close to a statement of fact. Consider that the W3C is holding a forum on developing standards for web applications (since there are things people want to do with the web that HTML is just not suitable for). Forum participants have to submit position papers. Read Microsoft's at http://www.w3.org/2004/04/webapps-cdf-ws/papers/mi crosoft.html
So now we have an objective statement from Microsoft on what they think the future of the web should be. We can have rational debate about that while they implement this future, right?
Oh, and the Sean Hall / Dante Evans duo (same person, actually, if you look at the www-style@w3.org posts) is frankly incompetent. Their tests tend to be utterly incorrect and rather meaningless....
Er.. that report wasn't done by Anne (Anne's just linking to it). And due to a bug in the script generating the test suite (since fixed), there are wild inaccuracies in it.
> The memory lost this way is never accessed from > there on, but the system cannot release it > without the program telling it to,
It's worse. If it's allocated on the C heap and there's something allocated past it, the system can't release it even if the program DOES tell it to. Yay lack of heap-compression in C.
There are security checks in Gecko that prevent doing exactly this sort of thing from an http:// page. Did you even bother testing your HTML snippet before posting? It doesn't work in HTML that doesn't live in a file:// URL already.
Slashdot Mirror
> Can one do general-purpose GUI application development with Mozilla/XULrunner--using JavaScript instead of Python or Tcl as the programming language?
;)
Yes. And the hope is that soon you will be able to use JavaScript _or_ Python as the programming language.
> 2. Does developing with this environment require one to do hacking in C++? (I'm not interested in hacking with C++.)
The idea is that it should not. Some things are still not easily (or at all) doable without using C++, of course. Writing device drivers in JavaScript may not work, say.
> (Plus, closures that contain DOM objects leak memory. This is "WONTFIX" because IE does it too.)
I'm sorry, but you have no clue what you're talking about. This bug was fixed on the Gecko trunk back in September 2005 (as in, 4 months ago). The fix will be in Gecko 1.9 (and Firefox 3). It _might_ end up in Gecko 1.8.1 (and Firefox 2) if the remaining regressions are resolved fast enough.
On a more general level, "IE sucks and has this bug" is not necessarily a reason not to fix the bug.
If a specific page causes a memory leak, please file a bug! With a reproducible testcase, it should be fixable.
> "Um...how to make text bigger? h1,h2,h3,h4,...
> but we'll use "big" tags here.
, etc are not "make text bigger" -- they're "This is a heading". HTML as originally designed didn't have a concept of "make text bigger" at all -- the assumption was that HTML would have logical markup (headings, paragraphs, quotes, etc) and that the renderer would choose the best way to actually present that markup.
Then browser makers started introducing all sorts of presentational markup ( is an example, as are , etc).
> SVG is similar: a well-defined standard,
That you say this tells me that you've never actually tried implementing SVG.... It's not as bad as HTML4, but it's not even close to "well-defined".
> but I doubt any browsers implement that.
Could try testing. Gecko implements it.
> and it kept crashing, over and over and over
This is exactly why we ship a beta -- so people will tell us about this stuff. You did file a bug so it'll get fixed for final, right?
> TADA!!! The entire html of the current page (save the HTML element
> itself)
No, that's a serialization of the DOM, not what was actually sent over the wire (which is what users saving HTML only want to save). In particular, the innerHTML can be affected by scripts...
The Korean site is NOT A MIRROR. That's the whole point. They're not offering the official Mozilla.org binaries, but binaries they compile themselves.
The question of what constitutes a normal distribution channel in this case is a good one, however.
Could you please point me to the Mozilla bug in question? Better late than never...
Yes. Otherwise it would become unusable for a day or so any time there's a slashdot story, and that would be rather unfortunate.
Unfortunately, that SVG is sent as image/svg-xml, which isn't an SVG MIME type, so a compliant browser or plugin can't possibly show it...
The key difference is that the monkeys have to get their code reviewed and accepted by someone competent _before_ it makes its way into the general codebase.
> We haven't really noticed the effects because all
> the attention has been shifted to Firefox
All the media and pr attention has shifted to firefox. The core developers are working on the core as they have been; just check out the list of layout checkins on the trunk in the 6 months since firefox branched.
Keys can be dynamically generated and queried, so there can't be a definitive list....
The CSS is perfectly valid CSS3. The validator only speaks CSS2.
> (a) why this happens
It's an error in some min-width computation code in Gecko.
> (b) why it only happens occasionally
Because it's only an error in the incremental reflow code; if the initial layout happens early enough, the problem is not hit.
> (c) whether anyone is working on fixing it?
It's been fixed in trunk Gecko since April. It's not fixed on the stable Firefox branch yet, and probably won't be because the fix leads to problems of its own on some sites.
> XForms is easy and useful enough that it can be
> efficiently implemented in much less time than
> the argument takes.
Mozilla is looking for someone to implement XForms efficiently. So far, no patches have been posted to the bug. The people who have looked into it have decided that it is in fact not easily implementable efficiently.
Did I just hear you volunteer to implement it?
I'm not sure why people think of highlight-and-middle-click as pasting. It's more like a drag-and-drop operation except that you don't have to keep the left mouse button down during the drag and you can rearrange windows before you drop. Apart from that, all the behavior is exactly identical to drag-and-drop.
Control-C and Control-V are copy and paste (and use the CLIPBOARD). They work just like Windows (or like the Mac clipboard). If an app doesn't work right with these, it's just broken. File a bug on the app.
> The author makes the usual MS are trying to take
i crosoft.html
> over the world but provides no proof or
> indication of how this will actually happen
Here's some proof and indication:
1) The W3C is having a workshop on web applications
2) Participants had to submit position papers on how they think web applications should work.
3) Microsoft's position paper is at http://www.w3.org/2004/04/webapps-cdf-ws/papers/m
(note the space Slashdot inserted in the damn url). Read that paper carefully (all 5 lines of it). The article author is actually spot-on with the "future of the web" thing, and a number of W3C people agree...
> And sentences like "[o]ne of the purposes of
i crosoft.html
> Longhorn is to destroy the web as we know it."
> aren't going to engage anyone in a rational
> debate.
Unfortunately, that's close to a statement of fact. Consider that the W3C is holding a forum on developing standards for web applications (since there are things people want to do with the web that HTML is just not suitable for). Forum participants have to submit position papers. Read Microsoft's at http://www.w3.org/2004/04/webapps-cdf-ws/papers/m
So now we have an objective statement from Microsoft on what they think the future of the web should be. We can have rational debate about that while they implement this future, right?
Oh, and the Sean Hall / Dante Evans duo (same person, actually, if you look at the www-style@w3.org posts) is frankly incompetent. Their tests tend to be utterly incorrect and rather meaningless....
Er.. that report wasn't done by Anne (Anne's just linking to it). And due to a bug in the script generating the test suite (since fixed), there are wild inaccuracies in it.
> The memory lost this way is never accessed from
> there on, but the system cannot release it
> without the program telling it to,
It's worse. If it's allocated on the C heap and there's something allocated past it, the system can't release it even if the program DOES tell it to. Yay lack of heap-compression in C.
There are security checks in Gecko that prevent doing exactly this sort of thing from an http:// page. Did you even bother testing your HTML snippet before posting? It doesn't work in HTML that doesn't live in a file:// URL already.