It's not that it bothers me in the nightlies (I keep backups of stable versions). It's just I hope they have them fixed when they release the milestone. I've just been watching it go downhill for the past week or so and I hope they don't show up in the milestone. It creates a bad image for the project.

Hm, no link?

Sweet! I love it! "You can do it! You can do it all night long!"

Man MacOS X is almost too much for me... maybe I will go buy one of those new iMacs... ;)

Go Moz! Native widgets rock!

--Micko

I tried to recreate the OS X screenshot (http://bugzilla.mozilla.org/attachment.cgi?id=64512&action=view) on my Windows XP machine using the new natively drawn widgets and the StyleXP based AquaMax theme.

I think it turned out pretty well...except for the transparency, and some minor differences. Note that my screenshot is using Cleartype anti-aliasing, so the text might look a little weird on a CRT monitor, but it looks incredible on a LCD screen - better than the OS X screenshot, actually.

Anyway, here is my screenshot - http://www.loodi.com/XPTheme.png (161kB, 1138x1017 24bit PNG)

Sounds better. If it will be an option. But in that case - when anybody finally kick off that piece of crap calling itself "OS native file-picker"? ^_^ Personally that's horrible when during work with differently (but very good) looking program you sometimes get something completelly OS-related. (Especially when it's something like filepicker. I have feeling sometimes OSs are competing who can do it worse ;-) If I remember it right there was idea of filepicker XUL tag but never got in implementation further than an empty block and died soon after it...

Yeah, you're being bitchy. I figured if he "upgraded" WinME with WinXP, it is "very" possible that the original application data is corrupted. I've had it happen. The data is listed in directories but it is completely inaccessible and therefore utterly useless. Anyway, thanks for bashing me around. Always a pleasure.

James

I have had many problems with people trying to guess answers to my technical issues when they really did not have a clue. If someone is honestly trying to help then I can appreciate that, but they should also predicate their suggestions with "I really do not know, but maybe ..." It is always annoying if they state their suggestion as if they KNOW that it is the right answer. It is even worse when they go so far as to argue with you when you tell them that their suggestion is wrong.

One of the worst cases I have experienced was with AOL....

A while back I was configuring a firewall on a T-1 to the Internet for a client; there was a VP who was using AOL and so I had to open up the necessary ports for it, but I could not find any info anywhere on the web what ports AOL's software used (it is now on the AOL website, but it was not there then). Since I did not have a packet sniffer handy, I called AOL's tech support line. I ended up having to spending several HOURS calling several times because I kept getting ignorant answers.

A few of the answers that I was given :

1) We do not use one. 2) I can not tell you because that is an AOL trade secret. 3) It is randomly selected each time you start the AOL software.4) No one here in technical support knows; you would have to talk to the programmers, but they don't have phones. 5) You do not need to know the port number. It should go through the firewall automatically. 6) We can not help you with that, you need to talk to your network administrator. It is up to them to configure the firewall. (Me: I am the one trying to configure the firewall and I just need to know what ports the AOL software uses.) Well, then you need to call your Internet Service Provider. (Me: I am with the ISP) Sorry, we just can't help you if you do not know what you are doing.

What was extremely annoying was that no one would admit to not knowing the answer. They all insisted that what they were telling me was THE correct answer. Most of the people refused to transfer me to any higher level support and some said there were no supervisors or higher level support. Finally I got totally fed up and told a woman that "This is just bullshit!" She replied that there was no reason to use that kind of language (she acted as if it was the worst cuss word she had ever heard) and that if I could not be polite that she was going to transfer me to the "irate caller line" where they were trained to handle people like me. After being on hold for a minute or two, a man came on the line and said "I understand that you are unhappy with the support that you have received, how can I help?" I told him that I just needed to have someone tell me what TCP/IP port or ports were used by the AOL software. He immediately replied "We use port 5190." I politely said thank you. He asked if that was all that I needed. I told him yes unless he could also explain why I had to go through so many people making up answers out of thin air in order to finally get such a simple question answered. He had no answer for that.

At the moment, soome of the widgets are \"truly native\", while others are not; they just call the Appearance Manager to see what the background ought to look like, and then draw that.

Two examples of true-native widgets are scrollbars and progress bars. Thr progress bar ripples as it should (though this seems to take an enormous amount of CPU time, more than it should actually). Likewise, there\'s an extremely subtle effect when you drag a scroll thumb that cannot be reproduced by a static image; Mozilla draws this correctly.

However, look at dialog buttons. The default button is blue, as it should be, but it doesn\'t throb. This is a case of Mozilla calling the Appearance Manager just to get a background image. It should, of course, be fixed, and likely will be in the future. Butnot just yet.

All told, though, it\'s a very impressive first effort. If it\'s this good having only been out for a couple of days, I can\'t wait to see what it\'ll be like by 1.0 time.

Yes, XUL is still responsible for the large-scale structure of the window. What you and a few others aren't getting is that in the new regime -- at least on Mac and GNOME -- once you get down to a certain level XUL is out of the picture. It's not true that Mozilla just queries the theme engine for CSS attributes like foreground and border color. Instead, it calls the OS native widget rendering routines to draw the widget in its current state, rather than using XUL to render the widget from an HTML-like representation. I gave specific examples of the native OS widget rendering calls being used on both GNOME and MacOS. Did you look at the code? It's in nsNativeThemeMac.cpp and nsNativeThemeGTK.cpp.

As I noted, the Windows code is not as easy to read as the MacOS and GNOME code due to its indirection through an undescribed DLL. It's possible that the native code on Windows does work in the "semi-native" way, simply querying for CSS attributes and still calling out to HTML-like XUL versions of the widgets for rendering. If so, that would mean the feature was implemented differently on different platforms. I tend to doubt that, and the inconsistency would be a problem in itself if it were true, but I can't rule out the possibility based on what I see in nsNativeThemeWin.cpp.

Lee Strauss

I think it's pretty cool that you can simultaneously acknowledge that I've been right all along and still insist that I am horribly mistaken in some way you can't quite put your finger on. It shows real creativity.

I can't speak for Asa, and as I point out in other comments, I'm pretty much an outsider myself so I can only go on what I've read from other people, like Asa, who do know what they're talking about. But here's my take on this question:

Fundamentally, it *doesn't matter*. It's an implementation detail. The spec for the new CSS appearance attribute specifies "this should look like a button" or "this should look like a textbox", and whether this is accomplished by getting the OS to "tell us what it should look like" and then using that, or by getting the OS to actually create a widget directly on the screen for rendering, is really an insignificant detail. From the information I have now (which could well be wrong) my best guess is that, in fact, the answer to the question is different on different platforms (closer to the former on windows, to the latter on GTK, mac somewhere in between).

Whether they "act native" is actually a very good question, and one that so far I haven't seen an answer to anywhere. I'm not talking about things like whether a disabled button is semi-transparent - that's still part of the "look". But for example, whether click-and-drag or click-release-click are both valid selection mechanisms for a dropdown (select rows=1) control or for a context menu is an OS-dependent behavior.

So far it's not clear to me whether this pseudo-native theming has any bearing on that kind of behavior. My guess would be that it doesn't, and that the theme changes, however much "native" code they use, still interpret events much the same way as they did when they were pure XUL/CSS. But I'm not sure, and until I see a linux build with these features turned on, I'm not inclined to pass of my speculation as anything but speculation. Perhaps Asa or another mozillan might comment on this issue?

Stuart.

Thanks for your note. There are two important changes that I've been discussing.

One is a change in argument. For the last few years, the big argument against native widgets has been that there were supposedly important CSS attributes that were difficult or impossible to apply to native widgets. If you look at the CSS specs, though, it doesn't appear that any of these are mandatory attributes for form controls, and in fact it appears that CSS3 actually requires the use of system default appearances for form controls, as one would expect given the importance of platform standards in user interface design. I've been arguing this issue without getting much of anywhere since 2000, but suddenly, without any public discussion, the Mozilla project as a matter of policy has turned around and decided that in fact the extra CSS attributes are not important, while platform default appearances are. For people who follow CSS and related issues I think it's important to note how this argument wound up coming out, rather than sweeping the issue under the carpet as an embarassing about-face.

The other change is technical, although it also has significant consequences for the user. There has been a fundamental architectural shift in the XUL widget model. The previous model was that widgets were described in an HTML-like form stored in user-selected repositories that allowed for a variable interface. At runtime, when a widget was created, the XUL layer would go to the user-selected file, pull out the variable HTML-like representation of the widget, and render the widget from that representation. Now, at least when using native widgets, the HTML-like representations in the user-selectable files are ignored in favor of native OS widget-drawing calls. This is a basic architectural shift in XUL, and again it's something that is important to note for people who follow XUL, as well as people who follow the features of theming and skinning of which so much has been made by Mozilla advocates. The scope of theming and skinning is now considerably reduced, given that most users prefer the platform standard appearance.

My attempts to point out these two important changes have been met by the usual chorus of personal attacks against me, and by vague claims that I am committing some error which somehow cannot be pinpointed. II don't think it bodes well for the project that the level of argument continues to be so low.

Lee Strauss

Thank you thank you :) Think this will make life much easier for many people :)

for the first comment: I think this is not the last Milestone before 1.0. There's still a 0.9.9 in between and maybe more? Even if Mozilla is as great as it is now, they shouldn't rush now. A few weeks sooner or later won't make much difference now but can help a lot to make the best 1.0 release such a large project has ever seen...

Currently 'View Source' fetches the page from the network rather than the cache. This is fine normally but can cause problems with dynamically-generated pages.

Alex

This is true, but the document says they will still work on issues that block the mail/news from general use,easy to fix, and for dataloss. My premise is that all bugs I cited are general-use blockers (and two of them have dataloss keywords) but there has been very little action with them lately. In the case of the not seeing all atachments, one of the devs thinks it could be solved by opening a different kind of window (mail window rather than view source) - I should hope that as fixes go, that is a fairly minor one.

Why do you continue to bitch about the inclusion of mail/news in Mozilla?

Myself and others have gone into depth previously in these forums showing you that, from day one, Mozilla was a project to develop a suite including browser, HTML editor, mail, and news.

It has also been pointed out on numerous occassions (as fuzzygorilla did in his post directly above yours in this thread http://mozillazine.org/talkback.html?article=2127&message=49#49 ) that work on mail/news bugs rarely, if ever, delay the development of the browser.

If you just want a browser with the mail/news client and other extras that many other people want, then that is fine.

If you want to speed up the development of the browser, then contribute constructively to the development.

If you want to continue to try to blame the mail/news client for single-handedly delaying the release of Mozilla 1.0, then go right and do so, but just not where we can read it. Your blame is misplaced; reiterating it here does not do anyone any good.

If you want to keep harping about the fact that the mail/news client is part of Mozilla, then please don't. It is a moot point. Mozilla has always and will always include a mail/news client. Your complaining about it is just a waste of your time, a waste of bandwidth, and a waste of time for anyone who has the misfortune of reading your post about it.

Why doesn't we just call it Mozilla 5.0 ? This will cause much less confusion. I guess this question must have been discussed allready, so can somebody give me a reason it has been chosen the version-number 1.0 ? Generally the Mozilla browser is already known as Mozilla 5 pretty much everywere. And how are we going to explain the userAgent string says "Mozilla/5.0..." ?

What links? Is it consistent on any particular link(s)? Does TalkBack pop up? Are you sending in Talkback reports? What are the TalkBack Incident IDs? Have you reported this to Bugzilla? What is the bug #?

I appreciate general \"it\'s less stable\" or \"it\'s more stable\" comments so don\'t take my questions as discouragement. If you are having specific and reproducible failures, however, it is in your best interest to follow-up a little (sending in talkback takes about 10 seconds, filing a bug takes a few minutes) by providing information that helps us fix the bug.

And if you send in talkback or include that in your bug report (and somehow let me know the incident ID) I\'ll even help see that that bug gets assigned properly.

--Asa

I fear for the worst. Don't give AOL anything! If the own your desktop the will own you even more then Microsoft.

Why would it be a bug? You just said you told the computer to resend the data. "Data" means the form, which was the message you just wrote.

Thanks. That's too bad...

As a second question to you guys, is there a way of getting to your Netscape WebMail with Mozilla via IMAP/POP etc. and if so what's the server (this is what I get for momentarily switching to N6 from Moz--it's different)?

BTW I do use Trillian, but the less RAM needed, the better...

Tanyel, just out of curiousity, what was the winner last year? :)