Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Awesome git-master support #36

Open
Elv13 opened this issue Dec 26, 2015 · 3 comments
Open

Fix Awesome git-master support #36

Elv13 opened this issue Dec 26, 2015 · 3 comments

Comments

@Elv13
Copy link
Owner

Elv13 commented Dec 26, 2015

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
@mindeunix
Copy link
Contributor

Thanks, I really waiting this commit.

My Awesome wm configuration highly depends on the Radical menus, and I want to update everything to the 3.6 branch. As you have already guessed I have started writing my own Implementation (which already have basic functions to draw wibox/add widgets) but I do not want to leave Radical because everything I need it already have.

@mindeunix
Copy link
Contributor

@Elv13 What do you think about moving radical/impl/* and some parts from radical/widgets/* to another repository, leaving in Radical only what is responsible for creating menus/dialogs ?

@Elv13
Copy link
Owner Author

Elv13 commented Oct 22, 2016

  • radical/widgets/ I already done much of them. There is still some remaining (not for long)
  • radical/impl/* I am not sure, nobody will use this module if there isn't "value added". But maybe, I will see

I am currently not working on Awesome, I have some other projects with higher priorities. I don't know how long it will be until I get "awesome time" again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants