561458 - Create sane API and/or approach to console UI construction

Status: RESOLVED WONTFIX

(DevTools :: General, defect)

Description

[David Dahl :ddahl]

Currently creating the entire UI via DOM api, after talking to rs, I think it should all be done via document.loadOverlay()

Comment 1

[David Dahl :ddahl]

(This is for the Console UI work.)

Comment 2

[David Dahl :ddahl]

Actually, now that I read the documentation, this seems to be a non-starter:

"Loading an overlay with the same URI twice is not currently supported, although it may work sometimes. There's a comment in nsXULDocument::LoadOverlay to that effect."

https://developer.mozilla.org/en/DOM/document.loadOverlay

Not only that, but the overlay would need to know the id of the dom node it is overlaying beforehand. The idea of the notificationbox i that is dynamically generated is the parent node of each HeadsUpDisplay.

I think I will just concentrate on making a sane API for the dynamic DOM-API-created UI

Comment 3

[David Dahl :ddahl]

(In reply to comment #2)
this:
> ...the overlay would need to know the id of the dom node it is
> overlaying beforehand. The idea of the notificationbox i that is dynamically
> generated is the parent node of each HeadsUpDisplay.

should say:

...the overlay would need to know the id of the dom node it is
 overlaying beforehand. The id of the notificationbox is dynamically
 generated - which is the parent node of each HeadsUpDisplay.

(i need coffee)

Comment 4

[Robert Strong (they/them - no direct email)]

bummer

Comment 5

[David Dahl :ddahl]

I suppose in the long run, all of this UI should be converted to XBL. I am currently using html:div elements for all of the logging nodes, which have the magical method .scrollIntoView(), which makes the console and JS Workspace very "consoley" without trying to hard. How would this be impacted by a move to XBL?

Comment 6

[Robert Strong (they/them - no direct email)]

sicking would likely know whether this would work via xbl

Comment 7

[David Dahl :ddahl]

Changing title from:  "Convert UI creation from JS to document.loadOverlay "

to: Create sane API  and/or approach to console UI construction

Comment 8

[David Dahl :ddahl]

Current approach is here: 

http://hg.mozilla.org/users/ddahl_mozilla.com/heads-up-display/file/6b9ff3dc7cd0/toolkit/components/console/hudservice/HeadsUpDisplay.jsm#l287

I am slowly breaking this up into more methods to isolate the widgets.

Comment 9

[Robert Strong (they/them - no direct email)]

Keep in mind that the original question you approached me with was regarding creating commandsets via JS. I really don't know what the *right* or *best* solution for this is. I personally prefer having UI in XUL or XBL vs. creating everything dynamically via JS as I noted but others may not have this preference.

Comment 10

[Philip Chee]

Perhaps someone could have a peek at how Songbird loads new UI using their "Feathers" feature. I seem to remember that they had to jump through a lot of hoops to have the ability to load and unload UI dynamically but it seems to work.

Comment 11

[Rob Campbell [:rc] (:robcee)]

I think I have Rob Strong's preference for declarative commandsets and UI as well. Dynamically-created features are going to be a lot harder to tease out of the accompanying code. Resultant code should also be more understandable if it's well-separated.

Philip: Interesting suggestion, but probably completely different from anything we're doing in the browser already. Do you have some convenient links to source handy before we go exploring?

Comment 12

[Philip Chee]

> I think I have Rob Strong's preference for declarative commandsets and UI as
> well. Dynamically-created features are going to be a lot harder to tease out of
> the accompanying code. Resultant code should also be more understandable if
> it's well-separated.

Me three. Not to mention making it easier to review.

> Philip: Interesting suggestion, but probably completely different from anything
> we're doing in the browser already. Do you have some convenient links to source
> handy before we go exploring?

Sorry, nothing except the Songbird blog posts that showed up on planet.mozilla.org earlier on in the Songbird development timeline. Perhaps you can ping Mook (Mark Yen) on IRC. He's a back end guy but could probably put you in touch with the relevant Feathers person.

Comment 13

[David Dahl :ddahl]

We can come up a plan in the next rev of the console or re-open this bug at that time.