Include Default Panels on All Monitors By Default

[Lonnie Lee Best]

Currently, when you install Kubuntu 19.10 onto a computer that has multiple monitors, KDE only puts panels onto the default monitor and the user has to add panels to all additional monitors.

I want to make my case that this should NOT be the default practice.

I think all panels, that are visible in a one-monitor setup, should also be on each additional monitor until they are decidedly remove. I'll make my case with the "Application Menu Panel", but I have the same opinion for all other panels.

Because KDE doesn't put an Application Menu Panel onto each monitor, the new KDE user will not know how to access an Application's main menu if they have the window open on one of the additional monitors. For new users of KDE, like myself, it is very clear that the burden of customization should be on the advanced user and not the new user. The advanced KDE user will know instantly how to remove an unwanted panel, but the new user is burdened with a task that is way more difficult than removing an unwanted panel:

Please let me help you see this from the eyes of a new user who has an application open on one of the additional monitors.

1) First I looked at the top of the application window and didn't see the application's main menu where I expected it to be (either in that window's title bar, or at the top of the entire monitor window).

2) I hit the alt-key (a common MS shortcut), hoping that the Application's main menu was just hidden and that alt would bring it up.

3) I had to do an internet search and learn about panels in KDE and then proceed to create my first panel.

4) When I right-clicked on the additional monitor's desktop and selected Panel > Application Menu, nothing happened on the vary monitor I did this on, instead it added an additional Application Menu panel to the default monitor, and worse: it added it on top of the existing Application Menu that was already on that monitor (making it practically invisible that anything had occurred).

Now, I ask you this. Is this the type of user experience that produces new user adoption?

Wouldn't it be better to put all the panels, that are on the default monitor, onto each and every additional monitor by default? Put the burden of customization onto the advanced user. After all, the burden of removing a panel is easier that creating and customizing a new one from scratch AND the advance user will already know all about panels. You don't need to put the burden onto the new user who can't access the main menu of an application their using because it is open within and additional monitor.

Who on the KDE development team thinks this is an acceptable default behavior (to not make Application Menus of an application accessible until you create and customize a panel onto that monitor)?

I love the KDE is so customizable, but you guys need to couple that richness with sensible defaults and this is an area that is not sensible (to the new user)!

ProblemType: Bug
DistroRelease: Ubuntu 19.10
Package: kubuntu-desktop 1.387
ProcVersionSignature: Ubuntu 5.3.0-29.31-generic 5.3.13
Uname: Linux 5.3.0-29-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu8.2
Architecture: amd64
CurrentDesktop: KDE
Date: Tue Jan 28 03:13:51 2020
InstallationDate: Installed on 2020-01-27 (1 days ago)
InstallationMedia: Kubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: kubuntu-meta
UpgradeStatus: No upgrade log present (probably fresh install)

[Lonnie Lee Best (launchpad-startport)]

Currently, when you install Kubuntu 19.10 onto a computer that has multiple monitors, KDE only puts panels onto the default monitor and the user has to add panels to all additional monitors.

I want to make my case that this should NOT be the default practice.

I think all panels, that are visible in a one-monitor setup, should also be on each and every additional monitor until they are decidedly remove. I'll make my case with the "Application Menu Panel" alone, but I have the same opinion for all other panels.

Because KDE doesn't put an Application Menu Panel onto each monitor, the new KDE user will not know how to access an Application's main menu if they have the window open on one of the additional monitors. For new users of KDE, like myself, it is very clear that the burden of customization should be on the advanced user and not the new user. The advanced KDE user will know instantly how to remove an unwanted panel, but the new user is burdened with a task that is way more difficult than removing an unwanted panel: learning what panels are, learning the names of each type of panel, dealing with bad panel creation workflow (explained below in #4).

Please let me help you see this from the eyes of a new user who has an application open on one of the additional monitors in a multi-monitor setup.

1) First I looked at the top of the application window and didn't see the application's main menu where I'd expected it to be (either in that window's title bar, or at the top of the entire monitor's screen).

2) I hit the alt-key (a common MS shortcut), hoping that the Application's main menu was just hidden and that alt would bring it up.

3) I had to do an internet search and learn about panels in KDE and then proceed to create my first panel.

4) When I right-clicked on the additional monitor's desktop and selected Panel > Application Menu, nothing happened on the vary monitor I did this on, instead (outside of my eye's focus) it added an additional Application Menu panel to the default monitor (which already has an Application Menu Panel), and worse: it added it on top of the existing Application Menu panel that was already on that monitor (making it practically invisible that anything had occurred)!

Now, I ask you this. Is this the type of user experience that produces new user adoption?

Wouldn't it be better to put all the panels, that are on the default monitor, onto each and every additional monitor by default? Put the burden of customization onto the advanced user (the one who already know how to do it). After all, the burden of removing a panel is easier that creating and customizing a new one from scratch (especially for a new user who doesn't even know what a "panel" is). You don't need to put this burden onto the new user who can't access the main menu of an application their using because it is simply open within and additional monitor.

Who on the KDE development team thinks this is an acceptable default behavior (to not make the "main menu of an application" accessible until you create and customize a panel onto that monitor)?

I love that KDE is so customizable, but you guys need to couple that richness with sensible defaults a...

[Lonnie Lee Best (launchpad-startport)]

https://askubuntu.com/questions/1206280/kde-show-app-menus-on-all-displays

[U26 (u26)]

Thank you for your feedback.

Defaults are highly subjective and it is impossible to please everyone. I'm unconvinced of the problem here. The panel is still on the other monitor, all that is required is moving the mouse further.

[Lonnie Lee Best (launchpad-startport)]

"all that is required is moving the mouse further" - David Edmundson

Respectfully, here me out.

As a new user of KDE, I have no clue what that means (above). Is there some implicitly hidden gesture that produces the Application Menu on Additional Monitors? If so, why is this gesture not required on the default monitor? That's an inconsistency guaranteed to confuse a new users of KDE (like myself).

Closing this ticket on the grounds that "defaults are subjective" ignores the fact that "sensible default increase new user adoption".

I'm making the effort to push this point because I've just started using KDE and I want it to become the goto desktop for all types of users. Obviously, I can see that it is the goto desktop for power users, but if you'd give my suggestions deeper consideration KDE will evolve into the desktop that's preferred by power users AND new users. This can be accomplished by making defaults explicit instead of hidden: "Show it until they know it".

I donated $20.00 to KDE.org the other day because of the potential I see in KDE. That doesn't make what I'm saying unquestionable, but I want you to know my sincerity.

Here's my primary desktop history:
Windows 3.1
Windows 98
Window XP
GNOME 2 (April 2007 is when I started using Linux exclusively)
Unity 7
GNOME 3
KDE

Out of all of these GNOME 2 was the easiest to use as a new user, but Unity 7 had the most sensible defaults when it comes to panels in a Multiple Monitors environment:

In Unity 7, if you installed that desktop onto a computer having multiple monitors, each additional monitor had all the same panels as the default monitor. In its day, Unity 7 had more users than GNOME and KDE combined. When it came to new user adoption, they were doing something right.

Here's why KDE should do this too by default:

1) Concept of "Burden of Configuration". The burden of configuration is best placed on users that already have the knowledge of how to configure KDE. New users benefit from explicit interfaces that show things (on screen) by default. Auto-hide and gesture-driven access to menus are NOT sensible defaults for new users. This is NOT subjective. It is a fact. Once new users know where things are, at that point they can give more priority to saving screen real-estate with auto-hide and learning shortcuts such as mouse gestures and hot-keys. Those things are not intuitive to new users. Until they know it, show it!

2) Concept of "Lowest Number of Steps Required". It requires less steps to remove a panel than it does to 1) Learn what a panel is 2) Learn the KDE names of each type of panel 3) Learn the KDE idiosyncrasies of new panel creation in a multiple monitor setup (see #4 in my original post; its a bug in and of itself).

3) Concept of "Less Steps Drive New User Adoption". In Web Marketing, it is a known fact that you lose sales for each additional step that's required to purchase your product online. Example, if it requires one step maybe 20% of the people that see it will buy it. If it requires 2 steps: only 15% will buy it. 3 steps 7% will buy it. Amazon.com knows this, and that's why they created the feature (one click purchasing). The point is, with each additi...

[U26 (u26)]

Just to clarify, I meant you move the mouse to the other monitor and click on the panel. Not some gesture.

The rest of your argument about reducing the number of steps is all based around the notion that people want two panels with two monitors. Otherwise this whole burden of steps works the other way round.

Given I see screenshots on bug reports on a daily basis, I do have an idea of what is popular. For more empirical evidence panel count and screen count are something we are collecting in the new user feedback module.

[Lonnie Lee Best (launchpad-startport)]

If not by default, add a feature called: "Clone Default Monitor's Panels and Widgets to All Monitors".

If you have 3 or 4 monitors, and want to have the same panels and widgets on all monitors, repeating the same task 3 or 4 times, for each panel and widget, begs for automation.

At the very least, you should be able to right-click on any panel and clone it and all of its widgets and drag it to the desired screen edge.

I wish every KDE developers had about four 4K monitors to set up on each install. At least the guy calling the shots at KDE ought to have this setup (not some guy with one 1080p laptop monitor). Sorry, these are my honest thoughts; repetitive tasks beg for automation.

[5-kde (5-kde)]

In Kubuntu 20.04, I put the same panels and widgets on each monitor.

Recently, all of those panels and widgets disappeared from my external monitor.

It would be very nice if I could clone an existing panel (along with all the widgets on that panel) and drag that copy to the edge of my external monitor (that lost all panels for no apparent reason). But, in KDE, each panel has to be created from scratch and customized; you can't clone an "already customized existing panel".

Even better, I wish I could right click on an external monitor and tell KDE to clone all panels and widget of another monitor.

The current status of this is "CLOSED NOT A BUG". It should instead be "Open Feature Request". Automation is the natural progression of any project: you eliminate steps that can be performed automatically through programming. This would be a nice feature.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.