Support for MX and antiX Linux distros
http://www.forum.mxlinux.org/
Jerry3904 wrote: ↑Sat Dec 14, 2024 6:15 am I've been spending a lot of time on menus the last few weeks while working on an Openbox respin, and it leads me to add the topic to the thread:
We might want to review the root menu.
1) I see that some Fool added a main-level entry called "Extras." I assume that the intent was to make obscure items more visible, but it might at least be dropped down and some components might well need to say by-by..
2) "Music" might be generalized to "Entertainment" so that Xkcd, for instance, could find a home. I'm confident that users would have their own items to place here...
3) The label "Out of sight" is great for me but difficult to translate. Maybe a much more general "Hide/Show" would be easier on translators and avoid having to use the word "toggle" on items
4) There's probably other stuff as well that we might want to re-examine
Code: Select all
[submenu] (Extras)
[exec] (Weather) {mxfb-simple-weather}
[submenu] (Window options)
[Exec] (Border) {mxfb-borders}
[Exec] (Titlebar) {mxfb-top}
[end]
[exec] (Xkcd) {bl-xkcd}
[end]
[exec] (Help) {mxfb-help}
[exec] (Music) {deadbeef}Why not name that catagory Window Manager like they have it in the manual?"The label "Out of sight" is great for me but difficult to translate. Maybe a much more general "Hide/Show" would be easier on translators"
@Jerry3904 This is a rough idea I have.
Code: Select all
#the default versions of the submenus are located in /usr/share/mxflux/menu
[begin] (MX Fluxbox)
[submenu] (All Apps)
[include] (~/.fluxbox/submenus/full_menu)
[separator]
[exec] (Update) {/usr/bin/mxfb-menu-generator}
[exec] (Disable) {mx-tweak --other}
[end]
[submenu] (Recent files)
[include] (~/.fluxbox/submenus/recent_files_menu)
[separator]
[exec] (Update) {~/.fluxbox/scripts/recentfiles-fbmenu}
[end]
[separator]
[exec] (Browser) {sensible-browser}
[exec] (File manager) {exo-open $HOME/.fluxbox}
[exec] (Terminal) {roxterm}
[exec] (Run) {mxfb-rofirun}
[exec] (Settings manager) {custom-toolbox /etc/custom-toolbox/mxfb-settings.list}
[exec] (Fluxbox Manual) {mxfb-help}
[separator]
[submenu] (Appearance)
[include] (~/.fluxbox/submenus/appearance)
[end]
[submenu] (Settings)
[include] (~/.fluxbox/submenus/settings)
[end]
[submenu] (Window manager)
[include] (~/.fluxbox/submenus/out-of-sight)
[end]
[submenu] (Leave)
[exec] (Refresh) {fluxbox-remote restart; idesktoggle idesk refresh }
[exec] (Suspend) {sudo 'pm-suspend'}
[exit] (Logout)
[exec] (Reboot) {sudo /sbin/reboot}
[exec] (Shutdown) {sudo /sbin/halt}
[end]
[end]
Code: Select all
;
-- fluxbox adjustment
return_code = os.execute('pidof -q fluxbox')
if _VERSION == 'Lua 5.1' and math.floor(return_code/256) == 0 or
_VERSION ~= 'Lua 5.1' and return_code then
conky.config.own_window_transparent = true
conky.config.own_window_argb_visual = false
end
Instead of removing the fluxbox customizations, you could extend them to take into account whether a display compositor is being used, either comton, picom or xfwm (with compositing enabled) is used, and set the opacity of conky accordingly.siamhie wrote: ↑Wed Jan 22, 2025 9:10 pm One quick idea. Can we have compton enabled at boot (new installs) since it is already installed.
This way we can get rid of the fluxbox adjustment code from the conky's. XFCE and KDE have their own compositors.
This is what was causing my fuzziness with a recent conky I'm building that had that code and it interferes with compton.
I tested (and it works without that part of the code) on the MX-CoreBlue conky with compton enabled.
Code: Select all
; -- fluxbox adjustment return_code = os.execute('pidof -q fluxbox') if _VERSION == 'Lua 5.1' and math.floor(return_code/256) == 0 or _VERSION ~= 'Lua 5.1' and return_code then conky.config.own_window_transparent = true conky.config.own_window_argb_visual = false end