fluxbox v1.3.8 ?

skidoo · posted: 2017-04-27 04:26

Several weeks ago I went down the rabbit hole of modding fluxbox.
We're beyond the debian freeze, so debian"stretch" users will (still) be stuck with fluxbox v1.3.5
The v1.3.7, from 2015(!) is still sitting in debian"experimental" and is known (per upstream patches which immediately followed) to be buggy.

After merging the current fluxbox git"master" and the"debian" subdirectory from experimental repo, I scoured the github branches and cherrypicked various patches. Also, I cherrypicked (and modded) several bitrotting patches which had been submitted to the old fluxbox project pages at sourceforge. My new version builds fine (dpkg-debbuild) & runs fine on antiX16. Now I'm working through the miserable chore of attempting to (finally!) bring the fluxbox docs (and manpages) up-to-date.

I'll place a followup post once I've uploaded to github. Although I intend to provide (along with the source) a test (64-bit) *.deb file to testers, I'm averse to"maintaining" in the sense of creating redistributable binaries.

The new fluxbox version has several new and exciting (to me, at least) features. Off-the-cuff examples:

* The toolbar can (and, as provided, does) contain a"Menu" button.
This is important for use in sessions where desktop is managed by rox or spacefm.

* Additional custom buttons can be created (within init, specify label + Execstring for each) and placed into the toolbar.
One immediate usage could be a"toggle: ShowDesktop" (remove it if you don't want) button as found in many other environments.
Also, tweakers can specify inclusion of"spacer" placeholders to better control/customize the toolbar layout.

* fluxbox toolbar can now"make smart use of available width" when placing taskbar buttons.
Instead of a fixed/equal width for all buttons, a button for a window titled"Find:" (e.g. geany popup find dialog) can receive
a suitably narrow button (and a window titled"geany: /long/path/to/file_i_am_editing.txt" receives a wider button).

* The (my) default slated-for-antiX menu template contains a range of additional launchers, tucked into submenus,
along with a couple new top-level (wow, I didn't realize fluxbox could do THIS... and THAT!) menu items.

* probably unknown to Debian (and downstream) users, recent fluxbox version now provide"snap to edge" configurable feature.

* This (my) new version provides a new curated selection of fluxbox styles/themes.
Within the source package, none are shoehorned into the"debian" subdirectory. Expectation is that any undesirables can (will) be removed
during the build-iso, and (as is current practice) supplemented by styles provided/installed by the"fluxbox-themes-antix" package.
Similarly,"desktop-defaults-fluxbox-antix" should continue to provide (override) the packaged default"keys","init", and"menu" files.

ASKING: What is the"proper" version to declare for the package?
AFAICT, to avoid the need for apt-pinning, it must be higher than the version available from debian repos.

Would this be regarded as an appropriate packagename?
fluxbox_1.3.8-2-ski_amd64.deb

anticapitalista · posted: 2017-04-27 10:49

Sounds like a very good addition to antiX.

Package name- Using fluxbox_1.3.8-2-ski_amd64 seems ok to me.

I had a look at the fluxbox page and sourceforge, but do not see a 1.3.8 version - but I do see a 1.4 future dev one.

fatmac · posted: 2017-04-29 08:52

Sounds to me like this is turning a WM into a DE - IceWM & JWM fall into this category to my mind too.

What I like about Fluxbox, & other WM's is the fact that there are no extras, just a menu, brought up by clicking on a space of the background area. I don't even need desktop switching from a WM.

I know we all like something different, but I'll be running out of choice soon. __{{emoticon}}__

dolphin_oracle · posted: 2017-04-29 10:11

You can put an epoch version in front as well if necessary.

Like. 2:1.3.8

Or something like that. That should put it above versions in debian.

As a long time Flux box user, I look forward to trying this out! Thanks skidoo!

skidoo · posted: 2017-04-29 18:52

this is turning a WM into a DE

FWIW, quite a few of the"new" features were actually present in earlier versions, but were never documented.

Not mentioned in my initial post, I have separately rebirthed fbpanel as well as a menu editor GUI utility which enables editing icon+label+execstring of each entry and add/remove launcher and submenu entries. Those are not bundled into the fluxbox debfile. As for"menu button in the toolbar", I don't use a desktop manager to place icons on desktop, so have no immediate use for that ~~ but many users would, so support for the option to have such was added upstream in v1.3.7

fluxbox v1.3.5 packagefile from debian repos is 1.4Mb

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://ftp.us.debian.org/debian/pool/main/f/fluxbox/"
linktext was:"http://ftp.us.debian.org/debian/pool/main/f/fluxbox/"
====================================

vs 798kb for my latest v1.3.8 build
(the debian package included"branded" wallpaper, which I've nixed)

In an apples-to-apples comparison (all build flags enabled), v1.3.8 exhibits lower runtime memory overhead compared to 1.3.5. Chalk it up to improved internal garbage collection? I haven't altered the (puny) default pixmap cache allotment along the way.

Code: Select all

~/.fluxbox/init
session.cacheMax: 200
Specifies how much memory (in kilobytes) fluxbox may use to store cached pixmaps on the X server.
Consider lowering this value if your machine is low-spec, or runs short of memory. (default: 200)

session.cacheLife: 5
This tells fluxbox how long unused pixmaps may stay in the X server’s memory. (default: 5)

Compiling fluxbox takes only a few (like, about 3) minutes. For the sake of knowing, and toward documenting whether or not it"would be worthwhile" for someone to streamline their copy of fluxbox by disabling build flags for unneeded/unwanted features (xinerama support, nls lang/locale support, bidi {bidirectional characters/language} support) and DIY. No, the benefit is negligible. The debfile size shrinks by 200kb... and good luck accurately assessing the difference in runtime memory overhead ~~ in my testing, the RSS difference was within 1Mb.

The point of the above was to clarify:"No. Not turning a WM into a DE"

In my usage, the toolbar is set to autohide, no icons on the desktop, and the"slit" is hidden. I want the"environment" to stay the hell outa my way. Nonetheless, I value having the option to launch an additional panel (or 3) while working on certain projects... and now, given the option to place fluxbox menu button in toolbar, will probably shift using from fluxbox-min session (to fluxbox+spacefm).

Because I continually"change contexts" (various machines, various OSes), I cannot, or will not, memorize the buku many keybinds in effect in each context. At this moment, on this machine, I'm certain I have a fluxbox keybind set for"toggle: ShowDesktop" ...but, shrug, I'm at a loss to recall what it is. So, scratching my own itch, I'll likely ship a default which includes a (redundant) narrow toolbar button to perform that operation. If that's a waste of space/electrons in YOUR usage, you can remove it. Conversely, although toolbar buttons for"prev/next workspace" are useless for ME (autohidden toolbar, I change workspace via mousewheel) those remain present in the 1.3.8 default configuration. Even the"focus prev/next window in this workspace" buttons (I _do_ have Alt+Tab memorized by now, thankyouverymuch) are, IIRC, present in each of the new default as-shipped styles.

Do you know"wingrid"? Do you use the wingrid keybinds?
If so, why? Unless you're jumping between fluxbox/JWM etc sessions so rely on their consistent availbility...
fluxbox already contains native (internal) robust"arrange windows" functionality.
This functionality, like many of the other 125+ fluxbox"commands"
fluxbox --list-commands
has, historically, been poorly documented (or, for certain commands, undocumented entirely).
Until cows fly and I get a handle on revising the 56+ (looooong, rambling) pages of fluxbox wikidocs,
I'm shipping a default menu which exposes more of these"hidden/undocumented gems".

When did fluxbox introduce"fbrun"? Back around version 0.9.x?
Maybe that was the turning point re"turning a WM into a DE".
Idunno. What that feature even 'novel' at the time? Unique to fluxbox... or was inherited from blackbox?
Howabout the longstanding bundled"fbsetbg" utility? Set muh wallpapaz blingbling...

fatmac · posted: 2017-04-30 18:43

@skidoo - Sorry, my tongue was firmly in my cheek. (Maybe our humour differs.) __{{emoticon}}__

skidoo · posted: 2017-04-30 19:27

whoosh... yeah, I didn't catch the humor. I read it as a"valid concern, meriting a more detailed explanation".

skidoo · posted: 2017-05-03 02:59

This post is primarily a note-to-self

Confusingly, the manpage.in files in the fluxbox git repo
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/fluxbox/fluxbox/tree/master/doc"
linktext was:"https://github.com/fluxbox/fluxbox/tree/master/doc"
====================================

differ in content from their plain-text analogues residing in the"asciidoc" subdirectory.
Further confusing is the fact that nothing in the source tree, including the debian/ stuffs
nothing references those"asciidoc" subdirectory files.

Today I finally got around to opening the README in"asciidoc" subdirectory & now understand that re-generation of
fresh manpage.in files requires a separate (manual, prior to building the overall project) operation.
Whoops, the debian package maintainer apparently didn't realize that ~~ neither asciidoc nor"xmlto" (pkg required)
are listed among the build-depends.

asciidoc.org
Okay, the asciidoc program (plus xmlto utiity) can convert output to PDF, html...
...ah, thankfully that's different from"htmldoc" generator used to create the miserable, convoluted, 56 pages of htmldocs
I've been editing. Those docs, retrieved from sourceforge (allinone, or 56 separate pages) (and written for fluxbox v0.9x !)
will be provided via a separate"fluxbox-docs" package.

skidoo · posted: 2017-05-03 03:46

Styles ~~ are they"styles" or"themes"?
Maddeningly, confusingly... the inherited code, the paths and filenames, the manpages, the (html) wikidocs, the lines within the"init" and style.cfg ...inconsistently mention both.

For backward-compatibility, fluxbox does (and 1.3.8 will) recognize both"theme.cfg" and"style.cfg" files
but throughout the docs I've swapped in"style" anywhere theme was loosely mentioned.

related:
Within the 1.3.8 docs,"blackbox" will be mentioned once (a single occurrence, to credit"derived from") and then largely, or entirely, omitted.
500+ downloadable styles are available for fluxbox nowadays; user shouldn't care whether fluxbox is STILL compatible with blackbox theeeeemes.

===========

"resource files" vs"resources" vs"pixmaps" vs"icons" vs ...images(imagefiles)
An imagefile is a resource, and can be specified for use as a given icon...
...but an icon isn't necessarily an imagefile. It may an xpm (pixmap) resource file...
...and although the fluxbox"resource files" (init, menu) include references to various"resource" files.
I DON'T HAVE A HANDLE ON DRAFTING LESS-MADDENING"STYLING" DOCUMENTATION.

Nowadays, users probably expect to read"configfile(s)".
Nowadays, would-be theeemers stylists probably wanna know:
"can I use scalable (svg) here, or must I supply exact-sized imagefile? and, jpg is ok... or must be png?"

skidoo · posted: 2017-05-29 23:05

In advance of uploading to github later today the"fluxbox_1.3.8-2~ski_amd64.deb"
along with source code and step-by-step how to build instructions,
this post visually introduces various new features and explains a few points regarding the
"default as-shipped configuration" of this for-testing version.

Toward illustrating feature parity with other environments, the fluxbox toolbar (iconbar)"default as-shipped configuration" in this testing version includes a"Menu" button and a"Show Desktop (toggle)" button. The ridiculously wide"current workspace name" button shown in the screenshot underscores the point: regardless the CURRENT ws name, the button is sized to accommodate the longest textlabel (which was"Workspace Epsilon" at time of screencap). The disparity between the default ws names (one is"ws3", another is"Workspace Epsilon") hopefully stirs a new user into realizing that the name labels are customizable.

In my own usage, I would choose to drop the <|> previousWIndow|nextWindow buttons, in favor of using Alt+Tab... as well as the"Menu" button, but a new user might welcome having those available. When customizing, it's much easier to remove a toolbar item (especially a button) than to add from scratch. Seeing the customizable buttons in action is more enlightening (IMO) than poring through some dank ol' manpage(s) trying to figure out HowTo.

Fluxbox now provides native (vs wingrid keybinds) ability to auto-arrange windows within a workspace, plus Toggle_Maximize_Horizonally and Toggle_Maximize_Vertically. I think it's important to highlight this functionality, hence the prominent placement of the"Arrange WIndows (submenu)" menu item.

Yes, some of the menu entries are"redundant" ~~ the underlying rationale is to aid discoverability.
Although it's"just as easy" to ControlCenter }} Edit Fluxbox Settings
...arguably, the fluxbox default configuration shouldn't rely on a 3rd party app to expose"How To".

For the sake of fleshing out the Help submenu entries, this for-testing build installs a few html helpdocs.
Later, an expanded (dare I say"comprehensive"?) set helpdocs will be provided by a separately-installable deb package.
In the meantime, part of the"testing" is to ensure the installed htmldocs and manpages contain no inaccuracies. As for layout/format details, a"typo" is a bug; a section of preformatted text spilling beyond the border of an html DIV is not a bug (is just an indication of the WIP status of the docs).

dolphin_oracle · posted: 2017-05-29 23:26

this is looking fantastic skidoo!

skidoo · posted: 2017-05-30 00:13

A few weeks ago, I discovered
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://git.fluxbox.org/fluxbox.git/log/?h=prep/release-1.4.0"
linktext was:"http://git.fluxbox.org/fluxbox.git/log/ ... ease-1.4.0"
====================================

and this for-antiX-testing build is based on, forked from that WIP release-1.4.0 branch

I'm sticking with"v1.3.8" as the version label. In the future, if/when 1.4.0 ever hits debian repos...
...upgrading an existing antiX system to the 'official' 1.4.0 should be a smooth (non-breaking) upgrade.

OTOH, because this test-build is workaround-ing debian's"menu install" hooks & is shoehorning content
(default fluxbox menu, styles, fluxbox keybinds+init) typically provided by other packages and/or mechanisms...
it is not suitable for use on non-antiX systems.

Although this build & accompanying docs contain some"quirks"
(fluxbox docs repeatedly mention"lucida" font, which is not pre-installed in antiX)

and a couple"known issues", e.g.

Code: Select all

     at each startup (as noted in desktop-session log)

Failed to read: session.screen0.iconbar.iconifiedPattern
Setting default value
Failed to read: session.screen0.struts
Setting default value
Failed to read: session.screen0.struts.1
Setting default value

Code: Select all

(from my devnotes):
         fbrun   textbox should be MUCH wider, eh
         but
         can't pass param to FbTk::TextBox
         so, can the fbrun init() call a resize method?
         -=-
         Dammit, size is (surrent style) locked at 200x13    NOT resizable via ALT+rightmouse drag
         interestingly (related bug/feature)
         attemting to"maximize" the fbrun window causes it to snapto 0,0
         and it cannot be dragged via titlebar until/unless it is UNmaximized (by issuing"maximize" again)

         pssst ~~"gExec" runbox is typically used (not fbrun)
         so don't sink a lot of time into wrestling with this

...during testing, you should expect trouble-free operation
(any outright BUGS are hopefully minimal, hard to find/notice/discover)

Code: Select all

BUG:  max.horiz and max.vert (windowmenu) are NOT fully maximizing the width
      until/unless the window is dragged (then it *is* snapped, and fills the entire width
      REGRESSION?   I THOUGHT I'D SUCCESSFULLY TESTED THIS PREVIOUSLY

Code: Select all

BUG, or uncleaar docs?
after trying each of the following within my fluxbox init
                      session.screen0.iconbar.iconifiedPattern: %t
                      session.screen0.iconbar.iconifiedPattern: foo %t
                      session.screen0.iconbar.iconifiedPattern: ( foo %t )
          I FOUND NO CHANGE (each of the above yields an identical result)

skidoo · posted: 2017-05-30 04:30

attached to this post is"fluxbox_1.3.8-2~ski_amd64.deb" renamed to .zip to permit upload to forum
( md5sum of the file is 19042cea125f3971ae8b385a385a3220 )

the sourcecode is available here:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/antix-skidoo/fluxbox"
linktext was:"https://github.com/antix-skidoo/fluxbox"
====================================

along with step-by-step instructions how to build on your machine:
========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"https://github.com/antix-skidoo/fluxbox/blob/master/INSTALL#L29"
linktext was:"https://github.com/antix-skidoo/fluxbox ... NSTALL#L29"
====================================

@prospective testers:
After downloading the attachment, rename it ( remove the tail-end .zip )

As noted within earlier posts in this topic, typically some of the antiX fluxbox configfiles
are pre-installed by other debfiles. Installing this"fluxbox v1.3.8-ski" debfile to an existing antiX system
necessitates some preparatory steps:

Code: Select all

    0) before proceeding, switch away from fluxbox session ~~ perform the following
        from an icewm or JWM session

    1) FOR TESTING (and in case you wish to rollback):
           sudo cp -R /usr/share/fluxbox  /usr/share/fluxbox_bak

    2) cp -R ~/.fluxbox  ~/.fluxbox_bak

    3) By design, your existing"startup" file will be preserved.
       FOR TESTING, we want to ensure fluxbox uses"fresh, new version config files, so
           rm ~/.fluxbox/init && rm ~/.fluxbox/keys && rm ~/.fluxbox/menu
           rm ~/.fluxbox/overlay && rm ~/.fluxbox/windowmenu

    4) Install the package by issuing the following command:
       sudo dpkg -i /path/to/working_dir/_name_of_the_new_fluxbox_debfile.deb

    5) Start a new fluxbox session and check out the new menu entries (and newly-installed styles)

Recommended followup:
view the inline comments (notes/tips) within the newly-installed ~/.fluxbox/keys file

NOTE: INSTALLING THIS DEBFILE DOES NOT UPDATE THE"SYSTEM-WIDE DEFAULT COPIES" /etc/fluxbox CONFIG FILES
(A NEWLY-CREATED USER ACCOUNT WILL RECEIVE"OLD VERSION" CONFIGFILES)
The"other user(s)" scenario is beyond the current scope of testing.
However, if you decide to"create a new user account and test", you can expect:
· the new user does receive a"Menu" toolbar button, but some"new" items are (still) absent from the RootMenu menu
·"new" items are absent from windowmenu...

skidoo · posted: 2017-05-30 05:03

if you type at a terminal prompt: apropos fluxbox
you'll find that all the fluxbox-related manpages are (now, as of v1.3.8) listed

fbpager (1) - pager application for the Fluxbox window manager
fbrun (1) - displays a Run... dialogwindow (provided by"fluxbox" package)
fbsetroot (1) - a simple background utility used by the fluxbox(1) window manager.
fluxbox (1) - A lightweight window manager for the X Windowing System
fluxbox-apps (5) - per-window attribute configuration for fluxbox(1)
fluxbox-keys (5) - keyboard shortcuts configuration for fluxbox(1)
fluxbox-menu (5) - fluxbox(1) menu syntax
fluxbox-remote (1) - command line access to key commands for fluxbox(1)
fluxbox-style (5) - A comprehensive look at Styles for fluxbox(1)
fluxbox-update_configs (1) - A lightweight window manager for the X Windowing System
startfluxbox (1) - start a fluxbox session

I have diverted"fluxbox-update_configs" to open the main"fluxbox" manpage
(currently, that bundled utility is not useful in antiX. Its executable is still built, but is removed during dpkg post-install)

fbsetroot ~~ it's been part of fluxbox since way back when. Use it (call it manually/scripted), or don't.

fbpager ~~ part of fluxbox since way back when. Butt ugly, feature limited compared to other (3rd party) pager utils

fbrun ~~ part of fluxbox since way back when. I've included an example (containing colorized text+bgcolor) in the default menu.
A history of commands entered is maintained ( ~/.fluxbox/history ) and history items are accessible
via up/down arrow keys... but, all things considered, gExec is a more appealing runbox utility.

fluxbox-remote ~~ added to fluxbox several versions ago, but has seldom been mentioned.
It offers very creative scripting possibilities.

rust collector · posted: 2017-06-30 02:02

I just did a quick test of this (on mx), and I am looking forward to try it on antix.
looks good!
Thanks skidoo