mxfb-2025 development ideas

[DeepDayze]

Perhaps MX could ship a package (if not already) with some nice MX-inspired styles to match the XFCE and KDE theming as closely as possible.

@DeepDayze Keep a lookout to see if anyone has started a thread for those desktops. This thread is ideas for the upcoming MX-25 fluxbox desktop.

That's what I meant for MX-25.

[i_ri]

Hello Jerry3904 and Everyone
Was mentioned having the Slit mousewheel create swipe to other workspace or swipe to ShowDesktop.

How about Slit for rootmenu?
//keys
OnSlit Mouse4 :RootMenu
OnSlit Mouse5 :RootMenu

[Jerry3904]

Not sure ATM who would use that, but thanks.

[Jerry3904]

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

[siamhie]

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}

Move Weather to [submenu] (Accessories) or [submenu] (Other)

Move Xkcd to [submenu] (Multimedia)

Remove (Music) and move deadbeef to [submenu] (Multimedia)

"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"

Why not name that catagory Window Manager like they have it in the manual?
(examples section of man fluxbox-menu)


[submenu] (Window Manager)
[exec] (Edit Menus) {nedit ~/.fluxbox/menu}
[submenu] (Style) {Which Style?}
[stylesdir] (~/.fluxbox/styles)
[stylesmenu] (fluxbox Styles) {@pkgdatadir@/styles}
[end]


Move entries in [submenu] (Window options) to newly named [submenu] (Window Manager)

[Jerry3904]

Good thoughts, thanks.

[siamhie]

Good thoughts, thanks.

@Jerry3904 This is a rough idea I have.

root-menu.png

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]

[Jerry3904]

Another on this topic: add item "Lock" to the "Leave" category, following results of this thread:

viewtopic.php?p=805766#p805766

(There is another way to do it with xscreensaver that I will include in a revised MXFB manual.)

------------------

I want to start working on this topic as a beginning of our MX-25 development period--we have lots of great ideas in this long thread, and I will try to organize the comments in some useful way over the next week or so.

[siamhie]

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

[fehlix]

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

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.
This would result in conky always being displayed in the same way, regardless of whether the compositor is activated or not.
This way it would also work for xfce if the compositor with xfwm was disabled by the user.
I don't think a MX-25 specific conky set is needed as we can use the same conky data set for both mx-23 and mx-25 for fluxbox, xfce and kde.