Elv13
commented
8 years ago I pushed a major rewrite. The bug is fixed (and all the unmaintainable code related to it is gone forever). In theory, this should now work, but there is some improvments to be done to get rid or more .fit method overrides. Depending on the menu layout, these may still cause the bug. But the "core reason" why this happen has been fixed.
I am not about 50% into the re-write. The model and core APIs are the next things I will do. This will obviously break the API, something I managed to mostly avoid until now.
The first thing I will do is to replace the underlay/overlay system. Hopefully the next one will be more flexible and useful, but will have a totally different API (and name). There is still many places in Radical with hardcoded underlay code. I need to get rid of it so I can refactor those modules. After that the theme API will change. I hope to be able to change the theme at runtime, this would be nice. I will get rid of most item_styles. Since a few commit they are now placeholders anyway, the code is already gone. Item styles can now be generated from shapes dynamically. Finally, I will try to attack the core.
Also, I don't know if you saw, but you really want to use: http://awesomewm.github.io/apidoc/documentation/03-declarative-layout.md.html
Eventually (hopefully), Radical, the wibox.widget disposition, tag declaration and the client layouts will all share the same declarative syntax.
Feel free to report the (many, many) regression I just caused. I know about most of them, I am just not done implementing everything back.
As an example I have menu
when clicking on the - (minus) icon my widget changes its size to 0,0
but radical menu geometry remains unchanged. a simple signal would be enough I think
and maybe something like that is already there, I just missed it?