Closed
Bug 803477
Opened 13 years ago
Closed 9 years ago
GCLI tooltip text gets cut off
Categories
(DevTools Graveyard :: Graphic Commandline and Toolbar, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: vporof, Unassigned)
References
Details
Attachments
(1 file)
269.22 KB,
image/png
|
Details |
STR: type dbg, return.
I couldn't find any other related bug filed, but please close this if a dupe.
Updated•13 years ago
|
Summary: GCLI help text gets cut off → GCLI tooltip text gets cut off
Comment 1•13 years ago
|
||
I'm not sure what we should do about this. We could widen the max-width of the tooltip, but where do we stop with that? People are going to create longer and longer tooltips, and not realize that other people have narrower screens, so there needs to be a limit on the length of the help text.
Also on the other side: TL;DR.
If it's not possible to meaningfully shrink the descriptions then perhaps our limits are too limiting. Might shrinking them work?
Perhaps also we should make a hard limit (via an exception) on command descriptions???
Reporter | ||
Comment 2•13 years ago
|
||
Is having a fluid layout is out of the question? I mean, why couldn't we just allow text to break here as well, like in the 'help' popup?
Comment 3•13 years ago
|
||
(In reply to Victor Porof [:vp] from comment #2)
> Is having a fluid layout is out of the question? I mean, why couldn't we
> just allow text to break here as well, like in the 'help' popup?
There isn't really a help popup - there's the output of the help command, which like all output is wrapped.
This is just a menu. In a way, I'm tempted take away all the descriptions like normal menus. I think that having it wrap makes it uglier, harder to scan, and less likely to be read. I really think we can do more by being more concise in how we describe the commands.
Could we change the description text to be manual text (which is used by the help command) and introduce a more concise description text?
dbgContinue=Continue script execution
dbgStepOverDesc=Pause at next statement in this function
dbgStepInDesc=Pause at next statement
dbgStepOutDesc=Pause at next statement in calling function
Are the current descriptions accurate? What does 'main thread' mean to a JavaScript developer?
Reporter | ||
Comment 4•13 years ago
|
||
(In reply to Joe Walker [:jwalker] from comment #3)
> (In reply to Victor Porof [:vp] from comment #2)
> > Is having a fluid layout is out of the question? I mean, why couldn't we
> > just allow text to break here as well, like in the 'help' popup?
>
> There isn't really a help popup - there's the output of the help command,
> which like all output is wrapped.
>
> This is just a menu. In a way, I'm tempted take away all the descriptions
> like normal menus. I think that having it wrap makes it uglier, harder to
> scan, and less likely to be read. I really think we can do more by being
> more concise in how we describe the commands.
Fwiw, this also happens with other commands, like pagemod, but indeed, most of the commands have *short enough* descriptions to fit in there.
I'd be happy, thought, if this menu (and the help popup) would be a tiny bit wider to allow for more wordy descriptions if necessary. For example, what happens with command 'foo bar baz omega epsilon'? There's almost no room left in there for descriptions. But that's a different bug.
> Could we change the description text to be manual text (which is used by the
> help command) and introduce a more concise description text?
That's a good enough solution.
> dbgContinue=Continue script execution
> dbgStepOverDesc=Pause at next statement in this function
"current function" sounds more appropriate
> dbgStepInDesc=Pause at next statement
> dbgStepOutDesc=Pause at next statement in calling function
> Are the current descriptions accurate? What does 'main thread' mean to a
> JavaScript developer?
I think loosely translating it would be 'script execution', so for consistency, let's also modify dbgInterrupt to read "Pause script execution"
Comment 5•12 years ago
|
||
(In reply to Victor Porof [:vp] from comment #4)
> I'd be happy, thought, if this menu (and the help popup) would be a tiny bit
> wider to allow for more wordy descriptions if necessary. For example, what
> happens with command 'foo bar baz omega epsilon'?
OK, I'm happy to grow it a bit.
> > Could we change the description text to be manual text (which is used by the
> > help command) and introduce a more concise description text?
>
> That's a good enough solution.
>
> > dbgContinue=Continue script execution
> > dbgStepOverDesc=Pause at next statement in this function
> "current function" sounds more appropriate
> > dbgStepInDesc=Pause at next statement
> > dbgStepOutDesc=Pause at next statement in calling function
>
> > Are the current descriptions accurate? What does 'main thread' mean to a
> > JavaScript developer?
>
> I think loosely translating it would be 'script execution', so for
> consistency, let's also modify dbgInterrupt to read "Pause script execution"
Is there a bug for this?
If so, I'll make this bug depend on that so I've got more data on how much to widen by.
Comment 6•12 years ago
|
||
Why don't we just fit it to the text like we do with the help popup?
Comment 7•12 years ago
|
||
(In reply to Michael Ratcliffe [:miker] [:mratcliffe] from comment #6)
> Why don't we just fit it to the text like we do with the help popup?
Because we don't want to fit very long text in. This is a menu that the user scans, so brevity is a feature and the maximum width is a leaver to encourage command authors to make their descriptions quickly scannable.
Reporter | ||
Comment 8•12 years ago
|
||
(In reply to Joe Walker [:jwalker] from comment #5)
> > > dbgContinue=Continue script execution
> > > dbgStepOverDesc=Pause at next statement in this function
> > "current function" sounds more appropriate
> > > dbgStepInDesc=Pause at next statement
> > > dbgStepOutDesc=Pause at next statement in calling function
> >
> > > Are the current descriptions accurate? What does 'main thread' mean to a
> > > JavaScript developer?
> >
> > I think loosely translating it would be 'script execution', so for
> > consistency, let's also modify dbgInterrupt to read "Pause script execution"
>
> Is there a bug for this?
> If so, I'll make this bug depend on that so I've got more data on how much
> to widen by.
Not that I'm aware of. We can make these changes here.
Comment 9•12 years ago
|
||
New component triage. Filter on "Lobster Thermidor aux crevettes with a Mornay sauce"
Component: Developer Tools → Developer Tools: Graphic Commandline and Toolbar
Comment 10•9 years ago
|
||
Triage. Filter on Lobster Thermidor.
Nice idea, but it's not been worked on in 4 years, and I don't see that the priority of GCLI has increased in that time, so I don't think we need to keep it on file.
Comment 11•9 years ago
|
||
Triage. Filter on Lobster Thermidor.
Actually closing this time.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Updated•7 years ago
|
Product: Firefox → DevTools
Updated•7 years ago
|
Product: DevTools → DevTools Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•