Reply
Thread Tools
Bec's Avatar
Posts: 876 | Thanked: 396 times | Joined on Dec 2009
#51
I've set it to <NotOnlyUnallocated/> since only unallocated was duplicating the icons I chose. The icons selected for the new folder were kept in "more..." aswell.

However I do not see why my first attempts got the menu stuck...
Could it be because:

1) the main menu does not allow more than 15 items? <- tested, the main menu does allow 15+
2) empty lines between the main menu and new folders have to be removed in “hildon.menu”?
3)what is the relevance of "bb_apps", does the name of the new *.directory matter?

Last edited by Bec; 2010-01-09 at 13:59.
 
Posts: 18 | Thanked: 14 times | Joined on Jan 2010
#52
Originally Posted by Bec View Post
I've set it to <NotOnlyUnallocated/> since only unallocated was duplicating the icons I chose. The icons selected for the new folder were kept in "more..." aswell.

However I do not see why my first attempts got the menu stuck...
Could it be because:

1) the main menu does not allow more than 15 items?
2) empty lines between the main menu and new folders have to be removed in “hildon.menu”?
3)what is the relevance of "bb_apps", does the name of the new *.directory matter?
The first sentence sounds strange for me because in my case I have not had duplicates... BTW:
http://standards.freedesktop.org/men...t/ar01s04.html
Each <Menu> may contain any number of <OnlyUnallocated> and <NotOnlyUnallocated> elements. Only the last such element to appear is relevant, as it determines whether the <Menu> can contain any desktop entries, or only those desktop entries that do not match other menus. If neither <OnlyUnallocated> nor <NotOnlyUnallocated> elements are present, the default is <NotOnlyUnallocated>.
It looks like the GUI (or whatever... ) is buggy because it looks for me that there is a new code bounded to caching for maemo. I've got my menu stuck right after I did last manipulations with it and did update the icons cache... I did roll-back all changes and then started from the beginning adding those one by one. Now it is working with exactly the same configuration as it stuck with.
 
Bec's Avatar
Posts: 876 | Thanked: 396 times | Joined on Dec 2009
#53
http://zehjotkah.blogspot.com/2010/0...-for-n900.html

Here's a nice tool for managing the menu, although I don't dare try it until I undo the modifications since it seems to work automatcally.

I think this should somehow be reported as a bug.
Also I noticed two more things:
-if the menu is broken, it won't update until you reboot... and it will brake
-if the menu is setup correctly it will automatically update and work correctly with no reboot required.

P.S. I do my dirty work via OpenSSH
 
Posts: 18 | Thanked: 14 times | Joined on Jan 2010
#54
BTW... A thread in regards to MyMenu: http://talk.maemo.org/showthread.php?t=39141
 
Posts: 42 | Thanked: 75 times | Joined on Jan 2010
#55
Mhh, seems like the new OS update (1.2009.44-1.203.4) modified this mechanism... any change to hildon.menu now is simply not reflected in real-time, regardless of correctness; a reboot is always required.
Bit of a pain, but slightly more bulletproof, I guess (makes it harder to mess up the phone, you always have a chance to rollback changes).
 
Posts: 293 | Thanked: 76 times | Joined on Jan 2008 @ Fremantle, W. Australia
#56
Originally Posted by toyg View Post
a reboot is always required
I doubt that. This is Unix,not Windows. Just restart the appropriate process, or better 'kill -HUP' to signal it to reload config files, if it has been written properly.
 
Posts: 336 | Thanked: 610 times | Joined on Apr 2008 @ France
#57
Originally Posted by myk View Post
I doubt that. This is Unix,not Windows. Just restart the appropriate process, or better 'kill -HUP' to signal it to reload config files, if it has been written properly.
Even when the binaries have changed? Right.
 
Posts: 293 | Thanked: 76 times | Joined on Jan 2008 @ Fremantle, W. Australia
#58
Originally Posted by CrashandDie View Post
Even when the binaries have changed? Right.
Huh? If I understand correctly, he is talking about editing an ascii (XML) config file, and rebooting to make config changes take effect. What are _you_ talking about?
 
Bec's Avatar
Posts: 876 | Thanked: 396 times | Joined on Dec 2009
#59
hookjford
Possible workaround: Lets say we want to have two shortcuts to the Phone
program. We go to /usr/share/applications/hildon and make a copy of the
rtcom-call-ui.desktop and call it rtcom-call-ui-2.desktop. Now we can add two
shortcuts. To avoid having another Phone shortcut in "More..." we can go to
/etc/xdg/menus/hildon.menu and add
<Exclude><Filename>rtcom-call-ui-2.desktop</Filename></Exclude> in the
Application menu, which is the "More.." so far haven't experienced any other
side effects, not sure if this causes issues with uninstallable programs.
It works, but don't move the shortcuts you want to get rid of from "more..." since if you exclude them in another folder they'll show up in more.
__________________
 
Posts: 1,224 | Thanked: 1,763 times | Joined on Jul 2007
#60
Originally Posted by toyg View Post
Mhh, seems like the new OS update (1.2009.44-1.203.4) modified this mechanism... any change to hildon.menu now is simply not reflected in real-time, regardless of correctness; a reboot is always required.
Bit of a pain, but slightly more bulletproof, I guess (makes it harder to mess up the phone, you always have a chance to rollback changes).
It does not make sense - all the menu displaying/reading/rereading is done in the binary hildon-desktop.launch from the package hildon-dekstop, and this package was not upgraded. I still see the same behaviour of menu changing immediately after editing menu.hildon file.
 

The Following User Says Thank You to Matan For This Useful Post:
Reply


 
Forum Jump


All times are GMT. The time now is 18:50.