Ok, it isn't pretty (yet), but I fixed Radical to work on master. It is still too dirty to commit into a new branch and it wont support both 3.5.6 and master in the same branch (impossible)
Basically, all item.styles are lost and it is still crashy. The trick was mostly to replace all fit method with the new syntax. The draw ones are mostly broken, but compatible "enough" not to crash. Also, the high-DPI support (retina Mac Book Pro) is not yet implemented.
That being said, a lot of the hacks used by Radical can be "merged" into the new API so once implemented, this will simplify the code (no more wibox.widget.fit and radical.item.fit duplication).
So, as @mindeunix pointed out, the complexity of the code base is out of control. I guess e is right and I will have to go back to the drawing table to simplify the abstractions so they can seamlessly use Awesome layout system instead of the duplicate system (actually, it is more a proxy between Awesome and Radical).
So, for the Awesome 3.6 version of Radical, I think it could look like:
- Implement the contextual fit so High-DPI is supported without relying on
beautiful.default_height (yes, Radical does support High-DPI using this hack, I own 2 High-DPI devices and it work)
- Remove
item_fit and use the new contextual mode for fit to store the context that was kept by item_fit (work in progress)
Use "real" wibox.layout, so all radical.layout and radical.item.layout need to be converted to fully compliant wibox.layout without extra internal hacks inside Radical to handle them
Remove setup_drawable and the other ones to use proper wibox.widget constructor
Figure out how to re-enable complex radical.item.style
Ok, it isn't pretty (yet), but I fixed Radical to work on master. It is still too dirty to commit into a new branch and it wont support both 3.5.6 and master in the same branch (impossible)
Basically, all
item.styles are lost and it is still crashy. The trick was mostly to replace allfitmethod with the new syntax. Thedrawones are mostly broken, but compatible "enough" not to crash. Also, the high-DPI support (retina Mac Book Pro) is not yet implemented.That being said, a lot of the hacks used by Radical can be "merged" into the new API so once implemented, this will simplify the code (no more
wibox.widget.fitandradical.item.fitduplication).So, as @mindeunix pointed out, the complexity of the code base is out of control. I guess e is right and I will have to go back to the drawing table to simplify the abstractions so they can seamlessly use Awesome layout system instead of the duplicate system (actually, it is more a proxy between Awesome and Radical).
So, for the Awesome 3.6 version of Radical, I think it could look like:
beautiful.default_height(yes, Radical does support High-DPI using this hack, I own 2 High-DPI devices and it work)item_fitand use the new contextual mode for fit to store the context that was kept byitem_fit(work in progress)Use "real"wibox.layout, so allradical.layoutandradical.item.layoutneed to be converted to fully compliantwibox.layoutwithout extra internal hacks inside Radical to handle themRemovesetup_drawableand the other ones to use properwibox.widgetconstructorFigure out how to re-enable complexradical.item.style