Just some thoughts...
1. The menu doesn't seem to update. Since Fluxbox does not support dynamic menus, and fluxbox-generate_menu doesn't work too well, I would suggest including only a few essential applications and options in the default menu, and instead relying on dmenu to launch stuff. This isn't as straightforward as using the Fluxbox menu, but should not be much more difficult for experienced Windows users (who have similar software) let alone experienced Linux users.
2. There's no battery monitor by default, which is not so great for laptop users. Conky is not ideal, but I think it should do the trick.
3. The suspend and hibernate menu entries should probably use sudo instead of sending a dbus message to HAL. Using sudo is a dirty hack, but it's guaranteed to work once the switch to upower comes along, and sending dbus messages from the command line is in my experience not guaranteed to work at all.
4. Finally, just IMO, menu options for suspend and hibernate should lock the screen first by default. This is easy, you just add "xscreensaver-command -lock &" before the command that invokes suspend.
... I think that's all I've got for now. What do you think? Any other ideas?
Suggestions for the next Salix Fluxbox version
Re: Suggestions for the next Salix Fluxbox version
Hi,
add a GTK+ theme manager like "gtk-chtheme 0.3.1".
Thanks
add a GTK+ theme manager like "gtk-chtheme 0.3.1".
Thanks
Re: Suggestions for the next Salix Fluxbox version
D'oh, right, I forgot that one. Adding lxappearance (much better than gtk-chtheme) would make sense.
Re: Suggestions for the next Salix Fluxbox version
Of course the menu doesn't update. It's Fluxbox. dmenu has the downside that you need to know what you're searching for. Not at all useful if you don't know that e.g. the media player that you want to launch is called "exaile". Not an option for a default installation.GJones wrote:1. The menu doesn't seem to update. Since Fluxbox does not support dynamic menus, and fluxbox-generate_menu doesn't work too well, I would suggest including only a few essential applications and options in the default menu, and instead relying on dmenu to launch stuff. This isn't as straightforward as using the Fluxbox menu, but should not be much more difficult for experienced Windows users (who have similar software) let alone experienced Linux users.
Conky is overkill and a CPU hog. If users want it they can install it. gkrellm is another option (in my opinion, better), but it's not going to be included by default either. If there was a tray battery monitor that worked, we might use it.GJones wrote:2. There's no battery monitor by default, which is not so great for laptop users. Conky is not ideal, but I think it should do the trick.
13.37 is never going to be switched to upower. If and when this switch happens for future releases, changes can be made in those future releases so dbus is calling upower, but not 13.37. Using sudo is a terribly ugly hack, no way we're going to use that. Unless you have specific examples of the dbus commands not working in 13.37, I'm going to stick with my own experience which indicates that it always works.GJones wrote:3. The suspend and hibernate menu entries should probably use sudo instead of sending a dbus message to HAL. Using sudo is a dirty hack, but it's guaranteed to work once the switch to upower comes along, and sending dbus messages from the command line is in my experience not guaranteed to work at all.
Not a bad idea. We'll see.GJones wrote:4. Finally, just IMO, menu options for suspend and hibernate should lock the screen first by default. This is easy, you just add "xscreensaver-command -lock &" before the command that invokes suspend.
Can be done.GJones wrote:Adding lxappearance (much better than gtk-chtheme) would make sense.
Re: Suggestions for the next Salix Fluxbox version
Okay, makes sense. I just don't like the idea of the user having to manually add menu entries for each new application.gapan wrote: Of course the menu doesn't update. It's Fluxbox. dmenu has the downside that you need to know what you're searching for. Not at all useful if you don't know that e.g. the media player that you want to launch is called "exaile". Not an option for a default installation.
Didn't know Conky was a CPU hog. I do think a battery monitor is kind of essential, but installing gkrellm or whatever manually isn't so awful.Conky is overkill and a CPU hog. If users want it they can install it. gkrellm is another option (in my opinion, better), but it's not going to be included by default either. If there was a tray battery monitor that worked, we might use it.
I was thinking of the one based on the next Slackware version, after 13.37. In retrospect though that was a dumb idea - by the time the next version of Slackware comes out, there might very well be a usable 'upower' command (there's already 'udisks-mount').13.37 is never going to be switched to upower. If and when this switch happens for future releases, changes can be made in those future releases so dbus is calling upower, but not 13.37. Using sudo is a terribly ugly hack, no way we're going to use that. Unless you have specific examples of the dbus commands not working in 13.37, I'm going to stick with my own experience which indicates that it always works.
[/quote]Not a bad idea. We'll see.GJones wrote:4. Finally, just IMO, menu options for suspend and hibernate should lock the screen first by default. This is easy, you just add "xscreensaver-command -lock &" before the command that invokes suspend.
Can be done.GJones wrote:Adding lxappearance (much better than gtk-chtheme) would make sense.
Thanks and thanks.
- jayseye
- Posts: 233
- Joined: 24. Jul 2011, 17:22
- Location: Brownsmead, Oregon (Center of the Universe)
Re: Suggestions for the next Salix Fluxbox version
Hi -
Good to see other Fluxbox users here. With quick X startup just shy of the baseline set by TWM, manual configuration is the price we pay, in the Slackware way.
OTOH Salix has been called the Lazy Persons' Slackware, with a focus on (relative) ease of use and attractiveness. So GUI-based configuration utilities would would make great additions, as long as they have minimal impact on performance.
For instance I'd love to have an interactive Menu Editor, and maybe even the equivalent of the GNOME2 "Add Widgets To Panel" utility. Would other users find these useful?
Also there's a relevant post in this section which has yet to receive any feedback:
viewtopic.php?f=32&t=2535
I had to enter just a fragment of the URL above, since this is only my second Forum post. Anyway, is anyone else having issues with HOME and END keys in 'less', as mentioned in that message?
Regards,
jayseye
Good to see other Fluxbox users here. With quick X startup just shy of the baseline set by TWM, manual configuration is the price we pay, in the Slackware way.
OTOH Salix has been called the Lazy Persons' Slackware, with a focus on (relative) ease of use and attractiveness. So GUI-based configuration utilities would would make great additions, as long as they have minimal impact on performance.
For instance I'd love to have an interactive Menu Editor, and maybe even the equivalent of the GNOME2 "Add Widgets To Panel" utility. Would other users find these useful?
Also there's a relevant post in this section which has yet to receive any feedback:
viewtopic.php?f=32&t=2535
I had to enter just a fragment of the URL above, since this is only my second Forum post. Anyway, is anyone else having issues with HOME and END keys in 'less', as mentioned in that message?
Regards,
jayseye
Re: Suggestions for the next Salix Fluxbox version
In the past, I always used menumaker (sourceforge) for fluxbox and icewm menus.
Worked great for me, but YMMVV
Worked great for me, but YMMVV
- jayseye
- Posts: 233
- Joined: 24. Jul 2011, 17:22
- Location: Brownsmead, Oregon (Center of the Universe)
Re: Suggestions for the next Salix Fluxbox version
Thanks, alaskan -
MenuMaker might be useful as a starting point, as it was last released in 2005 and has been dormant since 2008. The dates are relevant because one of MenuMaker's algorithms searches for specific apps. Also, Python standards have moved on a bit, so the source code is now throwing deprecation warnings, etc.
A more interactive, WYSIWYG-y menu editor, like the one in KDE, would be useful for those of us who truly embrace their inner laziness
Can I get a witness?
jayseye
MenuMaker might be useful as a starting point, as it was last released in 2005 and has been dormant since 2008. The dates are relevant because one of MenuMaker's algorithms searches for specific apps. Also, Python standards have moved on a bit, so the source code is now throwing deprecation warnings, etc.
A more interactive, WYSIWYG-y menu editor, like the one in KDE, would be useful for those of us who truly embrace their inner laziness
Can I get a witness?
jayseye
Re: Suggestions for the next Salix Fluxbox version
Try fluxMenu, available through sourcery/slapt-src.
- jayseye
- Posts: 233
- Joined: 24. Jul 2011, 17:22
- Location: Brownsmead, Oregon (Center of the Universe)
Re: Suggestions for the next Salix Fluxbox version
Very cool, gapan -
From the screenshot, FluxMenu appears to have the features I was looking for:
> http://fluxbox-wiki.org/index.php/FluxMenu
Will try it ASAP, and will spend some more time exploring that wiki.
Thanks for the reply!
jayseye
From the screenshot, FluxMenu appears to have the features I was looking for:
> http://fluxbox-wiki.org/index.php/FluxMenu
Will try it ASAP, and will spend some more time exploring that wiki.
Thanks for the reply!
jayseye