After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 591779 - Docking doesn't make it go away entirely, wasting screen space
Docking doesn't make it go away entirely, wasting screen space
Status: RESOLVED DUPLICATE of bug 588491
Product: gdl
Classification: Other
Component: general
CVS HEAD
Other Linux
: Normal enhancement
: ---
Assigned To: Anjuta maintainers
Anjuta maintainers
Depends on:
Blocks:
 
 
Reported: 2009-08-14 08:29 UTC by Philip Van Hoof
Modified: 2012-07-30 20:07 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Philip Van Hoof 2009-08-14 08:29:37 UTC
Docking in Anjuta using the [<] button still creates an area at the far left (for the left pane) that consumes the width of a button. That area never disappears, thus consume the same space that you wanted to regain my docking it.

In Visual Studio .NET they solved this by, like how that start-bar of Windows can auto-hide, auto-hide this clickable area and letting it appear as soon as you mouse-over it or when you press one of the acceleration keys.

It's also not possible to dock the entire left area. I have to dock the panes one by one.

And esthetically it would be nicer if this wouldn't immediately get docked but instead if it would slide at a slower speed (in an animated way). But maybe that's just because I got addicted to VS.NET ;-)
Comment 1 Naba Kumar 2010-02-18 15:43:17 UTC
(In reply to comment #0)
> Docking in Anjuta using the [<] button still creates an area at the far left
> (for the left pane) that consumes the width of a button. That area never
> disappears, thus consume the same space that you wanted to regain my docking
> it.
> 
The button area is much smaller then the actual panes, hence there is space gain.

> In Visual Studio .NET they solved this by, like how that start-bar of Windows
> can auto-hide, auto-hide this clickable area and letting it appear as soon as
> you mouse-over it or when you press one of the acceleration keys.
> 
If the sidebar is hidden where do you mouse-over to gain it? Just "crossing the boundary"? I think there is not a lot of gain here and costs us potential issue that users is not aware there is sidepane where he can restore his panes.

> It's also not possible to dock the entire left area. I have to dock the panes
> one by one.
> 
This is fixed in gdl branch "minimize-all" http://git.gnome.org/browse/gdl/log/?h=minimize-all. I will merge it once gdl 2.30 is released.

> And esthetically it would be nicer if this wouldn't immediately get docked but
> instead if it would slide at a slower speed (in an animated way). But maybe
> that's just because I got addicted to VS.NET ;-)

That's actually a tough bit to solve. When we animate it slowly sliding the pane, it will trigger a lot of resize requests and resize the contents as well (some may even fail to resize). I believe it has to be handled at much lower level (like actually animating the window picture or something). Do you have any better idea?
Comment 2 Philip Van Hoof 2010-02-18 15:52:03 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > Docking in Anjuta using the [<] button still creates an area at the far left
> > (for the left pane) that consumes the width of a button. That area never
> > disappears, thus consume the same space that you wanted to regain my docking
> > it.
 
> The button area is much smaller then the actual panes, hence there is space
> gain.

Tell that to people with small screens :)

> > In Visual Studio .NET they solved this by, like how that start-bar of Windows
> > can auto-hide, auto-hide this clickable area and letting it appear as soon as
> > you mouse-over it or when you press one of the acceleration keys.
> > 
> If the sidebar is hidden where do you mouse-over to gain it? Just "crossing the
> boundary"? I think there is not a lot of gain here and costs us potential issue
> that users is not aware there is sidepane where he can restore his panes.

Can't we expect from a software developer who has set this behaviour (for example in a preference) to know where his side-panes went to?

Hmm, not sure.
 
> > It's also not possible to dock the entire left area. I have to dock the panes
> > one by one.
> > 
> This is fixed in gdl branch "minimize-all"
> http://git.gnome.org/browse/gdl/log/?h=minimize-all. I will merge it once gdl
> 2.30 is released.
> 
> > And esthetically it would be nicer if this wouldn't immediately get docked but
> > instead if it would slide at a slower speed (in an animated way). But maybe
> > that's just because I got addicted to VS.NET ;-)
> 
> That's actually a tough bit to solve. When we animate it slowly sliding the
> pane, it will trigger a lot of resize requests and resize the contents as well
> (some may even fail to resize). I believe it has to be handled at much lower
> level (like actually animating the window picture or something). Do you have
> any better idea?

But I want ponies! :(

;-)
Comment 3 Naba Kumar 2010-02-23 11:06:09 UTC
This is gdl bug, moving so.
Comment 4 Sébastien Granjoux 2012-07-30 20:07:39 UTC
Now that the minimized all is implemented. I think this bug is a duplicate of the bug #588491.

I have seen such auto hide pane in several docking interface. I don't know how to do this so I think it will not be for this cycle.

*** This bug has been marked as a duplicate of bug 588491 ***