Yes of course
https://dl.dropboxusercontent.com/u/633 ... _tabs2.png

cool, cool, now I have no excuse to not implement the tab API in the new deco.

Should the tab with hover really have a close button?

Also, something I thought about when seeing #5 and #6: the Opera browser (at least the Windows version) has a setting for enabling or disabling an empty top-pixel line above the tabs. This allows users to choose whether they want the tabs to reach all the way up, or leave the tab one pixel from the border. The effect is of course that it allows one to choose to have the tabs extend to the screen border (and thus have an "infinite" hit area), or to place the mouse pointer at the top of the screen while the window is maximised, and still not hovering over any tabs.

Anyhow, mgraesslin preferred #4, and I agree that is the best look. But I'm just wondering if we should consider adding an option for extending the tabs to the top or not. Or at least making it easy to add such a feature at a later date?

veqz wrote:Should the tab with hover really have a close button?

If you hover a tab most of the time you want to do something with it, either activate it or close it. There is no point in activating a tab just to close it... And no close button on inactive tabs saves space.

veqz wrote:Also, something I thought about when seeing #5 and #6: the Opera browser (at least the Windows version) has a setting for enabling or disabling an empty top-pixel line above the tabs. This allows users to choose whether they want the tabs to reach all the way up, or leave the tab one pixel from the border. The effect is of course that it allows one to choose to have the tabs extend to the screen border (and thus have an "infinite" hit area), or to place the mouse pointer at the top of the screen while the window is maximised, and still not hovering over any tabs.

Anyhow, mgraesslin preferred #4, and I agree that is the best look. But I'm just wondering if we should consider adding an option for extending the tabs to the top or not. Or at least making it easy to add such a feature at a later date?

In the old opera the 1px space at the top had a lot of sens.
Opera allowed you to use double click on the tab bar to open a new tab(no other browser that i know allows you that, not even the new chropera...). Now if you had maximized the window you would not be able to perform a double click on the window title - maximize/restore window - or you wouldn't be able to drag the window. On "restored"(not maximized) windows the gap grew to the size of the titlebar allowing the user to drag the window. This gap was there for a reason
So the main question is if there is a need for that gap in case of KDE on a maximized window. Will it have any usability aspects as in opera case? On the "restored" window it just looks better with a gap

EraX wrote:If you hover a tab most of the time you want to do something with it, either activate it or close it. There is no point in activating a tab just to close it... And no close button on inactive tabs saves space.

Eh, I guess you're right. It's probably the right way of doing it.

EraX wrote:In the old opera the 1px space at the top had a lot of sens.
Opera allowed you to use double click on the tab bar to open a new tab(no other browser that i know allows you that, not even the new chropera...). Now if you had maximized the window you would not be able to perform a double click on the window title - maximize/restore window - or you wouldn't be able to drag the window. On "restored"(not maximized) windows the gap grew to the size of the titlebar allowing the user to drag the window. This gap was there for a reason
So the main question is if there is a need for that gap in case of KDE on a maximized window. Will it have any usability aspects as in opera case? On the "restored" window it just looks better with a gap

Well, I prefer the gap in both cases. It looks better in "restored"/windowed mode, and it leaves room for the mouse pointer in maximised mode.

Doesn't really bother me if the gap isn't there in maximised mode thought. I can't see any very important reason to required it, and I can always park the mouse pointer somewhere else.

Very cool work EraX!

EraX wrote:Yes of course
https://dl.dropboxusercontent.com/u/633 ... _tabs2.png

mgraesslin wrote:cool, cool, now I have no excuse to not implement the tab API in the new deco.

Is possible to add the proper application icon to each tab if you're using different applications? Or it would make things very difficult from an implementation perspective.
There would be no need for this if all the tabs are from the same application of course. But it would help the user differentiate the tabs more if you are combining different applications in the same window.

No technical issue - they could even all act as menu buttons.

mgraesslin wrote:cool, cool, now I have no excuse to not implement the tab API in the new deco.

Can we haz application menu button theming, too? :3

EraX wrote:Yes of course
https://dl.dropboxusercontent.com/u/633 ... _tabs2.png

Excellent work EraX!

EraX wrote:Ok so here is what i came up with so far. Six variants.
https://dl.dropboxusercontent.com/u/633 ... c_tabs.png
#1 Active tab
#2 Hovered tab

Love option 5 and then option 3 and 4. Beautiful work.

Very nice!

For me, it is 3 and 4. They do break the overall flatness, but in an awesomely subtle manner

about the mockups:
consider that window contents may not always blend with the decoration (xterm/konsole, java clients, mplayer...)
-> since there's apparently a blue line on the bottom (of active windows?), should the selected tab have the full blue (and a hovered one some blend in)?

just an idea after seeing the tabs, when the window is maximized the tabs, if there are any, could go down into the taskbar (since maximizing means you want to see as much of the content as possible) and the menu could go (unity-like) into the titlebar. quick gimp job (tabs are gone)

example

From this:
https://i.imgur.com/D9BJvHs.png

to this:
https://i.imgur.com/o6hf3jT.png

to get the application list again you move your mouse cursor gnome like to the bottom

On the other hand it could confuse the user when first confronted with this, but it basically brings back the feeling when there where no tabs and the last few years people were trying to reinvent them because they take a lot of horizontal space on the screen

EraX wrote:Ok so here is what i came up with so far. Six variants.
https://dl.dropboxusercontent.com/u/633 ... c_tabs.png
#1 Active tab
#2 Hovered tab

So the ones with blue coloring are hovered? For me, the last two ones would be totally out of question. The subtle slight blue tint works much better. Why? Because mouse cursors tend to wander around screen. Having part of screen suddenly flare up in bright blue when passing over tab would not be very nice, like screaming "LOOK HERE USER!!!" for no good reason. Bright colors are alert colors normally. It also is bit confusing because in Oxygen the actively selected tab is that color. Took me a while to figure out which is active and which is hovered from mockup.
I would go as subtle as possible. From these #2 is my favorite: a bit brighter font color than other tabs and very subtle light glow is clearly pointing out that element can be interacted with but nondistracting. Also worth keeping in mind is that there is mouse cursor pointing to tab under it, too! Bright hover-over tabs would be confusing, distracting and redundant.
Some kind of combination of #2 and #4 (or #2 and #5) would be doubly nice, so we could get clearly outlined borders between tabs while keeping it subtle.

I just wondered something. When every tab has a close button, what happens when I click the close button of the window decoration? Will it close all the windows that are represented as tabs, or just the focused one?
If it closes only the currently focused one then it might be a good idea to either remove the close button in the focused tab or visually indicate that the window controls are part of the currently focused tab and not of all tabs.