missing dynamic.lua.. there is new depency rquired?

[landscape69]

somehow broken...

[Elv13]

Opps, yea, I should mention there is a missing module. Either copy/paste it into ~/.config/awesome/awful/layout or use the upstream_shape_api_p4_unmerged from my Awesome fork. I will package it better as it wont be merged into Awesome anytime soon.

[landscape69]

can you put it on your config on github please. i dont find this anywhere to paste/copy it into :))

[Elv13]

This is my config, as-is and without any changes. I was talking about Awesome itself.

This is my Awesome development branch (the name is random, I know) https://github.com/Elv13/awesome-1/tree/upstream_shape_api_p4_unmerged . It is always a few commits ahead of Awesome git-master. In theory, I could make modules for all these things, but that would put me back to square one. Awesome 4.0 has a clean version of many of my old internal APIs. Going back to make modules for everything will be a dead end again. The 2014 (Awesome 3.5) version of my config was unmaintainable and relied on layers upon layers of hacks to "fix" Awesome own APIs. Just look at the diff when I "ported" it to Awesome 3.6/4.0, it is a full rewrite.

For now I wont support running my WM on top of the official Awesome releases. Just like I did for 3.4, only my fork will be supported. Maybe for Awesome 5 I will support the vanilla source again, but that remain to be seen. That being said, I will probably fork this project into a more official WM and make sure it works with Awesome latest version to make it easier for "regular users" to access my features. All of my modules master branch also supports Awesome 4.0.

[landscape69]

well this will be a hack for me again. this will be hard to convince any developer to make a live ebuild for an unoffical fork of awesome in gentoo :(. its really pitty that everyone do his own work and dont cooperate.

the version 4.0 ist fresh released now i must waiting for version 5.0 to hope for support :))

[Elv13]

Its really pitty that everyone do his own work and dont cooperate.

I don't think you correctly understand the situation. I am one of the core AwesomeWM developer and I have been since day one (even if I didn't tried to merge my changes during the first few years and favored modules). You are using my testbed configuration. It is where features are tested before they go into Awesome (if ever) or are packaged into modules. For 3.5, I used modules for everything so I could support the default Awesome binary. This was a failure, as it required me to develop workarounds and internal APIs that reduced maintainability and increased code duplication across the modules. Doing module was also a failure because almost nobody used them. Awesome lost ~70% of its userbase since 3.4 was released. Most of this have something to do with the fragmented ecosystem and the lack of standardized "useful" components.

I am not "fragmenting" things even more by using a fork for this config. I am solving the fragmentation by merging my config into Awesome. However this takes time and require consensus on every design decisions. Some very important components, such as the new layout system, are very large and controversial. Awesome 4.0 was already too big (2200 commits and 4 years) to include such a major project. Most of the other patches could have been merged, but would have delayed the release so I moved them to the next version.

[landscape69]

ah ok thanks for this good explanation.

now i understand it better and i see your works as really necessary, because after every version release i had also a lot of problem to customizing my configs files for awesome since, 3.4.

i think its really great and also my feature-request once that your nice configuration get merge into official awesome features, if u could remember.

but at the moment the awesome configuration, which u are releasing here is only suitable to a fork of awesome wm and u are head developer of it. why not let user contribute help by testing it in the officially awesome wm somehow... so u can also get feedback from user and can fix all problems and merge it step by step into upcoming official release 5 ?

[Elv13]

u are head developer of it

No, I am not, @psychon is. AwesomeWM is not a 1 man project, it is an healthy community with tens of active developers every years. It also has users who rightfully expect stability. My config is everything but stable. It has never been and never will be. I fix most (ok, some) bugs that are reported and implement most good ideas proposed. I also change things all the time. This isn't something 99% of the Awesome users would appreciate. I already pushed my luck (and psychon nerves) quite far last year with 37,000 lines of changes to make 4.0 happen, more activity than the previous 5 years combined.

why not let user contribute help by testing it in the officially awesome wm somehow...

Because I would have to make more modules and they would diverge from the mainline APIs again. It failed last time. One of the trait of stupidity is doing the same thing many time and expecting different outcomes. I wont waste my time implementing a strategy that was a total failure. Moving the dynamic layout system into a module will only make it harder to merge later on, same thing for the other widgets and layouts present in my fork.

once that your nice configuration get merge into official awesome features, if u could remember.

The config itself wont get merged, its [important && sane] features are / will be (hopefully). Awesome 4.0 already inherited most of the widgets and API improvements to all core modules and libraries. For example, the retrograde module was fully merged. One of the 3 main components of blind (the shape API) was merged and integrated with 11 other APIs. All of Tyrannical low level hooks were standardized so the new version doesn't require monkey patching anymore (the request API and awful.rules improvements). For Collision, the way geometry changes are handled was totally rebuilt. The Radical object model and GUI library was merged and is now used by all official widgets. The shorter module was deprecated in favor of the new official hotkey framework. UltiLayout was rewritten to use the new layout system (but as stated above, is not merged). WireFu, Forgotten and FdAsync are still candidates for inclusion, but are far down the priority list. Repetitive is the only module that's unchanged. It would require an input handling overhaul and neither me or @psychon want to touch that code with a 10 foot pole. That module work fine as it is anyway.

[landscape69]

well this sounds very interesting. i seriously in love with your improvement since the first day as i use it, even i am only a common user and it took me also a bit time to get into they way how to customize it all.

i took for sure also some nerves of you and psychon here and in IRC :).

i mean rename the fork as awesome-5-beta or whatever, package it out of the box with all stuff and release it ... its way better to keep the fork hidden...this would also easier for us to make request at our Unix-distribution-maintainer for merge this testing stuff in testing repository and we would have more user.

i am sure your works deserve more attention and user would love it too like i do :)

[psychon]

Repetitive is the only module that's unchanged. It would require an input handling overhaul and neither me or @psychon want to touch that code with a 10 foot pole.

(Ah, that's why GitHub shows me this issue).

What kind of input handling overhaul? After taking a quick look at the code, I can say that... I have no idea. What's wrong?

[Elv13]

What kind of input handling overhaul? After taking a quick look at the code, I can say that... I have no idea. What's wrong?

You 23 days ago in #1267 ;)

(so I only need to find someone who manages input handling and keygrabber mess... :-) )

From the top of my head right now:

• Enabling and disabling keybindings at runtime is almost impossible
• Keybindings have silent collision issues
• Adding keybindings at runtime is ugly
• Implementing tag specific or client specific keybindings is ridiculously impractical (yes, I know about the awful.rules trick)
• Sometime the (mostly mouse) input is also sent to the client, sometime not (due to press and release events not being captured together)
• Keygrabbers can't handle recursiveness properly
• It isn't possible to send raw inputs to clients (that would otherwise be eaten by the keygrabber or keybindings) [3]
• The clipboard API is lacking (that's input too!)
• There is no way to implement input pass though for wiboxes (Plasma, Mutter and Unity have it)
• Awesome doesn't support trackpad gestures (requires libinput)
• Everybody is switching to libinput because its better (and supports modern input devices better [1], and make migrating to wayland easier)
• Repetitive implements macro support almost fine, but keep hitting either Fake input cannot bypass Awesome keys (shortcuts) awesomeWM/awesome#77 or root.fake_input({}, " ") or root.fake_input({}, "space") doesn't work awesomeWM/awesome#815

Then again, as I said, those would be "nice to have", but I don't expect either of us to do something about these.

i mean rename the fork as awesome-5-beta or whatever, package it out of the box with all stuff and release it ... its way better to keep the fork hidden...this would also easier for us to make request at our Unix-distribution-maintainer for merge this testing stuff in testing repository and we would have more user.

No distribution will merge/package/ship something that breaks its own API every week. Awesome itself already have grumpy maintainer complaints about breaking it every few years. The features in my fork are not ready and don't have a stable API, that's why they are there.

I suggest you try my new version. It is really much better than the one for Awesome 3.5. The new launcher features and the dynamic layout editor (mod4+s) are very nice improvements over the old version. The only drawback is that you have to upgrade both the config and the core libraries at once. You don't have to install my Awesome fork. You just have to add --search option to the awesome command to point my fork build/lib/ directory. In theory, you could also use ln -s of gears, wibox, and awful in your ~/.config/awesome and it should work (note that you have to run make first to make sure the paths in awful.util are set).

I know you don't like the fact that it doesn't work with the vanilla version. This isn't optimal and it also hurt me a little because I put a lot of work over 8 years writing the stuff and I know almost nobody will use it for the next year due to that. All[2] my modules are working fine with the vanilla version. It is only the experimental stuff that isn't.

[1] Multi-trackpad, multitouchscreen, Wacom multisurfaces and VR
[2] Shorter, UltiLayout and Retrograde are deprecated and wont be ported
[3] Repetitive have a weird hack to pause and restart the mousegrabber/keygrabber between each events

[psychon]

(Sorry for hijacking the discussion here)

There is no way to implement input pass though for wiboxes (Plasma, Mutter and Unity have it)

You mean "when I click on the wibox, the window below the wibox should get the event and not the wibox"? That's easy to implement.
So far we only use version 1 of the SHAPE extension (bounding and clip shape). Version 1.1 added an input shape that should do just that. If you want, I can easily handle the C side of this. If so, please open an issue at the awesome repo for this and assign it to me.

Awesome doesn't support trackpad gestures (requires libinput)

Just a short nitpick: AFAIK: No, it does not require libinput. libinput is a server-side thing (X11 server), not client-side. On the client side, we would have to switch to using the INPUT extension and then... something, I don't know. But yeah, I try not to touch this topic....

The clipboard API is lacking (that's input too!)

That's awesomeWM/awesome#492. Sounds like I should start working on that one, should I?

[Elv13]

If so, please open an issue at the awesome repo for this and assign it to me.

That would be cool. I will finally be able to add 10 layer thick of additional randomness to make my computer look busy like in movies!. But seriously, this is useful for notifications and non-intrusive system alerts (and for less useful hacks https://www.linux-apps.com/content/show.php/BeClock?content=117542 )

That's awesomeWM/awesome#492. Sounds like I should start working on that one, should I?

That would be very welcome. I know someone on IRC had a couple of broken patches for it. I didn't hear about him in many months. I think getting the selection buffer and secondary buffer was working, but not the events. I also guess glib or gtk probably have a MIME parser we could re-use. There is also some performance concerns that will need to be investigated.

libinput is a server-side thing (X11 server), not client-side.

Its both, right? In the X11 world you don't need to use it on the client side, but Wayland aware toolkits started doing so anyway (no?). In Wayland the picture is even worst, as there is no WM or proper server. The compositor is the server, the DE, the WM, the hotkey daemon, the clipboard manager and security bouncer (Awesome is also most of these things... but not the compositor). But they also delegate some work to the toolkits. Anyway, this is off topic and I didn't worked on my toy Wayland port since last year.

[psychon]

Random idea: Add something like awful.Elv13_version = true to your version of awesome and check for this value in your config. That way you can provide a better error message than this "dynamic not found".

[BeniaminK]

Just update... The branch we are looking for is doc_tests_and_notif ( https://github.com/Elv13/awesome-1/tree/doc_tests_and_notif ), I guess...

[Elv13]

Yeah, this isn't getting any better, is it... At least the "doc" and "notif" part of that branch is mostly merged. Having a clear branch for the dynamic layout stuff isn't really working for me because I apply multiple unmerged patchset at the same time to beta test them. I guess I should rename the branch "experimental" at some point.