ede-launch now will read Terminal key, and if set to true, will load default selected terminal (or one of known terminals). It will also read now StartupNotify key, and initiate startup-notification protocol if compiled in; by default, it will not use startup notifications.
Resource loading is now made lazy, so first need for ede-launch configuration will load it from file.
When user hit shutdown or restart from dialog, evoke will immediately sent shutdown/restart signal, causing abnormal X termination, killing all childs. With this commit, evoke will first close all X childs, then send shutdown/restart signal.
Hider calls some Panel specific code and doing that from applet will make shit like selinux or apparmor quite unhappy (due relocations), which will refuse to start ede-panel. ...yet another workaround for that crapy security junk.
In startede sysresources are refering to older X11R6 (now is X11R7). Also as reported, on some systems the path '/usr/X11' is used too. Solving by removing resource usage at all; not seeing any usefulness of it...
When tray icon gets destroyed, space it was occupying would not be cleaned, yielding wholes inside taskbar. Fixing by explicitly hiding and deleting FLTK window which holded application tray window.
By default, pekwm will reorder window list on input focus (probably to optimize things) and this would also reorder buttons inside taskbar. Also, on new window list, all panel buttons would be recreated again, causing many allocations and deallocations. Now, window list received from wm is compared agains internal window storage for diffs.
Fixing this issue made removal some old edewm specific code and made panel nicely working under sawfish ;)
When user logout or shutdown the system, a warning dialog was showing about wrong DBus reply. Now are used
ConsoleKit commands 'CanStop' and 'CanRestart' to check can user perform the action.
When issue gets update, reporter can receive mail notifications, but has to have bugzilla account first. The later could not be avoided. Implements #201.
Menu reload is using DirWatch to monitor application menu folders for changes. With this, any change on some content will trigger
menu update. Update is trying to be safe as possible: when menu is open, a backup menu will be constructed and replaced as soon as menu
was closed; when is closed, it will be directly replaced.
This still can include races, but I'm hoping they will not occur.
Related to memory leaks: on couple of places in cpu applet, delete was wronly called instead delete[]. Also, when ede-panel exits,
AppletManager would not clean loaded apples. Strange. So now explicit clear was added on exit.
