Picks up the work that got dropped off from bug 720641

This is shorlander's, from bug 720641 comment 32: (In reply to Joe Walker from comment #18) > Can you give me an example of >> for overflow? > My reasoning behind >> was that it was like the > we already used, but "more > so", and it worked simply anywhere, allowing a change of color and > background using only CSS, which unless you know of cool tricks that I > don't, you can't do with graphics. (I know you can change one of > color/background using transparency, but both, independently?) We use it for toolbar overflow: http://cl.ly/1t1W312V2s172x3b1v01 Although we use a single tailless arrow for scroll left/right also so maybe it doesn't matter that much. Where would we be reusing it so that we need to change the style that often? > I agree that it's not massively discoverable, but on the other hand: > - it is 'the standard' > - we do tell people about it in the opening blurb that shows every time > until they say they've read it > - it's not a requirement for using GCLI. The obvious thing to do if you're > not sure is to type help, which we also support (and I guess we could add F1 > instruction in there too) > - the help shows automatically when we think people need it. so this is just > for when people say they want help, and we've not guessed Fair enough, just a thought :) > The location of the (?) clashes somewhat with the (tick) marker that we > previously discussed to show that a command worked but had no output. How do > you see those interacting? They could align next to each other without much issue assuming we end up needing an indicator like that. > I agree that moving the hints as you type would be really annoying, but the > hints change depending on which parameter the cursor is in so I think it > makes sense to connect the hint to the parameter in some way. Right, let me think about that some more. I have a few things I was trying, I will post those. > One thing I would like to do is to get away from monospace fonts. I don't > see any good reason for them other than implementation detail (which is/was > the issue, we might be able to fix that now). Can we get away from that? > It's certainly not needed in the hint/output area, and possibly not in the > input any more, although that will require some experimentation. This has the makings of a larger and more contentious debate ;) There is no reason we couldn't use the system font here. I think the concern is what kind of font people expect from a command line. Especially in a situation where you might be entering code into it. I do think we should use a consistent font for both the input and the output/help panels. > What's the 'undefined' for in the final example? I actually meant to ask you that ;) It is what showed up in my GCLI output with your patches.

(In reply to Joe Walker from comment #3) > This is shorlander's, from bug 720641 comment 32: > > (In reply to Joe Walker from comment #18) > > Can you give me an example of >> for overflow? > > My reasoning behind >> was that it was like the > we already used, but "more > > so", and it worked simply anywhere, allowing a change of color and > > background using only CSS, which unless you know of cool tricks that I > > don't, you can't do with graphics. (I know you can change one of > > color/background using transparency, but both, independently?) > > We use it for toolbar overflow: http://cl.ly/1t1W312V2s172x3b1v01 > > Although we use a single tailless arrow for scroll left/right also so maybe > it doesn't matter that much. > > Where would we be reusing it so that we need to change the style that often? In the tab view of GCLI, we currently use it as a prefix on executed commands with 3 colors, red: error, green: ok, blue, incomplete. For example: http://mozilla.github.com/gcli/ » echo hi » sleep 1000 (I'm not sure there is a command that can fail there) Also I would like to add some colors to the prompt to indicate what state the current command is in: red: error, orange: incomplete, blue: ready to press return. I guess this is just 4 graphics, given a transparent background - not a huge hassle. > > The location of the (?) clashes somewhat with the (tick) marker that we > > previously discussed to show that a command worked but had no output. How do > > you see those interacting? > > They could align next to each other without much issue assuming we end up > needing an indicator like that. I suggest we see how it works without a (?), and we can add one in if we need one. > > I agree that moving the hints as you type would be really annoying, but the > > hints change depending on which parameter the cursor is in so I think it > > makes sense to connect the hint to the parameter in some way. > > Right, let me think about that some more. I have a few things I was trying, > I will post those. Thanks. > > One thing I would like to do is to get away from monospace fonts. I don't > > see any good reason for them other than implementation detail (which is/was > > the issue, we might be able to fix that now). Can we get away from that? > > It's certainly not needed in the hint/output area, and possibly not in the > > input any more, although that will require some experimentation. > > This has the makings of a larger and more contentious debate ;) > > There is no reason we couldn't use the system font here. I think the concern > is what kind of font people expect from a command line. Especially in a > situation where you might be entering code into it. > > I do think we should use a consistent font for both the input and the > output/help panels. Right now, we've even removed the ability to enter Javascript, so you can't enter code at all! I would like to add that back in, but only once we've established the idea that we can have a command line separate from an JS prompt. I would also like to have the input area be hidden and represented on-screen by nicer markup. The idea is to be able to: - display text inside {} in a monospace font, variable width outside - display long arguments elided when not being edited - display passwords obfusticated in some way - etc. > > What's the 'undefined' for in the final example? > > I actually meant to ask you that ;) It is what showed up in my GCLI output > with your patches. I hope that's gone now. Please tell me if you find it again.

Using as a meta bug for UI issues with developer toolbar.

Old meta bug that's not particularly helpful to have kept around. Triage.