Closed Bug 894352 Opened 11 years ago Closed 11 years ago

[app manager] Connection footer and Device Inspector

Categories

(DevTools Graveyard :: WebIDE, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 912447

People

(Reporter: paul, Unassigned)

References

Details

Attachments

(6 files)

Attached file Content to show in the inspector (deleted) —
The Connection Footer is where the user can connect a device and start a simulator. The Connection Footer includes a Device Inspector that shows various useful data about the connected device.
Attached image WIP mockup footer (design) (deleted) —
Attached image WIP mockup (interaction) - PART 1 (deleted) —
Attached image WIP mockup (interaction) - PART 2 (deleted) —
Attached image WIP mockup (interaction) - PART 3 (deleted) —
Attached image WIP mockup (interaction) - PART 4 (deleted) —
Depends on: 895360
Depends on: 895361
Depends on: 887506, 800447
Depends on: 895362
Blocks: 894354
Depends on: 895364
Depends on: 895366
Depends on: 817580
Depends on: 895802
Component: Developer Tools → Developer Tools: App Manager
Depends on: 898394
Panos, can I ask you to take a quick look at these commits: > actor: url-resolver > actor: permissionsTable > actor: device-info > start actors > connections-manager (see https://github.com/paulrouget/mozilla-central/compare/mozilla:fx-team...app-manager) I'm not asking for a formal review, but for a quick feedback.
I took a rather brief look, mostly in the parts I'm familiar with, and here are a few comments I have: - the device-info and permissionsTable actors should probably be unified to a DeviceActor or a MainProcess actor as discussed on IRC - the connections-manager module API does not seem sufficiently encapsulated and gives clients access to stuff that should be private. I would expect a ConnectionManager object to encapsulate the connection list and provide createConnection/destroyConnection methods to add/remove connections, instead of handing out the connection list to the clients. - the Connection object is described as a wrapper around a debugger client object, but it looks more like a RemoteInstance or RemoteTarget object to me. It contains both connection-related data like host and port, but also a generically-named "store" that contains device-related information. In pure remote protocol terms, it looks more like a DeviceActor front combined with a debugger client. This weird layering is partly the fault of dbg-client.jsm, which needs to be refactored to split the various actor fronts from the connection management parts. - the object hierarchy inside the store reflects the parent-child relationship I mentioned on IRC between the DeviceActor and the Webapps actor (a device contains a webapp manager instance).
No longer depends on: 895366
Depends on: 898485
Depends on: 898487
Blocks: 900356
Depends on: 900972
Depends on: 895982
Depends on: 901917
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
No longer depends on: 800447, 887506, 895362, 901917
Filter on 86b7095e-2bd0-499e-a704-d00f2524aeef / PAUL STOP SETTING QA CONTACT TO THE DEVTOOLS COMPONENT'S WATCHERS EMAIL FOR BUGS YOU FILE :)
QA Contact: developer.tools
Product: Firefox → DevTools
Product: DevTools → DevTools Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: