Closed Bug 413059 Opened 17 years ago Closed 14 years ago

Bookmark Contextual Dialog: Tab like appearance

Categories

(Firefox :: Bookmarks & History, defect)

All
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 597557

People

(Reporter: faaborg, Unassigned)

References

()

Details

(Keywords: polish, Whiteboard: [polish-hard][polish-visual] [polish-p1][icon-namoroka])

Attachments

(4 files)

On Windows the contextual dialog should expand to cover the icon that produced it, giving it a tab-like appearance. Mockup available at: http://people.mozilla.com/~faaborg/files/granParadisoUI/places_NewBookmarkDialog_i9.png
Assignee: mano → nobody
Blocks: 403157
I can think of 3 approaches to use here: 1. A second panel which is only the tab, it pops at the same time as the editBookmarkPanel but covers the star obviously. This panel will need to overlap the editBookmarkPanel by 1px in order to block the border. The drop shadow will go away when you set -moz-border-radius to round the top, but that's kind of relying on a bug (unless we have a way of specifying no drop shadow?), if the drop shadow comes back then you'll have the tab's drop shadow on top of the editBookmarkPanel. My quick attempts at this show that it's possible, albeit tricky because you're dealing with 2 panels. This is probably the most complex. AFAIK this approach will also not work for styling the Larry window, since I don't think we can make triangle shaped panels. 2. Transparent <hbox> on top of the panel, with the tab being a styled <box>, and the contents of the editBookmarkPanel inside a styled <vbox>. This has 2 flaws that I know of, you'll be able to see the UI behind the transparent box, but the panel is still there, so you can't actually use that UI while the panel is up. The other might just be something I'm not thinking of, but I can't figure out how to get rid of the border where the tab <box> would meet the <vbox>, my quick attempt at this method has gotten me this far: http://img216.imageshack.us/img216/1496/bookmarkclosekk6.png Again we run in to not being able to make triangle <box>es, but maybe SVG instead of the <box> in that case. 3. SVG as demonstrated in Bug 403157#c16. I can't foresee any real problems with this, also, instead of using SVG border radius and colors we could use CSS styling the same way we would on the panel in option 1. I don't really know enough of SVG to attempt this one though.
Alex, is this bug still valid?
>Alex, is this bug still valid? Yeah, for XP and Vista, and possibly linux. OS X has a lot of instances of a half diamond arrow for popup windows, so we might want to use that appearance there.
Just FYI, this is much "easier" now with -moz-border-image although you have to basically override native appearance (as far as I know at least). Native theme can be done (and works ok using try-server builds) with clip-path and filters when/if the SVG-CSS stuff ever lands. Do we basically have to wait for that? I think this has just become one of my pet-peeves of the FF UI, so I'm curious (although I'd be willing to attempt a patch when SVG/CSS lands and if I can ever figure out Mercurial).
Attached file Quick Extension Version, XP Only (deleted) —
This is just a quick extension hack to do this, only tested (and themed) on XP. I don't have time to set up a repo, so its the closest I can get to a starting patch. A better patch would also wrap editBookmarksPanel in a container so that it could be themed in one foul swoop (i.e. with -moz-appearance), rather than having to theme each panel individually. It loads an overlay from the a theme directory, which has the clippaths, filters, and inline CSS in it (and a little javascript just for positioning the popups). Really I was just curious. To use SVGinCSS "correctly" you need remote content references from CSS. Since Mozilla doesn't do that right now, and XUL gives us a nice overlay ability, is it... politically correct to just give theme's an overlay entry point? We could put all of Firefox's SVG in it so that its all fully themeable, even the parts that aren't themable through CSS (i.e. rounded corners on rects, SVG-transforms, path shapes, etc.).
Attached image Screenshot of extension behavior (deleted) —
This screenshot shows how the extensions currently works. For me the bookmarks dialog looks a bit diminished. This also applies to the borders. Alex, any thoughts from your side?
Attachment #340817 - Flags: ui-review?
Attachment #340817 - Flags: ui-review? → ui-review?(faaborg)
Attached image General design direction (deleted) —
>Alex, any thoughts from your side? In general this is the correct idea. For XP we want to match the appearance of menus (fill area and border color), with a 8 pixel corner radius. For Vista Aero we want to match the appearance of tooltips (fill gradient and border color), with a 4 pixel corner radius. Making the panel slightly translucent would help reinforce the idea of click outside to close.
Wesley, are you interested in continuing the work you have already started? It would be a pleasure.
Nah. I don´t have a good machine to do it on, or the desire really. There´s some difficulties with setting up a coordinate system that works (you can do things in the popup´s coordinate system, but that means you can´t specify something like 10px, only 10%, if you do them in absolute coordinates then you have to use scripts or something to size and position things correctly). At least, from what I know of SVG, those are the problems. If someone does do it, it might be a good time to look for any other SVG or filters than can be moved into a default theme file, it should be easier to do now and should make theme writers happy.
this bug is eligible for bug 462080
Keywords: polish
Whiteboard: [polish-hard][polish-visual]
Whiteboard: [polish-hard][polish-visual] → [polish-hard][polish-visual] [polish-high-visibility]
Attachment #340817 - Flags: ui-review?(faaborg) → ui-review-
Comment on attachment 340817 [details] Screenshot of extension behavior This approach looks like it has promise, but as Wesley stated the extension is just a rough prototype. Visual style guidelines can be found in attachment "general design direction"
Depends on: 363861
Blocks: wine
couldn't we simply backport to Windows the OS X way of doing this (bug 462650)? i've tried locally and works fine.
This would suffer from bug 363861 on Windows.
Attached file UserChrome for border image (deleted) —
Are you suggesting we use the same images Dao? From my reading of the ClearType bug it only affects text on transparent surfaces. Can't we just not use transparent surfaces? Just asking out of curiosity. This is something similar to the OSX solution done with UserChrome and some data urls. I don't see many errors that I don't see now anyway (a few letters clipped at the start or end), but my eyes have trouble picking out the errors in the ClearType bug too. Maybe my ClearType is set up funny too though.
Keywords: icon
Whiteboard: [polish-hard][polish-visual] [polish-high-visibility] → [polish-hard][polish-visual] [polish-high-visibility][icons-3.1]
Whiteboard: [polish-hard][polish-visual] [polish-high-visibility][icons-3.1] → [polish-hard][polish-visual] [polish-high-visibility][icon-3.1]
Whiteboard: [polish-hard][polish-visual] [polish-high-visibility][icon-3.1] → [polish-hard][polish-visual] [polish-high-visibility][icon-3.1][icon-needed]
Whiteboard: [polish-hard][polish-visual] [polish-high-visibility][icon-3.1][icon-needed] → [polish-hard][polish-visual] [polish-high-visibility][icon-3.5][icon-needed]
This bug's priority relative to the set of other polish bugs is: P1 - Polish issue that appears in the main window, or is something that the user may encounter several times a day. There are two interfaces in the main window that need to pick up this appearance, the bookmark contextual dialog, and the site identity contextual dialog. We are also thinking about ways we might use this style of UI in the future.
Whiteboard: [polish-hard][polish-visual] [polish-high-visibility][icon-3.5][icon-needed] → [polish-hard][polish-visual] [polish-p1][icon-namoroka][icon-needed]
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
I'm guessing this'll be in FF4. Also, is there a W7/vista xpi?
Depends on: 597557
Status: NEW → RESOLVED
Closed: 14 years ago
No longer depends on: 597557
Keywords: icon
Resolution: --- → DUPLICATE
Whiteboard: [polish-hard][polish-visual] [polish-p1][icon-namoroka][icon-needed] → [polish-hard][polish-visual] [polish-p1][icon-namoroka]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: