added "expo"(spaces) style mode, with commandline option eg "skippy-xd -ad"

[dobkeratops]

added "expo"(spaces) style mode, with commandline option eg skippy-xd -ad
refactored some layout code to seperate X11 stuff from layout calc
added some vec maths helpers,

the 'expo' style mode is different to others that its rescaled to only show the acoverlap tually used area.
if you have 2x2 used out of 3x3.. it only shows that much.

I want to do a bit more, what I have in mind is an option to automatically pick expo/scale based on whats actually on the current screen. (if (windows are hidden by overlap) then 'scale' else 'expo');
also i'd like to implement a grid layout option, easier to navigate with cursors a. Independant scaling is why i've refactored the layout calc

extra options so far (they can go in config too)
skippy-xd -a // force gathering windows from all desktops
skippy-xd -ad // force gather from all desktops , plus keep desktop layout.

I use this with "fvwm" at the minute. I like a minimal desktop on my laptop... its a very handy setup.
but I'm inspired by the experience of a mac where expose+spaces and mission control were genuinely more useful than anything i've found in linux.
It should just take a small amount of smart-triggering to get the same functionality. just one hotkey or mouse gesture to 'zoom out more' and one to 'select perhaps
eg start->
press hotkey -> see expo/scale based on context
-> if you didn't you see what you want,
-> press same one again -> combined expo+scale views everything , but more zoomed
.. that sort of thing

I've embarked on customizing 'skippy' instead of compiz because I haven't got the latter to compile yet :)

NOTE:-
I also changed some defaults in the config file, i hope they're ok
I like to be able to actually read the text in the previews.. so i've upped the default opacity to 248 , and reduced border sizes to 8 pixels - I

[richardgv]

Thanks a million! :-) I will look into the code later. I probably would need to apply my own WIP patch firstly, which solves a number of known issues, though.

And I'm fvwm user as well. :-)

[dobkeratops]

bit closer to what i was trying to do.. got 'show-desktops' and 'grid layout' option;
they dont quite interact together nicely yet,
[1] cursor warping seems broken when you pick offscreen windows - the cursor ends up on the screen edge (perhaps its clamping it prior to letting the window manager switch desktop?)
[2] my animation hack doesn't transition.. i'll need to mess with how its storing client/mini state a bit more

some of the code might have changed quite a bit, im trying to refactor it to use a 2d vector type to make layout calculations cleaner, and i've generalized the scaling. Should merge ok i hope, i've just been wrapping accessors for a 'rolling refactor'.

to get the desktop stuff working fully i'm tempted to add an actual desktop concept (throw the clients in a heirachy?)..

[dobkeratops]

( if a merge proves problematic... i'd be willing take a look )

[richardgv]

That's fast indeed! :-) I will most likely push my changes to the repo tonight, and it probably already breaks some of your things, but I won't know how much until I have time looking at your code.

[dobkeratops]

ideas on what next..
I dont think i'll persevere with animation.. seems possible, but glitchy. the instant switch is still useful and grid layout doesn't shift things so far because of sorting.. so its easier to see where you were.. i like the pointer-warp skippy does.

Seems like fvwm triggering plus this can acheive what I was after. just toggle between what you see (all desks/all windows/ detail of current desk) without needing loads of hotkeys bound.

maybe some simple way of acheiving an alternative to what gnomeshell/MC do, eg showing the whole desktop overview in the corner, but thumbnails from the current desk occupy the majority of the screen.
another simple idea is an option to constrain the thumbnails to show a crop with zoom at 0.5..keep the text readable.
.. (but what to show,the window centre? or top corner? or scroll throught it, animated..)..

another spurious idea is a screensaver mode.... slideshow of everything open..

I managed to get compiz compiling, but skippy has the advantage its a small source, easy to work with :)

[dobkeratops]

hi, just curious if this merge is still possible, or if this code makes sense

[richardgv]

@dobkeratops:

Oops, sorry. From your last reply I thought you were going to continue modifying your code, so I didn't review it.

For your contribution I'm truly grateful, firstly.

I looked brief at the changes, and no, I will not merge your commits in its current form. Your code is pushed to the dobkeratops-dev branch here, to ease local merging, and most likely I will gradually merge part of them -- probably the vector part at first. But I need to firstly strip those commented out code and printf-s, remove the strange macros, fix the style issues (yes, there is a lot of code with bad styles in the source code right now that came from the previous authors, but it does not mean I would like to tolerate such things), and make sure it works correctly in the corner cases and has as little minor issues as possible. Unfortunately, the impression your code gave me is, I can't really trust it. There are PPAs directly pulling from the master branch, and merge cannot be done casually.

[dobkeratops]

firstly are you ok with the idea of the wrappers i've tried to put i. For me any sort of layout arthimetic is a lot clearer with vector /rect structs, and chunks of arithmetic pulled out into a vector maths "library". (in c++,i'd do a lot of this with an N-D templated vector type, or a Vec2, Vec3{ xyz } etc.. similarly handling of fixed point arithmetic is easier.
do the names make sense v2i_ (vectors are usually float.. mentioining an int helps).

the intention was a rolling refactor to move the window structs over to holding the size as either a "PosSize" or "Rect", to slot into the maths helpers directly. hence all the cw_pos(..) stuff. These sort of wrappers can be replaced afterward with a regex expansion. in the intermediate state, the code is unfortunately bloated.

'strange macros' - could they be renamed, which ones are 'strange' to you. to me, code is clearer when details are abstracted. for example, the iteration through the dlist, which seems to require manually extracting a pointer into a local variable ..code you'd probably cut/paste in every loop.
Do you actually prefer everything written out explicitly - for me, putting this sort of repetition in macros is less error prone, and clearer. its just you have to agree on names that make sense to everyone

the debug prints, oh sorry those should be wrapped really, something that can always be ifdeff'ed out .. but for me working on anything debug is essential, it should be left around to be re-enabled when you actually want to start changing things.

r.e. the layout algorithms,it seems to me there are many possibilities to explore,being a small source its easier to try things out here than in compiz.
in the 'grid' mode i'd used sorting to try to keep the thumbnail layout coherent with the fullsize original - I have another way of doing that in mind that might even work better (going from front to back in the stacking order, and placing the thumbnail on the grid in the nearest unused slot). I liked the ability of osx snow leopard to combine the expo/scale effects... and so on.

If i was going to change more, i'd prefer to wait till after a merge has been done,so that code stays in sync.
So lets see how much of this you want, or if it can be changed till you're ok with it.

There's part where i think i refactored to decouple - the intent was to seperate the X stuff from layour calculations more rigourously (i recall something to do with 'factor' being held inside).. i needed the ability for individual windows to be scaled differently and couldn't really see how to do that with the existing stuff which seemed to share the matrix.

[dobkeratops]

-- and yes - I have more changes in mind but I put this to one side at a convinient point; (back to working on rust-related things). it would be better to wait to see what can be merged before proceeding. diverging sources scare me.

skippy / 'expose' type functionality is not just a gimmick, its genuinely helpful for navigating (it works amazingly well on the mac, nothing i've seen on linux matches it ) - hence the work on trying to get options on keeping the most useful information visible, and trying to find a way of combining desktop/window overviews.
in 'grid' mode, information is prioritized differently.
I use a lot of chromacoding on rust sourcecode, that makes it easier to pick out in thumbnails (they have a lot of differnt keywords to distinguish declaring various elements..)

[dobkeratops]

animated transition is something else i wanted - seemed possible but glitchy so i disabled it. One would have to figure out how to do it smoothly. again its not a gimmick , it helps your eyes track where things are (also why an option for coherence between thumbnails is nice) - thats another reason i wanted to wrap the states - to add a seperate current location moving from original location to the layout calculated target. then you could try various ways of paging between different subsets.

compiz has a slightly irritating wobble where all the motion overshoots a little - i think apple might actually have a patent on using a sin curve, or something anoying like that, i wonder if that actually prevents people from implementing a similarly smooth transition, but i'd be really surprised if they could enforce that, and they've ditched the expo/spaces behaviour now.

[richardgv]

My apology, being super-busy today. Will reply when I get some free time.

[richardgv]

If i was going to change more, i'd prefer to wait till after a merge has been done,so that code stays in sync.
So lets see how much of this you want, or if it can be changed till you're ok with it.
...
-- and yes - I have more changes in mind but I put this to one side at a convinient point; (back to working on rust-related things). it would be better to wait to see what can be merged before proceeding. diverging sources scare me.

I would recommend you to continue. It isn't too likely for me to invest too much time on open-source projects now. (My work is hell.) Just go ahead. Eventually you may find you are maintaining your fork of skippy-xd, but that's pretty common in the open-source world. Maybe I should have headed the project to you, but I'm not certain if you are cautious enough.

firstly are you ok with the idea of the wrappers i've tried to put i. For me any sort of layout arthimetic is a lot clearer with vector /rect structs, and chunks of arithmetic pulled out into a vector maths "library". (in c++,i'd do a lot of this with an N-D templated vector type, or a Vec2, Vec3{ xyz } etc.. similarly handling of fixed point arithmetic is easier.

Abstractions sound like a good idea. :-) As far as it's worthwhile and makes code cleaner.

do the names make sense v2i_ (vectors are usually float.. mentioining an int helps).

Name doesn't matter. Don't worry, I will follow your convention. :-)

the intention was a rolling refactor to move the window structs over to holding the size as either a "PosSize" or "Rect", to slot into the maths helpers directly. hence all the cw_pos(..) stuff. These sort of wrappers can be replaced afterward with a regex expansion. in the intermediate state, the code is unfortunately bloated.

Sounds good, but I'd better judge this when I finish reading the code.

'strange macros' - could they be renamed, which ones are 'strange' to you. to me, code is clearer when details are abstracted. for example, the iteration through the dlist, which seems to require manually extracting a pointer into a local variable ..code you'd probably cut/paste in every loop.
Do you actually prefer everything written out explicitly - for me, putting this sort of repetition in macros is less error prone, and clearer. its just you have to agree on names that make sense to everyone

Oops, sorry, I guess we are not talking about the same set of macros... I spot a few macros that seem useless, well, but now I think they are probably somehow useful.

the debug prints, oh sorry those should be wrapped really, something that can always be ifdeff'ed out .. but for me working on anything debug is essential, it should be left around to be re-enabled when you actually want to start changing things.

I agree, but I prefer to at least keep them commented out in releases...

in the 'grid' mode i'd used sorting to try to keep the thumbnail layout coherent with the fullsize original - I have another way of doing that in mind that might even work better (going from front to back in the stacking order, and placing the thumbnail on the grid in the nearest unused slot). I liked the ability of osx snow leopard to combine the expo/scale effects... and so on.

Heh, I need to read your changes to understand this...

skippy / 'expose' type functionality is not just a gimmick, its genuinely helpful for navigating (it works amazingly well on the mac, nothing i've seen on linux matches it ) - hence the work on trying to get options on keeping the most useful information visible, and trying to find a way of combining desktop/window overviews.
in 'grid' mode, information is prioritized differently.
I use a lot of chromacoding on rust sourcecode, that makes it easier to pick out in thumbnails (they have a lot of differnt keywords to distinguish declaring various elements..)

I personally never loved it, though, and I was working on it simply because somebody else asked. :-D For me the ugly fvwm Alt-Tab window seem satisfactory.

compiz has a slightly irritating wobble where all the motion overshoots a little - i think apple might actually have a patent on using a sin curve, or something anoying like that, i wonder if that actually prevents people from implementing a similarly smooth transition, but i'd be really surprised if they could enforce that, and they've ditched the expo/spaces behaviour now.

Compiz doesn't have a terribly clean codebase. In my impression it tries to do quite some abstractions, which unfortunately seemingly messed thing up further.

[dobkeratops]

cautious enough.
Well if i was going to put more time into it to that extent ... i'd consider moving it to C++. The downside there being , you start saying its "C++", and some people will whine about it not being "modern" c++ or whatever. what's the lesser evil.. having more i's & t's to manually dot (in C), or more style options to argue over in C++...

For me the ugly fvwm Alt-Tab window seem satisfactory.
nothing wrong with simple/light
but thanks for reminding me:) another nice option would be an "alt-tab" mode which orders the grid in stacking order, and respond to 'tab' /shift-tab to step fwd/back.

anecdotal - i'd never enjoyed coding on a laptop - till i tried a macbook pro. the combination of trackpad+expose/spaces allowed it to punch above its weight in screenspace,IMO.

Compiz doesn't have a terribly clean codebase. In my impression it tries to do quite some abstractions, which unfortunately seemingly messed thing up further.

plugin architecture seems like a good thing, in my case it seems like i would just need to add a new plugin, but its much bigger to compile and relies on a heavier compositing WM. right now its a little slow on my laptop. i get window glitches on resizing.. not so with fvwm

[richardgv]

Well if i was going to put more time into it to that extent ... i'd consider moving it to C++. The downside there being , you start saying its "C++", and some people will whine about it not being "modern" c++ or whatever. what's the lesser evil.. having more i's & t's to manually dot (in C), or more style options to argue over in C++...

I sometimes found that I wish to use some C++ features, as well, but we have some users with unexpected versions of compiler -- take FreeBSD 9, which uses gcc-4.2 for licensing issues, as an example. Those old versions may fail to properly support the fancy C++ features you plan to use. And converting from existing codebase is a problem, considering C++03 does not support some features in C99 that we are using. The issue exists on library, too: I've seen some others with such old X Render library (presumably on an outdated Fedora or RHEL installation at workplace) that he has to patch the code himself to compile correctly.

anecdotal - i'd never enjoyed coding on a laptop - till i tried a macbook pro. the combination of trackpad+expose/spaces allowed it to punch above its weight in screenspace,IMO.

Basically I've never enjoyed doing anything on a laptop. The keyboard is just too weird for me. Nor on a Mac, just can't love the unfamilar keyboard layout that poses quite some issues even on navigating in a line.

plugin architecture seems like a good thing, in my case it seems like i would just need to add a new plugin, but its much bigger to compile and relies on a heavier compositing WM. right now its a little slow on my laptop. i get window glitches on resizing.. not so with fvwm

The approach I favor is a small, monolithic piece of software with compile-time options controlling whether a feature is enabled.

The classic version of Compiz (0.8.8, which in my viewpoint is a lot more stable and actually has more features) was last updated on early 2011. It would be surprising if the version appears slow on your computer.

[ikem-krueger]

Is that already merged?

[richardgv]

Is that already merged?

Not yet.

[abmantis]

Is this abandoned?