You are not logged in.

#76 2019-06-09 05:16:39

malm
jgmenu developer
Registered: 2016-10-13
Posts: 449
Website

Re: Experimental BunsenLabs Lithium

@Sector11
It’s in the backports repo. You should just be able to do “apt install jgmenu”

Offline

#77 2019-06-09 05:59:38

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,578
Website

Re: Experimental BunsenLabs Lithium

jgmenu is also in the lithium-dev repository (that this thread is about), and the latest lithium-dev bunsen-configs 10.2-1, apart from pulling it in as a Recommends:, already ships the necessary config files for jgmenu to look almost identical with the Openbox menu. Try it: copy /usr/share/bunsen/skel/.config/jgmenu/ to ~/.config and set some of your keyboard/mouse shortcuts to execute 'jgmenu_run'.

I think it's an excellent merger of the fixed BL menu with an auto-updating apps menu. Of course the details can (and will) be adjusted before the official Lithium release, so please post anything you think needs changing!


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#78 2019-06-09 06:14:05

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,578
Website

Re: Experimental BunsenLabs Lithium

hhh wrote:
Sector11 wrote:

Like a .deb file  big_smile

Eventually, yes, it will be added to bunsen-configs (I'd guess, or maybe its own package that bunsen-configs pulls in). Maybe even in time for Lithium, we're working hard!

This isn't maybe baby, this is right now, here, today. cool


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#79 2019-06-09 06:14:05

hhh
Meep!
Registered: 2015-09-17
Posts: 8,059
Website

Re: Experimental BunsenLabs Lithium

There you go.

+1, type-to-search FTW.

Offline

#80 2019-06-09 06:16:29

malm
jgmenu developer
Registered: 2016-10-13
Posts: 449
Website

Re: Experimental BunsenLabs Lithium

Thanks @johnraff
Much better response smile

Offline

#81 2019-06-09 06:33:59

hhh
Meep!
Registered: 2015-09-17
Posts: 8,059
Website

Re: Experimental BunsenLabs Lithium

Maybe my favorite thing about getting older is the privilege of throwing around terms like "baby" and "Kiddo" at people with relative impunity.

That and only getting asked for ID when buying beer once every 3 years (it happened last night, the woman cashing me out was 1 month younger than me.)

-edit- In retrospect, she was either screwing with me or flirting with me, or both. That bitch! monkey

Offline

#82 2019-06-25 07:05:18

dekks
New Member
Registered: 2017-06-28
Posts: 1

Re: Experimental BunsenLabs Lithium

any path yet to convert existing helium build to lithium?

Offline

#83 2019-06-25 09:22:22

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,578
Website

Re: Experimental BunsenLabs Lithium

Hi dekks,
well, Lithium isn't yet ready - this is an experimental repo based on Debian Buster. If you'd like to help us get it into shape it's suggested that you follow the instructions here: https://forums.bunsenlabs.org/viewtopic … 524#p81524
This will create a new system.

We have never provided a guaranteed upgrade path from one version to another, although it's not impossible. That said, I wouldn't recommend converting an existing Helium installation to Lithium at this point if you are using it for anything at all important.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#84 2019-06-25 10:00:04

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,578
Website

Re: Experimental BunsenLabs Lithium

With the latest bunsen-configs (10.3-1~test) and the two previous upgrades, rather more changes than usual to the BunsenLabs user interface. We hope these will be considered improvements rather than irritations. smile

Basically, it's all about being less tied to openbox, although that will still be the default window manager for some time to come.

*) jgmenu now generates the desktop menu, and the files to edit are ~/.config/jgmenu/prepend.csv and jgmenurc
*) xbindkeys determines the global keybinds (run applications, like Win+T for a terminal) defined in ~/.xbindkeysrc. Of course, openbox's bl-rc.xml still defines openbox-specific keybinds, like resizing windows.
*) Yes, rc.xml is now bl-rc.xml. OpenBox's rc.xml remains and can be used for a vanilla openbox session separate from BL. BL's menu.xml is now bl-menu.xml but now we've switched to jgmenu it isn't used anyway (lxde does the same, using some other menu generator.) The old openbox stub menu can be brought up with Ctrl+Alt+Q, but the other menu keybinds invoke jgmenu.
*) Autostarted applications are triggered from ~/.config/bunsen/autostart. The file is identical in style with the previous ~/.config/openbox/autostart, but allows setting a different window manager.
*) Users can disable the xdg autostart from bunsen/autostart if they want to start everything manually.
*) Autostart, menu and keybinds work regardless of window manager.
*) The menu has new entries for editing autostart, menu and keybinds and the old openbox entries removed.
*) bunsenlabs-session is the Debian alternative for x-session-manager so if lightdm login is set to "Default X session" BunsenLabs' session will be started, likewise from startx.
*) 'man x-session-manager' brings up the new bunsenlabs-session man page.
*) BL's openbox session is independent of openbox and a vanilla openbox session can co-exist with it. However, the BL keybinds will persist, and will launch the BL menu or default applications (like x-terminal emulator or bl-file-manager). (The keybinds could be made strictly specific to the BunsenLabs session if we disabled the xbindkeys desktop file and launched it manually from BL's autostart. Whether to do that or not is still undecided.)

Anyway, not much has really changed from the new user's point of view, except that some config files have changed. The new menu "edit..." entries have been changed to match. We hope more experienced users will enjoy a bit more flexibility. (Both jgmenu and xbindkeys are powerful apps capable of more than our configs do.)

New config files (like ~/.config/bunsen/*) will be copied in from /usr/share/bunsen/skel if they don't exist in $HOME, but existing files will not be overwritten. The easiest way to get all the default user config files is to run:

bl-user-setup --refresh

The terminal output will show any changed files - backups are made with a datestamp so you can copy back any settings you want to keep.

Last edited by johnraff (2019-06-26 06:57:33)


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#85 2019-06-25 12:28:47

PackRat
jgmenu user Numero Uno
Registered: 2015-10-02
Posts: 1,064

Re: Experimental BunsenLabs Lithium

hhh wrote:

-edit- In retrospect, she was either screwing with me or flirting with me, or both. That bitch! monkey

Sad part about getting older is that you didn't figure that out until after you left.


xbindkeys determines the global keybinds (run applications, like Win+T for a terminal) defined in ~/.xbindkeysrc. Of course, openbox's rc.xml still defines openbox-specific keybinds, like resizing windows.

Have you tested this out by installing some other WM's or DE's? Other window managers should be ok, but I can see where a DE would get messed up. There are already a lot of pre-defined key bindings set up for DE's (and some terminal applications like terminator). Could be setting yourself up for some keybinding conflicts; run the risk of locking up the X-session.


You must unlearn what you have learned.
    -- yoda

Offline

#86 2019-06-26 07:30:04

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,578
Website

Re: Experimental BunsenLabs Lithium

PackRat wrote:

Other window managers should be ok, but I can see where a DE would get messed up. There are already a lot of pre-defined key bindings set up for DE's (and some terminal applications like terminator). Could be setting yourself up for some keybinding conflicts; run the risk of locking up the X-session.

@packrat valid point, although it's maybe not too disastrous.

We're certainly not suggesting running a DE inside BL, or BL in a DE - in fact by making a bunsenlabs-session we're aiming to allow BL to co-exist with other session-managers or DEs as login alternatives.

I've only tested with a couple of other WMs so far - awesome and xfwm4 - but they looked OK. Being able to bring up a terminal or the BL menu should be enough to straighten things out in most cases. Also, the default keybinds are mostly win+* so should not clash with app keybinds, except perhaps for a couple like Alt+F2 for gmrun. xbindkeys seems to override keybinds in openbox's rc.xml, although we've removed clashes anyway, but we don't yet know the exact behaviour with all the other WMs that set their own keybinds - whether xbindkeys' settings will be added to them, replace them or be defeated by them.

Anyway your warning is well taken, and an argument for doing this after all:

johnraff wrote:

The keybinds could be made strictly specific to the BunsenLabs session if we disabled the xbindkeys desktop file and launched it manually from BL's autostart.

In that cases users could just remove xbindkeys from BL's autostart if it caused problems - although it would mean setting some other way of launching the menu, eg a tint2 button.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#87 2019-06-26 14:19:05

PackRat
jgmenu user Numero Uno
Registered: 2015-10-02
Posts: 1,064

Re: Experimental BunsenLabs Lithium

Also, the default keybinds are mostly win+* so should not clash with app keybinds, except perhaps for a couple like Alt+F2 for gmrun

True, as long as your xkeybinds are launching applications you should be good to go. I know fluxbox and i3 use the Mod4 (Win key) for window management and switching desktops, usually something like:

# fluxbox defaults

# send the current window to a specific workspace
Mod4 F1 :SendToWorkspace 1

# send the current window and change to a specific workspace
Control Mod4 F1 :TakeToWorkspace 1

Alt + F2 launches fbrun for fluxbox, and the run dialog for xfce4 so keeping that in the openbox rc.xml would probably be a good idea.

Some others to watch out for:

Mod4 + p, or Mod4 + x =  usually launches dmenu in tiling window managers

Alt + Return, Mod4 + Return, or Mod4 + Shift + Return = default for launching a terminal in a lot of window managers

Mod4 + Space = launch the desktop menu, or cycle through tiling layouts

Last edited by PackRat (2019-06-27 00:03:04)


You must unlearn what you have learned.
    -- yoda

Offline

#88 2019-06-26 14:47:59

PackRat
jgmenu user Numero Uno
Registered: 2015-10-02
Posts: 1,064

Re: Experimental BunsenLabs Lithium

johnraff wrote:

Anyway your warning is well taken, and an argument for doing this after all:

johnraff wrote:

The keybinds could be made strictly specific to the BunsenLabs session if we disabled the xbindkeys desktop file and launched it manually from BL's autostart.

In that cases users could just remove xbindkeys from BL's autostart if it caused problems - although it would mean setting some other way of launching the menu, eg a tint2 button.

I think that would actually be your best route - keeping it contained in the BunsenLabs session. Easy enough to tell a user how to port the keybindings over should they want them in a different window manager. Maybe even a short How To if it gets requested enough.

A tint2 button for launching jgmenu is easy (I do that myself). Fluxbox with jgmenu launched from tint2 button, or Mod4+Mouse1 on the desktop:

fbox_menu-021XP.th.png

the terminal icon on the polybar will also launch a drop-down jgmenu.

Simply need a couple of jgmenu configs - one for mouse, one for tint2 - that's just a one-line edit; then call the correct jgmenurc.

Last edited by PackRat (2019-06-26 14:51:03)


You must unlearn what you have learned.
    -- yoda

Offline

#89 2019-06-27 00:23:44

hhh
Meep!
Registered: 2015-09-17
Posts: 8,059
Website

Re: Experimental BunsenLabs Lithium

PackRat wrote:
hhh wrote:

-edit- In retrospect, she was either screwing with me or flirting with me, or both. That bitch! monkey

Sad part about getting older is that you didn't figure that out until after you left.

No that's the sad part of being younger, not realizing that women you loved were totally into you. I had that cashier figured out in 5 seconds. She was hitting on me and screwing with me. Passive-aggressive is the Southern way, bless our little hearts (which mean eff u, the ultimate passive-aggressive statement in the South).

Offline

#90 2019-06-27 02:34:48

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,578
Website

Re: Experimental BunsenLabs Lithium

@PackRat Thanks!

PackRat wrote:

Mod4 F1 :SendToWorkspace 1
Control Mod4 F1 :TakeToWorkspace 1
Alt + Return, Mod4 + Return, or Mod4 + Shift + Return = default for launching a terminal in a lot of window managers

None of these are in our default keybinds, so safe.

Alt + F2 launches fbrun for fluxbox, and the run dialog for xfce4 so keeping that in the openbox rc.xml would probably be a good idea.

That launches gmrun in BL which is essentially the same function, so maybe no harm in overruling fbrun or xfce4-run (or whatever). The idea here is to keep bl-rc.xml strictly for openbox-specific keybinds ie window manipulation etc.

Mod4 + p, or Mod4 + x =  usually launches dmenu in tiling window managers

We don't use Win+p but yes Win+x would clash with our call to an exit dialogue. (We launch dmenu with Alt+F3.) So that would surprise users who expected dmenu, although it's easy to leave the exit dialogue.

Mod4 + Space = launch the desktop menu, or cycle through tiling layouts

Win+Space launches jgmenu in our keybinds. That would of course overrule a WM's own menu.

PackRat wrote:
johnraff wrote:

The keybinds could be made strictly specific to the BunsenLabs session if we disabled the xbindkeys desktop file and launched it manually from BL's autostart.
In that cases users could just remove xbindkeys from BL's autostart if it caused problems - although it would mean setting some other way of launching the menu, eg a tint2 button.

I think that would actually be your best route - keeping it contained in the BunsenLabs session. Easy enough to tell a user how to port the keybindings over should they want them in a different window manager.

Actually, the idea here is to make it easier for users to switch to a different WM within a BunsenLabs session, keeping their familiar startup apps, menu and keybinds. So yes, let's disable xbindkeys.desktop with a local version with "Hidden=true" then start it from bunsen/autostart instead.

Openbox is still our default, but of course we want to avoid people who switch WM getting stuck in a frozen Xsession etc. OTOH I think minor differences in keybinds are something they can be expected to live with or tweak to taste. Once xbindkeys is launched from autostart instead of via xdg-autostart then users can easily disable it if they don't want it in their BL session, or only want it with specific WMs.

So as long as we don't run xbindkeys when someone logs into a different session -"pure" WM or other DE - I think it might be OK.

A tint2 button for launching jgmenu is easy (I do that myself).

Yes, devs have just agreed to implement that (and replace the four launchers on the top left). New users might like a familiar widget.

And thanks again for the input - it really helps!

Last edited by johnraff (2019-06-27 02:52:38)


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#91 2019-06-27 03:09:45

hhh
Meep!
Registered: 2015-09-17
Posts: 8,059
Website

Re: Experimental BunsenLabs Lithium

johnraff wrote:

We don't use Win+p but yes Win+x would clash with our call to an exit dialogue.

I've been using Alt+Esc to trigger exit, and I'd like to suggest it here. It's less likely to be triggered accidentally, and then your thumb, or whatever digit you use, is already over the Alt key for the yad-exit shortcuts.

Offline

#92 2019-06-27 03:14:02

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,578
Website

Re: Experimental BunsenLabs Lithium

hhh wrote:
johnraff wrote:

...Win+x would clash with our call to an exit dialogue.

I've been using Alt+Esc to trigger exit, and I'd like to suggest it here. It's less likely to be triggered accidentally, and then your thumb, or whatever digit you use, is already over the Alt key for the yad-exit shortcuts.

They are a bit far apart for me, but any other opinions?


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#93 2019-06-27 03:37:33

hhh
Meep!
Registered: 2015-09-17
Posts: 8,059
Website

Re: Experimental BunsenLabs Lithium

Alt+x?

Offline

#94 2019-06-27 03:51:55

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,578
Website

Re: Experimental BunsenLabs Lithium

Let's start a new topic in Development for suggested changes to our default keybinds. Get it all done at once.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#95 2019-07-05 11:45:21

redrobo66
Member
Registered: 2018-03-18
Posts: 44

Re: Experimental BunsenLabs Lithium

With Buster due out tomorrow, what's the time frame looking like for the next Bunsenlabs release?

I've had to run an alternative for the past 6 months since my new PC was simply unusable on a Stretch based system (nothing worked, not even basic ethernet). So I've been enjoying OpenSUSE but really missing Bunsenlabs.

Offline

#96 2019-07-06 05:53:45

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,578
Website

Re: Experimental BunsenLabs Lithium

^We're all sweating gobs to get this thing out as soon as possible, but a broken system that would have to be followed by repeated bugfix upgrades (like some big companies we used to know) would be no fun.

We're looking at a test iso before long, but the final release will probably not be for another month, I'm guessing, possibly longer. It's a very small dev team and everyone has Real Life things too.

But if you're eager for BL on Buster why not do a Buster netinstall add the experimental repo and add BL from the metapackage? That's what this thread is all about, after all. It will be quite easy to switch to the regular BL repos later, after the official release.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#97 2019-07-06 07:54:06

Martin
Member
From: Stockholm, Sweden
Registered: 2015-10-01
Posts: 333
Website

Re: Experimental BunsenLabs Lithium

johnraff wrote:

^We're all sweating gobs to get this thing out as soon as possible, but a broken system that would have to be followed by repeated bugfix upgrades (like some big companies we used to know) would be no fun.

Don't rush it.

/Matin


"Problems worthy of attack
prove their worth by hitting back."
Piet Hein

Offline

#98 2019-07-06 13:09:22

ghorvath
Member
Registered: 2015-10-01
Posts: 142

Re: Experimental BunsenLabs Lithium

Hi Team!

First, thank for all the work you put into Lithium. Can't wait to try it when it will be ready.

2 quick questions:
- Now that a lot of development is going towards the possibility of using other WMs, will there be a page in bunsen-welcome, where the user could ask for installing, say, xfwm4, and then would get it completely bunsenified by the script?
- Raspberry Pi 4 is now basically as strong as a complete PC. Is there a chance to provide armhf support, maybe some netinstall script that can be used to set up a Bunsenlabs feel on Raspbian buster (already out). I haven't checked, but it might be that debian buster will also support the Pi 4. I have several Pis, and it always takes me a couple seconds to realize that Super+T doesn't open the terminal by default....

Again, thanks for all the hard work!

Offline

#99 2019-07-06 16:15:53

Sector11
The Tpyo Knig Mod
From: 77345 ¡#
Registered: 2015-08-20
Posts: 5,443

Re: Experimental BunsenLabs Lithium

Martin wrote:
johnraff wrote:

^We're all sweating gobs to get this thing out as soon as possible, but a broken system that would have to be followed by repeated bugfix upgrades (like some big companies we used to know) would be no fun.

Don't rush it.

/Matin

AMEN to that!

Polish vs broke anyday.


BunsenLabs Forum Rules ---== I'm a Conky 1.9'er ==---
System:    Host: d67 Kernel: 4.9.0-9-amd64 x86_64 (64 bit gcc: 6.3.0)
Desktop: Openbox 3.6.1 Distro: Debian GNU/Linux 9 (stretch)

Offline

#100 2019-07-06 20:11:41

hhh
Meep!
Registered: 2015-09-17
Posts: 8,059
Website

Re: Experimental BunsenLabs Lithium

ghorvath wrote:

Hi Team!

First, thank for all the work you put into Lithium. Can't wait to try it when it will be ready.

2 quick questions:
- Now that a lot of development is going towards the possibility of using other WMs, will there be a page in bunsen-welcome, where the user could ask for installing, say, xfwm4, and then would get it completely bunsenified by the script?

Most likely not for the release of Lithium. We have a lot to tie together still (package upgrades, new themes, icons and configs, the inclusion of jgmenu, a switch to our new bl-exit script, actually building and testing the ISOs...)

That said, this is something that can be included as an upgrade to the script at any time. Commits can be proposed by anyone to bunsen-welcome...

https://github.com/BunsenLabs/bunsen-welcome

Offline

Board footer

Powered by FluxBB