New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make LiveDevMultiBrowser's Launcher instance configurable via public set Launcher() method #10558

Merged
merged 2 commits into from Mar 12, 2015

Conversation

Projects
None yet
3 participants
@humphd
Contributor

humphd commented Feb 10, 2015

We're working on using the new LiveDevMultiBrowser code to allow an in-browser Brackets to use an iframe-based browser and postMessage-based protocol, see https://github.com/humphd/brackets/issues/27. One of the snags we've hit is that we need a way to override how the default browser is launched, and the Launcher is currently not configurable.

This patch follows the same pattern currently in place for swapping the protocol's transport (which we also make use of in order to use postMessage to/from the iframe), and adds a setLauncher() method. If you'd consider this API change, we'd be able to get our own iframe-based launcher hooked into live dev.

cc @busykai, @sebaslv, @sedge

@sebaslv

This comment has been minimized.

Show comment
Hide comment
@sebaslv

sebaslv Feb 13, 2015

Contributor

@humphd, looks good to me having this mechanism to dynamically set a different Launcher instance. We have a unique launcher instance now to make it compatible with CDT-based live dev UI but, in the near future we would like to decouple launch mechanism from live dev session to better support launching multiple clients per session.

Just curious, have you consider some way of static configuration also for your use case? I mean, something like having a pref that allows setting the Launcher instance to be loaded during initialization rather than always loading DefaultLauncher and then dynamically swapping it?

Contributor

sebaslv commented Feb 13, 2015

@humphd, looks good to me having this mechanism to dynamically set a different Launcher instance. We have a unique launcher instance now to make it compatible with CDT-based live dev UI but, in the near future we would like to decouple launch mechanism from live dev session to better support launching multiple clients per session.

Just curious, have you consider some way of static configuration also for your use case? I mean, something like having a pref that allows setting the Launcher instance to be loaded during initialization rather than always loading DefaultLauncher and then dynamically swapping it?

@humphd

This comment has been minimized.

Show comment
Hide comment
@humphd

humphd Feb 13, 2015

Contributor

OK, great. Using this patch (which I landed on our brackets fork), we've just today been able to get Live Dev working in the browser with an iframe and postMessage--it's awesome :) It would be great if you'd take this patch upstream so we don't have to modify brackets at all to make it work.

Regarding your other question, I've been wondering about that too. I don't love the idea of doing it with prefs, since that still forces changes in brackets proper, and isn't something you can do from an extension. I like the model you have with the live dev server manager, where you can register a server with a priority. In an ideal world, it would be great if an extension could somehow provide the transport, launcher, and maybe a few other internal implementations for Live Dev, and have Live Dev's init use these instead of starting with the defaults and then being forced to switch them. It's a bit of a pain to switch them, because you have to get the timing right, or your transport/launcher get overwritten by the defaults again.

I had the same issue with swapping out my in-browser filesystem (https://github.com/filerjs/filer) for the appshell's impementation, which requires me to change the brackets source internally. It would be great if there was a way for extensions to override more of the internal code, but that's a larger issue, and I don't want to block this bug on figuring that out if possible.

Contributor

humphd commented Feb 13, 2015

OK, great. Using this patch (which I landed on our brackets fork), we've just today been able to get Live Dev working in the browser with an iframe and postMessage--it's awesome :) It would be great if you'd take this patch upstream so we don't have to modify brackets at all to make it work.

Regarding your other question, I've been wondering about that too. I don't love the idea of doing it with prefs, since that still forces changes in brackets proper, and isn't something you can do from an extension. I like the model you have with the live dev server manager, where you can register a server with a priority. In an ideal world, it would be great if an extension could somehow provide the transport, launcher, and maybe a few other internal implementations for Live Dev, and have Live Dev's init use these instead of starting with the defaults and then being forced to switch them. It's a bit of a pain to switch them, because you have to get the timing right, or your transport/launcher get overwritten by the defaults again.

I had the same issue with swapping out my in-browser filesystem (https://github.com/filerjs/filer) for the appshell's impementation, which requires me to change the brackets source internally. It would be great if there was a way for extensions to override more of the internal code, but that's a larger issue, and I don't want to block this bug on figuring that out if possible.

@busykai

This comment has been minimized.

Show comment
Hide comment
@busykai

busykai Mar 3, 2015

Contributor

Sorry I haven't been able to get to this for a little while. I'll review and merge this code. We'd want to have as little diffs as possible with the mainstream Brackets. As for static configuration, we'll consider it as the next step (this one may actually help it).

Contributor

busykai commented Mar 3, 2015

Sorry I haven't been able to get to this for a little while. I'll review and merge this code. We'd want to have as little diffs as possible with the mainstream Brackets. As for static configuration, we'll consider it as the next step (this one may actually help it).

@busykai

This comment has been minimized.

Show comment
Hide comment
@busykai

busykai Mar 3, 2015

Contributor

@humphd, looks good, only one minor comment.

Contributor

busykai commented Mar 3, 2015

@humphd, looks good, only one minor comment.

@humphd

This comment has been minimized.

Show comment
Hide comment
@humphd

humphd Mar 3, 2015

Contributor

Thanks, fixed.

Contributor

humphd commented Mar 3, 2015

Thanks, fixed.

@humphd

This comment has been minimized.

Show comment
Hide comment
@humphd

humphd Mar 3, 2015

Contributor

Ugh. Fixed.

Contributor

humphd commented Mar 3, 2015

Ugh. Fixed.

@humphd

This comment has been minimized.

Show comment
Hide comment
@humphd

humphd Mar 9, 2015

Contributor

@busykai ping?

Contributor

humphd commented Mar 9, 2015

@busykai ping?

@busykai

This comment has been minimized.

Show comment
Hide comment
@busykai

busykai Mar 12, 2015

Contributor

Looks good! Merging. Sorry for the delay.

Contributor

busykai commented Mar 12, 2015

Looks good! Merging. Sorry for the delay.

busykai added a commit that referenced this pull request Mar 12, 2015

Merge pull request #10558 from humphd/configurable-launcher
Make LiveDevMultiBrowser's Launcher instance configurable via public set Launcher() method

@busykai busykai merged commit ddc760b into adobe:master Mar 12, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@humphd

This comment has been minimized.

Show comment
Hide comment
@humphd

humphd Mar 12, 2015

Contributor

Great, thanks!

Contributor

humphd commented Mar 12, 2015

Great, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment