Release Hotfix 6 Final released!


I selected the 'show window manager selection menu' boot option (or something to that effect), but if I select the mini version it'll pop up the login window (I had selected automatic login), ask for the password, then cycle back to the window manager selection. I have to always select xfce4, which works, and from there I can successfully change to minimenu. Seems to be some quirk there.
 
Wow, that's complicated stuff.


So we have like 5 instances of menu and no processes? Would be nice to see ps aux with and without multiple menus. (Can't see it on my Pandora - no screen)


I also wonder if xfce uses dbus, maybe if it does we could kick the menu via dbus.
 
Last edited by a moderator:
For people who had problems running PNDs or launching minimenu after the update: what version of the firmware did you have?

I had the official HF5, never tried any of the HF6 betas/rcs.

I've found that those problems are because of version 1.0-r58.5 of the pandora-scripts package, that includes some files that it should not have included and conflicts with the new version of pandora-libpnd. That version is installed at least in HF5rc2.


If you had that problem, but you can run xfce it is quite easy to solve the problem with no need to do a full flash.


[...snip...]

Yup, that fixed all my problems for me, thanks.


Now I just need a way to get the newer menu launchers/etc. :)
 
when I updated I from the last version of HF5 I noticed that the additional option to chose what environment you want upon boot wasnt there, also my wifi toggle doesnt work I really dont want to flash from fresh as I did some udev stuff for my mobile broadband dongle.
 
EvilDragon:


Maybe you can execute a script, that writes the status of the menu into a file when it is launched. Then it waits 20 seconds and removes the status. If you try to open another menu wile the 20 seconds aren't over, the same script can beforehand check, if this timespan has expired and if not, it doesn't launch the menu.


Not the cleanest solution, but with that you can make sure the menu isn't opened twice accidentally.


Edit: of course you would have to reset that flag on shutdown.
 
Last edited by a moderator:
Maybe you can execute a script, that writes the status of the menu into a file when it is launched. Then it waits 20 seconds and removes the status.
And if you accidentally close the menu you have to wait for 20 seconds before you can open it again. There doesn't seem to be a really clean solution for this issue, strangely enough.


So far opening double menus seems to be the best one so far (assuming it is in the bottom left is bound to piss off several users). Perhaps we should put in a "close menu" application which does absolutely nothing (selecting anything in the menu would always close it).


My mistake, I assumed that the code assumed that the button was in the bottom left, but it seems to be aware of the actual location of the menu button. So this is actually a better solution.
 
Last edited by a moderator:
Instead of checking to see if the menu is open or not, how about a script that gets the mouse position, moves the mouse to the menu and forces a click, then moves the mouse back?
 
Instead of checking to see if the menu is open or not, how about a script that gets the mouse position, moves the mouse to the menu and forces a click, then moves the mouse back?

That's what it's doing right now...


I have a strange, somewhat related question: I was recently playing with stuckie's Debian on SD card, so I have my card formatted into two partitions. I realize, however, that the instructions for re-flashing the FW from scratch say to extract the image to the SD card's root.


I'm guessing it assumes that the files are all on the first partition. So what would need to be changed (boot.scr?) and how to get it to reflash from a different partition?


I suppose I could reorder the partitions, but it seems like there should be a better way.
 
@tonsofquestions: Ah, sorry, I don't read well enough yet. I just assumed since everyone was making a fuss about it that it was leaving the mouse in the bottom left. Is the time between moving the mouse to the menu and back a lot? Like half a second?
 
May i can post my dmsg log tomorow ewening?? there are a lot Lets Play Videos on Youtube (minecraft, sims 3, maxpayne 2) from gronkh, and i worked today until 18 Hour mid european time..,
 
I'm guessing it assumes that the files are all on the first partition. So what would need to be changed (boot.scr?) and how to get it to reflash from a different partition?
At the time I wrote some of those updater scripts they were looking at first 2 partitions, don't know if that still works though.
 
The menu can be opened by commandline. I did this to launch it with wbar. Maybe the Pandorabutton could just execute this command. Or do you already do it this way?
That's what was used before, but if you enter the command 5 times, five instances of the menu open. How can I tell the menu via the command line to only open if it's NOT yet opened and to close if it IS currently opened?

It's even clicking in the right place when the panel is hidden...it just takes too long for the panel to rise before the click. If you add a short delay (I used 'sleep 0.2') between the first mousemove and the click, it works even with a hidden panel. Of course, a longer delay is more reliable, but also more irritating. The 0.2 second delay is nothing - but it may not work if you're lagging when you hit the button.


Edit: For those wanting to know, the script is '/usr/pandora/scripts/op_xfcemenu.sh'.


It needs root priviledges, so Alt+F2 and 'gksudo mousepad /usr/pandora/scripts/op_xfcemenu.sh'. I saved a .bak backup before resaving as .sh and editing.


Here's what it looks like:



Code:
#!/bin/bash

POSMENU=`DISPLAY=:0.0 xwininfo -name xfce4-menu-plugin | egrep 'Absolute upper-left X|Absolute upper-left Y' | awk '{print $4}'`

Xold=`DISPLAY=:0.0 xdotool getmouselocation | awk  '{print $1}' | sed 's/^..//'`

Yold=`DISPLAY=:0.0 xdotool getmouselocation | awk  '{print $2}' | sed 's/^..//'`

Xnew=`echo $POSMENU|awk '{print $1}'`

Ynew=`echo $POSMENU|awk '{print $2}'`

DISPLAY=:0.0 xdotool mousemove $Xnew $Ynew

sleep 0.2

DISPLAY=:0.0 xdotool click 1

DISPLAY=:0.0 xdotool mousemove $Xold $Yold


All I did was add that 'sleep 0.2' line.
 
Last edited by a moderator:
@tonsofquestions: Ah, sorry, I don't read well enough yet. I just assumed since everyone was making a fuss about it that it was leaving the mouse in the bottom left. Is the time between moving the mouse to the menu and back a lot? Like half a second?

Yeah, it's about that. Possibly a bit longer. But the bigger problem, as mentioned by others is if the panel isn't there (moved to a different part of the screen), or if it autohides - doesn't come back fast enough. Plus it's rather distracting, IMHO. I'm amazed there's no way to tell if it's open, but I'm not too familar with the structure of XFCE.

I'm guessing it assumes that the files are all on the first partition. So what would need to be changed (boot.scr?) and how to get it to reflash from a different partition?
At the time I wrote some of those updater scripts they were looking at first 2 partitions, don't know if that still works though.

OK, thanks. Good to know. I think I have 3, so rearranging it is. I also happened to notice today that inserting it into a Windows computer only recognized the first (non-FAT) parition, so it must be a sign.
 
But the bigger problem, as mentioned by others is if the panel isn't there (moved to a different part of the screen), or if it autohides - doesn't come back fast enough. Plus it's rather distracting, IMHO. I'm amazed there's no way to tell if it's open, but I'm not too familar with the structure of XFCE.

When it autohides, it just slides to the edge of the screen. There's basically still one pixel of it showing, whichever side of the screen you put it on. ED's script actually finds the menu button on your panel and clicks it using xwininfo and xdotool.


It's especially funny that you can find the exact position of the plugin on the screen, but not kill the menu it spawns as a seperate process. The menu is spawned by the panel plugin, so the root program running it is xfce4-panel. It's no different than the File Menu on the menubar of any other app, except with the panel what's there is customizable. But the menu it spawns is part of the panel.


The command 'xfce-popup-menu' does basically the same thing as ED's script, without moving the mouse - but it has that issue where it allows more than one instance. If the xfce people fix that, it'll be a better option.
 
Maybe you can execute a script, that writes the status of the menu into a file when it is launched. Then it waits 20 seconds and removes the status.
And if you accidentally close the menu you have to wait for 20 seconds before you can open it again. There doesn't seem to be a really clean solution for this issue, strangely enough.
What about something as simple as writing a file when the menu is opened, and removing that file when it's closed. If the file's there, don't open another menu. To address the possibility the menu is exited uncleanly and leaves the file there (like if the Pandora crashes etc) then check for the existence of the file when the system boots and remove it if it's still there.


Too noob?
 
What about something as simple as writing a file when the menu is opened, and removing that file when it's closed. If the file's there, don't open another menu. To address the possibility the menu is exited uncleanly and leaves the file there (like if the Pandora crashes etc) then check for the existence of the file when the system boots and remove it if it's still there.


Too noob?
To write a file when it is closed you need to detect when it is closed. That is exactly the problem, there does not seem to be a simple way to do that.
 
I'm curious what's next for the Pandora OS - I remember you (ED) mentioned it would be a full version and not a hotfix, but do you know of details, yet?
 
Back
Top