Make the tree view a dock item

[nathansobo]

⛑ This can be merged once 1.17 reaches stable. Tests are red because we're building against a version of Atom that doesn't have the dock APIs ⛑

Hey, @simurai. I don't think we're really ready to ship this in the next release cycle because it needs some design ❤️.

In the screenshot above I deliberately sized the tree view so the tab stretched across 100% of its width. But when the tree view is wider, the narrower tab looks awkward:

I also think the tab being white when the tree view isn't focused looks weird. Do you think you could come up with some mock ups, a PR on the tabs package, or just do some styling overrides on this branch for a treatment of tabs in docks that feels more natural? I don't think having a tab for the tree view is fundamentally bad. At least it vertically aligns the content of the tree view with the panes, which I think is nice. But I do think the dock tabs need to look somewhat different and more subtle than the pane tabs.

[nathansobo]

Another option could be to do not render the tabs at the top for the left and right panels, but instead render them at the left and the right as icons. This might work better because these spaces are fairly narrow. I guess it depends on how many tabs we try to fit in. At the moment, in the default configuration, we only have the tree view so it doesn't matter much. The real problem is making the default configuration not look awkward while still making room for people to add more items.

[simurai]

Just merged atom/one-light-ui#96. So if you build atom/atom you should see it like this (plus the docks border):

Single tabs are now pretty seamless and look more like titles. Just once you start to add more items, they feel like tabs:

[nathansobo]

Looks amazing. I'm even more excited about this feature now.

/cc @maxbrunsfeld @matthewwithanm

[nathansobo]

BTW I think we should make this title-bar free mode the default.

[Alhadis]

Where's the option to disable this?

Or should I ask: will there an option to revert to the default?

[matthewwithanm]

Looks amazing @simurai!! 😍

[nathansobo]

@Alhadis I'm considering leaving an option to render the tree view in a panel instead of a dock. It's a bit more code complexity but could be a nice escape hatch for people who only want a tree view at the left and don't plan on using the docks at all.

[Alhadis]

Well that would be me, but I'm kinda hoping there'll be something that will leave the tree-view looking like it hasn't been touched at all...

#changeHater

[simurai]

You could add

atom-dock.left .tab-bar {
  display: none;
}

then it feels like the current panel.

[simurai]

Ohh.. wait, even better. I forgot about the "Always Show Tab Bar" option:

[matthewwithanm]

@Alhadis I'm considering leaving an option to render the tree view in a panel instead of a dock.

@nathansobo Is this despite the setting @simurai mentioned?

[matthewwithanm]

imo it should be docks-only and any tweaks we wanna allow should be done within that framework. for example, if the existing "Always Show Tab Bar" option isn't enough, we could add one that's dock-specific. branching just makes it more complicated and i'm not sure what the gain is.

i'm a fan of the workspace items concept not just because devs don't have to duplicate logic (toggle side, etc) or because it gives users more control (since they can drag to new locations), but also because the centralization gives Atom more control. for example, Atom could add a mode to docks where they only show one item—the active one—and no tabs. or an option to always add new items in a split. the bottom line is that these things become consistent and predictable instead of having each one governed by a unique set of rules.

[maxbrunsfeld]

omg @simurai that looks awesome.

[nathansobo]

I think the setting covers it. Worst case there's a user style sheet if someone is upset about the toggle affordance.

[simurai]

@nathansobo Worst case there's a user style sheet if someone is upset about the toggle affordance.

The One themes already have a setting for that:

For those that like a more minimal UI and are ok toggling with the keyboard only (or status-bar/tool-bar buttons).

[simurai]

Should find-and-replace also be moved to a dock (bottom)? I think yes. Then the rule of thumb would be:

• Larger things that you want to show/hide "temporarily" -> docks (tree-view, find-and-replace, etc).
• Smaller things that you want to show "permanently" -> panels (status-bar, custom title-bar, tool-bar).

It could overlap, but then you can just keep a dock open all the time, or keep toggling a panel (like tool-bar).

[nathansobo]

@50Wliu Apparently this warning has been removed in newer versions of Chrome. At this point I'm not sure it's worth worrying about it.

[winstliu]

This fixes #68
And #480 when you have no project folders open (though the UX can definitely be improved)

[winstliu]

Pending pane items aren't working:

[fabianfiorotto]

What is going to happen with the config showOnRightSide? I see that is deleted from the config form but you are still using it in the code

[nathansobo]

@fabianfiorotto We still honor that config setting on package activation because we don't want to flip the tree view back to the left for users that have chosen to put it on the right when they upgrade. Going forward, however, we want to use the drag-and-drop behavior afforded by docks rather than custom configuration.

[Alhadis]

Looks like we can merge this now. =)

[nathansobo]

❤️