The desktop pager configuration is limiting me to no more than 20 desktops. I'm wanting to set up (at home, Slackware64-13.37 and KDE 4.5.5) a desktop environment similar to what I have at work (Ubuntu, Gnome, Compiz) which is a 6x6 grid of 36 desktops (almost all used). I tend to prefer large windows, usually no more than 2 tiled per desktop, so a lot of desktops are typically used. How can I get past this limit of 20? Does it require a recompile?

Also, compiz shows me a fuzzy transparent grid when I press Ctrl+Alt+Arrow to move around the desktop grid, with the one I'm on highlighted. This grid appears once I move, and stays as long as I hold Ctrl+Alt. Is there a way to do that with Kwin?

I already have Ctrl+Alt+Arrow mapped to do the desktop switch, but have no way to see where I'm at without doing Ctrl+F8 separately. BTW, if it would do the same unzoom effect as Ctrl+F8 does, and hold there while switching with arrow keys as long as I hold Ctrl+Alt, and then go to the selected desktop when I release, that would be as good, maybe even better. But the complication is making it hold while holding keys, and out of it by releasing. The current default way to see the whole grid, move, and zoom back in, is too cumbersome for the speed and frequency I move around.

ditto here, max. no. of 20 desktops. However, you could also set up different activities to further divide your computer activities into fields such as work, play, internet, etc.

toad wrote:ditto here, max. no. of 20 desktops. However, you could also set up different activities to further divide your computer activities into fields such as work, play, internet, etc.

And how would these "activities" be switched? My goal is to replicate at home the way I operate on my work computer as much as possible. Home is Slackware/KDE/Kwin and work is Ubuntu/Gnome/Compiz with a 6x6 grid using Ctrl+Alt+ArrowX to move around (holding Ctrl+Alt holds the grid in view until released).

Or does anyone know what it takes to actually expand the number of desktops to at least 36? I have tested Compiz as high as 64, so that might some day be a target, too.

I tried editing ~/.kde/share/config/kwinrc and changed the "number=" to 24 in entry in the [Desktop] section, restarted KDE for it to take effect and the line was changed to 20 so it appears it is a limit hard coded somewhere

google01103 wrote:I tried editing ~/.kde/share/config/kwinrc and changed the "number=" to 24 in entry in the [Desktop] section, restarted KDE for it to take effect and the line was changed to 20 so it appears it is a limit hard coded somewhere

But is it hard coded in the GUI app to configure it, or in the code that actually reads the config and does the work? Would it be possible to completely hand edit the file to set everything up as a 6x6 for 36, and have it run that way (just avoiding the app)? Or do I need to get source, do a patch, and rebuild?

Should I submit it as a bug, or as a feature request?

Skaperen wrote:But is it hard coded in the GUI app to configure it, or in the code that actually reads the config and does the work? Would it be possible to completely hand edit the file to set everything up as a 6x6 for 36, and have it run that way (just avoiding the app)? Or do I need to get source, do a patch, and rebuild?

Should I submit it as a bug, or as a feature request?

you should ask on the kwin mailing list and/or irc channel to see if there's away around http://techbase.kde.org/Projects/KWin#D ... nformation

bugs.kde.org for feature request, you can also post on the brainstorm forum to see if it's a feature others want - I did look and so no bug or requests for this

google01103 wrote:bugs.kde.org for feature request, you can also post on the brainstorm forum to see if it's a feature others want - I did look and so no bug or requests for this

I did see a feature request to make desktops dynamic. I think that was to have a dynamically configurable number. If that is what it meant, maybe the limit of 20 now is because of a hard coded array. It needs to be at least a linked list, or maybe a BST or such. But even 36 of them would be fine in a linked list. This would be something to scale, but not THAT big (it's not like someone can readily handle 1048576 desktops).

You switch activities with the special function (i.e. Window) key + TAB on the keyboard or you can put the activity bar widget in your taskbar if you prefer using the mouse.

toad wrote:You switch activities with the special function (i.e. Window) key + TAB on the keyboard or you can put the activity bar widget in your taskbar if you prefer using the mouse.

Unfortunately, I don't have things well set up, yet (things like this are part of what I am working on). That means I'm not actually using KDE, yet. So actually testing these things right when I read posts here is usually not yet possible. I can't test these key operations until this evening (e.g. I am at work, on Gnome, which won't be changed until I have switched to KDE as my prime desktop at home). And, I need to get things up to a certain level of productivity before I can make the switch to KDE.

Anyway, I'd like to know more about how this "switch activities" works, and the basis behind it. How is it different from "switch desktops"? WHY is it different (e.g. why are there two such different things to do what in my mind so far seems to basically be the same thing)?

Is there a summary of how things are implemented? I can see at least 4 explanations of implementation.

One way of implementing things is a window manager simply unexposes and reexposes windows based on which group of them are currently selected by the user. A window can also be in more than one group at a time.

Number two is to create a larger wider wirtual workspace, with extended geometry. Selection takes place by moving the display sized view of this workspace. Only the view of the space is given to the video card. X buffers the whole workspace while the video card buffers only the viewport.

Number three involves a wider workspace literally buffered in the video card with only a subset actually selected to be transmitted over the video output. It's like number two, but the video card does the heavy lifting and X sends command or updates registers to manage it.

Number four would be a variation of number three with the arrangement being simply a set of display sized buffers that can be jump switched. It could effectively be a faster version of number one.

There could be others. But basically the idea is that there are these different collections of windows. Some ways would implement the ability for a window to space over more than one desktop and for the view to slide smoothly between them.

Oh, I suppose you might have windows spanning across corners of a cube rendering, too. But that could get interesting at the triple corners of a cube. Let's not go there. I'm not using the cube effect and have no plan to.

One quick google later I have a number of links for you relating to activities:

http://maketecheasier.com/use-kde-plasm ... 2010/09/01

http://userbase.kde.org/Plasma

http://www.ghacks.net/2010/08/16/kde-de ... explained/

viewtopic.php?f=14&t=7671

That should answer all your questions.

A simple solution using desktops+activities would be to use 6 desktops arranged horizontally using ctrl+alt+right/left to switch between them, then set up 6 activities and use ctrl+alt+up/down to switch between them. This will give you the 6x6 grid. The unfortunate thing about this set up is that the pager (and any virtual-desktop-showing effects) will only show the 6 desktops on the current activity.

Another option is to use another window manager/environment with the KDE applications (unless there are some specific parts of KDE's desktop setup that you want to use). A setup that I would recommend is Enlightenment (e17) + Ecomorph (a patched version of compiz to work with enlightenment. See http://code.google.com/p/itask-module/wiki/Stuff).

toad wrote:One quick google later I have a number of links for you relating to activities:

http://maketecheasier.com/use-kde-plasm ... 2010/09/01

http://userbase.kde.org/Plasma

http://www.ghacks.net/2010/08/16/kde-de ... explained/

viewtopic.php?f=14&t=7671

That should answer all your questions.

Thanks for the reading. It seems that Activities and Virtual Desktops are still a similar concept, but sufficiently different that using them together can be confusing. One major problem I see with this is the need to have separate key bindings to control them.

Perhaps what should be done is to revisit the whole thing not in terms of having something to add on, but rather, something to replace both. The fact that activities supports changing things (like theme, I suppose) that desktops do not, makes it a better starting point, IMHO. But I do note that even with Activities, you canNOT change the dekstop behavior (e.g. if you have 4 desktops, you have 4 desktops in every activity).

What I think would be better is to just get everything down to having a set of things which can be organized and reorganized in more flexible ways. Effectively, activities and desktops have a nesting relationship. Why not have a more flexible arrangement where you have any kind of topological relation desired. You have one big heap of objects that can be referred to as desktop/activity. Then you have a mapping that establishes relationships much like filesystem directories and file inodes. This mapping is thus your means to access these desktop/activity objects. You can organize however you like: grids, trees, grids inside trees, trees inside grids, grids inside grids. With any number of levels. And that's just barely starting. The mapping relationships could let you create a Dungeon style maze if you like, with different keyboard and/or mouse actions bound to different mapping steps. The simpler (and one default) setups with just have a few pre-coded and provided mappings. But you can code you own mapping with discrete access to every desktop/activity object (by arbitrary naming scheme). And this would also include the visual effects system where each transition point can be defined in terms of a visual effect (e.g. as you transition through your customized mapping, the effect can be different at each point).

Oh, and no limit on the number of these objects aside from your system capacity. Any authorized app should be able to access and control it all, triggering any change and any effect to go with it. Then we'd be open to all kinds of ideas on how to go about, custom mapping coding language choices ... or just a simple browser of all the desktop/activity objects in the heap (by name and possibly showing various settings and notes).

Skaperen wrote:

toad wrote:One quick google later I have a number of links for you relating to activities:

http://maketecheasier.com/use-kde-plasm ... 2010/09/01

http://userbase.kde.org/Plasma

http://www.ghacks.net/2010/08/16/kde-de ... explained/

viewtopic.php?f=14&t=7671

That should answer all your questions.

Thanks for the reading. It seems that Activities and Virtual Desktops are still a similar concept, but sufficiently different that using them together can be confusing. One major problem I see with this is the need to have separate key bindings to control them.

Perhaps what should be done is to revisit the whole thing not in terms of having something to add on, but rather, something to replace both. The fact that activities supports changing things (like theme, I suppose) that desktops do not, makes it a better starting point, IMHO. But I do note that even with Activities, you canNOT change the dekstop behavior (e.g. if you have 4 desktops, you have 4 desktops in every activity).

As I understand, they are going to be changing it so that each activity may have a different number of desktops. I'm not sure when that is expected to be released, though.

Skaperen wrote:What I think would be better is to just get everything down to having a set of things which can be organized and reorganized in more flexible ways. Effectively, activities and desktops have a nesting relationship. Why not have a more flexible arrangement where you have any kind of topological relation desired. You have one big heap of objects that can be referred to as desktop/activity. Then you have a mapping that establishes relationships much like filesystem directories and file inodes. This mapping is thus your means to access these desktop/activity objects. You can organize however you like: grids, trees, grids inside trees, trees inside grids, grids inside grids. With any number of levels. And that's just barely starting. The mapping relationships could let you create a Dungeon style maze if you like, with different keyboard and/or mouse actions bound to different mapping steps. The simpler (and one default) setups with just have a few pre-coded and provided mappings. But you can code you own mapping with discrete access to every desktop/activity object (by arbitrary naming scheme). And this would also include the visual effects system where each transition point can be defined in terms of a visual effect (e.g. as you transition through your customized mapping, the effect can be different at each point).

Oh, and no limit on the number of these objects aside from your system capacity. Any authorized app should be able to access and control it all, triggering any change and any effect to go with it. Then we'd be open to all kinds of ideas on how to go about, custom mapping coding language choices ... or just a simple browser of all the desktop/activity objects in the heap (by name and possibly showing various settings and notes).

while an interesting idea, I don't think it will fly very well as it will most likely lead to confusion.

A simple way to think of activities and desktops is that activities are segregated areas for the things you do (developing an app, designing a wallpaper, socializing with friends, etc.), and desktops are extra space for the given activity (e.g. whilst developing an app, I open an IDE; a web browser open to the project/issue tracker; another web browser open to online docs and forums; a console window for running things, testing apps, etc. I can put them on different desktops and then I don't have to worry about which one is on top and how far I have to alt-tab to find it).