Restore "AllowWindowOverlap" functionality

[pelle.k]

I'm running bazaar rev: 1193.
There's is no way to allow windows to overlap i.e. "slide under" without user interaction using the "intellihide" mode.
The rationale for this is explained here: https://bugs.launchpad.net/do/+bug/375177/comments/5
However, the feature was straight forward, it was working very well, and i cant imagine it brought you a lot of headaches in terms of code bloating and readability of the codebase. I might be wrong though ;)
So, i'm just asking politely if you would reconsider adding this feature, once again. Consider this a "wishlist" item.
That said, the "intellihide" is working very well. It's just not optimal (for me, and possibly others).

[Alex Launi (alexlauni)]

Can you explain what is suboptimal?

--
--Alex Launi

[pelle.k (pele2)]

I'm going to touch on why intellihide is suboptimal (for *me*, not necessarily anyone else).
First of all, any docklet you add, that is visually presenting some form of data through means of real time graphics, like say the clock, or maybe the coming cpu frequency meter, has to be called be means of user interaction, while i would like to have that data displayed all the time.
Same goes for presenting what applications are running, without me "asking", i.e. touching the bottom border (or what have you). Another scenario would be that of someone using mainly keyboard navigation, and would like to have docky show itself without having to minimize the fullscreen window (without mouse interaction that is).
You could argue that i can have all that, by always showing docky, but then i will loose an inch or so at the bottom of my screen. So in essence, i had it all with "window overlapping" functionality. I had the best of two worlds ;)

I'm not arguing you should drop the intellisense feature, because it'll surely please some (most?) people, but rather add (optional) window overlapping functionality to the "never hide" preset.

I should add that this "bug" is a duplicate of https://bugs.launchpad.net/bugs/375960
Should i mark this bug as duplicate, seeing that https://bugs.launchpad.net/bugs/375960 came first?

Lastly, i've presented my case. Feel free to close this bug if you feel this is not enough to warrant reimplementing "window overlap" functionality into docky. :)

[pelle.k (pele2)]

This restores window overlap, using the old gconf key, so that it'll continue working when updating from 0.8.1.
It's very discrete, no changes to the preferences GUI are made, but those who wish can still enable "allow window overlap" through gconf, when in "autohidetype: none" mode. To each his own?
It applies cleanly to bzr rev 1216.

I should point out that i have no previous mono/C# programming skills, so if something looks odd, you know who to blame :)

[Dario Ruellan (druellan)]

Gnome-Do updated las night to version 0.8.2, since then I no longer can use the AllowWindowOverlap feature. The option is there on gconf (I think inherited from previous version) but not functional. Since I use Docky as a replacement to the taskbar (to gain space), now I only can use autohide, nice but not optimal if I want to have running applications always on sight.

Notice that if you only have running applications on the dock, because the size and the position most of the time the dock does not overlaps to other window information.

My wishlist would be to have 4 options: always on top, always on background, autohide, intellihide.

Thanks!

[pelle.k (pele2)]

I've rebuilt the "official" ppa package (jaunty) with support for AllowWindowOverlap here http://download.tuxfamily.org/pandora/temp/jaunty/gnome-do/
You still need the 0.8.2 jaunty PPA activated to pull in dependencies though. Will add 64bit packages as well.
This is a temporary solution anyways.

[Jason Smith (jassmith)]

Send me your diff and I'll consider it for official inclusion if your
serious enough to attempt a fork.

On Thu, 2009-07-02 at 21:04 +0000, pelle.k wrote:
> I've rebuilt the "official" ppa package (jaunty) with support for AllowWindowOverlap here http://download.tuxfamily.org/pandora/temp/jaunty/gnome-do/
> You still need the 0.8.2 jaunty PPA activated to pull in dependencies though. Will add 64bit packages as well.
> This is a temporary solution anyways.
>

[pelle.k (pele2)]

For bzr or 0.8.2?
I'm including the patch used for 0.8.2 in this post.

[ajfier (jabryl)]

It's not a bug, it's a feature!

*shakes head*

I would also like to request that overlap be restored.

[Stani (stani)]

When I updated docky, I was very disappointed that the 'above overlap' has been removed. I tried intellihide for a while but it doesn't work for me. (Eg I don't like to be forced to unhide the dock to see the time.) I would be very glad if it can be restored.

@pelle
Could you please make a 64bit package. I can't wait to get this functionality back.

In the meantime I will downgrade to the previous version.

[pelle.k (pele2)]

Sorry for being "OT" guys...

Stani, i did announce the 32bit package in this thread on the ubuntuforums: http://ubuntuforums.org/showthread.php?t=381039&page=12 and it's probably better if you we continue discussing any matters regarding my packaging gnome-do there. i'll drop a comment in that thread right now, regarding the 64bit package.

[Robert Dyer (psybers)]

Let's compromise! :-) Check out my linked branch: lp:~psybers/do/intellifade

To test it out, you have to manually set AllowWindowOverlap to true in gconf, and then disable all hiding in the prefs dialog. Once you do that, you get sort of my idea of a cross between Intellihide and Allow Window Overlap which I am dubbing Intellifade.

Feedback welcome. :-)

[pelle.k (pele2)]

That's excellent Robert! I've tried it out, and its working very well. I cant speak for anyone else, but i certainly think this is good enough to replace the classic "window overlap".
It would be nice if one could set alpha/transparency level, but i still think it's very functional.
Also, just a quick note; it would be very nice if the dock "faded" into the transparency, i mean going from full visibility to 50% transparency in 0.5 seconds or so (and vice versa). That would be pure eye candy really, but i just thought i'd throw it out there.

Thanks for the effort!

[Robert Dyer (psybers)]

Actually it *does* fade. :-) I hacked this up very fast so the fade time is the same as the autohide time, which is very fast so it may not be noticeable. A proper implementation would be done if this interests enough people.

For now though I doubled the time it takes to fade so its a bit more visible. Feel free to update and comment.

[Stani (stani)]

@Robert
Do you have this available in a PPA?

[pelle.k (pele2)]

I'm running rev 1296 now, and it does indeed fade out, but not in. Not that there's a need for that (just an observation), but i wouldn't mind a fade in, when it's that short.
It doesn't fade on mouse over, but i suspect that's intentional. However, i wouldn't mind that either, with a short fade time.

It does suffer from the same cosmetic bug as intellihide though; when calling a modal window in, say firefox (preferences window), it does flicker on opening/closing the window.

I have it packaged up btw, but i'm not going to share it (for testing), unless you explicitly say that's OK, Robert. I now how developers usually feel about people sharing unfinished work.

[Robert Dyer (psybers)]

@stani: I don't do PPA, so no.

I have no problem with people making a PPA out of dev code in general, though it does lead to just that many more (different) versions of the software out there so tracking bugs is just a bit harder (as most people report a bug and *maybe* give the exact version/ppa they are using, but often not).

[pelle.k (pele2)]

I noticed you implemented fade on mouse out as well :)
My take is that you may just as well go the whole nine yards, and fade in _and_ out on every event, just like intellihide animates up and down on on every event. That would be more consistent (if you're used to intellihide), and there could also be a global option (that affects both intellihide and intellifade) to "turn off animations" it off if you're bothered by it.
And again, a setting for preference for transparency level could probably be useful - i find it a tad bit too transparent (too hard to read the time on my small dock), and i presume people have different eyesight/screen setups/etc. If you feel transparency preference adds to much complexity to the "settings gui", one could always leave it as a gconf option for "advanced users" or those who think going that extra bit is so worth it.

Feel free to ignore me :) and keep up the good work!

[Robert Dyer (psybers)]

I fully intended to do fade-in as well, but apparently my little hack to get this up and running just wont cut it. When/if I get time to implement this properly it will have fade-in.

The GUI preferences wont change. At best, I'd add 'Intellifade' or something to the hide drop-down, but that doesnt even make much sense so I dont know. No new widget(s) will appear on that dialog though.

The opacity level used probably should be a gconf setting, I'll go hack that in now.

[Robert Dyer (psybers)]

Lots of changes. Now should fade in/out consistently. Theres a gconf key to set the opacity it fades to (try setting it to 0, thats pretty cool!). To enable you no longer need to hack gconf, its in the dropdown for hide options in prefs.

In fact, with this in place if you set the opacity to 1 you have exactly the functionality this bug report requests.

I'll probably clean my code up some and propose a merge. Hopefully the other devs like it as much as I do. :-)

[pelle.k (pele2)]

I'm sorry i'm "spamming" this bug yet again. I'm now running rev 1302.
What strikes me at first glance is that the less opacity the deafult "fade" has, the shorter the fade time is. There's nothing wrong about that, i just noticed it. Maybe i'm imaging it though. I'm not a machine, mind you :)
Also, the default opacity key in gconf may have a few too many decimals. It doesn't really matter to the end user, but i thought i'd mention it. In my case, the default value of 0.40 is 0.40000000596046448.

Good work, and yeah, lets hope the other devs like it! :)

[Stani (stani)]

Hi Robert,
I didn't have time to try it yet, but the described behaviour sounds very exciting and would fulfill my needs. So I hope you can get it accepted in the main trunk!

[ajfier (jabryl)]

So is this going to be fixed in the next version or not?

I've been using pelle.k's rebuilt package, thanks for that btw, and won't be going back to the official version until this is fixed.
Intellifade with opacity set to 1 sounds like something I might be able to live with, but it's not exactly an ideal solution.

[Robert Dyer (psybers)]

@ajfier: First of all this is a 'wishlist' item, thus there is nothing to 'fix' in the main trunk. This is a brand new feature.

Second, Intellifade with opacity 1 is *identical* to AllowWindowOverlap.

Third, I think the other devs are slowly warming up to this feature so there is still hope it might make it into trunk. ;-)

1) Intellifade + opacity==1 is AllowWindowOverlap, so anyone who liked that old feature would be happy to have this.
2) Intellifade + opacity==0 is basically Intellihide, but instead of sliding away it fades. One of the designers said this is a better animation for that so thats nice.
3) Intellifade + any other opacity is a new feature, one I personally have been using (opacity=.4) and very much prefer over Intellihide.

Since it has multiple use cases and should be able to make many many people happy, I don't see why we can't merge it in. I'll be proposing a merge soonish (need to clean the code first, and I am under a research deadline). *If* that merge is accepted it probably will make the next release.

[ajfier (jabryl)]

It's not a new feature, it's an old feature that was removed. The sudden absence of essential functionality is a problem that is certainly worthy of "fixing".

I haven't tried Intellihide yet but I hope it makes it into the next release.

[Robert Dyer (psybers)]

If we purposely remove an old feature, then it obviously is not 'essential' (and no, it IS NOT essential, despite what you may think). Thus the fact that feature was removed, means adding it back in makes it a *new* feature and thus there is nothing to "fix". This point is not arguable, we are the devs so we decide what features are/are not part of the system (for better or worse). :-)

Also its called IntelliFADE -- intelliHIDE already exists. This confusion may need remedied in the prefs UI, but for now I'll hope people notice there are 2 different options in the drop-down (even if those 2 are similarly named).

[ajfier (jabryl)]

It's essential to those of us who use it. What is essential changes from person to person and for users like me this is a crippling bug. Belittling my opinion isn't going to change that.

Why are you so adamant about not restoring this feature? Would it really be that hard to put it back? You've obviously put forth a lot of effort to try to replace it.

[Stani (stani)]

@ajfier

That 'allow windows overlap' feature is also essential to me. But Roberts intellifade contribution is great and offers exactly that behaviour back. It is quite obvious you didn't try the intellifade or you would be enthusiastic. Instead of arguing against Robert, you'd better look for ways to get his contribution in. The sooner it is accepted, the sooner we have back 'allow windows overlap'. Besides that open source developers are benevolent dictators, which mostly proves to work well.

[Robert Dyer (psybers)]

I'm sorry but as a developer, I must consider what is essential as 'what is essential for the vast majority of users'. Also, we are allowed to override that arbitrarily, as stani pointed out. :-) This isn't because we hate you, it's actually because we love our users and thus we try to do whats best for the majority, which sometimes pains a small minority.

What I did in this case, however, was recognize that there are a group of users (this bug report) that want a certain functionality. There are also another group of users that wanted yet another new functionality (on another bug report). Thus I decided there probably was enough users wanting a feature that I took these two very features and effectively merged them into one. You may not get 'allow window overlap' functionality 'out of the box' (youll have to set something in gconf, oh no!) but it *is there* with my branch.

It is quite obvious you have yet to even try this new feature, because as I have stated *more than once* it actually supports the behavior you are so adamant to have restored. Stop arguing with me, the guy who is effectively on your side, and start convincing some of the other devs that my merge proposal is worth merging!

[Smintheu (smintheu)]

@ Robert: I would like to use your solution, but I can't seem to find out how. I've added the gnome-do repositories to apt-get and installed 0.8.2 that way on jaunty. Can you tell me how to integrate your solution, or to a page where I can RTFM?

Tnx!

[Robert Dyer (psybers)]

You would have to compile it from source.

At this point I would hold off. We will be releasing Docky 2 in a month (hopefully) and I have managed to get this support into that release. :-)

[ajfier (jabryl)]

I'm glad that the next version is coming out soon. Ubuntu 9.10 seems to have broken the patched version of Do that I've been using, so for now I'm stuck using AWN as my dock.

I hope that next time you guys think twice before you arbitrarily remove a popular feature.

[Jason Smith (jassmith)]

We thought about it for a long time actually. The decision was made for
the sake of keeping the number of options down. I don't want to have a
configuration UI that looks like Cairo Dock or AWN's. They are insanity
and its these kind of tough decisions that will keep it sane.

I am sorry you lost an important feature to you, I don't regret the
decision however and have already accepted that users with your
particular needs will not be suited to docky. I should mention that the
removal of that feature was to make room for the Intellihide feature,
which has been vastly more popular. I think it comes down to this: you
can have lots of features, you can have lots of stability, and you can
have it done quickly, but you can only have two.

Think of it another way. There are two types of options. Options that
interact with others, and options that dont. The latter group we can
basically have as many of as we want since QAing them is easy. The
former group we can have as many as we can reasonably QA. However there
are n-factorial possible combinations to test, which means that we are
reasonably limited to about 5 of those. We make choices.

With 5 we have to test 120 different combinations to *ensure* everything
works as we think it does, with 6 its 720, and with 7 it becomes
outrageous. Before you mention it, yes, we do try to make sure our code
all works properly with each other, but thats no substitute for real
testing.

On Fri, 2009-10-30 at 16:25 +0000, ajfier wrote:
> I'm glad that the next version is coming out soon. Ubuntu 9.10 seems to
> have broken the patched version of Do that I've been using, so for now
> I'm stuck using AWN as my dock.
>
> I hope that next time you guys think twice before you arbitrarily remove
> a popular feature.
>

[pelle.k (pele2)]

@ ajfier, i'm sorry but i haven't had the opportunity to package up a karmic version. Besides, docky 2 i due in a short while.

@ Jason Smith, is intellifade present in docky 2? Also, it's become quite clear that AllowWindowOverlap is not getting in the present docky, maybe this bug should be closed as WONTFIX?

[Jason Smith (jassmith)]

I am not saying no to restoring this yet. I think docky 2 as it matures
may show to be able to do this functionality in a method that doesn't
make me nervous about QA.

On Fri, 2009-10-30 at 21:17 +0000, pelle.k wrote:
> @ ajfier, i'm sorry but i haven't had the opportunity to package up a
> karmic version. Besides, docky 2 i due in a short while.
>
> @ Jason Smith, is intellifade present in docky 2? Also, it's become
> quite clear that AllowWindowOverlap is not getting in the present docky,
> maybe this bug should be closed as WONTFIX?
>

[Robert Dyer (psybers)]

Actually, this functionality is already possible in Docky 2 (similar to my docky1 intellifade branch). Just set the dock to intellihide, enable fade, and in gconf set the fade opacity to 1.

[ajfier (jabryl)]

@ pelle.k, don't sweat it, you've already done more to help with this than any of the developers have.

@ Jason Smith, I can appreciate the need for a straight forward and simple interface, but you really do need a viable alternative for people who don't want to use autohide. Intellihide isn't much better than regular autohide, and without the overlap feature I lose the bottom inch of my screen if I turn off autohide completly. With my wide screen monitor that's at least 10% of my screenspace. In other words, with autohide off the dock becomes an unusable eyesore.

Did you consider making overlap the default behavior?

[ajfier (jabryl)]

This is what I'm talking about.
This is even more unpleasant than autohide.

[Robert Dyer (psybers)]

"@ pelle.k, don't sweat it, you've already done more to help with this than any of the developers have."

@ajfier: Have you not been paying attention at all? I have written a viable solution that PROVIDES THE FUNCTIONALITY YOU WANT and managed to get it included in Docky 2. Stop complaining, your problem is already solved!

Why don't you stop attacking us devs and just be grateful for such an awesome product. It is users like you that really make open source devs question the time commitment they put into a project such as this!

[ajfier (jabryl)]

@Robert Dyer, Your solution requires editing an obscure setting in the configuration editor. I can live with that, but it's not ideal.

Incidentally you've done nothing but belittle my opinion since I came here. You've implied that a feature that I use everyday was so unimportant that it needed to be removed, and you've repeatedly insisted that intellihide is better despite the fact that it doesn't provide the same functionality.

Take my advice and stop trying to interact with the users. You just not very good at it.
The least you could do is stop trying to interact with me.

[Robert Dyer (psybers)]

I would be more than ecstatic to stop interacting with you. Please stop posting to the project's bug reporting system.

[lifestream (lifestream)]

Arg! Please, please stop the personal attacks, it's annoying and not helpful...
I think there is a lot of misunderstanding. Let me try to explain, and please, please, please read all of the post.

Problem:-------------------------------------------------------------------
We cannot maximize a window to use the ENTIRE screen space, AND have Docky ALWAYS, always, on top.
We used to be able to do that. If devs don't want that feature anymore, that's okay. However, you keep stating that the feature works.
------------------------------------------------------------------------------

To me, it seems we have 4 options regarding hidding the dock:
=None
=Intelihide
=Autohide
=Defenestraphobia

BUT here is what happens when we select them:
=None:
    Docky stays on top BUT makes one inch of the screen completely unusable. CANNOT maximize window over all screen space.
http://i37.tinypic.com/2qxow88.jpg

=intelihide:
     Docky hides when mouse isn't on bottom of screen. CAN maximize windows to all screen space.
=Autohide
     Docky hides when mouse isn't on bottom of screen. CAN maximize windows to all screen space.
=Defenestraphobia
     Docky hides when mouse isn't on bottom of screen. CAN maximize windows to all screen space.

Those 3 hiding options work all the same to me. O_o?
I want the docky always-on-top, even when the mouse isn't at the bottom of the screen, and I want the window to be completely maximized. Docky used to do this. There isn't an option in gconf-editor to make it so.

Intelihide doesn't do this either.

I hope this doesn't sound "agressive", I just want to clarify the misunderstanding ^_^;;

[lifestream (lifestream)]

=intelihide:
     Docky hides when mouse isn't on bottom of screen. CAN maximize windows to all screen space, but if we do, the Docky disappears.

Fixed that part, sorry.
Basically we want the Docky visible, even if the window is maximized.

[Robert Dyer (psybers)]

What you (and others) still fail to realize is the following:

1) my docky branch (mentioned in the comments above) *PROVIDES THIS FUNCTIONALITY*!

2) docky 2, which will be replacing docky 1 (the gnome do theme you know and love) *PROVIDES THIS FUNCTIONALITY*!

Do you have to edit a gconf key to get it? Yes! Is that going to change? No! You have what you want, please stop posting here asking us to implement something we have already spent time and effort to do!

[Robert Dyer (psybers)]

Because I feel almost like you guys think I am a liar or something... here is an image showing you the functionality you keep asking for.

Keep in mind this image is Docky 2 (because docky 1 is going bye bye real soon), but all I had to do was change 1 gconf key and voila.

[lifestream (lifestream)]

Not calling anyone a liar, just stating a problem and I the posters above seem to have.
I'm sure I'm speaking for all who posted above, that we really do appreciate the work the devs put into this amazing Do and Docky. It's been a joy to use since they came out.

I am running:
Docky 2.0.0-Alpha-1
docky-2.0~bzr531

That's Docky 2, right?
I didn't have that AllowWindowOverlap in /apps/gnome-do/preferences/Docky/Utilities/DockPreference nor any other place Gnome-Do or Docky are mentioned. So I added it with a boolean value of true.

That's not much work at all, it's not a bother at all!

But the problem is, the Docky (or Gnome-Do, whichever I run) *still* doesn't show the Dock above all windows.
Intelihide + Fade, right?

I didn't think you were a liar at all, I'm just trying to figure this weird problem out.

[lifestream (lifestream)]

AllowWindowOverlap + None (no hidden) also doesn't work.

[pelle.k (pele2)]

@lifestream
With intellifade, the dock is supposed to fade away. Now, if you set the "fade opacity" key in gconf-editor to say 0.7, the dock is going to fade from 100% to 70% visibility instead of disappearing. clever huh? ;)
Oh, and thanks again Robert. You are our hero. :D

[lifestream (lifestream)]

*gasp!* It works!

Had to quit and restart the Docky2 a few times, but that worked, pelle.k!
Fantastic! Thanks *so* much, both of you!

Not messing with it anymore, that's for sure :P

[lifestream (lifestream)]

Just had to set the opacity ^_^