[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [orion-dev] Firebug integration
|
On 2/19/2011 10:33 AM, Boris Bokowski wrote:
John J. Barton wrote on 2011/02/19 12:59:33:
> the thing that is in the window is some complicated dojo application
not
> a component that can be talked to. (I'm basing this on trying to read
> the code, I didn't find any docs).
This is not because we wanted it to be this way, it's because we
didn't have anybody who wanted to consume the editor with key bindings
etc. as a component yet. Sounds like now is the time to work on making
it a component.
What's the interface you would like to see? The simplest possible
interface I can think of is an object you can call setText and getText
on. You could pass the id of a div in the constructor, or something
like that. You probably want to be called when the dirty state
changes. Anything else?
That pretty much describes what I have now with editor.js, so it would
work. I also need to
highlight a line in the editor and tell the user why the line was
selected (hit various kinds of breakpoints, errors, links to functions).
Eventually to complete the integration we'll need
obtain the code under the mouse (for fly-over inspector)
highlight a range of text,
get the selected range of source, (for watch evaluation)
Who would react to Ctrl+S, the editor?
If by Ctrl+S you mean save to server, I think the answer is "the
editor, but if it can't, don't go nuts". For normal web app dev it seems
like the editor should save; for prototyping work the ideal case is the
editor should save and the server should support trivial roll back; for
exploratory work on sites you don't own the editor can't save but
Firebug can still apply the changes to the live image.
Separately there is "I'm happy with my editing so far, I want to see how
well its working". That can be bound to Ctrl+S. But it also could be
more or less aggressive, and it could be a separate control. The Java
hot loading solution in eclipse binds it to save so that is where to start.
What about the outline and the error markers, would you expect that to
be part of the component?
Yes, I believe that is what users will want. However, one of my goals
however is it make error markers obsolete. I want to stop and fix errors
immediately, not create a list of them, fix them, then retry.
I've filed an enhancement request for the detailed discussion:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=337647
Thanks, that sounds great!
jjb
Thanks,
Boris
