Closed
Bug 80392
Opened 24 years ago
Closed 22 years ago
tracking: panels whose contents need to fit
Categories
(SeaMonkey :: Preferences, defect)
SeaMonkey
Preferences
Tracking
(Not tracked)
VERIFIED
DUPLICATE
of bug 133627
People
(Reporter: bugzilla, Assigned: bugs)
References
Details
(Keywords: meta, Whiteboard: se-radar)
Attachments
(13 files)
(deleted),
image/png
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
image/gif
|
Details | |
(deleted),
image/gif
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review |
tracking bug.
Reporter | ||
Comment 1•24 years ago
|
||
filed as result of bug 79948 --in order to more easily keep track of the various pref panels whose content needs to fit in a fixed-sized dialog. pls do add bugs as blockers to this one [some of which might need reopening if they were dup'd in favor of bug 54679, which was marked wontfix]. thx!
Comment 3•24 years ago
|
||
Speaking as an NS manager affected by this change, I think we(Netscape) should do one of two things. Either make it so that the size and resizeability can be overridden in the NS tree to be what it was before or back this change out when we branch. I'm not going to argue that there wasn't work needed on various pref panels, but I will argue that other bugs that are being worked on are higher priority and making this work have to be immediate was unnecessary with so little time left in 0.9.1
No longer depends on: 80415
Reporter | ||
Comment 4•24 years ago
|
||
bug 33985 has a patch that added a pref to make all windows and dialogs resizeable. should it be reopened?
Comment 5•24 years ago
|
||
What Scott said. To have to redo chunk of preference panels for what value at this stage is ridiculous. A change of this nature should have occurred weeks before the UI freeze, not days after it. Especially any newly designed UI (such as the LDAP UI) would have benefited from knowing that the prefs panel was going to be limited real estate sometime in the near future. Had that been communicated early on and widely the UI could have been designed to fit whatever goal we're trying to go for here.
Comment 6•24 years ago
|
||
Uh...sorry, but to claim that this idea wasn't communicated early and widely is ridiculous. The apparent apathy of developers towards designing a professional UI has been a publicly stated pet peeve of Ben and others for months. And if you haven't kept up on IRC, read the newsgroups, perused the related bugs, heard of the discussion, then surely you read the notice that Ben sent to seamonkey-internal over two months ago. If the UI had been designed with a little thought and care in mind from the start, we wouldn't be having this problem today -- something that Ben and others have warned about for months. Scott, I don't really buy the time and priority argument. It hardly takes much longer to do it right the first time than to do it wrong. If you're spending the time to create the UI in the first place, then it's your responsibility to make sure it's correct. In short, Mozilla has no such freeze coming up, so I see no reason to back this out of the trunk. As always, the commercial tree is at your disposal.
Comment 7•24 years ago
|
||
Blake, to make it clear what I was trying to say, let me rephrase that my suggestion to back out was for after NS branches, not affecting mozilla. On the other hand, I really do believe that there are higher priorities in most of the modules than having to fix a bunch of new bugs that were added, so 0.9.1 is going to suffer in some regard. Either these panels will look worse than they did before if nobody fixes them or some other set of bugs won't get fixed.
Assignee | ||
Comment 8•24 years ago
|
||
Scott, I have a patch in my tree that makes every panel except LDAP (still working on that one) fit correctly, at all font sizes (tested a range between standard through 200%). Note that the previous pref dialog would remain sized at 630px wide, no matter what the font setting, a serious problem for vision impaired users. My patch fixes this by ensuring that the window is always sized correctly regardless of the font size. I accidentally updated some of the stylesheet changes so have to do a full pull & resources build now, but expect to finish it off later tonight & have it attached for review by tomorrow.
Assignee | ||
Comment 9•24 years ago
|
||
Comment 10•24 years ago
|
||
Ben. Great. In that case my previous comments don't matter. My concern was very much the 17 dependency bugs I see. If you have fixes for them that work with your new patch and any wording changes have gone through UE/localization then I have nothing left to be unhappy about :)
Assignee | ||
Comment 11•24 years ago
|
||
OK, I have fixes for every panel except LDAP. I'll attach them soon but I need to fix some classic stuff to do with the stylesheet scoping landing tonight first. I've decided that I will not be fixing the LDAP panel. I looked at a build from the 9th (prior to my checkin) and it shows the panel's contents not fitting /then/, so as far as the average user is concerned, the situation hasn't really changed. How it was checked in the first place is beyond me.
Assignee | ||
Comment 12•24 years ago
|
||
Assignee | ||
Comment 13•24 years ago
|
||
Assignee | ||
Comment 14•24 years ago
|
||
Assignee | ||
Comment 15•24 years ago
|
||
Assignee | ||
Comment 16•24 years ago
|
||
Assignee | ||
Comment 17•24 years ago
|
||
These patches fix the fit bugs for all panels except LDAP in Classic-Win and Modern, at standard font size through 200% font size (and probably beyond, didn't test past that). I'll be attaching mac classic changes in a minute. cc'ing: hewitt: for overall sr sspitzer: for the mail changes cmanske, brade: for editor changes.
Assignee | ||
Comment 19•24 years ago
|
||
Assignee | ||
Comment 20•24 years ago
|
||
Assignee | ||
Comment 21•24 years ago
|
||
Assignee | ||
Comment 22•24 years ago
|
||
Assignee | ||
Comment 23•24 years ago
|
||
OK, updated the patches to support Mac. Tested configurations: Windows, Modern, 100% font size Windows, Modern, 125% font size Windows, Classic, 100% font size Windows, Classic, 125% font size Windows, Classic, 200% font size Mac, Classic, standard fonts Mac, Modern, standard fonts I expect Linux to work properly as most of the changes were made to accomodate mac's fonts, and linux seems to fall between Windows and Mac. Need reviews, sr's.
Comment 24•24 years ago
|
||
How did we get so many dialogs and panels that required resizing or scrolling (whose content does not fit well), in the first place? Such crap should not pass UI review, code review, or super-review. I'm still angry that netscape.com failed to communicate its "UI freeze" *again*, just as back in 6.0. I hear it took ben about a half-hour to come up with the patches to fix the bad CSS (or whatever was to blame -- not my point). Doesn't that make anyone who claims to own these things feel a little bit bad? Why can poor code get checked in, lock out improving changes (even temporarily, and we all know that later is never), and then the burden of fixing the bad code falls on the person bringing in the good code? I do not believe that only Ben could have made these fixes in such short order. Where's the accountability? Mozilla has been hit with bad code all over, and for too long -- don't get me wrong, I'm not doting on this issue at the expense of others (see hyatt's huge style system performance improvements, under way currently). We need to draw a line in the quality sand, and hold it. We need to start upholding higher standards, and stop whining about 30 minutes of work (total, not per panel), even if it's at an awkward time. 30 minutes is not a cost-free good, of course, and no one owes Ben that free lunch. But those responsible for the wrongly sized dialogs/panels do owe a few minutes apiece to Mozilla, i.e., to our shared idea of quality, the one thing that keeps people willing to work on the project. Ben has paid others' debts, so now those who perpetrated the badly fitting panels *do* owe Ben something. Mozilla is not a zero-sum game, however much netscape.com managers may feel trapped by commercial deadlines and fixed headcount. People have free time at night (Ben did); there are unpaid contributors, motivated more by quality and comradeship than by deadlines and related pressure to compromise on quality. There are new hires and new members of the community, in due course. If we have to take badly fitting panels, and then we can't fix them because of triage-style priority, we are doing something terribly wrong. We shouldn't take the bad code up front (super-reviewers are the *last* line of defense; where are the others?), and we should insist on payback ASAP when bad code gets through our shields. ASAP means in this case (or should have meant) that some people work a few minutes late one night during 0.9.1's development cycle. /be
Assignee | ||
Comment 25•24 years ago
|
||
Assignee | ||
Comment 26•24 years ago
|
||
seth has given me his 'r/sr' for the mail patch, attachment 34251 [details] [diff] [review].
Comment 28•24 years ago
|
||
Patch to editor's "Editing" pref panel is good, but not 100% adequate to fixing the chopped off widgets in this panel. We already had bug 77517 on that issue, which hopefully will be fixed for 0.9.1. I'll integrate Ben's changes with that bug's fix, so that patch doesn't *have* to be checked in (but it is ok if it is) r=cmanske if it is decided to checkin that asap.
Comment 29•24 years ago
|
||
Editor bug 77517 is fixed and has patch attached that should be used instead of patches for editor attached here. It includes change to modern/editor/EditorDialog.css slightly different from Ben's patch here labeled "Changes to Modern (Editor and Global)"
Comment 32•24 years ago
|
||
I don't like inline style, but I think its use is justified in cases like this. </window> + + + Unnecessary, of course. - style="width: 51em; height: 40em;" + style="width: 51em; height: 40em" This is probably harmless, but don't both properties need (or shouldn't they both have) trailing semicolons? r=blake on the xpfe patch if you address the above.
Comment 33•24 years ago
|
||
Comment 34•24 years ago
|
||
Ben fix probably already took care of this, but suggested fix for Message Display (Mail). Move "variable width" to the right of "fixed width" instead of below it. See above.
Comment 35•24 years ago
|
||
(overriding character coding specified by MIME header). I think we use Si&ze in most places. And I would expect either St&yle or &Style.
Assignee | ||
Comment 36•24 years ago
|
||
Assignee | ||
Comment 40•24 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 41•24 years ago
|
||
vrfy'ing. remaining issues are tracked separately in the open bug blocking this one.
Status: RESOLVED → VERIFIED
Reporter | ||
Updated•23 years ago
|
Whiteboard: se-radar
Reporter | ||
Updated•23 years ago
|
Depends on: TruncHApps
Comment 44•23 years ago
|
||
Reopening. This is not fixed in either RC1 or RC2. Either this or bug 133627 need to be fixed.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 47•22 years ago
|
||
Additional information. BuildId: 2002072308. When an application is selected in Navigator Helper Applications, the window extends to thr right driving the buttons off the screen.
Comment 53•22 years ago
|
||
In MacOS 9.2.2 Preferences panels are still not resizable and buttons are still clipped on the right in these panels: Navigator..Helper Applications Mail and News Groups..Message Display Advanced..Cache These errors exist in NS7, as well. This thread is over a year old. Why weren't the patches mentioned in this report applied to all builds after May 2001?
Comment 54•22 years ago
|
||
I also (still) have this problem with Win32, using the (old) build 2002091014 but I bet it is still the same in newer ones. If we could just have a resizeable Preferences dialog back, I would aready be satisfied. [Others might not]
Updated•22 years ago
|
Comment 55•22 years ago
|
||
I agree with Simon Hetzer: can't we just make the Preferences dialog resizable? For me that would solve the problem. Found more duplicates of this bug: 143290, 160149, 160420.
Updated•22 years ago
|
Reporter | ||
Comment 57•22 years ago
|
||
dup'ing in favor of bug 133627; also transferring dependency tree. *** This bug has been marked as a duplicate of 133627 ***
No longer blocks: 114521
Status: REOPENED → RESOLVED
Closed: 24 years ago → 22 years ago
No longer depends on: 125, 70296, 70392, 74002, 77513, 77517, 77845, 80304, 80314, 80395, 80397, 80398, 80402, 80404, 80411, 80413, 80414, 80415, 80417, 80419, 80442, 81529, 84692, 86305, 86478, 86780, 86918, 93866, 96541, 103192, 103198, 112314, 112420, 112995, 124258, 125567
Resolution: --- → DUPLICATE
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•