Conversation
833cbf6
to
740922b
Compare
This was relying on the views being added after the activation promise was resolved. Since atom/atom#13977 adds an async db lookup to the `open()` path, that's not enough.
atom/atom#13977 adds multiple pane locations and updates the `atom.workspace.getPanes()` API to return the panes from all of them. This fixes the resultant test failures by only checking the panes in the center.
While `atom.workspace.open()` was already async, there were some situations where the item would be added synchronously (which this test took advantage of). After atom/atom#13977, this is no longer the case.
atom/atom#13977 updates the `atom.workspace.getPanes()` API to include panes in additional containers. This commit updates the tests to maintain the original behavior.
This has been relying on the pane to be created synchronously when dispatching the command (and calling `open()`), which would only happen in certain conditions. After atom/atom#13977, `open()` is more reliably async so we need to take that into account.
atom/atom#13977 adds multiple pane locations and updates the `atom.workspace.getPanes()` API to return the panes from all of them. This fixes the resultant test failures by only checking the panes in the center.
atom/atom#13977 adds multiple pane locations and updates the atom.workspace.getPanes() API to return the panes from all of them. This fixes the resultant test failures by making assertions about the number of text editors instead of the number of panes (which I think is more true to the intent of the test).
740922b
to
991bf37
Compare
atom/atom#13977 adds multiple pane locations and updates the `atom.workspace.getPanes()` API to return the panes from all of them. This fixes the resultant test failures by only checking the panes in the center.
atom/atom#13977 updates the `atom.workspace.getPanes()` API to include panes in additional containers. This commit updates the tests to maintain the original behavior.
atom/atom#13977 adds multiple pane locations and updates the `atom.workspace.getPanes()` API to return the panes from all of them. This fixes the resultant test failures by only checking the panes in the center.
991bf37
to
c6efee6
Compare
I saw a situation where this was calling `destroy()` on `undefined`— presumably because destroying one caused the list to be mutated elsewhere and the indexes to shift.
@nathansobo @maxbrunsfeld think i got it: atom/deprecation-cop#81 |
Summary: atom/atom#13977 updates the PaneContainer constructor to require the view registry. This is a forwards-compatible change. Reviewed By: hansonw Differential Revision: D4800218 fbshipit-source-id: 9f751aa21c5ac1d37ae4ba021cc6e9ed84dba507
👏 Thanks for your hard work on this @matthewwithanm. This is a huge feature. |
@simurai What do you think of the behavior now: the dock tabs only appear if there is actually something in the dock. They also appear when you're dragging a tab, in case you want to drag it to the dock. Does this make it less distracting? We'll likely iterate a bit on the UX, but I feel like this is a good default. |
Summary: Changes the existing names to the ones used by atom/atom#13977 pane -> center right-panel -> right left-panel -> left bottom-panel -> bottom Reviewed By: jgebhardt Differential Revision: D4714075 fbshipit-source-id: 5ee7607f816aa9201b94fa372dd06f8a8dece1f1
…transition Summary: If the new Atom API is available, use that instead. This paves the way for deleting the workspace-views package (once atom/atom#13977 makes it to stable). Reviewed By: shushz Differential Revision: D4714099 fbshipit-source-id: 050e90b7aa41cabb698aac765e2df62d82eb7c4c
Yeah, a little, but docks will probably not be empty that often? I actually felt bad, suggesting to remove the toggle buttons 😇 , but then I was like: "Well, it's just a suggestion, people don't have to agree." So yeah, I'm ok to keep the toggle buttons as a default and maybe I can try to add a config option to hide them in the One themes. Then it's more like the wrap-guide, have it for easy discoverability, but still let people remove it, if they like a more minimal UI. @matthewwithanm Thanks so much for this. Really ❤️ how it lets you organize panels exactly how you like them. |
@simurai Should we tweak the styling of tabs inside docks to go full width? For some reason the empty space to the right of the tree-view's tab is feeling awkward to me. Also, want to do an icon for the tree-view's tab? BTW I'm calling the "tree view" the "project browser" in the UI because I think it conveys more information. |
Yeah, for the One themes it will be the new default: atom/one-light-ui#96. It actually goes full width for all tabs, also in the center. I'll merge it so people can try it out and see how it feels. There is still the option to only use the minimum width: We could also try to add it to |
Summary: atom/atom#13977 updates the PaneContainer constructor to require the view registry. This is a forwards-compatible change. Reviewed By: hansonw Differential Revision: D4800218 fbshipit-source-id: 9f751aa21c5ac1d37ae4ba021cc6e9ed84dba507
Summary: Changes the existing names to the ones used by atom/atom#13977 pane -> center right-panel -> right left-panel -> left bottom-panel -> bottom Reviewed By: jgebhardt Differential Revision: D4714075 fbshipit-source-id: 5ee7607f816aa9201b94fa372dd06f8a8dece1f1
…transition Summary: If the new Atom API is available, use that instead. This paves the way for deleting the workspace-views package (once atom/atom#13977 makes it to stable). Reviewed By: shushz Differential Revision: D4714099 fbshipit-source-id: 050e90b7aa41cabb698aac765e2df62d82eb7c4c
Now that the latest stable version of Atom includes atom/atom#13977, we no longer need this shim.
Hey all! I wanted to get this up to get some eyes on it and discuss some stuff. I'm trying to keep all the commits very focused to make things easy to review.
Stuff to Do
workspace.open()
to be location-awareWorkspaceCenter
class andworkspace.getCenter()
methodworkspace.toggle()
methodsaveFocusedPaneItem()
and call it in "core:save" command #14027)Questions/Stuff to Discuss
I have some FIXMEs in the code for questions that came up along the way, as well as some others:
Is there any good way to detect whether something's droppable in the dock?There are some known edge cases with showing the toggle buttons on hover. Should we address them?Is trying to remember the split worth it? It's not enough to just do it when a pane is moved (as is currently happening) since another pane moving would affect it. We could abuseserialize()
and do it there instead. (It shouldn't be in the serialized value though because we want it to be shared across workspaces.) That wouldn't be perfect either though, because if the same item was in different locations in two windows, we wouldn't know which was preferred. (Either way, we're still kinda making a "best guess" since split location isn't context-independent.)Is there a more efficient storage mechanism than putting stringified JSON in local storage?openItem()
will have to return a promise)The open API doesn't currently have a way to ensure a new item is created. (It always searches at least the active pane of the center.) Does that matter?Is it weird to have some of the workspace API methods (paneForURI()
,paneForItem()
)* include the docks while others (getActivePane()
) don't? Similarly, ifsearchAllPanes
includes docks, what's the desired behavior whensearchAllPanes
is false? (Previously, I mistakenly thought it meant to search no panes, so there wasn't any question.)paneForURI()
andpaneForItem()
will include docks; active-related stuff won't. therefore,searchAllPanes = true
will search docks,false
(which only checks the active pane) won'tworkspace.getCenter()
will be added and return an instance of the newWorkspaceCenter
class, which trivially wrapsworkspace.paneContainer