Progress and Future of Mozilla the Application SuiteThursday February 6th, 2003The latest mozilla.org Status Update is all about the progress and future of the Mozilla application suite. Featuring a summary of the improvements since Mozilla 1.0, the update also details the planned work that will be completed over the next few months and outlines some possibilities for the future. roaming profiles is at the bottom of the priority list (or at least at the end of the timeline :-( ) All that means is "no one is actively working on this yet". Which is true. Lots of people say they want it, none of them seem to be willing to do anything to make it happen.... Actually Ben Bucksch is working , isn't he? Roaming - funding via Beonex: http://bugzilla.mozilla.org/show_bug.cgi?id=124026 Roaming - 4.x-HTTP-compatible: http://bugzilla.mozilla.org/show_bug.cgi?id=124029 Too bad the existing bugs don't get fixed before new functionality gets added. One basic functionality bug in particular is the TITLE (toolitip) bug #45375. It has been sitting in Bugzilla for over 2 years and 6 months with over 41 duplicates, and nothing is even being done about it. That is what is too bad. Fix basic functionality before adding new features. You really have no reason to complain that this work is being done to implement a "new feature" bug (which has been sitting in Bugzilla for much longer than your "basic functionality" bug) instead of other bugs. Roaming profiles are being worked on because various people are PAYING an independant developer to have the work done. Mozillla.org and Netscape are not making the call here. Are you volunteering to pay someone to work on bug 45375 for you? What is actually stopping Enigmail from getting checked into the trunk? From my own experience this seems to be quite mature. This would be awsome yes. Enigmail is really working great and it would ne nice to to see it become part of Mozilla. Shipping the Mozilla.org product as separate apps rather than a monolithic executable will be a positive move welcomed by many. We'd also benefit from improvement of Layout as discussed recently by Baron (and in bug 157967) as well. Layout improvements would go under "gecko"; the document in question acknowledges that it's not dealing with things like that at all. It seems to me that the Mozilla browser already has 99% of all major features that could possibly be useful in a browser. What we need now is minor tweeks/improvments of existing features. An example would be the download manager - it's more or less has everything except it doesn't remember paused downloads which means you can't continue a download the following day. I just spotted Midas and I have to say it is fecking superb. Well Played What exactly is meant by "This document does not cover other projects like ... Calendar?" Is mozilla-calendar not going to be included in "Mozilla-the-application-suite"?? I would say a calendar, especially one with good publishing and sharing features, is a very important part of an application suite including email and addressbooks and such... What is meant is "Seth was trying to cover things he actually knows something about or could get information on". Feel free to mail him information on Calendar and ask him to include it in the list. Calendar will probably be included in the 1.4 builds. It is currently under going a review, which is needed before it gets built by default. Mike Great is right! I was wondering when we could expect to see Calendar packaged with a Mozilla release. This is good news indeed. Mozilla-calendar is THE most promising Free Software calendar solution I've seen, and with WebDAV publishing and good integration with mozilla-mail it is the final step towards a free Outlook/Exchange substitute. I personally think Calendar deserves all the attention it can get. We've got to break Mozilla up ASAP so we can show up Apple. What would splitting the app up have to do with showing up Apple? Are you trying to be facetious? Splitting the apps would allow for much better performance from Navigator. What makes you think Navigator would perform significantly better if the apps were split? There's likely to be very little - or no - CPU benefit from splitting the apps, but there might be a slight memory benefit (unless you actually use more than one in which case there will be a memory cost). So, unless working on machines with very low memory, all you'll get is faster startup time - probably only slightly faster since I suspect startup for mail etc. is already deferred until the first time you use it. Mozilla starts up perfectly quickly anyway, who cares if it takes five seconds, you only have to do it once. A much better reason for splitting the app is reliability. I don't care if my browser crashes but I *do* care if it brings down the email I'm typing. [[Of course, Mozilla really should have the feature that used to be in antique Unix mail software, so that it saves everything you type to a file immediately and can recover from just where you left off if the program crashes - I don't know whether this feature is present or not but my experience with other Windows mail software suggests not.]] If the apps are in different processes then crashes in one don't affect the other. So splitting them is definitely worthwhile IMO. But don't expect to see a huge performance benefit from it. --sam He's trying to be funny, but it just comes accross as stupid. I agree with splitting up the apps, however. No I'm not trying to be funny, I'm serious. The only way Mozilla will ever be able to snuff Safari in performance is to split the apps and optimize Navigator like it can't be optimized while part of a monolithic app. Thankfully GRE is actually moving in this direction, along with XRE. The Mozilla browser does not have to be separate in order to compete with the size and speed of Safari; Chimera is already filling that niche. What?? Chimera *proves* that the browser needs to be separate to compete with the "size and speed" of *any* browser. Ideally, Mozilla.org would be nothing more than Phoenix/Chimera. Chimera A) is a full implementation of Mozilla (not using GRE yet, etc.) and B) doesn't have anywhere near the support of mozilla.org. Same for Pheonix. If Mozilla ITSELF was made to separate apps and use GRE, Mozilla will benefit from the mass of developers that work on it. Phoenix and Chimera both have very few developers. I think Phoenix/Chimera are mainly to show Mozilla what it could do and isn't. It's time for Mozilla to BECOME Phoenix/Chimera. Is the GRE structure the way of the future for Mozilla? I think I noticed this in the latest nightlys but not in the 1.3 release? I can understand the logic behind it but it sure is a pain for testing purposes to have the files scattered in all kinds of locations. If you select a custom install, your program files are not in the same location as the base files installed for GRE. I switched from the installer to the zip file once GRE happened. It's a nightmare setting USE_LOCAL_GRE=1 when running a local build, then removing the variable so that the mozilla that was installed by the installer can run. The zip takes care of that, I can have USE_LOCAL_GRE on all the time, and all mozilla's will hapilly find their dlls in their own components directory. But who knows, I could have been doing something wrong, or missing a step that would have made everything co-exist happily. But even if that is true, there certainly wasn't any usefull documentation on it to help me out. GRE is the way of the future, but probably only for releases and never for nightlies (there are now command-line options to force your choice, though). For 1.3b the GRE has been turned off until there's more confidence in it, 1.3 final is still being discussed. Am I missing something ? I used to be one of those people who say "Mozilla.org should just focus on making the browser better... etc., etc." On all my Linux desktops I'm using Galeon for my web browsing, Evolution to check my IMAP mail, and had no real use all the extra Mozilla features. But then I took up a job where I have to provide applications and support for web browsing, email, address books, group calendars, and html publishing, on a range of platforms including Mac, Linux, Windows 98, and Windows 2000. Now Mozilla's application suite is looking a LOT better. I'm especially looking forward to the upcoming inclusion of the mozilla based calendar app, using iCal as a native format and automatically publishing calendars via WebDAV. It may be a good thing for you but your situation is rare and accomodating your niche situation has caused a major diversion of energy and resources away from the browser. And worse, you are hobbling your users with inferior choices in each category. It would be fine if not wonderful if Mozilla-like groups *totally* independent of Mozilla develop a suite of apps (XUL-based or not). But Mozilla.org should be 100% browser focused. His situation isn't that rare. I'm using mozilla _because_ it's a cross-platform _suite_. And I don't feel like using an inferior product at all. Give me a mail client with a working spam filter (it's *really* cool), multiple accounts, that easily holds ten of thousands of mails per folder, supports POP, IMAP both with SSL and runs on Linux, Solaris, MacOS X and Windows. Then give me a better browser than mozilla (at least with tabs, popup-blocking and typeaheadfind (and no, lynx in multiple terminals doesn't count)) that again runs on Linux, Solaris, MacOS X and Windows. And if there are those better non-suite-apps available then why shouldn't mozilla make a good suite? The other market for standalone products is obviously already catered for (according to you). pbreit, in the short time i've been aware of your presence, I've disagreed with virtually everything you;ve said. can you talk about *anything* else? you get trounced every time you bring up this little flamefest, you always run away from the long threads with your tail between your legs because your arguments* fall apart so quickly. just give it a rest, man. why dont you pick something new to troll about? *unsubtantiated claims and opinions stated as if they were irrefutable facts That's the problem, everyone here disagrees with what could best be described as common sense. I may get trounced every time but considering I've been making the same exact lonely argument here for over 3 years and since then Phoenix and Chimera have come on to the scene maybe you all should thank me. The troll lable is particularly troublesome because the argument is actually quite sound. Your argument may be quite sound for you... but remember that Mozilla is replacing/updating a product that was a suite, so one of the expectations of a lot of people was (is?) that it has (most of) the same capabilities as the old Communicator suite. And yes, I disagree with you. I like and use Mozilla Mail and Chatzilla (Composer I can take or leave) and I'l waiting AVIDLY for Calendar to be built in 1.4! (I do my own builds from source and use Calendar in them.) You've got it backwards. My argument is sound for Gecko marketshare. You turn right around and make an argument based on *your* prefernces. That's the rub. *Every* Moz user could "take or leave" every other component except Navigator. Actually the idea of breaking up the apps is a really GOOD idea. The "Window" menu option should really be an application launcher (where you could add any "mozilla protical compliant/aware" application. It would give the mozilla team a much more narrow scope so that incorporating changes would be a lot easier and simpler. If mozilla used this methodoligy then callendar would already be in the suit as simply as downloading a new theme. No need for approval and the whole mess. Plus you would be able to use callendar without needing mozilla (might be desirable if you prefer to use pheonix for example). My dream of an ideal future mozilla is one in which you could delete "Navigator" from the "Window" menu and simply replace "Navigator" with "Pheonix" without complaint (though I don't use Pheonix, It is a perfect example). Modularizing the package would mean that approval for changes/additions/deletions of functionality would be a whole lot easier because only those concerned about one thing such as "Navigator" don't have to worry about what is going on with the rest of the suite and the rest of the applications don't have to worry about changes in "Navigator" or whatever. This means that if navigator is ready to release a new version, developers don't have to wait for "Mail" and other packages to be ready before releasing it to the public (and vice versa). Just have an update on Mozilla.org stating "Navigator X.X is released. Update Navigator Today" and people would just update "Navigator" in the Mozilla suite. It would allow for the different components that make up "mozilla framework" an opportunity to develope at the pace they desire. "If mozilla used this methodoligy then callendar would already be in the suit as simply as downloading a new theme." But it is as simple as downloading a theme. Go to http://www.mozilla.org/projects/calendar/ and install it into your mozilla. Where's the problem. You can just as easily install MailNews, ChatZilla and Composer as XPIs. pbreit : ". . . . has caused a major diversion of energy and resources away from the browser. . . ." There has not been any diversion of energy and resources. Your statement presumes that if Mozilla had never included the mail client then there would have been more "energy and resources" working on the browser, but there is no reason to believe that. In the beginning there were X developers working on the browser and Y developers working on Mail/News. If Mozilla had dropped Mail/News then Mozilla would have likely dropped approxiamately Y developers. Even if a few of the Mail/News developers had stuck on to work on the browser, there is no reason to think that progress on the browser would have been any faster. As it is now, some people seem to think that the browser development was hampered because there were too many people involved in the browser development. Perhaps, Mozilla would have progressed faster if more developers had been working on the Mail/news client instead of the browser, eh? #52 Re: You just don't get it - there was no diversionby jsebrech Saturday February 8th, 2003 9:04 AM "Even if a few of the Mail/News developers had stuck on to work on the browser, there is no reason to think that progress on the browser would have been any faster." Exactly. Anyone who doubts this should go read The Mythical Man-month, by Fred Brooks, for an explanation of why more developers working on a project does not necessarily mean it will be done sooner or be of higher quality. No, no. You're missing the point entirely. It's not re-allocating x and y all to the browser. It's the simple concept of significantly smaller scope. There is all sorts of bloat in the code, management, bug reporting, projects, etc., etc. that has both slowed the whole thing down and produced the convolution we call Mozilla. The importance of focus really cannot be exagerated. If someone at AOL or Netscape or whatever felt it was necessary to create a mail client, news, compose, chat, etc. that is (sort of) fine. Just don't put them under the Mozilla umbrella. The browser is hard enough. Don't make matters worse by including all sorts of unrelated, equally difficult to develop components. I really don't know why this is so hard to understand. #79 I think I see what you are trying to say, but...by bmacfarland Sunday February 9th, 2003 2:45 PM I think that Mozilla as a platform is more important that Mozilla the browser in the long term. If you are suggest that they skip the concept of Mozilla as a platform and go with a smaller version of just Mozilla as a browser, then that might make sense for some people. I like the Mozilla as a platform as it seems to provide a means to let me choose my operating system separate from the applications I need. Right now I have to choose an operating system based on the applications it runs. If the applications were Mozilla as a platform-based, I've got the best of all worlds. "If someone at AOL or Netscape or whatever felt it was necessary to create a mail client, news, compose, chat, etc. that is (sort of) fine." But that's exactly what happened. Someone thought of creating chatzilla because it interested him, and it grew popular that people wanted it part of the suite, and it eventually did. Same story with multizilla and soon with calendar. This is actually healthy for the community. Not like it is taking away focus, because people work on what interests them. Yes the app suite is a good thing. (Apart from anything else it isn't just the browser that needs non-Microsoft competition, email could also benefit.) Solution: keep the app suite, just use separate processes. That way you can install them together (or just install the browser if you want), you can run them all at once (or just run the browser if you want), and if one crashes it doesn't affect the others. --sam They also need to improve on the password manager to include: 1) a password generator 2) improve the interface making it a decent database 3) other improvements like the ability to export and import the password database. 4) the password manager does not promt to remember some login pages I was surprised that this was not even mentioned in the update... Also Enigmail as mentioned in the above posts. Yeah .. for some reason it won't prompt for Yahoo! Mail. "Yeah .. for some reason it won't prompt for Yahoo! Mail." Not for "some reason". For a very specific and particular reason that they opted out. A site can decide that it doesn't feel secure with password managers and opt out. Mozilla code supports this and Yahoo is opting out. Don't like it? Mail Yahoo. Don't blame Mozilla for Yahoo's failure to take advantage of our features. http://bugzilla.mozilla.org/show_bug.cgi?id=93776 --Asa Looks like it's quite probable that at the end of the day bug 181293 (http://bugzilla.mozilla.org/show_bug.cgi?id=181293) will be the only thing blocking a 1.3b release (see http://groups.google.com/groups?threadm=b0ta1c%24brh1%40ripley.netscape.com)- but it doesn't seem people are managing to track down the cause of the bug. That bug should probably be retargeted to 1.4a since there isn't even a good idea of what's causing it, much less a patch in the works. well, 181293 has just been bumped up to 1.3final - I suppose *everybody* is stumped as to what is causing this behaviour. Every other 1.3b blocker has either been fixed or has a fix awaiting approval. The problem with 181293 is the completely random nature of the problem : no-one has been able to supply a 100% sure testcase. I for one haven't and I'm using the MachO build on a daily basis in all of my browsing. And I do have been looking for *some* way to reproduce this :-( My guess is 1.3b is scheduled for release monday or tuesday No word about any performance and footprint improvements planned in the future???. I cannot keep count of perf/footprint bugs I wollow since at least 0.9.6 and are still unfixed and keeps on getting targetted to future milestones at each release. I think *this* should be a much, much higher priority IMHO. Performance and footprint are almost all core gecko. This page is about proposed changes in the _UI_ layer. Not in the core renderer, the XUL implementation, the style system, or anything like that. I would like to see search improved and a genaral permission manager. The search should have a way to first get the session ID and then use it in the seach. Lots of Libraries use session ID for their search. Eg Libray of congress. This page has links to most libraries http://www.loc.gov/z3950/ . I would also like to have the POST bug in search fixed. I think Mozilla should be the best tool to find good information. The spam filtering looks promising to get good information. I would also like to have a gernaral permission manager that are "the same" for all permissions the manager should be easy expandable . EG I would like to control images, javascript, popups cookies, flash graphics... the same way. sow/ It is high time that Mozilla supported Indian scripts via OpenType fonts and a suitable rendering engine. There are one billion people in India. I don't know if the Windows version of Mozilla already does this via Uniscribe, but we need this on Linux, too (and particularly on Linux if you think of the audience most of who can't afford expensive operating systems). Would it not be possible to have Linux Mozilla use the Pango layout rendering engine, especially now that Mozilla switched to GTK+ 2 anyway? Stefan Here'a a related bug: http://bugzilla.mozilla.org/show_bug.cgi?id=52746 That bug is about dynamic fonts, but Indian script display does not at all require dynamic fonts. (Maybe it did in the pre-Unicode / Netscape 4.0 era, but that's not where we stand now.) What it does need is a rendering engine that is intelligent enough to combine Unicode character sequence into glyph clusters. Pango is such an engine. GTK+ 2 plus requires Pango. Mozilla requires GTK+ 2. Ergo, Mozilla requires Pango already. So why not just use it, too? S. One feature that comes up often as a wish in the Mozilla newsgroup is the ability to right click on a bookmark and see the edit/delete/copy/paste/move etc. window appear, so that one can do those task on the fly. For instance if I want to delete an "outdated" link, usually I realize this only when I click on the link and get a domain error message of some type. It's then that I right click on it and delete it in Explorer. In mozilla I have to open the side bar or use the Manage bookmark command. Regards. I'd settle for undo to work in the bookmark manager. I still often use Netscape 4.8 to manage my bookmarks because of this (and other occasional problems with the Mozilla bookmark manager). http://bugzilla.mozilla.org/show_bug.cgi?id=53422 "I'd settle for undo to work in the bookmark manager" Use Phoenix :) --Asa Phoenix doesn't have context menus for bookmarks either. I'd love to see this as I always want to add keywords to my bookmarks but have to open the sidebar to do it. To add a keyword to a bookmark just right click the bookmark, select properties and type your preferred keyword in. That is from any bookmark shown anywhere but in folders in your Personal Toolbar. Yes, I would like to see context menus showing up in ALL bookmarks, ala IE. #105 Re: Adding keywords with right-click? It's there!by grayrest Monday February 10th, 2003 11:34 AM What build of Phoenix are you running? It certainly doesn't work for me on Win2k 20030205. #109 Re: Adding keywords with right-click? It's there!by grayrest Monday February 10th, 2003 11:51 AM Bah didn't read your message. I don't like the personal toolbar so I turn it off, I was just referring to the bookmarks menu. Sorry for the confusion. I actually never delete outdated bookmarks because I can't be arsed to go into bookmark manager... :) --sam Whenever I show anyone Mozilla it is one of the first things ppl notice. This should be a high priority. What are the plans for SVG? The SVG builds I tested recently seemed quite robust to me. Will we see SVG enabled in the not too distant futuere? SVG is not an UI-Feature. So? I'm still interested in the answer to my question. You know, the answers you want are right there in bugzilla. Read 111152 and 182533 for an explanation of why SVG isn't in the default builds yet, and what it will take to get it in there. It's a bit of a read, but it gets the point across. No, the answers are not there. I read through most of the SVG related bugs and I fail to see where there is any kind of timeframe given. I know that no one can give me an exact date but I wonder if it's something like "we will see this in the next two months" or more like "don't expect this to happen before the middle of next year". None of the bugs I read sheds light on that. There isn't even a target milestone for bug 182533. I know there are still bugs to fix but when I tested the SVG/GDI builds I was pleasently surprised by the robustness of this build and wondered when we might see this enabled by default. Have you considered the fact that no one may _have_ a timeframe for it? Ok, that finally is an answer. Note that I'm not saying that there's definiely no one who has a timeframe. But it's definitely possible that this is the case. I went to a session given by the guy who's working on Mozilla support for SVG. At this moment there are still some parts that they're working on. I remember these: * transparancy for all objects * a font engine that can use platform specific APIs (OpenType on Linux, Quartz on Mac, GDI+ on Windows) * declarative (?) animation (animation without using JavaScript) * bits and pieces missing Once that was all finished he hoped that it got superreviewed and included in the default builds In moving forward, how about it if the mail/news team forget about features and just get the program debugged. mail/news has far more bugs than any other part of Mozilla and they never seem to get fixed. Every other new version of mail/news re-introduces bugs (editor bugs are the most common) that were fixed in the previous version. I set my mother up to use Mozilla 1.2 but mail is so broken (it now hangs every time she tries to send mail, or open the address book) for her that I need to move her back to 1.0 just to get something that works. And if that fails, then it's back to Outlook. Mail/News is the only part of Mozilla that really needs to take a breather and fix the problems before it tries to do anything else. The rest of Mozilla is the fine; none of the problems that mail/news has. Every major version gets more stable and works better. > Mail/News is the only part of Mozilla that really needs to take a breather and fix the problems before it tries to do The layout engine needs it even more.... " but mail is so broken (it now hangs every time she tries to send mail, or open the address book) " Have you tried deleting xul.mlf in the profile directory? Sounds like a corrupt cache again. >>Have you tried deleting xul.mlf in the profile directory? >>Sounds like a corrupt cache again. OK, I'll try this before going back to 1.0. Where do you learn about things like this? How did you know that xul.mlf might be an issue? Thanks. I agree, it's so poor. It has trouble with my mail box imported from Netscape 4.79. There are 2,200 messages in it yet, it rarely picks them all up. If I keep deleting the file it creates when I first open the inbox, and then try opening it again, it might or might not find all the messages! It can take up to 10 attempts to display the messages. Then selecting them all and deleting them doesn't always work. In fact, deleting folders often seems to copy but not move them to the trash. Grrr. And then try open alt.test (my ISP's news server has 190,000 headers for this group) - it doesn't even get halfway before it grinds to halt using 100% CPU. It just doesn't scale. It's been behaving like this for over a year. It comes across as untested pre-beta quality software. For now I stick with Netscape for my mail/news because it works. Disclaimer: I am not a Mozilla developer, and I'm not sure whether I will ever be one. I just follow the project closely since M16 and play an evangelist for all of my friends. The whole discussion about splitting Mozilla gets on my nerves. I'm of the opinion that Mozilla Suite should definitely be split up - as soon as possible. I am a Linux user and I really like the way Unix programms work - in toolchains. Every chain element is _one_ tool for _one_ task and not surprisingly, many chain elements work almost bug-free for years. As a result - bug-free toolchains, which work great and also give enough frexibility to the user. In theory, Mozilla is also a component-driven system. But in real life something strange happens. I never talked about Mozilla's bloat, even if it has been there. But now, I almost have to, because I feel that a _suite_ should not be as monolithical as Mozilla is. It need a clear structure badly - with easy installation of components, and most importantly, with their easy deinstallation. It should be split into pieces as small as they can get: to ensure strict borders between them. I still remember a bug (I guess it is still open) in which Composer should be de-bundled from Navigator and couldn't, because text-input widgets used by Navigator have been a part of Composer. It is just not normal, that far too many focus bugs exists. It is just abnormal, that such a suite already includes tons of extensions, including buggy ChatZilla and useless Download Manager, not forgetting about Composer which I hated in Netscape 4.x times already (and it's been 6 years ago!) and more extensions are to go into the total mess - CaScadeS, Calendar, some other crap that can be useful to many people, but hardly to everyone. Clear structure and inter-componental communication is what Mozilla needs. I want to be able to install extensions as a user under Linux!!! We also have positive examples of separated apps - Phoenix as the first one of them. But what do we see? Code is being checked in and out of trunk to and out of Phoenix, forth and back. Minotaur is not coming yet, mostly because developers are hunting bugs in Mail/News part of tremendous trunk. Separate it! Get it out of the main SeaMonkey trunk, build an extra communication layer so that integrity between Phoenix and Minotaur persists and you again have your suite - but with less bloat! Someone mentioned people upgrading to Mozilla and not recognizing the suite if it was separated. So what? The Communicator is 6 years old, it's time for a marginal upgrade. I guess it's what GRE is about - so use it. Make a basis like GRE and installable applications on top of it. I prefer Phoenix and Chatzilla and my mom will take Minotaur and MozSolitaire. Netscape can do something really special afterwards - for example adding his beloved AOL Messanger etc. apps. I hope I sounded not too histerical and could make my point clear. I want Mozilla to succeed, but at this pace I don't see it succeeding, because it's one _big_ green monster-lizard :) PS: Have you looked at the GRE page in a while? Look at the paragraph named "What's in a GRE?". The list almost killed me. PPS: Apple has already given you a message - KHTML is smaller and easier to integrate. And it does almost everything Gecko does, so go figure. It it's not the time to re-think, when is it then? > The list almost killed me Which part of it killed you? > KHTML is smaller and easier to integrate. And it does almost everything Gecko does It's a well known fact that the first 80% of the desired functionality come much more easily than the remaining 20%. Here's a typical example. Both Mozilla and Safari load web pages over HTTP. Mozilla uses necko, Safari uses the OSX system libraries. This means that Safari suffers from things like lack of support for persistent connections that make Mozilla much faster at loading things that are not in the browser cache over a real-life (56k modem) connection. Yes, we pay some footprint cost for our own XP network library. But we get lots of functionality out of it that is not avaiable in the system libraries (even on OS X, which has by far the best built-in networking API of the platforms Mozilla runs on). I am quite interested to see how things go in the next few years as Mozilla gets the message and slims down and simplifies while KHTML bulks up as it tries to deal with the web that's out there. I agree. Mozilla would be much better off if Mozilla.org were nothing more than Phoenix/Chimera. Minotaur is a good start. It just needs to get it's own domain name, own server, own bug tracker, etc. Same with news, compose and chat (although I think chat resources are better allocated to Jabber). There are plenty of suggestions waiting to be read by looking at what people are most insterested in. Bugzilla is a great source for ideas. That would direct developer time disproportionately towards UI features, many of them somewhat superfluous... Name 5 important layout architecture bugs that have _any_ votes? Same for the network library? "How about working bugs by the # of votes" I could probably file a bug "Add a delete all bookmarks button to the primary toolbar" and with a few key postings at mozillazine and some buzz in a few weblogs probably get dozens of votes. Should developers really implement features because they have a lot of votes? --Asa I think the answer is yes, developers *should* in general implement features because they have a lot of votes. But that doesn't mean checking their brains at the door. Votes should help determine priorities on features which are clearly a good idea (of which there are gazillions), pointing out those features which users (those who care) see as most important. If a million people vote for something stupid then it still shouldn't be done. But if a million people vote for sensible feature A, and only 3 people voted for sensible feature B in the same category, and a developer/project manager/whoever is trying to decide whether to develop A or B, then the presumption should be for A. --sam PS Cynically I could suggest, in answer to my subject, that the *only* point of voting is to reduce bugzilla-spam by encouraging people not to post 'me too' comments since they can register a vote instead. I would like to think that the mozilla team do not actually treat votes only in this manner. I have to second that. I know that this is open source and every developer works on what he wants and that no one has the right to ask for anything, especially if that person isn't a programmer. But I have been an avid supporter of Mozilla for something like two years now, I vote for bugs, download nightlies, report bugs and so on. The longer I take part these activities the more I fail to see the usefulness of the voting system. IME it has absolutely no effect on the actual work done on Mozilla. People work on whatever feature they want and that's ok. But I wonder if it wouldn't be much more honest to get rid of the voting system altogether since it serves almost no purpose. To me it really seems like pure alibi. I agree. Take the bug for cloning windows: http://bugzilla.mozilla.org/show_bug.cgi?id=18808. It's been around since 1999. It has 108 votes. I voted for it early last year. People obviously want it, but the developers seem to be in the camp opposed to it. Personally, I don't see why you'd be opposed it seeing as nobody is asking for the current behaviour to be removed or disabled. What is the point of the voting system? BTW, is there a way to see all of bugs sorted by number of votes? The main benefit from voting as I see it is that it prevents at least a few people from adding "me too" comments to bugs (which seriously hamper those bugs from ever being fixed, thus causing votes to have an overall positive effect). And I do believe that in those rare cases where a developer is in between things to code and looking for something new to get started on, there'd be a decent chance he'd let himself be guided by the votes. Right now there are simply too many things to work on for everyone, but by the time we reach mozilla 2.2 or thereabouts, who knows? Sam, your reasoning doesn't take into account that an equal number of even greater number of users (those who care) might have voted _against_ the feature given the chance. It also doesn't take into account the dismally small number of people who vote. There are over 50,000 bugzilla accounts and a the most voted for bugs only ever approach half of one percent of the total bugzilla users. And bugzilla users are just a tiny minority of Mozilla users. I think you give way too much weight to votes. If I say 6,000 votes in a bug I'd consider lending significant weight to that feature request. But that doesn't happen. Sometimes we get 100 or 200 votes (very rarely) and that's just not significant. --Asa All fair enough, but again: why having a voting system then? I still don't use composer, because it cannot deal with XHTML. I read long ago that all this 'checking' is difficult to implement, bet hey, could you at least write generated tags in XHTML manner, e.g. <br/> instead of <br> - it would be enough for a while. Why wait? Use TopStyle, WebEdit, HTML-Kit, XMLSpy, Dreamweaver, PBEditor, Phoundry Editor, Mozquito Factory, HyperText Builder, ScriptWorx, WebOffice, BlueFish, Namo, etc. There are probably others. I was going to ask, Which of these are free and WYSIWYG? Then I decided to do a little research myself. The one that looked the best to me is Selida: http://www.amaryllis.8m.com/selida.html Web Dwarf also looks interesting (with SVG support). I'm not sure if it supports XHTML: http://www.virtualmechanics.com/products/dwarf/info.html I haven't actually tried any of these programs though since I use Linux and mostly code by hand anyway but I sometimes have people ask me for a good, free, wysisyg html editor. BTW, does anyone else have trouble viewing htmlkit.com in Mozilla? I did not say I'm waiting I am just trying to judge Mozilla's Composer ;) For me it would be a time-saver, to have state-of-art XHTML/HTML/XML/JavaScript editor included in Mozilla Application Suite. The times of 'utilities' are gone - todays demand is having everything nice looking/tons of feature/integrated/polished, so I am against breaking up Mozilla into 'small' utilities, because somebody will end up writting front-end that integrates all those utilities ;) Is there any benefit whatsoever to "integrating" an editor into a browser? Putting a rendering client in an editor makes sense but not the reverse. Considering that 10% of fewer browser users will even use and there are numerous better free and low-cost options on every platform, it makes no sense to include it. It's just a drag on more important things. What I would like to see is an 1.x release with working bookmarks functionality. Otherwise than that it just gets better and better. Well, since votes don't seem to be a great source for ideas from the general public, then here are some ideas of my own: Focus on perfecting standards support in the following areas: XHTML 1 XHTML 1.1 XHTML 2 (This is an early draft specification. I don't propose implementation, just make sure the existing code is modified to allow for an easy implementation so support does not take a year once the final Reccomended Spec is ready.) DOM Level 2 (complete specification) DOM LEvel 3 CSS 2.1 (Once it becomes a reccomendation.) CSS 3 (This is an early draft specification. I don't propose implementation, just make sure the existing code is modified to allow for an easy implementation so support does not take a year once the final Reccomended Spec is ready.) DOM 3 (This is an early draft specification and is being produced in modules. I don't propose implementation, just make sure the existing code is modified to allow for an easy implementation so support does not take a year once the final Reccomended Spec is ready.) Just keeping up with the specs should suck up plenty of time. Here are some personal items I'd like to see: 1. Editor that uses CSS only for formatting. No legacy formatting period. We need editors that can produce strict documents that are as rich in design as transitional documents that use tables for layout and all the other tricks. 2. Finding duplicate URL's in the bookmark listing. This will help users like me not accidentlally bookmark the same page more than once. 3. Capability to file a bookmark in more than one folder but have them linked so that if one is deleted, all bookmarks for the same URL are also deleted. 4. Ability to use Windows Update with Mozilla. (I had to put this in, but I know this will never happen:) 5. Some kind of way where bookmarks are automatically filed under the correct category. In other words, a catalog of the top 1000 web sites so when a user tried to bookmark one, that bookmark is automatically filed in the correct category. Kind of like when you put an audio CD in and the CD info is downloaded and and tracks copied from the CD are automatically put in the correct Genre.
|