Slashdot Mirror
Future Directions Proposed For Mozilla
Ars-Fartsica writes "MozillaZine is now featuring a set of slides regarding future directions for Mozilla that were detailed at the recent Mozilla developers meeting. SVG and integration with programming languages are among the directions discussed."
Here's a direct link to the slideshow itself.
Type n, right-arrow, down-arrow, or space to advance a slide. Type p, left-arrow, or up-arrow to go back one slide. Type t to go the the first (title) slide.
Instructions taken from here
I agree, Mozilla is a bit bloated. However, Mozilla Firefox and Mozilla Thunderbird are meant to tackle problems like that.
The design of Mozilla has been to make it easily embeddable so other developers can use its rendering technology and make their own interface and use a different widget set. Many projects already do, e.g. Galeon in GNOME and K-Meleon (using MFC) for Windows.
My operat~1 system unders~1 long filena~1 , does yours?
There is Sodipodi for editing SVG.
...see if you can sort out the swing, awt, eclipse native widget fiasco.
J2EE seems strong at the backend. With a strong frontend, maybe MS has to react for a change.
So does Anonymous Coward have good karma?
> Why did they think this was a good idea?
d gets.html
See http://www.ocallahan.org/mozilla/why-no-native-wi
Firefox Session Saver
multizilla.mozdev.org
--Pat / zippy@cs.brandeis.edu
Firefox has a plugin, it's called session saver. Try guessing 3 times what it does. (Or just install it if you run out of idead)
Any feature you are missing, check the plugins first. Chances are someone's already implemented it.
- These characters were randomly selected.
I believe you're talking about Opera, then. It's been doing state-saving for years.
--
Don't like it? Respond with words, not karma.
I always found the "users want a standard look across platforms" argument a little ridiculous.
That may have been a justification, but I think that the real reason for Mozilla to have non-native widgets is that it's a lot of work to maintain all the platform-specific codebases. There are already platform-specific issues, but in general someone can add a feature to Mozilla without knowing how to code for every platform under the sun.
I don't know exactly how this will work with native widgets, unless the Moz folks want to take a least-common-denominator approach.
Plus, I wonder if they can rely on sizes of various widgets. Remember that they're integrating widgets with chunks of their laid-out document, when placing, say, a Submit button on the window. With their own widgets, they know exactly how big everything is.
Another issue might be different code structures. For example, the Macintosh Toolbox uses an event loop. GTK uses callbacks. How does one reconcile differently structured widget APIs?
I believe that Netscape Navigator 4.x tried to do this with native widgets back in the day...but the widgets operated different from regular widgets on my classic Mac.
I agree that native widgets would be wonderful from a user standpoint, but there *are* issues with having an extremely cross-platform program with native widgets on each platform. Remember that the MSIE developers only have to worry about one platform...
May we never see th
It'll integrate with the page, it'll work, it's for an entirely different purpose than Flash.
Look, go to Macromedia's page. You have a little menu there in Flash. That's pretty bad design. I'm browsing, I right-click on a text link in the body, I can open it in a new window, a new tab, send the link to my email client, bookmark it, etc. I right-click on a menu item, I get "about flash player". You give the browser control, and that's no longer a problem. You stick to standards and the browser can treat items in your graphic just like HTML items that perform the same function.
If you're using Flash in a way that doesn't seem wrong or clumsy now, then you probably shouldn't replace it with SVG. SVG just lets you use the good parts of vector graphics and animation without feeling guilty about it.
There is also Inkscape for editing SVG.
You are aware of the Flash Click to View plugin? Great at keeping those flash ads at bay :)
For people using their browser at non-standard font settings (and they often have a valid reason for that : some sight problems, for instance), your website would be far more consistent with pictures in SVG, which sizes are put in 'ems' instead of pixels.
Just try to resize your fonts (assuming that the website has not fixed-widths fonts ) (ctrl + in Mozilla). Ho! Where are your nice bitmap logos and graphics ? There, in the background, crushed by all the text at worse, overwhelmed by all the text at best.
SVG could just allow the same resize as text. And I guess a lot of people would appreciate that... Whether the implementation would be possible or not, as previously noticed in the thread, is another problem I'm not skilled enough to discuss.
But if it is possible, then sure, let's do it.
Regards,
jdifool
Let's overcome our weakness.
That's interesting. I've often thought that some bad Acrobat and FireFox interaction is causing problems.
FireFox 0.8 has memory leaks. Load enough instances and tabs, and it will always crash. (This has been verified under Linux and Windows XP.)
When FireFox crashes, it also crashes Windows XP SP1! Windows XP SP1 doesn't show an error message, but the OS becomes unstable, and it is necessary to reboot.
This is shocking to me. The explanation seems to be that the features of Windows XP that most users see run well, but a little below the surface, Windows XP is not a finished operating system. I think a fundamental definition of an operating system is that a real operating system can handle bad behavior of a program without self-destructing. So, after all these years of development, Windows is more a sociological phenomenon than an operating system. It amazes me that Microsoft managers are unable or unwilling to take care of business.
When FireFox crashes under Linux, Linux remains completely stable. (I suppose you could have guessed that.)
I have copies of all the browsers, and in my opinion FireFox is by far the best. Browsers are windows on the world for an increasing number of people, so it is important that the world has an excellent one.
I think FireFox's memory management issues should be fixed before any other work is done. Of course, that is for the FireFox/Mozilla team to decide.
(Posted using FireFox, of course.)
SVG is much different from Flash. Flash is currently primarily used for two things: (1) to provide crummy interfaces (an ugly wart from designers coming from the "multimedia era" when CD-ROMs came out and later the ".com era" when people thought that novelty was what made people keep coming back to websites). (2) To provide an efficient format for vector-based graphic animation.
SVG is lousy at both of the above. I have a friend that looked into the feasibility of SVG as an interface medium, and came back pretty depressed. At one point, I got a bit interested in using SVG for animation, and took a look at the format. I'm reasonably comfortable making the claim that it would be extremely difficult to make an efficient rendering engine for animations using SVG. Furthermore, SVG does not provide functionality for synchronizing audio and phases of an animation (which I believe Flash does).
SVG is good, IMHO, for the following:
1) Tagged diagrams. SVG allows tagging elements with data. This could be a big benefit for CAD and diagram usage.
2) More complex webpage layout. I've never seen it actually done, but it seems that SVG could be used to define arbitrarily-shaped regions in a webpage...up until now, the only regions designers have had to work with, the only thing they could flow text around, was rectangular regions
3) Vector graphics. Plain and simple, it's a standard format for storing vector graphics. This is good for both standalone files and for efficient web-based transmission of graphics.
As for your question about what SVG-based graphic tools are out there -- take a look at sodipodi. It isn't Illustrator (yet), and it isn't going to be for at least a while to come, but it's usable for basic work.
May we never see th
Agreed, small chunks are better. Thats why breaking up the original suite was a good idea. But a framework is just a collection of small pieces. Firefox for instance may still just be shipped with what is essentially just a wrapper for the networking and the layout modules. In fact, frameworking like that would probably require factoring the existing code into even smaller discrete chunks. If people want to be able to run a thin client application that uses the mozilla framework, then it could run off and download the relevant XPIs (which you would keep very small) by itself as it needs to. As an example, at the moment MPlayer is undergoing a major redesign led by Arpi in the form of MPlayer G2. It too is much more of a framework than MPlayer is, but in terms of monolithicism and bloatedness, its better in every way.
People frequently ask why Mozilla implements its own widget set rather than just using the widget set available on whatever platform it's running on. This document is an attempt to explain why. Transparency and Z-ordering
Consider this testcase. It's a text field behind an element full of "blah" text. The "blah" element is transparent, so you can see and even edit the text field with the "blah" text overlaid on top. This simply can't be done in with Gtk or Qt widgets (unless this has changed in a very recent version of these toolkits). In Win32 it can only be done in Win2000 or WinXP, and then it is tricky and inefficient. If you don't believe this, try implementing the same effect using your favourite platform toolkit, and email me if you succeed.
Getting this right isn't optional. It's a requirement for a correct CSS implementation. Other HTML/CSS functionality
An HTML BUTTON element can contain arbitrary HTML. It's practially impossible to get that to work with any platform button widget. (Note that the HTML inside the button is part of the same document as the button itself.) Printing
On many platforms it's very difficult or impossible to get a native control to print. International languages
When you browse the Web you find content in every language that computers can handle. It is important for the browser to have strong support for uncommon languages. This means it is important for the browser to display form elements containing strange characters and scripts. Many platforms (e.g., older versions of Windows) do not provide good support for locales other than the locale that the operating system itself is installed for. Therefore their widgets aren't good enough for strong browser language support. Performance
On many platforms the per-widget memory and time cost is quite significant. This is OK for most GUI apps because you typically don't have more controls per window than fit on the screen. But in a browser, you sometimes see pages with hundreds or thousands of controls. (Think "a long comments page in Slashdot when you have moderation points".) This has to be fast and not consume too much memory. On some older Windows versions it's simply impossible to create 1000 edit boxes without crashing the system! Event handling
The DOM Events model defines ways for a page to intercept events such as keyboard or mouse input before they are dispatched to the control with focus. It would be very tricky and error-prone to implement this using platform-specific hacks. Arguments For Native Widgets
Here are some arguments for using native widgets, and how we answer them. Native look and feel are critical for usability
Agreed. We have started using platform-specific APIs to render our widgets as if they were native widgets, wherever we can. For GTK, WinXP and MacOSX we actually call theme APIs so that Mozilla picks up whatever theme is currently in force. It really looks like a native app. All of the above advantages are still retained because we're still not using actual native widgets. It also means we automatically "keep up" as the platform look changes, which has been a big problem for "cross platform" UI toolkits in the past.
We're still working on the "native feel" problem. Feel doesn't vary as much as look, it seems, so it's less of a problem, but we have a number of tweaks that vary the feel of our widgets across platform and we'll add more. Native look and feel are critical for accessibilty
We're building in support for platform accessibility APIs in GTK and Win32, so our widgets will be just as accessible as the native widgets. Too much work for developers
Yes, but it's worth it. Too slow, too much footprint
Yes, rolling our own widgets requires some extra code and may not be as well optimized as the platform widgets. But as noted
"Black Screens Of Death" are usually caused by faulty RAM.
I suggest you try some different RAM chips and try Firefox again.
Although, realistically, Black Screens Of Death should occur randomly, not just when using Firefox.
Also various video card drivers are known to screw up your memory and go down with a Black Screen Of Death
The path I walk alone is endlessly long.
30 minutes by bike, 15 by bus.
This is a known issue, and the developers are quite well aware of the fact that Mozilla is not very efficient in this department. Firefox 1.0 will not have this problem; Firefox 0.9 will probably have modifications to reduce its effects somewhat.
SCREW THE ADS! http://adblock.mozdev.org/ Proud user of teh Fox of Fire - Registered Linux User #289618
my point was browser-independant.
But I just explained how Mozilla handled it, which is, indeed, quite bad... :(
Despite the fact that Opera surely zooms images, they remain bitmaps, and thus, they are badly deformed when you go through 2 or 3 zooming.
This is, in my mind, what SVG is really supposed to adress (of course, this is not about pictures or real photographies, just for graphics, buttons, logos and the like...) : non-deformed images.
Regards,
jdif
Let's overcome our weakness.
The reason SVG isn't included in the default build is nothing to do with "politics" unless you have a very broad definition of the term, it's not in because it's not complete.
Netscape/Mozilla have been burned before when they included half-assed support for a standard. It's bad for a ton of reasons. People don't know what features they can use and what they can't, if mistakes are made they get frozen into the defacto standard and so on. So, until Mozillas SVG support matches a W3C standard, it won't be switched on.
The main problem is that SVG is really huge and complicated. I think last time I checked they were aiming for "SVG Static" which is a cut down version (no animation for instance). Because that's also a recognised standard they could switch it on at that point.
I don't know how Konquerors SVG support matches against Mozillas, but I'd be surprised if they'd implemented the whole thing (with the required KHTML/DOM integration). If they haven't done the whole thing then I'd not suggest they switch it on, it's that simple.
MNG support was dropped because MNG is another huge, (bloated?) spec. It's not just GIF-with-PNG you know. If anything it competes with Flash. The code for it was huge and it the person who owned the relevant module didn't care about it, so it got dropped. Now, whether you agree with this decision or not is somewhat irrelevant, you aren't the maintainer of that part of Mozilla (feel free to fork the beast). You have to question though - if MNG had been 100x simpler it'd probably still be in there today. As it is, nobody uses MNG at all.
Many features are excellent. Except...
Roughly once an hour clicking back would simply take my machine (windows XP portable) out. Not even the blue screen of death but a black screen.
I had a simmilar problem with my XP notebook with Firefox. Turns out the problem was a combination of:
Sun's JVM and my ATI video driver (which is a forcefit as Compaq never put out an XP driver for the model laptop I have).
The fix was a laugher... I switched video mode to 24 bit color.
Firebird works fine.
-- $G
Pornzilla
It's funny because it's true!
"The number of Unix installations has grown to ten, with more expected." (Unix Programmer's Manual, 2nd ed.; june 1972)