Using Kubuntu 10.10 (Maverick) with KDE 4 (not sure about the minor version).

I have two monitors connected to the graphics card (nVidia Quadro NVS 280). Maverick automatically detected the two monitors and let me configure them properly on the fly. Something I never expected Linux to be able to do. Great news.

Now, when I try to assign a wallpaper to the desktop, I can only do so on one of the monitors at a time. I cannot use a wide-screen version to span across the two screens. I can do exactly that with KDE 3.5. Knowing that they have taken a lot of stuff from KDE 3, I wonder if this is one of those things I'll have to live without on KDE 4?

I could split the wallpaper in halves and assign them individually to each screen, but that'd be a little silly if you ask me. Any help would be appreciated.

Thanks,
Dai

This is a design intention of the KDE 4 Workspace, Plasma Desktop. Each monitor will recieve it's own activity. Each activity has it's own wallpaper.

bcooksley wrote:This is a design intention of the KDE 4 Workspace, Plasma Desktop. Each monitor will recieve it's own activity. Each activity has it's own wallpaper.

Please bear with me. What's the benefit of only providing that option? Doea that intention translate into more ease of use from the user standpoint?

[ADD] I may just be one user, but I find it hard to imagine that a majority of KDE users choose to have separate "activities" on separate monitors...

Several reasons:

1. It is the only usable solution when dealing with monitors of different resolutions
2. It is the only usable solution when dealing with monitors that are not in a straight horizontal or vertical line
3. It is the only usable solution when there are gaps between the two screens
4. It is the only usable solution when monitors might be disconnected, reconnected, or moved
5. It is much easier and more convenient when using wallpapers that are not specifically designed for multi-screen set-ups, and there are far, far more single-desktop wallpapers than multi-desktop wallpapers
6. It allows you to set different types of desktops on the two screens

For some of these, such as adding or removing screens, it is impossible for KDE to even know that they might be an issue.

In order to avoid the inevitable bugs and maintenance issues that would accompany an attempt to support two radically different approaches, KDE developers chose to stick with the one approach that was the most flexible and applied in the widest variety of situations.

TheBlackCat wrote:Several reasons:

1. It is the only usable solution when dealing with monitors of different resolutions
2. It is the only usable solution when dealing with monitors that are not in a straight horizontal or vertical line
3. It is the only usable solution when there are gaps between the two screens
4. It is the only usable solution when monitors might be disconnected, reconnected, or moved
5. It is much easier and more convenient when using wallpapers that are not specifically designed for multi-screen set-ups, and there are far, far more single-desktop wallpapers than multi-desktop wallpapers
6. It allows you to set different types of desktops on the two screens

For some of these, such as adding or removing screens, it is impossible for KDE to even know that they might be an issue.

In order to avoid the inevitable bugs and maintenance issues that would accompany an attempt to support two radically different approaches, KDE developers chose to stick with the one approach that was the most flexible and applied in the widest variety of situations.

Thanks for the info. That makes sense to an extent.

However, KDE 3.5 does support the use of a single wallpaper that spans across dual monitors. I've used that setup for more than 5 years and haven't run into any issue. With that in mind, is it that hard to maintain that capability while making sure the situations you mentioned above would be properly addressed?

I don't intend to bash KDE 4. I just genuinely wonder why something like this - that looks to be so basic to me, at least - had to be taken out. Did KDE conduct any usability study that concluded that most users of multiple monitors had monitors of different sizes/resolutions?

bcooksley wrote:This is a design intention of the KDE 4 Workspace, Plasma Desktop. Each monitor will recieve it's own activity. Each activity has it's own wallpaper.

That is not correct. There is always only one activity active/shown (since 4.6, maybe 4.5). On multiscreen environments, there is one containment per screen. A containment is a widget manager and may present more functionality by itself (like folderview).

Currently it is not possible to span a single wallpaper across multiple screens, because each containment handles wallpapers by itself. It might be possible in the future, though.

daihard wrote:However, KDE 3.5 does support the use of a single wallpaper that spans across dual monitors. I've used that setup for more than 5 years and haven't run into any issue. With that in mind, is it that hard to maintain that capability while making sure the situations you mentioned above would be properly addressed?

You may not have run into any problems, but lots of people did. There was a long string of complaints and bug reports relating to the issues I listed above. It was simply unmanageable in practice. It works fine for a very small subset of situations, but for anything else the approach is inherently broken.

So we have two alternatives. One leads to a cosmetic issue with an easy workaround (split the picture in half in an image editor). The other leads to breaking multiple basic functions, unpredictable behavior in a number of common situations, a major reduction in flexibility,

daihard wrote:I don't intend to bash KDE 4. I just genuinely wonder why something like this - that looks to be so basic to me, at least - had to be taken out.

Technically it wasn't taken out. These components were re-written from scratch. So they didn't remove it, they didn't re-implement it in the new system.

daihard wrote:Did KDE conduct any usability study that concluded that most users of multiple monitors had monitors of different sizes/resolutions?

First, these issues affect everyone who tries to use a laptop with a projector. So we have a major, basic, extremely common use-case for multi-monitor capabilities that will be plagued by these problems. And unlike a desktop user who can affording to spend 3 minutes cropping a picture, someone trying to do a presentation in front of their company cannot afford to have unexpected problems and unpredictable behavior. It has to just work immediately.

Second, when the drawback of one approach is seriously breaking basic functionality, while the drawback of the other approach is a cosmetic issue with any easy workaround, it really doesn't matter who is in the majority, it is better to have cosmetic problems than breaking functionality.

TheBlackCat wrote:

daihard wrote:However, KDE 3.5 does support the use of a single wallpaper that spans across dual monitors. I've used that setup for more than 5 years and haven't run into any issue. With that in mind, is it that hard to maintain that capability while making sure the situations you mentioned above would be properly addressed?

You may not have run into any problems, but lots of people did. There was a long string of complaints and bug reports relating to the issues I listed above. It was simply unmanageable in practice. It works fine for a very small subset of situations, but for anything else the approach is inherently broken.

Okay, I wasn't aware of that. I've never used Linux on a laptop with an external display.

Technically it wasn't taken out. These components were re-written from scratch. So they didn't remove it, they didn't re-implement it in the new system.

I know where you're coming from, though I'm not sure if that's any more convincing from the user's standpoint. If an old version of software had two features and a new version has only one of them, it shouldn't matter how technically the other one wasn't taken out but simply not re-implemented...

First, these issues affect everyone who tries to use a laptop with a projector. So we have a major, basic, extremely common use-case for multi-monitor capabilities that will be plagued by these problems. And unlike a desktop user who can affording to spend 3 minutes cropping a picture, someone trying to do a presentation in front of their company cannot afford to have unexpected problems and unpredictable behavior. It has to just work immediately.

Well, cropping one image may take just 3 minutes. Multiply that by 100+ images I have. Granted I don't have to do it all at once, but it's still pretty inconvenient. Well, looks like there's not much that can be done about it. I still much prefer KDE to the other DEs, so I will stick with KDE.

I understand why not enabling "spanning" makes sense. Would there be a reason against having the wallpaper selection allow me to select the "left" half and "right" half of an image? As in each screen I have has a resolution of 1680x1050, there could be simple logic that if I select an image that has a resolution of 3360x1050 (twice the horizontal resolution) that asking whether I'd want the left/right half of the image to be the wallpaper. If I selected one that was 1680x2100 it would ask top/bottom. There would be a "neither" option as default to leave it as it would work now.

I'm not sure, but I'd think this would be a simple enough thing to code, or even just without the logic parts, enable a "wallpaper cutter" so I could select the parts of an image I want as my wallpaper. It gets a little tedious to cut each wallpaper I want to use into two parts.

I think the decision was that something along those lines is acceptable, but so far no one has taken the time to implement it yet.

Makes sense. Functional for both setups, gets in the way of neither. Thanks for the reply, wasn't expecting one on a 3 month old topic so quickly.

There is no reason why KDE panel handler could not recognize that a wallpaper has been requested equaling in size to the span of two panels, then
(1) automagically (a) create file wallpaper_0.png which is correct half of wallpaper for itself (b) create wallpaper_1.png which is correct half for second display, and then....
(2) inform second panel handler that it will be using wallpaper_1.png.

This would allow for automatic recognition of multiple spanning wallpapers.

Or someone could write a utility or perhaps a widget to do the same thing.

I understand the long list of reasons why one might want to leave out the capability but to me, if there is a need, then why not be creative and solve the problem rather than discard it because it is difficult or deemed not worth the effort. If the latter was the rationale (according to the long list of reasons - it is) then I would remind that satisfying users is what makes a distribution/OS/Desktop Env popular. Many people want to span multiple panels with one wallpaper.

My 3.14159 Cents worth.

TheBlackCat wrote:

2. It is the only usable solution when dealing with monitors that are not in a straight horizontal or vertical line
3. It is the only usable solution when there are gaps between the two screens
4. It is the only usable solution when monitors might be disconnected, reconnected, or moved

My neighbour's dog barks all night. Perhaps you could set the volume to full blast and remove all the audio control features in the next release so I can sleep to loud music instead of a barking dog.

If you think that's ridiculous, well, it's no more ridiculous than your idea of having the desktop environment trying to enforce control over other things it has no control over.

If you don't already have Imagemagick, it's a simple yum install away. After the install you should have the command 'convert'. It will allow you to do some nifty tricks to your images from the command line, and it will take care of your background issue 1 file at a time, or will handle all 100 of them in one fell swoop. (Imagemagick will also give you the command 'identify' which we'll use to display our image geometries.

Step 1 is always make a copy of your original or originals:

[admin@geekb imageconvert]$ cp backgroundBIG.jpg backgroundBIG.jpg.orig

[admin@geekb imageconvert]$ identify backgroundBIG.jpg
backgroundBIG.jpg JPEG 5760x1080 5760x1080+0+0 8-bit DirectClass 3.878MB 0.170u 0:00.170

[admin@geekb imageconvert]$ convert -crop 1920x1080 backgroundBIG.jpg +repage bgpart%d.jpg

[admin@geekb imageconvert]$ ll
total 11668
-rw-rw-r--. 1 admin admin 3878127 May 4 23:22 backgroundBIG.jpg
-rw-rw-r--. 1 admin admin 3878127 May 5 00:02 backgroundBIG.jpg.ORIG
-rw-rw-r--. 1 admin admin 1312655 May 5 00:02 bgpart0.jpg
-rw-rw-r--. 1 admin admin 1351721 May 5 00:02 bgpart1.jpg
-rw-rw-r--. 1 admin admin 1518701 May 5 00:02 bgpart2.jpg

[admin@geekb imageconvert]$ identify bgp*jpg
bgpart0.jpg JPEG 1920x1080 1920x1080+0+0 8-bit DirectClass 1.313MB 0.000u 0:00.000
bgpart1.jpg[1] JPEG 1920x1080 1920x1080+0+0 8-bit DirectClass 1.352MB 0.000u 0:00.010
bgpart2.jpg[2] JPEG 1920x1080 1920x1080+0+0 8-bit DirectClass 1.519MB 0.000u 0:00.000

And now we'll spllit our new files all at once, just because it's fun:

[admin@geekb imageconvert]$ for i in `ls bgpart*jpg` ; do convert -crop 50%x100% $i +repage smaller%d.$i ; done
[admin@geekb imageconvert]$ identify smaller*
smaller0.bgpart0.jpg JPEG 960x1080 960x1080+0+0 8-bit DirectClass 666KB 0.000u 0:00.000
smaller0.bgpart1.jpg[1] JPEG 960x1080 960x1080+0+0 8-bit DirectClass 683KB 0.000u 0:00.000
smaller0.bgpart2.jpg[2] JPEG 960x1080 960x1080+0+0 8-bit DirectClass 724KB 0.000u 0:00.000
smaller1.bgpart0.jpg[3] JPEG 960x1080 960x1080+0+0 8-bit DirectClass 666KB 0.000u 0:00.000
smaller1.bgpart1.jpg[4] JPEG 960x1080 960x1080+0+0 8-bit DirectClass 690KB 0.000u 0:00.000
smaller1.bgpart2.jpg[5] JPEG 960x1080 960x1080+0+0 8-bit DirectClass 806KB 0.000u 0:00.000

Enjoy!

p.s. - Rarely do we have much control over our environment, and things will constantly change. Being versatile and able to effectively adapt to whatever happens around you is a trait that will likely take you far. Spanning backgrounds may come back to KDE one day. Or maybe not. I realize that this is a pretty petty issue to use as an example of versatility, but I think that it still makes the point: there is always another way. Discussing with humans that you would like your tool back will likely leave you disappointed much of the time.

physicsguybrian wrote:There is no reason why KDE panel handler could not recognize that a wallpaper has been requested equaling in size to the span of two panels, then
(1) automagically (a) create file wallpaper_0.png which is correct half of wallpaper for itself (b) create wallpaper_1.png which is correct half for second display, and then....
(2) inform second panel handler that it will be using wallpaper_1.png.

This would allow for automatic recognition of multiple spanning wallpapers.

Or someone could write a utility or perhaps a widget to do the same thing.

I understand the long list of reasons why one might want to leave out the capability but to me, if there is a need, then why not be creative and solve the problem rather than discard it because it is difficult or deemed not worth the effort. If the latter was the rationale (according to the long list of reasons - it is) then I would remind that satisfying users is what makes a distribution/OS/Desktop Env popular. Many people want to span multiple panels with one wallpaper.

My 3.14159 Cents worth.

I agree. The split-an-image thing doesn't work for me because, despite the marvels of ImageMagick, I enjoy the slideshow functionality of the desktop background and having to (a) split over 200 images and (b) open the Default Desktop Settings every 10 minutes (or half hour, or hour) is very inconvenient. I just switched from Ubuntu to Kubuntu for stability reasons, so I understand about the 1 monitor = 1 container thing ... Wallch worked on Ubuntu but didn't have the Span feature. Could it be adapted to cover this functionality? (Mebbe there's another topic I need to post that suggestion to)

Thanks, bcooksley and TheBlackCat for your patience in responding to our persistent pursuit of this