Fluentterminal: Edge-like tabs

[ZhouQD]

This is a great app.

I think it would be nice if its tabs look like Microsoft Edge.

Backgrounds of the active tab and the terminal panel are the same. It looks more intuitive.

[hanskokx]

@felixse this would solve the problem I was having. Is it possible to put
the tabs on the bottom? (Or have an option to do so?)

Hans Kokx

On Sun, Jun 17, 2018, 3:39 PM ZHOU Qiudi [e-mail] wrote:

This is a great app.

I think it would be nice if its tabs look like Microsoft Edge.

[image: image]
https://user-images.githubusercontent.com/11922388/41511391-34790eee-7276-11e8-9d34-e8555f7d6ac8.png

Backgrounds of the active tab and the terminal panel are the same. It
looks more intuitive.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/felixse/FluentTerminal/issues/44, or mute the thread
https://github.com/notifications/unsubscribe-auth/AB0sb6AnicVbH_JQ8OjML-9g2SDC6VG8ks5t9rBcgaJpZM4Uq8uv
.

[felixse]

The tabs are pretty basic right now, so there is much room for improvement

We could do edge like tabs by using the application theme background (black or white based on the current theme’s background) for the tab bar, and the theme background for the active tab, I will give this a try once I get to work on the tabs.

Tabs on bottom should be no big issue

[Linard11]

Would the new 'Sets'-Feature in Redstone 5 solve this if it would be supported?

[felixse]

Sets is great for combining different apps into one window, or to provide a tabbed experience to apps that just don't have them (like Explorer), but having tabs implemented on our own gives us advantages like configurable keyboard shortcuts for new tabs, confirm before closing, create a new tab with the shell selection dialog, etc.

Improvements to the tabs are coming soon, at least before RS5 😄

[yzhang-gh]

Good news. WindowsCommunityToolkit v5.0.0 introduced TabView control which looks great!

documentation

[hanskokx]

Can we tear tabs off into new windows with this?

Hans Kokx
On November 5, 2018 11:54:17 AM Yu Zhang [e-mail] wrote:

Good news. WindowsCommunityToolkit v5.0.0 introduced TabView control which
looks great!
documentation

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[felixse]

Doesn't look to different from what we have right now, do you see any point in switching to this?

@skipmeister123 the problem with moving to new windows is about serializing the renderer state, not the tab control

[hanskokx]

Ahh; my mistake, then.  I do like some of the options provided by this new framework -- such as auto-fitting tabs.  However, I don't know that there's a huge benefit to switching, unless this new framework becomes a standard (which would be easier to document and maintain.)

--
Hans Kokx
On 11/5/2018 12:10:28 PM, Felix [e-mail] wrote:
Doesn't look to different from what we have right now, do you see any point in switching to this?
@skipmeister123 [https://github.com/skipmeister123] the problem with moving to new windows is about serializing the renderer state [https://github.com/xtermjs/xterm.js/issues/595], not the tab control
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub [https://github.com/felixse/FluentTerminal/issues/44#issuecomment-435955077], or mute the thread [https://github.com/notifications/unsubscribe-auth/AB0sbxiquTvZWHltK3gKhp8Fx_QwQ4Yjks5usHEEgaJpZM4Uq8uv].

[yzhang-gh]

Just FYI 😅

My two cents is it is "official" in a sense. Another difference is that the close button (on mouse hover) is more like edge-style comparing to the current one.

current

edge

windows community tookits

[yzhang-gh]

Can we tear tabs off into new windows with this?

@skipmeister123 Yes!

See https://twitter.com/XAMLLlama/status/1063526194191118336

[hanskokx]

Perfect. Now we just need to sort out the split panes.

Hans Kokx
On November 17, 2018 1:02:45 PM Yu Zhang [e-mail] wrote:

Can we tear tabs off into new windows with this?
@skipmeister123 Yes!
See https://twitter.com/XAMLLlama/status/1063526194191118336
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[maxhora]

@felixse have investigated this in some details:

Mentioned above TabView sample with Tear Off functionality is based on TabView control from WindowsCommunityToolkit and on good amount of additional logic to support Tear Off (description of additional custom logic can be found there).

Fluent already has multi window functionality to run each separate window in its own thread (achieved by invoking CoreApplication.CreateNewView().Dispatcher.RunAsync). That's similar to TabView sample with Tear Off's implementation, but such things as "communication" between windows in different threads, drag-in/out logic and so on, still should be incorporated in Fluent.

Since each window has it's own thread, it's not possible to move WebView instance between threads or access it from another thread. UWP seems doesn't provide API "to change" the thread for UI control.

Above limitation forces us to find a workaround:

• It was discussed possibility to serialize Xterm.JS state to be restored in new launched WebView. So far, I've tried to achieve serialization with serialize-instance, but library has its own limitations and throws unhandled exceptions for Xterm.JS Terminal instance.
  Having reliable serialization of Xterm.JS, seems, involves custom serialization/deserialization code to be added into core Xterm.JS implementation or maybe as specific add-on (if add-on has enough access to XTerm.JS internals.)

• Another approach is to move each XTerm.JS instance into additional separate WebView instance that will: be invisible for user; communicate with another visible WebView instance inside active UWP Window; efficiently update visible WebView instance with DOM changes; live for whole terminal session, while connected visible WebView might be destroyed when tab was teared off or window was docked as tab.

• Any other ideas?

I would prefer to try to keep XTerm.JS in separate WebView instance, but it's additional complication and potential performance drop reason.

cc: @mjs @peske

[felixse]

I don't think this 2 WebView approach will perform very good. Somebody is working on a serialize addon for xterm.js right now, maybe we can work with that.

[maxhora]

@felixse yes, thanks, I've just discovered this ongoing work as well (it was published 5 hours ago).
That is very close to what we need! So we need to jump on xterm.js v4 beta build first!

[peske]

My opinion in short: since different FT windows are running in different UI threads, we must rely on xterm.js serialization. We cannot simply move views (tabs or WebViews) from one window to another.

The only question for me is how significant advantage we have by running windows in separate threads? If we can reconsider that (if we can run all windows in the same UI thread), we can simply accomplish moving tabs from one window to another (or a new one), without using serialization at all.

I'm afraid that xterm.js serialization will come with some gotchas...

[felixse]

WPF is different in this regard because it allows for multiple windows on the same thread. UWP has a different multi window concept and an API more closely to WPF is still in preview even in 1903

[mjs]

+1 to trying out the the xterm.js serialization approach for moving tabs between windows. That seems the most viable to me. A single thread for all windows isn't going to be possible for a while and multiple WebView instances is likely to be too heavyweight.

Serialization of xterm.js's state will no doubt be tricky to get right but it still seems like the right thing to try first.

[mjs]

@felixse I think this can be closed now right?