Epichrome's "App Window"-style SSBs compete unfavorably with Fluid

[cbeams]

This may be more of an observation than a bug report or feature request, per se, as I think I may be discussing fundamental limitations of Chrome as an SSB platform.

My typical use case with Fluid is as follows:

• Create an SSB for, let's say, https://github.com
• Use that SSB with the address / tab bar hidden, so as to maximize screen real estate. For example, the window I'm typing in now is a Fluid-based SSB for GitHub. It looks like this:
• Occasionally, I will want to look at or directly manipulate the URL in the location bar for some reason. This is no problem, I simply hit CMD-L, and Fluid reveals the location bar, allowing me to do whatever I want. It looks like this:
• When I'm done, I just hit escape, and the location bar hides itself again, restoring maximum real estate to the app.
• Occasionally, I will want a second tab. This is no problem in Fluid, I just hit CMD-T and it brings up a second tab (or CMD-click on a link), prompting me for the location. It looks like this:
• Again, once I've typed or pasted the url, I hit escape, and I'm back to a minimal layout (now with the two tabs visible):

The behavior described above is close to perfect. Unfortunately, in a Chrome-based SSB, there seems to be no way to hide the location bar except by (1) running the browser in --app mode, which is an all or nothing proposition or (2) hitting CMD-SHIFT-F to enter full screen mode, which is almost never what I actually want.

Again, these may be fundamental limitations for Epichrome based on its dependence on Chrome itself, but perhaps there's something I'm missing.

Ultimately, a unified experience is what I'm looking for: one where the user need not make an up-front decision about whether an SSB is an "App Window" or "Browser Tabs" based.

As an aside, another downside of Chrome's --app mode is that the Developer Tools cannot be rendered inside the app (i.e. on the right side or along the bottom of the window, as they can be in a normal Chrome window. The only option is to have them pop out as a separate window. This is an ironic limitation, given that one of my primary reasons for wanting a Chrome-based SSB in the first place is so that I can use Chrome's superior Developer Tools.

[dmarmor]

I agree with you that this limitation is annoying. Your message got me thinking, and I may have a solution. Not perfect, but it should help (and is also a good stopgap for the 1Password issue).

It turns out that contrary to the API documentation, I am able to move a tab from an app-style window to a regular tab-based window. It should be possible to use this ability to seamlessly "convert" an app-style window to tab-style and back again, so you could have the same Fluid-type functionality--access to the address bar (and any other plugin icons and bookmarks and whatever). In it's tabful state I've confirmed that 1Password will also work again. When you were done, you could convert back to app-style.

I have a couple ideas for how to invoke this: what makes most sense to me would be to overload ⌘-L (since it does nothing in an app-window). The only problem with this is that it wouldn't work to switch back to app-style, since that command would now set focus in the address bar. So not sure how to deal with that.

I could instead (or also) add a context menu entry so if you clicked anywhere in an app window there would be a "Show Address Bar" entry (and if you were in the tabby version of the app window, the context menu would be "Hide Address Bar".

Finally, I could set it so you switch by triple-clicking anywhere in an app-window, in either state.

Any of those ideas appeal to you more than the others? If I used the ⌘-L approach, any good ideas for how to switch back? I'm also very open to other interface ideas for making the switching seamless.

Thanks for the report! I think this will improve Epichrome a lot.

[dmarmor]

Oh--I forgot to mention, this will also provide a fix for the developer console problem. I switched one of my app windows to a tab, brought up the console as a pane, and then switched back, and it stayed attached as a pane.

[cbeams]

On Jul 16, 2015, at 4:04 PM, dmarmor notifications@github.com wrote:

I could instead (or also) add a context menu entry so if you clicked anywhere in an app window there would be a "Show Address Bar" entry (and if you were in the tabby version of the app window, the context menu would be "Hide Address Bar".

+1 for this approach. It sounds the closest to Chrome's current ⌘⇧B to "hide/show bookmarks bar". So, perhaps ⌘⇧L would be a good match for "hide/show location bar (and tabs)"

[dmarmor]

OK, I've just published a new version of the extension (version 1.1.0). It may take up to an hour to appear in the web store, but after that try updating it in your SSBs and see how it works for you.

It'll auto-update eventually, but can take the better part of a day, so if you want to try it now, go to your Extensions page, check "Developer mode" at the top, then click the "Update extensions now" button just below that. After that you can uncheck "Developer mode" again.

Basically it's the approach we talked about, using hot-keys (instructions will appear in the options page). I also included a context menu item just in case anybody ever forgets the hot-keys.

Anyway, let me know how it works! I've been using it for a day or so now and it seems good on my system.

[dmarmor]

Closing for now, let me know if you have any trouble with this. Thanks!

[smoofra]

@dmarmor Is this feature still around in 1.1.1? I don't see anything in the options for te extension about it and ⌘⇧L doesn't seem to work.

[dmarmor]

The feature is still around, but is only active for "App Style" SSBs. It won't work on Browser Tab SSBs. Is yours app style? If so, there should be a section in the Epichrome Helper options titled "Main Window Type" that has the instructions and hot-keys for switching. If that's not there, then something isn't right. Let me know. Thanks!