You are not logged in.
eight.bit.al wrote:I like the menu setup in #!++, it's a lot like the setup in Xfce's right-click menu.
What is it you like?
For me, using BL I spend most of my time in the second level menu "Applications"; in #!++ and Xfce, that section is on the top level.
Xfce and #!++ have two menu choices for 'system' stuff - System and Settings.
Their menus are simpler.
Bl has Preferences, System, Settings, and another System (could almost add Utilities in this group too). BL has two "Systems" that do different things, and I sometimes look in the wrong one.
Sorry about the image size; I reduced them until the Xfce one is starting to get fuzzy.
8bit
Last edited by deleted0 (2023-04-02 13:54:47)
Back to the Menu. The BL menu is oriented towards wordsmiths; programmers, system administrators, etc. Not a bad thing. There's is no "Graphic Editor" in the top level with "Text Editor", just for an example. To start GIMP it's three Levels down; main-menu Applications, Graphic, GNU Image...
Also needs to be said with jgmenu it's relatively easy to edit the Top Level menu items. But where does that stop?
Putting the Application Menu on the Top Level is a good compromise
between the Top Level being loaded with apps + all the rest,
and
only one mouse movement to reveal dozens of app's calling cards.
This brings up workflow.
I like to start with a file manager. Right click on a file and choose what editor to open it in. So I don't need any editors in the Top Level. For new files I also start with the file manager. In the dir where I want to store the file, right-click, new file. I always have a file manager open on each virtual desktop. Usually opened to what pertains to that editor.
Submitted for your consideration:
Also changed was Keybinds. See post below for more details.
8bit
edit: nothing to do with Boron; no need to do big changes at this point.
Just sayin'.
Last edited by deleted0 (2023-03-27 20:21:59)
The BL menu has evolved over the years. Like #! it started off mostly hard-coded, except for some of Philip's pipemenus. Then we (Damo at first) added more pipemenus that checked if certain apps (like Gimp) were installed and either offered to install them, or run them. So there was a "Graphics" pipemenu with items "Install Gimp"/"Gimp", etc.
Much later @malm brought jgmenu which seemed a big improvement on the native openbox menu and was eagerly adopted. Apart from all the preexisting hard-coded entries and pipemenus, it also supported an auto-updating applications menu, like XFCE, GNOME and everyone else.
I want to talk about all this, and how different peoples' work-flows could be helped - or not - by different menu items, but it might run a bit long, and I don't have time today. Also looking forward to reading more of what eight.bit.al and other people think about all this. As Al said, it's getting late to make sweeping changes to the menu for Boron, but we can certainly think about Carbon...
---
Meanwhile, two utilities I thought we might consider putting back in the main Boron menu:
1) Catfish file finder, in Utilities, next to "App Finder".
2) Hardinfo GUI system profiler, in System next to inxi's "Quick System Info".
Both those apps are already in the install list but right now they're only accessible via the "Applications" sub-menu.
---
The role of the "Applications" menu is a main topic I want to get into btw.
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
jgmenu is a joy to modify. Save edits and test realtime.
Updated Utilities menu - working.
The Utilities Menu - old and new; the new is ascetically more pleasing. Balanced for size/weight, grouped by extended menu or not, with the not extended on top, etc.
Throw some lovin' BL's direction. . The more I use it the more I like it. Now if I can get the menu tamed, I might just switch on the main machine. The current Sparky/MX mash-up has held up surprisingly well.
edit: I should try a BL/MX mash-up. But that's for another thread.
8bit
Last edited by deleted0 (2023-03-28 18:13:05)
The Utilities Menu - old and new; the new is ascetically more pleasing. Balanced for size/weight, grouped by extended menu or not, with the not extended on top, etc.
I see what you're getting at, in terms of visual appearance. Another consideration is getting the most-used items at the top. Now that "Quick Screenshot" is in the top level, I guess there's less need for the screenshot submenu to be at the top of Utilities.
Separating out the "display keybinds" menu makes some sense - the other edit etc items probably need access less often. I'm not 100% sure how useful the "display in new window" is anyway. The keybinds menu is already marked for attention because the two versions order items differently. There was something about the handling of tabs too...
I have to get out of here again, but I think we (other folks too) could usefully discuss different workflows, and how to accomodate as many different styles as possible without annoying too much the people who don't use a particular approach.
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
Another consideration is getting the most-used items at the top.
Of course it's always a trade-off.
Who is the target audience? I say it's new users. We don't need to "catch" existing users. Some existing users will not like any change, oh well. New and existing users will soon train/retrain muscle memory in selecting the option of choice. Ascetics is always there, in your face initially, forever subliminally.
BL needs to be as attractive as is suitable for our ethos.
(look at me sayin' 'we' 'our'. I've been sucked into BL. Resistance is futile)
I think we (other folks too) could usefully discuss different workflows, and how to accomodate as many different styles as possible without annoying too much the people who don't use a particular approach.
So far, a lack of input from the masses;
barely a peep from our Design Director. @hhh.
8bit
Last edited by deleted0 (2023-03-29 13:40:13)
When jgmenu opens, the last selected choice remains highlighted; and does not un-highlight (de-highlight?) until some mouse or KB input. Useful if one wants to rerun the same command again - 1%; and annoying the rest of the time - 99%.
Separating out the "display keybinds" menu makes some sense - the other edit etc items probably need access less often.
Great minds think alike they say. 'Course I wouldn't know. Ba Dum Tis.
The over all goal is to move what's possible from the Top Level to make room for the Application Section. After I moved Display Keybinds to Utilities, I wondered if it might have some special meaning in BL culture, ( I wish I knew more BL history), so I thought to put a pop-out only version back on Top Level.
Turns out that doesn't work in the real world. Bad design for that large pop-out to show every time one unintentionally mouses over it. So I left it as a single menu item. Which takes the shine off this idea; just leave the whole menu...
If, or not, there should be a Top Level Display Keybinds at all, is up for discussion.
8bit
Last edited by deleted0 (2023-03-29 14:34:39)
I suggest the overall goal for the menu is 'first time BL user easy' and 'eyeball friendly'. To minimize the stress of finding one's way around a new system.
8bit
Last edited by deleted0 (2023-03-29 14:53:42)
Oh man. You have been busy. Looking good!
Offline
Oh man. You have been busy. Looking good!
Thanks. Just getting over a computer burnout phase. I'm seriously courting OB for my main machine. Because nobody asked, here's my list.
Debian Stable - ✅
Editable right-click menu - ✅
Editable bar; tint2 in this case - next - make most of it go away
I'm trying to figure out which is easier; adding what I need to BL or removing what I don't need from LD.
BL needs a NVIDIA driver installer page in bl-welcome.
jgmenu has an odd trait. When called, the last selected option is still highlighted. Goes away with mouse or KB input, but not until.
Useful if one runs the same option over and again. 1%
Annoying the rest of the time. 99%
8bit
Last edited by deleted0 (2023-03-31 21:52:20)
^ Choice is good. The nvidia driver installer would be a cool option to have.
Offline
^driver installer would be a cool option to have.
As I suggested to you, grab the script from MX and edit to suit. I wonder how the BL community feels about using their (or any other distro's) work. Adding a page to bl-welcome was relatively easy. Has to be, if I can do it.
8bit
Last edited by deleted0 (2023-04-01 14:32:07)
@eight.bit.al
good job
Complete the pattern, solve the puzzle, turn the key.
Offline
^ Thank you for the kind response.
8bit
@al, leave icons on, for what my opinion is worth. Nice!
No, he can't sleep on the floor. What do you think I'm yelling for?!!!
Offline
@eight.bit.al you've made a lot of useful comments. Unsure whether to reply to each of them right away, or first dive into that Grand Exposition I mentioned earlier. Decided to do the latter.
The CrunchBang/BunsenLabs Menu
Can be roughly divided into three areas:
1) Hard-coded entries defined in a user-owned file. Complete freedom in arrangement. User has absolute control. Newly (un)installed apps require editing the menu by hand.
1a) Hard-coded entries imported from a system file by an include line in the user config file, like:
. /usr/share/bunsen/docs/menu-includes/help-menu
System files can be updated by a package upgrade without having to overwrite user files, so this method is good for documentation, which users don't really need to edit themselves.
2) Pipe Menus. Generated by a script, and can adjust to changing situations in the user's system. The script is a system file in /usr/bin/ and to customize it, needs first to be copied to ~/bin, and then the user has to understand how the script works. The hope is that such customization is seldom needed. Pipemenus are very cool and useful, but they have a couple of disadvantages:
i) the jgmenu search function can't see inside pipemenus because the content doesn't exist until the pipemenu is opened.
ii) jgmenu does not support icons for pipemenus.
3) Auto-generated "Applications" menu. These items are generated from the .desktop files in /usr/share/applications which each (or many) installed application adds. (Un)installation of apps is immediately reflected in this kind of menu. Customizaton is possible, but very complicated and beyond what most users would likely feel like doing.
Crunchbang's menu was mostly type 1), though Corenominal added some useful pipe menus for specific functionalities.
BunsenLabs started to work around the rigidity of hard coding for apps menus by making pipemenus like "Graphics" which would offer eg "Gimp" if it was installed or "Install Gimp" if it was not. The downside was that people with no interest in Gimp would still see that Install item. Some users disliked Pipemenus very much, perhaps partly because of that. When computers were slower, CPU load and sluggish response might have been another factor. The snappy hard-coded #! menu was certainly attractive.
The switch to jgmenu allowed us to include an auto-generated "Applications" submenu, making it unnecessary to code in an item for every app a beginning user was likely to want, or provide as many dedicated pipemenus for installing and running apps. As with pipemenus, there was not 100% enthusiasm for this addition among the developers. I saw it as a "fallback" for apps which a user had installed and didn't use often enough to justify the bother of editing the hard-coded menu. To be honest, I often use an apps menu that way too.
But, a big problem appeared when watching people review BL on YouTube. They would start at the top of the menu, scroll down through Run Program, Terminal etc to Applications and then dive straight into that. By the time they'd emerged they'd be too tired to pay any attention to our carefully-crafted Preferences* or System menus, not to mention Help & Resources... all the stuff that makes BL special. You could see those reviewers were missing all the important points. We guessed new users would be approaching the menu in the same confusing way.
The "System" section of the auto-generated "Applications" submenu is just a random collection of whatever apps have decided to add a System tag to their .desktop file, in a meaningless alphabetical order. Many of them are quite useless in fact, without a context like a file or directory to open. Likewise for Applications > Settings.* Many of our BL Menu System and Preferences items have no corresponding .desktop file anyway. EDIT 2023/10/4: some more .desktop files have since been added.
* For example, after changing themes in lxappearance in Preferences > Appearance, the GTK settings are automatically updated. If OTOH you go Applications > Settings > Customize Look and Feel then some of your changes won't be applied till you logout.
One reason for this mess is that /usr/share/applications/*.desktop files have another purpose beside menu generation: they are also used to associate filetypes with default applications. That's why there is eg a /usr/share/applications/bl-media-player.desktop. If a user clicks an .mp3 file it will be opened by default with whatever app has been set as bl-media-player in Debian alternatives.
So it was my suggestion to move "Applications" down the menu, so reviewers - and new users - would find it after going through the more useful stuff above. As a "last-resort".
Work Flows
For more common apps there are numerous different ways of launching:
*) menu item
*) keyboard shortcut
*) Alt+F2 "Run Program" box
*) Alt+F3 Dmenu
*) click a file in a file manager to open it with its default app
*) search for it in the App Finder (under Utilities)
*) click a tint2 launcher or button
*) click a launcher in a panel like xfce4-panel
(I often forget dmenu but it's good if you only remember part of an app's name)
OK personally, I open terminal windows, file manager windows and geany text editor all the time. For those I use Win+T, Win+F and Win+E, never the menu or anything else.
(The reason it's useful to launch Geany without a file to open - like in a file manager - is that it remembers the previous session, with all the files you had open last time, and even puts the cursor back it the same place it was before! Very useful IMO.)
For Firefox, Thunderbird and Shutdown I've got colourful launchers in a self-hiding xfce4-panel. Why? No particular reason.
But if I want to edit my autostart it's Menu>Preferences>BunsenLabs>Edit autostart
Like eight.bit.al, when starting a new bit of work I usually dive in with the file manager first, then open files and terminals as needed.
Other people will have quite different work flows, but we want to accomodate as many of them as possible without annoying the others.
For first-time users I think we need to make it as easy as possible to open a terminal or file manager. And a web browser. So multiple routes.
I'll leave it there for today, and respond to Al's useful suggestions later.
---
Boron vs Carbon
Debian Bookworm will be out soon, so for Boron let's incorporate changes that are both easy to apply and uncontroversial.
Lots more can follow in Carbon.
Last edited by johnraff (2023-10-04 06:04:32)
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
BL needs a NVIDIA driver installer page in bl-welcome.
Could you open a new topic for this suggestion? Menu thread itself is quite big enough already.
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline