So far the Classic theme does a good job of imitating the look and feel of many of the standard widgets, but we don't yet have a win32 tab control widget.
I tried to do that and got a GPF trying to add the extra boxes needed for the borders. Also I can't figure out how to force the border to overlap all adjacent borders - I tried margin: -2px; but that doesn't overlap the right-hand border :-(
Sending to Brendan
Assignee: hangas → bdonohoe
Status: ASSIGNED → NEW
Is this really nothing more than just polish? This is a pretty big deal, considering every other widget in Classic now (more or less) resembles win32 except the tab.
QA Contact: paw → BlakeR1234
See also bug 46009 for the mac tab l&f
We'll need a version of this for Linux, too.
Assignee: bdonohoe → nbhatla
*** Bug 48007 has been marked as a duplicate of this bug. ***
I hear Ben is gonna be checking in a new Tab XBL widget for windows. Once he does this, I'll get to work styling them so they look good on windows.
I'll try and check this in tonight. Each tab should be a box, the selected tab should be a box with no bottom border. The tabbox widget has an anonymous spring to the right of the tabs that you can style with a bottom border to span the rest of the space from the last tab to the right edge of the tabpanel.
reassigning -> hewitt
Assignee: nbhatla → hewitt
Status: ASSIGNED → NEW
I've got a working draft of the windows tabs going at the moment (about to be attached). It looks pretty authentic so far, minus a few minor details. There are some issues, however. 1. I need to put an anonymous spring in the tabbox, which conflicts with the fact that some of the tabcontrols in Mozilla chrome already have a spring in them. My spring is used for the bottom border, but the extra spring won't be bordered (unless explicitly styled by the user) which makes the top of the tabs have a big gap. 2. Many tabcontrols in mozilla (mailnews, composer, bookmarks) still use align instead of orient, which needs to be fixed. The CSS depends on the orient attribute being used. 3. I need to put an anonymous box around the tabpanel to make it's border look just right, but doing this causes my build to crash. I'll keep trying it in the coming days. 4. If you put the tabs on the left or right, it doesn't quite look right because the tabs don't stretch to be the same size. I can't use autostretch because it prevents my ability to raise the selected tab above the others. I've thought about putting an extra anonymous box within the tabs and using that to do the raising/lowering of tabs, but I'm frightened by the ugliness of that solution. Perhaps I'll try it.
The following files needed to be changed to work with the new skin. They were using old XUL code which used align instead of orient, and some had a spring in the tabbox which messed up the look: mailnews\addrbook\resources\content\abCardOverlay.xul xpfe\components\bookmarks\resources\bm-props.xul editor\ui\dialogs\content\EdAdvancedEdit.xul editor\ui\dialogs\content\EdTableProps.xul extensions\wallet\cookieviewer\CookieViewer.xul extensions\wallet\cookieviewer\SignonViewer.xul xpfe\components\search\resources\search.xul xpfe\global\resources\content\about.xul
so Joe, does your latest checkin fix this?
Looks pretty accurate now to me. Only two things still wrong with the tabs: A). The tabpanel needs an internal box for a thicker right/bottom border, but currently doings this with XBL is causing crashes. Looks ok without it for now, though. B). The space to the left of the first tab needs a bottom border, but when I put a spring there in the XBL it gets pushed off to the right of the tabs. Again, hard to notice it's not there.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
vrfy fixed in just-pulled build on win98; and they look nice, too.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.