[Webkit-unassigned] [Bug 32568] Web Inspector: Context Menus should be used in more places

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=32568





--- Comment #16 from Timothy Hatcher <timothy at hatcher.name>  2010-01-05 09:55:52 PST ---
(In reply to comment #15)
> (From update of attachment 45865 [details])
> Are you saying there is no way to remove breakpoint without involving context
> menu now? I'd be strongly against that. I think this strategy of breakpoint
> management is cluttering UI when investigating the code (and hence put many
> breakpoints).

What I told Brian on IRC was that we need a quick way to remove, and that
method in Xcode is drag away and poof. So without that I think we would be more
cumbersome in the removing category.

> On a more general note, I think that using Xcode as an IDE of reference is
> wrong. I know that you guys are used to it, but that's not the case for the web
> developers out there. I personally find Xcode confusing. I'd stick to more
> standard (wide-spread) platform such as Eclipse instead. We know that Java was
> getting the most IDE love for the past 10 years and hence got most advanced and
> used.

I would argue that most web developers don't use Eclipse. I know I never have,
and my web developer friends never have. They don't use Xcode either. Perhaps
the IDE most used is Visual Studio and it's JS debugger? I have no idea, but
that seems more likely to be familiar than Eclipse.

I (and other Apple engineers) use Xcode as a reference for obvious reasons.
None of us use Eclipse, so we have no familiarity with it. So I can't argue if
it is better in practice, but I have no other reference IDE.

> The Eclipse's model for breakpoint management (and I like it) is following:
> 1) Click in gutter sets / removes the breakpoint
> 2) Context menu in gutter has following actions:
>   "Toggle Breakpoint" (sets/removes);
>   "Disable Breakpoint" / "Enable Breakpoint" based on its enabled state
>   "Breakpoint Properties..." invokes a modal dialog that allows setting enabled
> state, hit count, enable condition, other java-specific options.
> So I think that removing breakpoint should be easier than disabling it. Hence I
> think that enable/disable breakpoint belongs only to context menu and
> breakpoint manager. Worst case, lets leave it as is with three click states.

Eclipse's way does sound logical and isn't too different from Xcode. Xcode has
click to toggle enable/disabled because drag away does a remove. I don't think
a "Toggle Breakpoint" item is needed, since it is more work to use than a
single click.

I wish we never landed the three-click method, it is frustrating to use. We
should mimic Eclipse, sicne we don't have drag and drop and drag to remove
support yet.

> Actually, there is one important scenario where I need to enable / disable
> breakpoints fast. That's when I need to debug n-th iteration of something. I
> run program and hit them all, disable then one by one, then count to the
> iteration I am interested it and then restore them all. But that's all due to
> the lack of 'Disable Breakpoints' action in the debugger and / or breakpoint
> manager. I think we need to implement it asap.

Maybe a double click on a breakpoint can toggle the enable state, and single
click toggles remove?

> One more thing to note: in IDE, breakpoints 'follow' code when you insert lines
> while editing. In our environment editing is disconnected and on the subsequent
> run of the app, breakpoints are all wrong. So removing them easily is
> important.

We should have a context menu item in the gutter that says "Remove All
Breakpoints".

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.