Status Meetings:2006-10-04:Log
Jump to navigation
Jump to search
12:04 <@froodian> alright, let's start
12:05 <@froodian> 1.1a1
12:05 <@ardissone> it needs way more testing that we can get at this point if we want 1.1 before 2007
12:05 <@froodian> we were planning on releasing this week
12:05 <@froodian> but a lot of the pieces aren't quite together
12:05 <@froodian> there's been some progress
12:05 <@froodian> but not enough imo
12:05 <@ardissone> i think we need to be out before Fx2 or after Fx2 has died down
12:06 < kreeger2> sorry i have been busy
12:06 <@froodian> when's Fx2?
12:06 <@ardissone> dunno for sure
12:06 <@ardissone> it's not on the ics anymore
12:06 < kreeger2> my guess is mid-october
12:06 <@ardissone> it's very close
12:06 < kreeger2> granted the security scare might push it back
12:07 <@froodian> i'd like to release before Fx2
12:07 <@froodian> personally
12:07 <@cl> that'd be nice, but is it realistic?
12:07 < kreeger2> are we just awaiting the kqueue patch and some popup UI things?
12:07 <@ardissone> planet says 24 Oct
12:08 <@ardissone> kreeger: more or less, yes
12:08 <@froodian> yeah
12:08 <@ardissone> any of the other "landing followup" bugs are also game
12:08 <@froodian> there's other stuff, but it matters less
12:08 <@ardissone> but popup UI is in the worst shape
12:08 -!- peepo has joined #camino-mtg
12:09 <@ardissone> kreeger: you hope to have kqueue ready fro review this weekend, right?
12:09 < kreeger2> yeah
12:09 <@froodian> if Fx2 is 24 Oct, I think we should definitely be before that
12:09 -!- kreeger is now known as _kreeger
12:09 <@ardissone> let's shoot for next week and re-evaluate if needed
12:10 <@froodian> sounds good to me
12:10 <@ardissone> pinkerton: ^^^
12:10 <@cl> when we say "release" are we talking about a1, or the final 1.1?
12:10 <@ardissone> a1
12:10 <@froodian> a1
12:10 <@pinkerton> that's fine
12:10 <@cl> because there's no way in hell we're getting a full version out before Fx2, is there?
12:10 <@froodian> jesus no
12:10 <@cl> ok, just making sre.
12:10 <@cl> *sure
12:10 <@froodian> ok, next
12:10 <@ardissone> no, not with our 3 month break after 1.0 ;)
12:10 <@froodian> Core bugs
12:11 <@froodian> take a very long time to get reviewed
12:11 <@froodian> is there anything we can do to get more loving in that area?
12:11 <@cl> 4 days? those examples don't look *that* bad to me?
12:11 <@ardissone> specificially hwaara was concerned that Camino fixes for major Core-caused
breakages take too long
12:11 <@cl> we've waited longer than that for review on Camino patches (albeit not lately)
12:12 <@ardissone> it also takes us too long to get patches ready for review in those cases :/
12:12 <@cl> mhm
12:12 <@froodian> yeah, i think the problem is specifically when it's major breakage problems
12:12 <@froodian> anyway, i don't think there are any "answers", it's just something we should be
aware of
12:12 <@ardissone> right, with xpfe going away, for instance
12:12 <@ardissone> but other major trunk changes
12:13 <@cl> right.
12:13 <@froodian> next?
12:13 <@cl> i'm all for updating the roadmap :-p
12:13 <@froodian> http://www.caminobrowser.org/development/roadmap/ is a big fat liar ;)
12:13 <@froodian> let's do it
12:13 <@cl> make it so.
12:13 <@froodian> somebody file a bug
12:14 <@froodian> queues are doing pretty well
12:14 <@ardissone> "Camino 1.1 is planned for 4th quarter 2006" :P
12:14 <@cl> well, that's still realistic. mostly.
12:14 <@cl> if we get a1 out next week.
12:14 <@cl> we could conceivably ship by the end of the year :-p
12:14 < kreeger2> ardissone: when is xpfe going away
12:15 <@ardissone> kreeger2: slow death
12:15 <@ardissone> but faster once SeaMokeuy 1.5 ships
12:15 < kreeger2> ok good
12:15 <@ardissone> which will be soon0ish
12:15 <@froodian> anybody have anything else before we move on to specific bugs?
12:16 <@ardissone> we need to focus on fixing 1.1 (and a1) bugs
12:16 <@froodian> yeah. a1 specifically until it comes out
12:16 <@ardissone> (unless it's mjr breakage, of course)
12:16 <@ardissone> we fixed 8 bug last week, but only 3 were a1
12:17 !sand.mozilla.org froodian invited thebot into the channel.
12:17 -!- thebot has joined #camino-mtg
12:17 <@froodian> bug 303193
12:17 < thebot> froodian: Bug https://bugzilla.mozilla.org/show_bug.cgi?id=303193 enh, --,
Camino1.1, nobody@mozilla.org, NEW, Make error pages look less like Windows and more
like Camino/Aqua
12:17 <@froodian> we should make a decision about bullets and land it
12:17 <@ardissone> smfr and philippe didn't like the loss of bullets
12:17 <@ardissone> i tend to agree
12:18 <@froodian> personally, i think philippe's bullets look nice
12:18 <@ardissone> url?
12:18 <@froodian> https://bugzilla.mozilla.org/attachment.cgi?id=240707&action=view
12:19 <@cl> i prefer that one as well
12:19 <@ardissone> that still has the too-big spacing, right?
12:19 <@froodian> uh, yeah
12:19 <@cl> yeah
12:20 <@froodian> just between the bottom of the list and the button
12:20 <@ardissone> pinkerton: is that attachment ok, once we fix the spacing between sections?
12:20 <@froodian> i think
12:20 <@froodian> i think the spacing section would be like that, no?
12:20 <@cl> and i prefer the bullets to the boxes
12:20 <@ardissone> hicks made the section spacing really large when he killed the bullets
12:20 <@froodian> ok
12:20 <@ardissone> let me look at his css
12:21 <@ardissone> yeah 1.5em vs 0.5 em in stock and 0.7em in hicks's last one with bullets
12:21 * pinkerton shrugs, looks fine to me
12:21 -!- peepo has quit [Quit: later]
12:22 <@froodian> ok. let's land it with reduced margins and spacing then?
12:22 <@ardissone> yeah
12:22 <@ardissone> and philippe's bullets
12:22 <@froodian> yes
12:22 <@cl> agreed
12:22 <@froodian> ok. bug 315340. too bad that neither of the people who commented in the bug are
here
12:22 < thebot> froodian: Bug https://bugzilla.mozilla.org/show_bug.cgi?id=315340 nor, --, ---,
nobody@mozilla.org, NEW, show inline tooltip for fields that don't fit instead of
dropped location as tooltip
12:23 <@cl> I like the idea of that one better than the "always show a tooltip" idea.
12:23 <@froodian> the only worry i have is that we'll need double the tracking rects
12:23 <@froodian> right?
12:23 <@froodian> so that we can have a url tooltip and a title tooltip
12:23 <@cl> probably, but is that really as big a deal as smfr seems to think?
12:23 <@froodian> dunno
12:24 <@ardissone> do we have 2 right now, or only one for the entire row?
12:24 <@froodian> one for the entire row
12:24 <@ardissone> i tend to think that we want the inline version
12:25 <@froodian> well, i'm not married to my patch, so i'd be ok w/ that
12:25 <@froodian> though it seems to have caught on on the forae
12:25 <@cl> also, I think we should *not* have tooltips (we currently do) for columns where you can
see the entire thing
12:25 <@cl> they're useless and they get in the way.
12:25 <@ardissone> that's what this proposes, no?
12:25 <@cl> yeah.
12:25 <@cl> which is the other reason i'm heavily in favour of it
12:26 <@froodian> i'm not sure it does
12:26 <@cl> because it would allow us to get rid of the tooltips that hide stuff.
12:26 <@froodian> it seems weird to have tooltips or not have tooltips based on column width and
title length
12:26 <@cl> for instance, a tooltip on the Location field for a bookmark folder is, well, silly.
12:26 <@cl> at least, our current one is.
12:26 <@cl> it's just the title of the folder. well, duh, i can see that!
12:27 <@ardissone> that's the way finder list views work,tho
12:27 <@ardissone> only tooltips when truncated
12:27 <@froodian> so it does
12:27 <@froodian> i guess i'm ok w/ it then
12:28 <@froodian> alright, so inline tooltips for titles and urls, and only when the title/url has
been truncated?
12:28 <@cl> right.
12:28 <@cl> how about for location/description?
12:28 <@ardissone> pinkerton: ^^^
12:28 <@cl> s/location/keyword
12:28 <@froodian> pinkerton: this is in the bm manager
12:28 < kreeger2> lunch
12:29 -!- kreeger2 has quit
12:29 <@pinkerton> what?
12:29 <@_kreeger> nick kreeger-lunch
12:29 -!- _kreeger is now known as kreeger-lunch
12:29 <@ardissone> tooltips in the bookmarks manager
12:29 <@ardissone> right now they're useless ;)
12:30 <@ardissone> the proposal is inline tooltips for titles and urls, but only when the title/url
has been truncated
12:30 <@froodian> pinkerton: when in the bookmarks manager, when you mouseover an item, we want to
have inline tooltips (instead of drop tooltips) for the title and url, and only
when the title/url has been truncated (by column width)
12:30 <@pinkerton> sounds fine to me, is that possible to implement in a cocoa tree?
12:30 * froodian has no idea
12:30 -!- Pinolo has quit [Ping timeout]
12:30 <@froodian> the downside of this decision is that since we made it, the bug is no longer fixed
;)
12:30 <@froodian> (or on its way to being fixed)
12:31 <@ardissone> well,???some enterprising soul can fix it at some point ;)
12:31 * cl wonders where the random Arabic letters come from in Smokey's IRC text every so often
12:31 <@ardissone> cmd-space :P
12:32 <@cl> heh
12:32 <@ardissone> next bug then?
12:32 <@froodian> ok, next
12:32 <@froodian> i was going to ask about Bug 290212, but I don't think enough people who could
shed brilliance on the subject are here
12:32 <@ardissone> bug 290212
12:32 < thebot> ardissone: Bug https://bugzilla.mozilla.org/show_bug.cgi?id=290212 enh, --,
Camino1.1, stridey@gmail.com, NEW, Implement bookmark folders' "Open in Tabs"/"Open
in New Tabs" with alternate menu items
12:32 <@cl> pinkerton, mento, smfr probably need to fight that out :-p
12:32 <@froodian> maybe. maybe it just needs something really clever.
12:32 <@ardissone> sooon, please ;)
12:32 <@cl> although...have we seen any big perf hits since the alternates for the bookmark menu
landed?
12:32 <@froodian> not that anybody has mentioned
12:33 <@ardissone> no one's really complained
12:33 <@cl> because that seems potentially a lot worse than what this bug is asking for
12:33 <@ardissone> but i think our testing is too light
12:33 <@ardissone> right now
12:33 <@cl> and if that hasn't caused problems, i think we're probably OK with this one.
12:33 <@ardissone> which is another reason for a1
12:33 <@froodian> well, the problem isn't the alternates
12:33 <@froodian> it's getting the text in them to update
12:33 <@cl> what's the problem, then?
12:33 <@cl> ah
12:33 <@froodian> based on the tabs/windows pref
12:34 <@froodian> personally, i see that as a very minor issue
12:34 <@froodian> compared to the current one
12:34 <@cl> have you tried Wevah's suggestion?
12:34 <@ardissone> yeah
12:34 <@froodian> yes
12:34 <@froodian> it's no good
12:34 <@cl> and it didn't work? shoot.
12:34 <@froodian> fuck, that's who i didn't invite
12:34 <@cl> yeah, but he's not there
12:34 <@ardissone> I think i'd be ok with landing the fix and fixing the text later
12:34 <@froodian> i'd be very ok with that
12:34 <@froodian> i dunno about smorgan though
12:35 <@ardissone> yeah....
12:35 -!- peeja has left #camino-mtg []
12:35 <@cl> i don't have any brilliant ideas there either.
12:36 <@ardissone> pinkerton: in Bug 290212, there's a regression where you have to hold down cmd
before opening the menu to make it "open in NEW tabs"
12:36 <@ardissone> can we go ahead and land the part of the fix that does that right now, and come
back to fixing things so the text updates based on all our tab/window prefs?
12:36 <@pinkerton> sure
12:36 <@ardissone> ok, why am i seeing that now :/
12:36 <@ardissone> k
12:37 <@ardissone> do we want to plug murph's bug for eyeballs, too?
12:37 <@froodian> we should
12:37 <@froodian> bug 341967
12:37 <@ardissone> (we should also revisit the color bug for pink's benefit)
12:37 <@murph> yeah, I have a few points I'd like to ask for opinions on..
12:37 < thebot> froodian: Bug https://bugzilla.mozilla.org/show_bug.cgi?id=341967 nor, --,
Camino1.1, camino@seanmurph.com, ASSI, Popup blocker notification text doesn't wrap
properly
12:38 <@murph> I've been having a hell of a time with this one, but I should have a (non-hackish)
solution pretty soon..
12:38 <@murph> but
12:38 <@froodian> specifically bug 341967 comment 10
12:40 <@froodian> i think the best chance for that bug is to flag the patch you have (or the next
iteration) to r?smorgan
12:40 <@murph> when the window size gets to be a certain [very small] width, I think the text needs
to stop wrapping (just like the Fx behavior)
12:40 <@froodian> because he probably has solutions
12:40 <@cl> don't we already have a minimum size for the window anyway?
12:40 <@cl> hrm, guess not.
12:40 <@murph> yeah, but it's a real small value
12:41 <@froodian> i have a wild idea. let's get rid of the text entirely, and just use an icon.
that way, it won't have to wrap. Plus, we could put it somewhere where it didn't
get in peoples' ways, like... um... i dunno...
12:41 <@froodian> sorry, not helpful
12:41 <@froodian> ;)
12:41 <@cl> lol
12:42 <@cl> i second that idea.
12:42 * pinkerton glares
12:42 <@froodian> sorry
12:42 * froodian hides
12:42 -!- cl is now known as userbase
12:42 * userbase glares back
12:42 -!- userbase is now known as cl
12:42 <@froodian> at this point, i'm just doing it to be snarky
12:42 <@froodian> i apologize. back to topic
12:42 <@froodian> murph: i think that's totally reasonable
12:42 <@pinkerton> i need food brb
12:43 <@murph> ok..bc otherwise we'd end up wrapping into about 50 lines with one char each
12:43 <@froodian> yeah, you have to draw the line somewhere
12:43 <@cl> can someone take a screenshot of the wrapping behaviour with a window resized as small
as it'll go?
12:43 <@ardissone> what's reasonable? the width of the prefs window?
12:43 <@cl> cause i'm curious to know just how bad it looks.
12:43 <@murph> cl: yeah..i'll upload one now
12:44 <@froodian> we must have at least a couple 800x600 users, right?
12:44 <@ardissone> yeah
12:44 <@froodian> prefs window is 595
12:44 <@ardissone> prefs are 595
12:44 <@froodian> that seems reasonable
12:44 <@froodian> if you're browsing at that resolution, you'll be using as much of the screen as
possible
12:44 <@ardissone> we should also fix min-width on the browser window, too
12:44 <@cl> hey, here's an idea...
12:45 -!- delliott has joined #camino-mtg
12:45 <@cl> instead of stopping the wrap at some magic number of pixels of width
12:45 <@cl> can we continue to wrap, but insert a linebreak so the button(s) and text are on
separate lines?
12:45 <@ardissone> ew
12:45 <@froodian> well, at a certain point you have more popup blocker than content pane
12:45 <@murph> cl: https://bugzilla.mozilla.org/attachment.cgi?id=241186
12:46 <@cl> yeah, see, that *does* look awful.
12:46 <@cl> but what if you stuck the buttons either above or below that message?
12:46 <@ardissone> basically, we need to account for l10n and reasonably-small widths
12:46 <@murph> ignore the button's being off-centered in that, btw :(
12:46 <@cl> (probably below)
12:47 <@ardissone> 278 is really too small
12:47 <@murph> the funny part about fixing this bug is that popuptest.com probably never had so many
hits in one week before I started working on this :D
12:47 <@cl> also, it occurs to me now (i probably should have said something before) that the "Tube"
icon and the close widget seem to be two different visual representations of the same
sort of idea, which makes me wonder if users are going to try to click the "Tube" icon
and get some unexpectedly wrong behaviour (or nothing at all)
12:47 <@ardissone> if there are popups throwing popups, that's just evil
12:48 <@cl> ardissone: you've never browsed much pr0n with IE, have you? :-p
12:48 <@ardissone> heh, no on both accounts
12:49 <@ardissone> we could use the standard warning icon if that starts to be a problem, i guess
12:49 <@cl> i think that might be better than introducing a new icon for an old concept.
12:49 <@froodian> ok. so, let's limit the wrapping width. murph can figure out the details of
exactly where the line is, but 595 sounds reasonable to me
12:50 <@froodian> well, remember that we want to use this icon in the status bar
12:50 <@ardissone> and then fix browserwindow to match
12:50 <@ardissone> right
12:50 <@froodian> if there's just a "warning" icon in the status bar, it doesn't mean anything
12:50 <@froodian> i like the tube icon
12:50 <@cl> i like it too, i just don't know that it's appropriate for this.
12:51 <@murph> alright, 595 should work out fine..I will try to have this one fixed asap then
12:51 <@froodian> i think having the close button be more visible will help
12:51 <@froodian> which will prolly happen as part of the existing followups
12:52 <@ardissone> bug 355323
12:52 < thebot> ardissone: Bug https://bugzilla.mozilla.org/show_bug.cgi?id=355323 nor, --,
Camino1.1, nobody@mozilla.org, NEW, Fix followup issues with changing the color of
the pop-up blocker bar
12:52 <@froodian> (since the hover and mousdown state need to be more visible, and you can only get
so much blacker, so the "standard" state will need to be lighter)
12:52 -!- kreeger-lunch is now known as kreeger
12:52 <@ardissone> i think we need to switch to a gradient
12:52 <@ardissone> for the bgcolor
12:53 <@murph> yeah, the pattern image assumes a fixed height at the moment
12:54 <@cl> mhm
12:54 <@ardissone> this one (i think)
http://adggda.com/~ss/camino/mockups/popupblocker2-toned_down_blue.jpg
12:54 <@ardissone> can be done as a gradient perhaps
12:54 <@murph> and then we have the whole resolution independent migration, and using bitmapped
images aren't always future-proof in this regard
12:54 <@ardissone> yeah (although we're screwed already there)
12:54 <@cl> can't we generate that gradient programmatically?
12:55 <@ardissone> the one in that screenshot, or the current glassy one?
12:55 <@cl> in the screenshot
12:55 <@murph> cl: sure, with CoreGraphics or CoreImage (CI is 10.4+ only tho)
12:55 <@ardissone> i think we should be able to generate toned_down_blue in code
12:56 <@ardissone> i think that instead of trying to match the close icon's color, it should stay
grey
12:56 <@ardissone> which will help with people finding ti
12:56 <@froodian> i agree
12:56 <@froodian> especially if we're going with the blue
12:56 <@murph> yeah, maybe make it's color more in-line with the aqua widgets accompanying it
12:57 <@murph> since they are the three objects that can be clicked
12:57 <@froodian> well, let's just keep it the way it is in the tabs
12:57 <@froodian> since we already have a graphic that means "close this" to people
12:57 <@murph> true..
12:57 <@cl> mhm
12:57 <@froodian> ok. i have to go make a presentation in class
12:57 * froodian hands ardissone the torch
12:57 <@ardissone> now the question is, has pinkerton seen any of this or is he still at lunch?
12:58 -!- froodian is now known as froodian|class
12:58 <@ardissone> thanks froodian
12:59 <@ardissone> pinkerton: did you catch any of this discussion on the problems with the glassy
black popup blocker bg?
13:00 <@cl> fwiw, i think glassy black looks horribly out of place with the rest of the UI
13:00 <@pinkerton> nope
13:00 <@ardissone> bug 355323 gives a good summary
13:01 * pinkerton waits for thebot
13:01 <@ardissone> https://bugzilla.mozilla.org/show_bug.cgi?id=355323
13:01 <@pinkerton> heh
13:01 -!- ardissone is now known as ardissone|thebot
13:01 -!- ardissone|thebot is now known as ardissone
13:01 < thebot> ardissone: Bug https://bugzilla.mozilla.org/show_bug.cgi?id=355323 nor, --,
Camino1.1, nobody@mozilla.org, NEW, Fix followup issues with changing the color of
the pop-up blocker bar
13:01 <@pinkerton> js
13:01 <@pinkerton> ha
13:02 <@pinkerton> i don't recall the buttons looking out of place in the mockups
13:02 <@ardissone> hwaara and smorgan both complained about that
13:03 <@pinkerton> i c
13:03 <@ardissone> they look "too suspened-in-air" or something; not sure how to describe
13:04 <@ardissone> but the bigger problem really is with wrapping the text to accomodate l10n and
smaller windows
13:04 <@ardissone> we need something we can do in code rather than as an image
13:05 <@ardissone> e.g., http://adggda.com/~ss/camino/mockups/popupblocker2-toned_down_blue.jpg
13:05 <@cl> so what's the end result of the wrapping going to be if the window *is* resized below
the 595-pixel threshold?
13:05 <@cl> murph: can you post a screenshot of that once you have a working patch?
13:05 <@cl> because if it's more of the current behaviour, that sucks ass.
13:05 <@murph> cl: sure thing..
13:06 <@murph> cl: if the window gets too small, and we back out of wrapping, the widgets would
(right now) be clipped off-screen (which is what Fx2 does)
13:06 <@ardissone> pinkerton: our consensus from this meeting discussion is go with a blue like that
mockup that can be done in code and go back to the standard close button so it
doesn't disappear
13:07 <@pinkerton> ok
13:07 <@cl> murph: that's better than what we're currently doing, i suppose.
13:07 <@ardissone> ok
13:07 <@cl> i still don't see why we can't wrap the two buttons onto a separate line
13:07 <@murph> yeah, i don't really like having the close button clipped off-screen though
13:07 <@cl> which seems like it would solve all the problems and avoid the issue of a magic-number
threshold
13:07 <@ardissone> anyone have anything else?
13:07 <@cl> yeah, one quick thing
13:08 <@cl> bug 337958
13:08 < thebot> cl: Bug https://bugzilla.mozilla.org/show_bug.cgi?id=337958 nor, --, Camino1.1,
bugzilla@chrislawson.net, ASSI, Dragging folder/tab group from Bookmark Bar to tab
strip should respect shift toggle
13:08 <@cl> there is no comment 17 :-p
13:08 <@cl> i assume you meant comment 12.
13:08 <@ardissone> smorgan's last comment
13:08 <@ardissone> i was tired and my head hurt last night
13:08 <@cl> heh
13:09 <@cl> pinkerton, this is where you come in.
13:09 <@cl> how is a class method different from what i've done already? :-p
13:12 <@ardissone> not to cut off the answer, but anything else, or can we go and let cl wait alone?
;)
13:13 <@ardissone> ok then...let's go out and fix a1 nominees and things for the popup blocker, and
we'll try again to ship 1.1a1 next week
13:13 <@ardissone> thanks everyone!
13:14 <@cl> pinkerton: you can answer over in #camino
13:14 <@cl> since i'm leaving this channel.
13:14 -!- cl has left #camino-mtg []
13:14 <@murph> sounds good. see everyone later.. (and sorry my bug is taking a while)
