We'll soon be flipping the sidebar mode on by default. If you don't like it, you can restore the previous UI for now by setting "devtools.webide.sidebars" to false. However, please let the WebIDE team know what was wrong so it can be improved via bugs / email / IRC / etc.
We plan to eventually remove the non-sidebar mode to reduce code complexity in the UI. - Ryan On Tue, Sep 8, 2015 at 11:08 AM, J. Ryan Stinnett <[email protected]> wrote: > On Tue, Sep 1, 2015 at 2:46 PM, Andrew Sutherland > <[email protected]> wrote: >> On Tue, Sep 1, 2015, at 11:52 AM, J. Ryan Stinnett wrote: >>> Would you prefer having the toolbox be "full screen" in the WebIDE >>> window (the way it appears today without sidebars)? It's easy to make >>> this happens if people would prefer it. It would then cover the >>> sidebars fully, and you'd need to use the wrench icon / close the >>> toolbox to access the sidebars again. >> >> Yes, if it wouldn't result in the loss of the devtools state. However, >> based on what you're saying and how things work right now when I play >> with it, I think there would be a compulsory loss of devtools state if >> trying to access any of the other tooling. (Unless there's a way to >> open multiple WebIDE's somehow? But it seems like a singleton window.) > > The full screen mode (as implemented today for non-sidebar mode) is > only active for "remote only" projects where there is no local source > to edit (like installed apps you may not have source for). > > You're correct that toggling the toolbox off via wrench / close / etc. > does currently clear all DevTools state (though a few things are now > persisted, like recent console history), but for a "remote only" > project, I believe you'd only do so to switch apps entirely, since > there is not much else you can do with such projects outside of the > DevTools toolbox anyway. > > Given this, does applying the full screen behavior to sidebar mode as > well seem worth it? > >> Maybe if the splitter for the devtools is a XUL splitter, a grippy can >> be put inside it and collapse used >> (https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/splitter#Attributes)? >> The fat grippy provides a visible affordance to get the content area >> back without the visual oddity of the current minimum size for the >> content area. > > Ah, that may be worthwhile as well. The "full screen" logic above > could still be used to set the default state (whether the toolbox > covers the entire height below the top toolbar). > > - Ryan _______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
