Detect panel position

[GoogleCodeExporter]

When the applet is in a panel positioned at the top of the screen,
directory headers are placed conveniently at the top each sub-menu.
However, if the panel is positioned at the bottom of the screen, this
placement is not so convenient. Could the order Header - Folders - Files be
reversed when the panel is at the bottom?

Original issue reported on code.google.com by james.r....@gmail.com on 26 Dec 2008 at 2:31

[GoogleCodeExporter]

And you'd also have to sort the entries in reverse.

Maybe to this one, it could possibly make sense. It could get complicated 
though:
What should we do when the panel is vertical? The right thing to do would be to 
check
how far up/down the applet is on the panel and change the behaviour 
accordingly. That
might confuse and annoy people.

Needs further thought.
a.

Original comment by bertol...@gmail.com on 27 Dec 2008 at 3:39

• Added labels: Type-Enhancement, Priority-Low
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

If auto-detection is awkward, a simple option in the preferences would suffice. 

> And you'd also have to sort the entries in reverse.
I'm not sure what you mean - alphabetical sorting is fine for me. I'd just want 
the
group ordering reversed, not the individual entry ordering.

Original comment by james.r....@gmail.com on 28 Dec 2008 at 9:33

[GoogleCodeExporter]

I'm not sure that makes sense; it would not be consistent (some items 
re-arranged,
others not). I think the menu would basically have to be mirrored: header 
first, then
dirs sorted ascending as you move up, then files.

This should be easy to implement. I'll add it and see how it feels.

Original comment by bertol...@gmail.com on 5 Jan 2009 at 12:26

• Changed state: Started

[GoogleCodeExporter]

Naw, it's not going to work. Just implemented it and notices one thing that's 
going
to make it less usable: when a sub menu is popped up, it's located such that 
the top
entry in the sub menu aligns with the menu item that owned the submenu. When the
entries in the sub menu are reversed, we really want the last entry in the sub 
menu
to align with the parent menu item.

See the attached screenshot.

For this to work we'd have to reposition the submenu.

Original comment by bertol...@gmail.com on 5 Jan 2009 at 12:39

Attachments:

• Screenshot.png

[GoogleCodeExporter]

A Debian user has requested this as well. See: http://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=557510

Original comment by A.Star...@gmail.com on 22 Nov 2009 at 5:49

[GoogleCodeExporter]

Fine! I'll look at this again...

Original comment by bertol...@gmail.com on 23 Nov 2009 at 4:14

[GoogleCodeExporter]

So, I started implementing this (again)... Still doesn't feel right.

On the one hand, it makes sense intuitively (I think) the the whole menu 
ordering and
placement is basically mirrored when the applet moves from the top of the 
screen to
the bottom. On the other hand, no other panel applets that have menus do this 
(main
menu bar, FUSA, applet context menus), so it creates an inconsistency.

Thoughts, anyone?

Original comment by bertol...@gmail.com on 25 Nov 2009 at 4:09

[GoogleCodeExporter]

Hi, I am the Debian user that A.Starr.B talked about.

Actually I think the way it is now is inconsistent with the rest of the 
interface.

Bare with me with the description, gnome-screenshot does not work when I have a 
menu 
open(?):
Lets say I have an 100 file list, and my screen only lets me see 50 files at a 
time.
-When I put the applet on a top panel, I get shown files 1 to 50 and have to 
scroll 
down to see 51+
-When I put the applet on a lower panel, I see files 51 to 100 and have to 
scroll up 
to see 50-

This is a problem which does not happen with the drawer applet (for example), 
which 
always shows the top icons first.

I don't think the menus should be mirrored to the bottom, only the above fixed. 
But 
of course, that's my personal opinion. 

Other than this bug, its a great applet and very useful.

Original comment by ped...@gmail.com on 25 Nov 2009 at 4:58

[GoogleCodeExporter]

Hi there,

I believe I understand what you're describing, and it's a different bug than the
original. 

In any case, I don't see that behaviour here :-( See screenshots. Do you have a
custom .gtkrc file? Sometimes this causes problems. Maybe you could attach your
.gtkrc so I can see if it is causing the problem.

Thanks.

As for the original problem, I'm still undecided what the right thing to do 
is...

Original comment by bertol...@gmail.com on 25 Nov 2009 at 5:12

Attachments:

• Bottom.png
• Top.png

[GoogleCodeExporter]

Hi,

I just noticed that if I set the root browser folder to one with few items like 
you 
have the bug does not happen for the next folders. But if you try setting the 
big 
folder as the root browser folder the bug will appear. 

Original comment by ped...@gmail.com on 25 Nov 2009 at 7:40

[GoogleCodeExporter]

Aha! I know the cause of the problem now. Unfortunately fixing it causes other
problems when the root menu is first opened :-(

Original comment by bertol...@gmail.com on 25 Nov 2009 at 10:53

[GoogleCodeExporter]

So... The problem described by pedrib... the fundamental cause of the problem 
is that
because the menus are populated dynamically, when the root menu is popped up 
for the
first time it is empty and thus it's size and placement are not quite right. To
correct this I was calling gtk_menu_reposition after populating the menu, which
worked fine when the panel was at the top, but caused the problem you described 
when
it's at the bottom.

The fix is top populate the root menu when the menu-browser object is created 
(long
before the menu is activated). This has a potential side effect that if you 
have a
root menu watching a dir with a lot of files, the app will be slow to startup.

Comments? Thoughts?

Fix is in svn, but I won't close this bug report as this issue as is not 
related to
the original bug report.

Original comment by bertol...@gmail.com on 4 Dec 2009 at 5:23

[GoogleCodeExporter]

Issue described by pedrib is Fixed in release 0.6.5.

Original comment by bertol...@gmail.com on 21 Dec 2009 at 5:47

[GoogleCodeExporter]

Thank you!

When you say that the app is slow to startup, is that always or just on the 
first run? 
Because if it is the latter, it doesn't really matter!

Original comment by ped...@gmail.com on 21 Dec 2009 at 5:50

[GoogleCodeExporter]

Hey,

I mean when the applet is loaded. So, basically every time you log in, or when 
you
kill/restart the applet if you're hacking on it, which I hope you are ;-)

This will only be a problem if you have a folder with a lot of large files (or 
your
disk is exceptionally slow). otherwise you won't notice it.

To be clear though, the latency/blocking when doing IO problem is still there 
(issue
52), so the delay/blocking will be there every time you open that folder 
(again, only
noticeable for folders with a lot of files).

a.

Original comment by bertol...@gmail.com on 21 Dec 2009 at 5:59