-7

Buttons of window (close, minimalise etc) down to panel (control; menu; tabs etc), as this realised in chrome (buttons of window on panel of tabs).

Support Qt and gtk. Really?

I kind of get what you want from the mock-up, but Could you explain it in detail?
Alsi I have a feeling you're using Google Translate or something similar, because the senteces don't make that much sense.
Maybe you should write them in Russian and someone who knows both Russian and English could translate them better than the internet translator.

Primoz wrote:I kind of get what you want from the mock-up, but Could you explain it in detail?
Alsi I have a feeling you're using Google Translate or something similar, because the senteces don't make that much sense.
Maybe you should write them in Russian and someone who knows both Russian and English could translate them better than the internet translator.

Ok, sorry, my english is very bad, but i no all translate in google.
All idea in image - buttons of window (close, minimalise etc) down to panel (control; menu; tabs etc), as this realised in chrome (panel of tabs) or mac os 10.7, for don't big screen (notebook or tablet).

alltiptop wrote:

Primoz wrote:I kind of get what you want from the mock-up, but Could you explain it in detail?
Alsi I have a feeling you're using Google Translate or something similar, because the senteces don't make that much sense.
Maybe you should write them in Russian and someone who knows both Russian and English could translate them better than the internet translator.

Ok, sorry, my english is very bad, but i no all translate in google.
All idea in image - buttons of window (close, minimalise etc) down to panel (control; menu; tabs etc), as this realised in chrome (panel of tabs) or mac os 10.7, for don't big screen (notebook or tablet).

Oh okay, yeah I get the point of your idea. I'll approve it.

PS I added Chrome in title, because I think Chrome or Chromium is more known to people than Mac OS X.

Bug in this forum: many symbols of cyrillic don't show.

[russian alphabet]: абвгде�жзийклмноп����������������

You should check this out:

http://blog.zx2c4.com/548

It's different from what you're asking for, but I personally think it handles menus and tabs quite well (the menu being condensed into a button).

this idea has been posted before and developers are already discussing it...


two other links about this topic:
http://blog.martin-graesslin.com/blog/2 ... corations/
http://ppenz.blogspot.com/2011/03/menu-bars.html

waldelf wrote:this idea has been posted before and developers are already discussing it...

This idea is different as this allows to add a breadcrumb to KWin or allows it to be embedded window controls to "toolbar level".

I dont like any of the ideas to move any other controls to window decoration as it is against usability studies what many has done (like Apple).

Users use window decoration area to move, resize, minimize, close, shade, on-top and other window manager functions.
That we have a space there in default Oxygen decoration does not make this whole idea good at all (not just this one, but now the shown up idea in wide).

If this gets maded, user is forced to have a specific decoration what allows that. Or that we need to remove all other possible window decorations to support this new ideal.

And we really need to keep window manager as a window manager and not as a part of application. The modularity
makes the desktop environment safer and easier and gives many other features like example:

- User can choose different window manager
- User can choose different window decoration to user WM
- User can configure window manager buttons places
- User can hide a window decoration
- User can set window a fullscreen
- User can use Window Manager tabbing feature

GNOME 3.0 made difference that user can no longer change window manager or even enable compositing (for now on).

If something happens to window manager, almost everything goes down.

Please, remember the whole UNIX philosophy, "If it ain't broken, dont fix it" and "One program for one specific task".

Now there is a tryout to "Fix" the problems what menubar (we only need to move Ctrl+M to kdelibs so every application allows it, nothing else need to be done) supposedly causes by being a drop-down list. And there is a tryout to "fix" the problems by tying multiple different functions to one (Window manager, menubar, breadcrumb, etc).

i think i can agree with you... this is a different idea and i do not support it

i would like a global ctrl+m option - BUT - hiding the menubar completely should be one option..

the other option (the default one so inexperienced users will find their menu again) should be "menubar in windeco" like ppenz and graesslin wrote in their blogs..

they also wrote that it will be optional and as fallback there will be the default menubar (for different windowmanagers or windecos without space or fullscreenapps)

waldelf wrote:the other option (the default one so inexperienced users will find their menu again) should be "menubar in windeco" like ppenz and graesslin wrote in their blogs..

they also wrote that it will be optional and as fallback there will be the default menubar (for different windowmanagers or windecos without space or fullscreenapps)

There is toolbar button to hide/show menu, there is no need for window decoration changes at all. And it will work even if window manager would crash or it would be changed or window would be in fullscreen or just without decoration the application GUI would be same, without need to any kind fallback functionality.

There isn't simply any kind need to tie application to window manager. Right now those ideas in blogs are just about desire to do massive changes without thinking what are the current possibilities with current features and what are the real needs and the current problems and their resolvers.

Moving Ctrl+M functionality to kdelibs would allow hiding menubar complete by default and only summong it back with a own shortcut (user can choose what to use) or clicking toolbar button or right clicking and selecting it from context menu.

the problem is.. there is no show/hide menu butten by default.. you have to know that this button exists and configure one of the toolbars to show it... no rightclick show menu in dolphin either... so most users will get really lost if they accidentally hide the menu..

i do not see any problem with some extended kwin functionality to embed a menubutton as long this is optional.. in fact.. this is something that has to be managed somehow.. i really do not like the menu in amarok and there is no way to hide it.. wtf? i would like to see some consistency here..

waldelf wrote:the problem is.. there is no show/hide menu butten by default.. you have to know that this button exists and configure one of the toolbars to show it... no rightclick show menu in dolphin either... so most users will get really lost if they accidentally hide the menu..

the solution is if hiding the menu is made the default then having a show menu button would be made the default as well. Users seem to fare well enough with the changes that Chrome and Firefox (4) made moving their menus to a button.

waldelf wrote:
i do not see any problem with some extended kwin functionality to embed a menubutton as long this is optional.. in fact.. this is something that has to be managed somehow.. i really do not like the menu in amarok and there is no way to hide it.. wtf? i would like to see some consistency here..

I suppose this could use the same functionality as the xbar/global menu, and kwin would present it as a new window button that you could add. On the other hand, I don't see much difference between having the button in the window title vs. having the button in the application's toolbar, other than a few pixels difference in location (and that the button in the toolbar is apparently already implemented, or at least would be trivial to finish implementing in comparison).

waldelf wrote:the problem is.. there is no show/hide menu butten by default.. you have to know that this button exists and configure one of the toolbars to show it... no rightclick show menu in dolphin either... so most users will get really lost if they accidentally hide the menu..

Fix = Move Ctrl+M to kdelibs and set a system setting option to enable (by default disabled) and configure the shortcut (Ctrl+M) for menu hiding and auto-add a "Hide menubar" button to right side of the toolbar.
No accident menu hiding and easy to get back or hide when wanted with already working toolbar button.

i do not see any problem with some extended kwin functionality to embed a menubutton as long this is optional.. in fact.. this is something that has to be managed somehow..

Best way seems to be what I said, forget the window managers integrations, they are totally different programs and does not belong to the application program itself what user runs. Even that user might believe that decoration is part of the application, it isn't. That was one of the reasons why KDE separated window decoration theming and application theming in system settings.

Still the technical problems and usability problems would be huge if menu would be added to KWin. Are we ready to shoot 90% of the KWin and KDE Plasma functionality about window management because we want just to get one stupid menu button to decoration?

The Googles and Mozillas idea to make one drop-down menu with two lines and sub-menus is terrible. The current menubar idea is much better and faster, problem is just that we do not have by default support for a Ctrl+M function as shorcut in every KDE application and it is not easy to get across all applications the toolbar button for it (technically it is already there but user need to edit every application toolbar by hand to add it there!)

i really do not like the menu in amarok and there is no way to hide it.. wtf? i would like to see some consistency here..

Amarok follows Ctrl+M functiality. It was added maybe two months ago in latest stable version. Amarok developers have been against it since Amarok 2.x development because they got _few_ questions how to get menu back when user accidentally hided it. Now it is fixed that when user first time hides the menu, pop-up comes up and informs user what just happened and how to get it back.

We already have technology, usability and features, but we just dont have anyone to add Ctrl+M feature to kdelibs and system settings option to make it easily globally.

amarok has this feature again? great news.. thx!!

yes ! make it globally.. make a menubutton appear instead of the menubar when hitting ctrl+m and make this behavior configurable via systemsettings, so it still will be possible to hide the menu completely..

i think a menubutton that appears somewhere in the programs toolbar is something that has to be implemented once for every single program... wrong?
so a better idea would be showing the menu in the menubar plasmoid or (if the windowmanager allows it) show it in the tilebar..

why should you have to shoot any functionality by providing an additional option to the user? what exactly are you talking about?
---------------------
the best solution IMHO would be:
#make this globally somehow
#let the user chose what happens when he hits ctrl+m (in systemsettings)

choices are:
#hide menu completely,
#show in menubar plasmoid
not everyone has this plasmoid activated) OR
#show in windowtitle
(not everyone uses kwin)
--------------------------


you are right! the classical menu is much faster than the menubutton.. so it would be your own choice what kind of menu you use... wouldn't that be great?

i do not use the menu after customizing my toolbars so i just don't care if a button makes some options i never use one click further away from my fingertips