#41 2017-04-17 08:41:22

ido

Member

Registered: 2017-04-17

Posts: 8

Re: Windowmanagers - a slow marathon with breaks

ohnonot, thanks for writing that fluxbox article and for posting a link to it.

I've been using fluxbox for a couple years, primarily due to just wanting "a WM that stays outa my way". Recently, while looking for a missing "feature", I checked the changelog (linked to the packages.debian.org page for fluxbox) and lo-n-behold, 1.3.7 seemed to have that feature... but that version is sitting (since 2015) in debian "experimental" repo. Sigh.

Topic: how to achieve vertical (left-side) toolbar + HORIZ button text ?
vsido.org/index.php?topic=1285.0

When I traipsed around looking for the current code, geez unmerged patches sitting since years ago which were uploaded to sf.net... 2yr-old outstanding pull requests at github... I wound up collecting & applying patches atop git1.3.7+ and rolling my own debfile.

I intend to post the source + "howto build" instructions to github. Would you be interested in building + testing it?
(and in collaborating toward further modding the code + FINALLY achieving comprehensive, up-to-date docs)

To be clear: I'm averse to uploading and distributing a .deb and I hope the excercise will teach prospective testers/adopters how easy it is to DIY build.
I don't intend to fork fluxbox, I'm just tinkering with maintaining a custom build/branch of it.

Your blog article didn't hint that you're aware of all the new functionality fluxbox has gained in recent versions.
Yeah, as you mentioned, lotsa 'stuffs' has never been documented.
Did you realize that we can now create freeform toolbar buttons?
(as in, within init: declare a button, a label, an Exec string ... and specify the button via the toolbar.tools line as a named, placeable, item)

I read that your modded fluxStyle utility creates missing preview images.
Wow, I woulda never considered that angle. I started (then parked, as back burner) crafting a python+gtk+sqlite utility to display the tenr.de "preview.jpg" images... with the intention of populating a db with "tags" like the color(s) etc for each of the indexed themes in the collection. An as-you-type filter would present a listview containing matching themes (maybe w/ screenshot for each) and right-clicking an entry would expose actions to "edit this record (add/edit tags or description)" and "testdrive". I reckon the app should be able to temporarily copy-into-place ~/.fluxbox/styles/styleX and remove it after testdriving, if user decides it's not a keeper.

ido

Member

Registered: 2017-04-17

Posts: 8

Re: Windowmanagers - a slow marathon with breaks

ps:
You've modded fbpanel as well? That's where I too wound up, in pursuit of achieving a wiiiiiide horizontal taskbar (iconbar?).
I'm disabling its tray (leave that to fluxbox toolbar or tint2 or) and most of its other plugins.
My fbpanel build has a nuisance message bug, logged at each mouseout event.
(along the lines of: garbage collection called on a non-existent object) Have you witnessed such a message?

Last edited by ido (2017-04-17 19:20:30)

ohnonot

...again

Registered: 2015-09-29

Posts: 5,592

Re: Windowmanagers - a slow marathon with breaks

thanks for your feedback.
i'll be happy to testdrive your "all patches included" version of fluxbox - on archlinux.

1.3.7 seemed to have that feature... but that version is sitting (since 2015) in debian "experimental" repo. Sigh.

one of the many things i forgot to mention in the article:
i'm on archlinux and the evrsion tested is 1.3.7

Topic: how to achieve vertical (left-side) toolbar + HORIZ button text ?
vsido.org/index.php?topic=1285.0

iirc, the toolbar can be vertical, and then rotates the font 90 degrees? A rather cool feature imo.

Did you realize that we can now create freeform toolbar buttons?
(as in, within init: declare a button, a label, an Exec string ... and specify the button via the toolbar.tools line as a named, placeable, item)

erm, no i wasn't.
can you show/explain/link?

about fluxStyle: my changes are extremely trivial.
i can't even code in  python.
just as a thought, and if i understand correctly, openbox uses a separate library to create the previews: libobrender.

ohnonot

...again

Registered: 2015-09-29

Posts: 5,592

Re: Windowmanagers - a slow marathon with breaks

You've modded fbpanel as well?

where did you get that impression?

ido

Member

Registered: 2017-04-17

Posts: 8

Re: Windowmanagers - a slow marathon with breaks

fbpanel ~~ dunno whether I just misread or was jumping between multiple browser tabs and got confused about the context where I read about someone's fbpanel mod.

I think there's an open ticket against 1.3.7 in which someone claims the "generic button" feature does not work. I thought so too, until I got 'round to wading through the code.
howto:

Decide an itemname for the button. In this example, button shall be named "boog".
Edit ~/.fluxbox/init and add these lines:

session.screen0.toolbar.button.boog.label: Menu
session.screen0.toolbar.button.boog.font: sans-10  # this line is optional
session.screen0.toolbar.button.boog.commands: RootMenu:Exec

Also, modify your "session.screen0.toolbar.tools:" line, to place the button (and to specify its ordering among the other elements).
e.g. for leftmost placement

session.screen0.toolbar.tools: button.boog, workspacename, prevworkspace, nextworkspace, iconbar, . . .

doc/asciidoc/fluxbox.txt
https://github.com/fluxbox/fluxbox/tree … c/asciidoc
you can see here that it (docs) wasn't added until 7mos ago.
IOW, anyone whose distro is shipping a package older than 7mos (cough, "debian experimental repo") wouldn't have seen the doc.

Button.<name>
    A generic button with customizable label and mouse actions
The contents and behavior of the toolbar can be configured, see the TOOLBAR section for details.

. . .

session.screen0.toolbar.button.<name>.commands:   string:string:string:string:string
A colon delimited list of commands, executed when the respective mouse button is pressed on the toolbar button tool "button.<name>"
The commands are the same as those detailed in fluxbox-keys(5).
Default: blank

This particular example might not be appealing for a bangcruncher (FWIW, my daily driver is antiX)
but is useful in setting up a session in which `spacefm -d`, or Rox (or pcmanFM?) is autostarted.

Last edited by ido (2017-04-18 07:57:59)

ido

Member

Registered: 2017-04-17

Posts: 8

Re: Windowmanagers - a slow marathon with breaks

iirc, the toolbar can be vertical, and then rotates the font 90 degrees?

Maybe I fell victim to lack-o-docs, but I tried everywhichway and wound up with only the pixmaps being rotated.
In dealing with c++, I'm more like a reverse engineering tweaker/patcher than "programmer".
My reach exceeded my grasp ~~ headspin when I considered the prospect of trying to rewrite the FbTk container classes.

fbpanel won my favor b/c it can run multiple concurrent instances, each with a separate config and customized edge placement.
I don't have a HiDPI display but have read comments grousing about fluxbox inability to scale pixmaps well.
Need to recheck, but I think fbpanel can render some imagefile types that fluxbox cannot. png? svg?

ohnonot

...again

Registered: 2015-09-29

Posts: 5,592

Re: Windowmanagers - a slow marathon with breaks

Decide an itemname for the button. In this example, button shall be named "boog".
Edit ~/.fluxbox/init and add these lines:

session.screen0.toolbar.button.boog.label: Menu
session.screen0.toolbar.button.boog.font: sans-10  # this line is optional
session.screen0.toolbar.button.boog.commands: RootMenu:Exec

Also, modify your "session.screen0.toolbar.tools:" line, to place the button (and to specify its ordering among the other elements).
e.g. for leftmost placement

session.screen0.toolbar.tools: button.boog, workspacename, prevworkspace, nextworkspace, iconbar, . . .

i must admit, it didn't work for me either. no error , the toolbar is as if the button hasn't been added at all...

session.screen0.toolbar.button.boog.label:	Menu
session.screen0.toolbar.button.boog.commands:	RootMenu
session.screen0.toolbar.tools:	prevworkspace, workspacename, nextworkspace, button.boog, iconbar, clock

my version is 1.3.7-2. built on dec 2015.
maybe i have to try the git repo.

ido

Member

Registered: 2017-04-17

Posts: 8

Re: Windowmanagers - a slow marathon with breaks

this is a "note-to-self" or "FYI" post ~~ no reply expected

http://dt.iki.fi/fluxbox-windowmanager

I grabbed the old documentation
( hyperlink to: dt.iki.fi/stuff/fluxbox/fb-doc-mfhtml.tgz )

Looks like you grabbed "Multifile HTML" from fluxbox.sourceforge.net/docbook.php
FWIW, the "Singlefile HTML" available from that sourceforge page is easier, er, less miserable to search (browser Find in Page)

additional unlinked souceforge -hosted doc pages (found via google search)

        "Getting Started"
        http://fluxbox.sourceforge.net/docs/en/ … arting.php
       
        "Ultimate Guide to fluxbox Tabs"
        http://fluxbox.sourceforge.net/docs/en/ … abbing.php
       
        "Keybindings"
        http://fluxbox.sourceforge.net/docs/en/ … ndings.php
       
        "Setting Backgrounds"
        http://fluxbox.sourceforge.net/docs/en/ … rounds.php
       
        "The Slit"
        http://fluxbox.sourceforge.net/docs/en/newdoc.slit.php
       
        "Editing Your Menu"
        http://fluxbox.sourceforge.net/docs/en/ … nuedit.php
       
        "The Basics of Themes (styles) in Fluxbox"
        http://fluxbox.sourceforge.net/docs/en/ … themes.php

I downloaded & extracted the 56 page html docset available here
https://github.com/fluxbox-wiki/fluxbox … /howtos/en
and pared away the pages containing out-of-scope blather (IMO) like "howto talk to IRC chatbots".
To prevent eyebleed while editing, I've ripped out nearly all of the markup in favor of giant PRE blocks and a few bordered divs.
Reputedly (I have not tried), the asciidoc utility which is currently employed to generate the fluxbox manpage content during build
is able to also export individual pages to HTML format. That would probably require followup (to convert all the "see: fluxbox-pikachu(5)" manpage -ish occurrences into hyperlinks). Besides, the docs really need to reside in a separate source tree / git repo, else their content pollutes `grep` searches across the source files.

ohnonot

...again

Registered: 2015-09-29

Posts: 5,592

Re: Windowmanagers - a slow marathon with breaks

i must admit, it didn't work for me either. no error , the toolbar is as if the button hasn't been added at all...

session.screen0.toolbar.button.boog.label:	Menu
session.screen0.toolbar.button.boog.commands:	RootMenu
session.screen0.toolbar.tools:	prevworkspace, workspacename, nextworkspace, button.boog, iconbar, clock

my version is 1.3.7-2. built on dec 2015.
maybe i have to try the git repo.

i tried the git master, it works as expected with that (however now i can't maximize over the whole screen anymore, 20px are left at top, dunno why, after 5min of not finding the problem i simply reverted back to fluxbox from the repos - a typical fluxbox story).

ido

Member

Registered: 2017-04-17

Posts: 8

Re: Windowmanagers - a slow marathon with breaks

session.screen0.toolbar.button.boog.label:	Menu
session.screen0.toolbar.button.boog.commands:	RootMenu
session.screen0.toolbar.tools:	prevworkspace, workspacename, nextworkspace, button.boog, iconbar, clock

session.screen0.toolbar.button.boog.commands: RootMenu:Exec

Do you now see?

ido

Member

Registered: 2017-04-17

Posts: 8

Re: Windowmanagers - a slow marathon with breaks

Ironically, you've mentioned Arch linux; packrat over at visido mentioned Void Linux. I chose to inquire here and at vsido forum expecting testers would have debian-based system; I'm not confident that my mods have not polluted the source tree with debian -centric bastardizations, like ripping out the "fluxbox-generate_menus" utility, b/c it is not suitable for use with antiX, nor debian in general.

I noticed that 1.37git (and debian's v1.3.7 copy in eXpErImEnTaL) damages the "keys" file content when fluxbox is upgraded from an earlier version. The "util/fluxbox-update_configs.cc", among its other operations, blindly (redundantly) postpends certain lines in the keys file, introducing breakage (evident in ~/.desktop-session/log)... so I've also ripped out that "update_configs" utility. Intend to ship a new default init; ta hell with bending over backwards to support upgrade from myriad versions spanning 1.5 decades.

Another inherited problem I'm wrestling with:
One of the default bindings specified in "keys" file reads "Control Mod1 Backspace :Minimize"
Same as in v1.3.5 and earlier, on every system I've tested, use of that keybind exits (crashes?) the fluxbox session.

git master [..] now i can't maximize over the whole screen anymore, 20px are left at top

Haven't witnessed that particular bug here. As of the v1.3.7 release (which the debian maintainer cloned), there was an annoying visual bug with width of desktop menu columns. That issue has now been explicitly patched in the current git. My further patched build intermittently displays empty "title" elements in the menus (after swapping between styles, until restarted); IDK whether that misbehavior is something I inherited, or introduced.

ohnonot

...again

Registered: 2015-09-29

Posts: 5,592

Re: Windowmanagers - a slow marathon with breaks

session.screen0.toolbar.button.boog.label:	Menu
session.screen0.toolbar.button.boog.commands:	RootMenu
session.screen0.toolbar.tools:	prevworkspace, workspacename, nextworkspace, button.boog, iconbar, clock

session.screen0.toolbar.button.boog.commands: RootMenu:Exec

Do you now see?

i said it is working as expected - exactly the way i wrote it.
after all, the documentation said that it "follows the syntax of the keys file".

there was that maximizing issue with the git repo; i didn't feel like investigating it so after a cursory glance i simply went back to the [community] version.
but yeah, built in Dec 2015, for archlinux that's positively ancient ...