Bug 188311 - The applet panel should not overlap applets
Summary: The applet panel should not overlap applets
Status: RESOLVED FIXED
Alias: None
Product: amarok
Classification: Applications
Component: Context View (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
: 174221 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-03-28 11:35 UTC by mangus
Modified: 2009-06-02 10:45 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
amarok-svn toolbar overlap (123.44 KB, image/png)
2009-03-29 19:39 UTC, mangus
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mangus 2009-03-28 11:35:10 UTC
Version:           svn (using Devel)
OS:                Linux
Installed from:    Compiled sources

In amarok2-svn I like the the new contextview , but I found the new bottom bar for managing applets annoying , as it covers parts of other applets sometimes , like lyrics one , so that you miss a part of it. Could be handy to have it appear and desappear onmouseover.
thanks
Comment 1 Dan Meltzer 2009-03-28 14:53:55 UTC
The real solution is to make it not cover applets, not make it appear/disappear on mouse over.
Comment 2 Leo Franchi 2009-03-29 14:34:53 UTC
i dont understand your point, dan... how do we make it not cover applets?
Comment 3 Dan Meltzer 2009-03-29 16:32:22 UTC
Thats your problem to solve :)

The toolbar should be like the panel in kde, it gets it's own area to draw in (a strut in window manager terms).  The applets should not consider the space the toolbar takes up to be theirs to play in, but rather end at the top of it.
Comment 4 Leo Franchi 2009-03-29 17:26:09 UTC
well if i move a window on my desktop down, the panel does cover it. so i still don't understand...
Comment 5 Dan Meltzer 2009-03-29 18:19:23 UTC
right, but new windows placed on the desktop do not get placed under the panel, and maximizing windows doesn't put them under the panel either.  You need to explicitely place the window under the panel, and I considder it a bug that it's possible (but that's not what this debate is about).]

The panel should not obfuscate applets by default.
Comment 6 Mark Kretschmann 2009-03-29 18:53:15 UTC
I fully agree with Dan here, and I also fully admit that I don't have the slightest clue on how to implement this technically :)

But I really think that what he wrote makes a lot of sense, if feasible.
Comment 7 mangus 2009-03-29 19:39:03 UTC
Created attachment 32462 [details]
amarok-svn toolbar overlap
Comment 8 mangus 2009-03-29 19:39:39 UTC
Me and Dan are meaning this.. a screen is better then words sometimes :-)
Comment 9 Leo Franchi 2009-03-29 19:44:35 UTC
i know what it looks like, 've been staring at it all day. btw, that screenshot is outdated now :)

i still don't see how else you guys plan to visualize it. do you just want a border for the applet area, so instead of hitting the panel directly, it ends at the border? i mean, applets *will* be logically under the location of the panel---all the applets that a user can  have will not fit on the screen at the same time---so how else to show it?
Comment 10 Dan Meltzer 2009-03-29 19:50:43 UTC
The applet should end where the toolbar begins.  Applets should not be larger than the viewable area, if there's an applet above it, then the lower applet should get a smaller sizehint, and resize if necessary when it's the active applet (and therefore the only one on the screen)

Basically, no applet should continue on off the screen, it should end at the panel.
Comment 11 Leo Franchi 2009-03-29 19:58:27 UTC
i disagree :) what you are describing is a very different use-case of the CV in general, and distinctly different from what the original idea that was developed. in fact, i think there is another bug where we've already had this discussion (with mark), and this has come up on IRC. anyway, this is not something to be fixed, but rather a change that needs to be discussed with people like e.g. leinir.

regardless of all of this, the problem of "applets falling off the end of the screen" should be mitigated when we are able to resize applets.
Comment 12 Dan Meltzer 2009-03-29 20:48:48 UTC
You can't tell me that the screenshot attached to this bug is intended.  There is no way to see the final line or two in the lyrics applet.  This is a major bug.
Comment 13 Dan Leinir Turthra Jensen 2009-03-30 17:30:19 UTC
The bug that is being shown here is the fact that you cannot yet resize your applets, and as such we also don't set default sizes sanely. You are reporting a bug on a non-completed feature ;)
Comment 14 mangus 2009-03-30 19:10:07 UTC
infact it was a wish! ;-)
Comment 15 Dan Leinir Turthra Jensen 2009-03-30 20:04:58 UTC
Of course :) Just thought i should point out that the feature is not yet completed - the polish that's gone into it lately could seem like an indication of feature completion, and as such it would seem the prudent course to inform you that that is not the case :)
Comment 16 Dan Meltzer 2009-03-31 00:33:48 UTC
I don't think that this should be dependent on being able to resize freely at all...
Most of the time, the sizegrip for resizing ends up in the bottom right corner, and as such, would be inaccessable reguardless of whether it was free sizing or not.

The bug isn't that the applet can't be made smaller, but that part of the applet is completely inaccesible.
Comment 17 Kevin Funk 2009-03-31 15:56:48 UTC
I fully agree with Dan aswell. I don't understand the confusion as it doesnt matter at all if an applet is resizable or not.
To quote Dan:
"The applet should end where the toolbar begins.  Applets should not be larger
than the viewable area, if there's an applet above it, then the lower applet
should get a smaller sizehint, and resize if necessary when it's the active
applet (and therefore the only one on the screen)"

That's the expected behaviour and what is used in the playlist aswell. Track items dont overlap the lower toolbar, do they?
Comment 18 Dan Meltzer 2009-05-17 17:22:44 UTC
*** Bug 174221 has been marked as a duplicate of this bug. ***
Comment 19 Leo Franchi 2009-05-18 01:02:22 UTC
will be fixed in 2.1.1, done locally.
Comment 20 mangus 2009-06-02 10:34:10 UTC
I found it probably fixed in trunk :-) can Leo confirm that? we could close this....
Comment 21 Leo Franchi 2009-06-02 10:45:41 UTC
yep, sorry forgot to close when i pushed.