MimeticDE - homebrewed lightweight all-in-one distro

[Hedon James]

One last thing: What if, from Openbox, you run the lxpanel --profile LXDE command?

 

Never mind, dumb question, you already wrote about what happens with commands like the following:

 

lxpanel -p Mimetic-Unity

 

I'm stumped. Unless lxpanel is looking in the wrong places for your .desktop files, but that makes no sense.

 

Eureka! That's it! I found out why Fluxbox (and presumably, Openbox) aren't displaying those icons! Screenshot below:

 

the lxpanel config file on the left indicates that icons are being pulled from the directory menu://applications/... instead of usr/share/applications/...

 

One of my "missing" icons on the launcher is for my custom File Manager Browser - PCManFM. This custom icon is simply a clone of PCManFM.desktop file with modified command (pcmanfm --no-desktop %U) to preserve fluxbox/openbox root menu and custom icon. The FileManagerBrowser-PCManFM icon is located in menu://applications/System Tools/ (right next to the original PCManFM icon). File properties confirms this. But the lxpanel config file believes that icon is located at menu://applications/Accessories/..., but that directory doesn't exist; and therefore, the icon isn't found, nor displayed. Not surprisingly, the other 3 "suspect" icons have the same issue. Directory paths that don't match between the lxpanel config file and the menu://applications/... directory. This seems to be limited to the "Accessories" and "Administration" directory paths of lxpanel buttons, both of which appear to be actually located at menu://applications/System Tools.

 

So that solves the mystery of "why" it's happening, but doesn't help much towards a solution. I suppose I could hack the lxpanel config file, but that will do nothing for future icons/software programs that a user may download and install afterwards. Inasmuch as the menu://application files are all symlinks, a better solution would be the re-categorization of the symlinks in the directory. But I'll be darned if I know how the menu://application directory gets built, or where it even exists on the system. I've never noticed this directory before, certainly not in Nautilus or Caja or any Nautilus derivative I've used. Is it unique to PCManFM? Perhaps this is a bug in PCManFM? Although this doesn't explain why an Lubuntu/LXDE session displays these icons just fine...

 

Perhaps this is a matter of Dmenu versus XDGmenu specifications? When I was tinkering with customizing my Fluxbox menu, I toyed with Dmenu but didn't like it, as it seemed my "categories" were messed up and too many programs weren't where I expected to see them. I much preferred XDG-menu, as that produced a menu exactly like what I'm used to. I use XDG-menu in Fluxbox to "update" the menu when new entries/programs are installed. This is the only thing I can think of that MIGHT explain why Lubuntu/LXDE displays applications differently than naked Fluxbox/Openbox. Dmenu and XDG categorize things differently?

[Hedon James]

Interesting stuff Saturnian. I used the export XDG_CURRENT_DESKTOP=LXDE command in autostart

 

I'm running Fluxbox in openSUSE 42.1, which I installed with KDE. Added Fluxbox later. In the Fluxbox session, I noticed that if I was running any KDE apps, the iconbar showed a button for that app, with the application name, but no application icon. The icon was missing for every KDE app I tried running in Fluxbox.

 

Added the following to the ~/.fluxbox/startup file:

 

export XDG_CURRENT_DESKTOP=kde

 

Started a new Fluxbox session and the problem with the KDE icons was fixed!

 

Your situation might be different but maybe try adding that line (use "lxde" instead of "kde") to your ~/.fluxbox/startup (not to your autostart file) and see what happens.

 

After much research, I'm convinced my issue has to do with PCManFM and the way it categorizes applications in the menu://applications bookmark. When I open PCManFM and view applications bookmark, they are categorized differently between LXDE desktop and Fluxbox and Openbox desktops. The LXDE environment causes PCManFM to classify categories differently than Fluxbox or Openbox, which is causing the "null path" to the lxpanel icons, causing them NOT to be displayed.

 

So I think you're onto something with the "export XDG_CURRENT_DESKTOP=kde" suggestion. However, changing kde to lxde doesn't solve, nor does changing to LXDE (assuming it might be case sensitive). Furthermore, I seem to lose my RootMenu on the desktop, both right click and keybinding invoked. But hand in hand with the export current desktop is the "export XDG_CURRENT_MENU=<menu-prefix>-" setting for PCManFM to identify which menu to use. This seems to EXACTLY describe my issue.

 

The lxsession file for the LXDE sessions indicate that the menu prefix should be lxde-, so I think I want to duplicate that in Fluxbox. But adding "export XDG_CURRENT_MENU=lxde-" to the Fluxbox startup file seems to have no effect on the PCManFM menu://applications bookmark directory. Is my syntax off? Does it need to be placed somewhere else, i.e. a PCManFM config file? What am I missing?

[Hedon James]

I don't want to necro-jack a thread, but wanted to add this post for a little closure, in case anyone else ever experiences this issue; despite it's admittedly narrow scope. FINALLY received an answer from a developer about the issue(s) described above. Long story short...found a bug; developer says fix will be implemented in next version. (apparently Bugzilla works?!!!) Copy of my e-mail/bug report and his response copied & pasted as follows:

 

• Comment:
  

This is a LXPanel issue, it should never save menu://applications/...... path but just an application id instead. This issue should be fixed in coming version 0.9.0. Thank you.

[bugs:#1025] menu://applications bookmark changes based on desktop/window manager session

Status: open

Group: 1.2

Created: Sun Sep 04, 2016 12:11 AM UTC by James Shriner

Last Updated: Sun Sep 04, 2016 12:11 AM UTC

Owner: nobody

Not sure if this is a bug in PCManFM, or an implementation within LXDE. I have customized Lubuntu 16.04 to resemble Unity, modifying lxpanels to place desired icons in order I prefer. I also have installed fluxbox and often log into the fluxbox session, invoking the lxpanels with "lxpanel -p <session-profile>"; in my case "lxpanel -p Mimetic-Unity". However, four (4) icons are missing from this panel: a modified "File Browser-PCManFM.desktop" file (modified with --no-desktop to retain fluxbox root menu) copied from PCManFM.desktop file; Appgrid; Lubuntu Software Center; and a customized YAD control center panel.

Looking at lxpanel config files and comparing with desktop files in menu://applications bookmark of PCManFM, the desktop files are changing directory/category between Lubuntu and Fluxbox sessions (naked Openbox duplicates Fluxbox's menu://applications directory structure in PCManFM. The changed categories cause a null path in the lxpanel config file, causing the icon in the lxpanel to not be displayed.

I believe this is either an issue with PCManFM displaying those categories differently in menu://applications bookmarks; or an issue with LXDE/Lubuntu re-categorizing the desktop files. I would expect the lxpanel to display itself in an identical manner, independent of window manager or desktop environment.

If this is a PCManFM bug, please address. If this is an issue with the way that LXDE/Lubuntu presents the categorized .desktop files, please advise how I can make Fluxbox or Openbox display the .desktop files in PCManFM's menu://applications bookmark in the same manner as LXDE/Lubuntu.

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/pcmanfm/bugs/1025/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

[Hedon James]

Also wanted to mention, I found a workaround for this problem, which is actually cleaner and more elegant than the kludge I was putting together in Fluxbox start file (and now PekWM also!). Despite the bug in lxpanel referenced in above post ^, the true culprit appears to be lxsession, and the manner in which it sets up default programs and "environments" for LXDE. I started tinkering with the lxsession file, changing the default window manager from "openbox" to "fluxbox" (and later, to "pekwm"), but this was causing collateral issues with my virtual workspaces, presumably due to the "workspace manager = obconf" component of that file. This was, in turn, wreaking havoc on my Tint2 config. Long story short....I never was able to figure out the equivalent command/program for Fluxbox (nor PekWM), but found this little nugget of wisdom, buried way down on the Arch Wiki page for LXDE:

 

Alternatively, you can autostart wm --replace using the method defined in #Lxsession where wm is the name of the window manager executable being started. This method does mean that Openbox will be started first on each login and will then immediately be replaced by the autostarted window manager.

 

Testing in Roxterm by typing "fluxbox --replace" or "pekwm --replace" did indeed replace OpenBox as the window manager with no ill effects whatsoever! So I added 2 new entries in the LXDE autostart file, "fluxbox --replace" to invoke a fluxbox-managed session of LXDE; and "pekwm --replace" to invoke a pekwm-managed session of LXDE. I have check boxes on each to PREVENT them from autostarting, but removing the checkbox allows for the alternative window manager with no adverse side effects. Simple stuff for a new or uninitiated user...PERFECT.

 

As for me, I prefer right clicking or keybindings to get the RootMenu for navigation, so I have identical entries in Openbox, Fluxbox, & PekWM to switch window managers on the fly. So now my MimeticDE boots into an Openbox-managed session by default; with MY desktop automatically replacing OpenBox with Fluxbox immediately after session load (or PekWM, if I choose); and the ability to switch to any other "on the fly" according to mood, whim, or necessity.

 

PERFECT! Happy camper! Just sharing the knowledge for anyone in the future who may find themselves in a similar scenario...

[securitybreach]

Neat stuff, thanks