yeah, and 1.90 was tagged in CVS on wednesday. your point is? it takes time for mirrors and such to be straight before kde really wants to see slashdot announcing it to the world...
yes, both at the same time - and with blackbox, not the native windowmanager of either one. They get along fine, Xlib is a nicely capable common denominator. Though I must admit that it's only kde2 whose CVS I have been tracking. I'll have to make it up to gnome now:-)
you'll note that the IP his link looks up at netcraft is 207.46.130.149, which, although it has no reverse-DNS, is served from an ip for which dns4.cp.msft.net is athoritive.
that's not slashdot:-) nice try though. On a hunch, I forward-looked up www.microsoft.com (hey, trolls aren't usually that creative) and it's one of the 4 servers in that DNS round-robin.
> Font support is nonexistent. Well it's not nonexistant, but it is quite a mess (at least for scaleable fonts). Point taken, but that is exactly what this article is talking about work on.
> Cut and paste is a mess How so? I personally like hilite-middle-click copying. d&d is an incompatible mess that needs some help from the Xlib level so that different toolkits could get along, but the X11 cut-buffers work quite well I think.
> On startup of FVWM, kde, whatever... You need to talk to fvwm/kde/whatever about this feature. X has nothing to say about virtual desktops, which are a window-manager creationand as such are managed by the windowmanager.
> With the current X release, no way exists to specify the location of pop-up windows
You mean the x,y,height, width, and Zorder (force to be on top) windowmanager hints? If your windowmanager doesn't respect them, I think that's it's problem. certainly X provides a way to tell the WM that this window should be here, this size, and always on top (thus avoiding the problem of being 'hidden under other windows'. In any case, a modal window should block only the one app it relates to, so killing the offender should be quite simple.
> A global way of assigning keystrokes to all apps under X.
There is one and only one X keymap (handled by Xkbd extension and tweaked by xmodmap). There are lots of ill-behaved apps that can't agree on what should be in it, but this is an issue exposed by the cross-platform heritage of these apps, not an inherent X11 problem. GTK and QT have gone a long way toward fixing this, it's just a matter of getting legacy apps tuned up.
It sounds to me like you don't like your windowmanager, and are blaming X for it's problems (an easy enough confusion - most other platforms don't have the distinction between graphics API and window-policy that X does).
well, the diffs give us *all* the changes that they made to mozilla. So they are equivalent to a 30 meg tarball (and much more informative to read) if you want to know what they changed.
They are just embedding mozilla by using the standard mozilla embedding API's I think, which would not fall under the viral nature of any license... MPL made them keep their mozilla work public, precisely what it was meant to do. Working on an opensource project shouldn't force you to make anything else you also work on opensource! Nor should using an embedding API specifically designed for outside apps to acess the functionality of the opensource product.
They did post the source (well, diffs against the main tree, close enough for me) of their modified mozilla, and placed them under the MPL-1.1. mozilla developers have been looking over them this morning (discussions in #mozilla), and there is some good stuff in there - if they work as claimed, real has fixed some long-standing bugs that nobody else had gotten to yet. Don't knock these guys too hard, it seems at first glance that they did everything right:-).
The only fault? there's no email address with any of it, so it's going to take a little searching for contact information to properly credit them if (or when) their work gets checked in.
different chromes are on http://www.mozillazine.org/chromezone
the command-line switch you seek is ./mozilla -chrome chrome:///content
chrome support is a bit technical right now, but I think the prefs dialong will have a GUI picker in the near future. In the meantime there are directions for the interested in the chromezone.
well, there's a monolithic installer in windows/win32/sea (I think that's right, it's in there). About 16 megs 'cause all the possible options are turned on, but should work for you...
legal issues - the bugs probably contain code excerpts, API discussions, patches, and such that you can't see w/o netscape violating their RSA license for BSAFE. Besides, the code that those bugs apply to (PSM) has patent issues that mean you can't see it or work on it anyway.
RSA has gone out of their way to make SSL an extremely sticky mess, that's why mozilla avoided it for so long...
tune2fs -r 0/dev/hda1 (of course, pick the correct/dev entry for your filesystem...). There, no reserve. Now don't run out of disk, ya hear! See man tune2fs for more fun things to do:-)
b) MkLinux is an old, nearly dead project which nobody cares about. See linuxppc.com for a RH6.x distro if you like redhat, debian or slackware both have PowerPC distribitions, and none of the above need macos to load except MkLinux or on a few subsets of extremely broken hardware. And even then miBoot should work, which doesn't need MacOS, just one 800k HFS (mac-style) partition.
Linux on the PowerPC is alive and well, thank you very much (as I go off to get a 2.3 kernel and Xfree 4.0)
I think it involves memory allocation races? I don't know the technical details, but bugzilla.mozilla.org probably does. search for SMP in bug summaries, you'll probably learn something.
There is a solaris machine in the tinderbox, so solaris is considered a first-tier platform (ie, solaris build-breakage automatically closes the tree to checkins). Also, most of the memory-leak kinds of analysis of mozilla is done on solaris w/ Purify. I think Sun may distribute the binaries instead of mozilla.org though for some reason.
Irix, I don't know, you could look on netscape.public.mozilla.builds on news.mozilla.org (NNTP) and you might find out...
Well, as you should have noticed, mozilla.org hadn't announced the release yet... slashdot just saw that a few of the files were up and announced it for them.
While mozilla will probably have to work-around their HTML problems (the odds of them fixing the incorrectly calculated widths that add up to more than the width of the page and make it linewrap) this is not a mozilla problem.
No it doesn't yet - but the bug # I gave you is the bug tracking this problem. The fix is non-trivial, because it involves changes to the event code; this code does not currently pass the clicks up. vote for it, and maybe it will get fixed...
Slashdot Mirror
yeah, and 1.90 was tagged in CVS on wednesday. your point is? it takes time for mirrors and such to be straight before kde really wants to see slashdot announcing it to the world...
yes, both at the same time - and with blackbox, not the native windowmanager of either one. They get along fine, Xlib is a nicely capable common denominator. Though I must admit that it's only kde2 whose CVS I have been tracking. I'll have to make it up to gnome now :-)
you'll note that the IP his link looks up at netcraft is 207.46.130.149, which, although it has no reverse-DNS, is served from an ip for which dns4.cp.msft.net is athoritive.
:-) nice try though. On a hunch, I forward-looked up www.microsoft.com (hey, trolls aren't usually that creative) and it's one of the 4 servers in that DNS round-robin.
that's not slashdot
smpeg does a pretty nice job too, and is more open. Loki apparently adopted it and brought it up to snuff because they needed one :-)
> Font support is nonexistent.
Well it's not nonexistant, but it is quite a mess (at least for scaleable fonts). Point taken, but that is exactly what this article is talking about work on.
> Cut and paste is a mess
How so? I personally like hilite-middle-click copying. d&d is an incompatible mess that needs some help from the Xlib level so that different toolkits could get along, but the X11 cut-buffers work quite well I think.
> On startup of FVWM, kde, whatever...
You need to talk to fvwm/kde/whatever about this feature. X has nothing to say about virtual desktops, which are a window-manager creationand as such are managed by the windowmanager.
> With the current X release, no way exists to specify the location of pop-up windows
You mean the x,y,height, width, and Zorder (force to be on top) windowmanager hints? If your windowmanager doesn't respect them, I think that's it's problem. certainly X provides a way to tell the WM that this window should be here, this size, and always on top (thus avoiding the problem of being 'hidden under other windows'. In any case, a modal window should block only the one app it relates to, so killing the offender should be quite simple.
> A global way of assigning keystrokes to all apps under X.
There is one and only one X keymap (handled by Xkbd extension and tweaked by xmodmap). There are lots of ill-behaved apps that can't agree on what should be in it, but this is an issue exposed by the cross-platform heritage of these apps, not an inherent X11 problem. GTK and QT have gone a long way toward fixing this, it's just a matter of getting legacy apps tuned up.
It sounds to me like you don't like your windowmanager, and are blaming X for it's problems (an easy enough confusion - most other platforms don't have the distinction between graphics API and window-policy that X does).
GRUB does this (look on freshmeat). Quite nice really, it even understands filesystems and can browse them to the kernel it wants.
correction, MPL did not in any way force them to release anything (it's more BSD-like). But they released their changes. Nice of 'em.
you're right, they didn't have to make their changes public - but they did anyway. Kudos to them for getting into the spirit of this!
continuing in parallel with the above?
anyone who wants to can use the mozilla code (and API's are provided to make this easier), that's sort of the point...
well, the diffs give us *all* the changes that they made to mozilla. So they are equivalent to a 30 meg tarball (and much more informative to read) if you want to know what they changed.
They are just embedding mozilla by using the standard mozilla embedding API's I think, which would not fall under the viral nature of any license... MPL made them keep their mozilla work public, precisely what it was meant to do. Working on an opensource project shouldn't force you to make anything else you also work on opensource! Nor should using an embedding API specifically designed for outside apps to acess the functionality of the opensource product.
They did post the source (well, diffs against the main tree, close enough for me) of their modified mozilla, and placed them under the MPL-1.1. mozilla developers have been looking over them this morning (discussions in #mozilla), and there is some good stuff in there - if they work as claimed, real has fixed some long-standing bugs that nobody else had gotten to yet. Don't knock these guys too hard, it seems at first glance that they did everything right :-).
The only fault? there's no email address with any of it, so it's going to take a little searching for contact information to properly credit them if (or when) their work gets checked in.
oops it ate part of that
./mozilla -chrome chrome://'chrome-name'/content
different chromes are on http://www.mozillazine.org/chromezone
the command-line switch you seek is
./mozilla -chrome chrome:///content
chrome support is a bit technical right now, but I think the prefs dialong will have a GUI picker in the near future. In the meantime there are directions for the interested in the chromezone.
well, there's a monolithic installer in windows/win32/sea (I think that's right, it's in there). About 16 megs 'cause all the possible options are turned on, but should work for you...
legal issues - the bugs probably contain code excerpts, API discussions, patches, and such that you can't see w/o netscape violating their RSA license for BSAFE. Besides, the code that those bugs apply to (PSM) has patent issues that mean you can't see it or work on it anyway.
RSA has gone out of their way to make SSL an extremely sticky mess, that's why mozilla avoided it for so long...
tune2fs -r 0 /dev/hda1 (of course, pick the correct /dev entry for your filesystem...). There, no reserve. Now don't run out of disk, ya hear! See man tune2fs for more fun things to do :-)
a) grammer. get some.
b) MkLinux is an old, nearly dead project which nobody cares about. See linuxppc.com for a RH6.x distro if you like redhat, debian or slackware both have PowerPC distribitions, and none of the above need macos to load except MkLinux or on a few subsets of extremely broken hardware. And even then miBoot should work, which doesn't need MacOS, just one 800k HFS (mac-style) partition.
Linux on the PowerPC is alive and well, thank you very much (as I go off to get a 2.3 kernel and Xfree 4.0)
1. yep. I hope they fix that
2. Bug #6085. there is a patch attached, hopefully it gets checked in before beta
3. You can (if so inclined) edit the XUL. But yes, there needs to be a pref dialog for this.
I think it involves memory allocation races? I don't know the technical details, but bugzilla.mozilla.org probably does. search for SMP in bug summaries, you'll probably learn something.
./configure --disable-mailnews
there, that was easy, wasn't it?
There is a solaris machine in the tinderbox, so solaris is considered a first-tier platform (ie, solaris build-breakage automatically closes the tree to checkins). Also, most of the memory-leak kinds of analysis of mozilla is done on solaris w/ Purify.
I think Sun may distribute the binaries instead of mozilla.org though for some reason.
Irix, I don't know, you could look on netscape.public.mozilla.builds on news.mozilla.org (NNTP) and you might find out...
Well, as you should have noticed, mozilla.org hadn't announced the release yet... slashdot just saw that a few of the files were up and announced it for them.
While mozilla will probably have to work-around their HTML problems (the odds of them fixing the incorrectly calculated widths that add up to more than the width of the page and make it linewrap) this is not a mozilla problem.
unfortunately, mozilla is multithreaded but not smp-safe. sucks, don't it?
But nice and solid otherwise... hopefully it will get fixed.
No it doesn't yet - but the bug # I gave you is the bug tracking this problem. The fix is non-trivial, because it involves changes to the event code; this code does not currently pass the clicks up. vote for it, and maybe it will get fixed...