Significantly Expanding Polycore.

[simotek]

Firstly, I think its worth explaining what i'm trying to solve, then how i'd like to adapt Polycore to solve these issues.

Currently I am looking at Conky from the perspective of a distro maintainer trying to provide the best possible out of the box experience when running Conky with a "Default" config. Currently there are three major issues with upstream Conky that I am trying to address, firstly the current conky config cannot adapt automatically to different system setups ie the number of CPU Cores, where drives are mounted, Network interface names etc. The second major issue I see is the out of the box styling is very dated and there are much better options out there. Thirdly if you want to do a custom config / layout its really painful in upstream conky.

I think the best solution to all of these issues is moving to a 100% lua based config. With that in mind I think that Polycore already solves 3 really well and with brndnmtthws/conky#1501 fixing the Lua text rendering issues when it is accepted I think it would be possible to move Polycore to 100% lua config. Polycore also can be adapted to help resolve the first issue by creating more advanced / higher level widgets that autodetect hardware where possible.

In terms of look Polycore already provides a great option, but i'd like to extend it with more inspired from

• https://github.com/zagortenay333/conky_themes/tree/master/conky_harmattan
• https://github.com/xexpanderx/Conky-themes
• and maybe a couple of others to show what can be done.

Once I have some of this done id like to approach other theme developers along with upstream about working together to create a more lua based "2.0 Config" for conky so we can all collaborate together in the same place, either in the upstream conky repo if they are happy with that or in some other form of "conky extended" repo. Long term I might even add a graphical tool for generating configs.

This is obviously a lot of new work so my first obvious question for you is would you like to be involved? and if so to what extent, for example I have a couple of small improvements to the core of your widget system and I could just send those as PR's or as I develop new widgets / modify the current widgets to use the new text rendering API I could send those, I guess the question is at the moment would you like me to send you everything? just the stuff that will make your Polycore theme function better or nothing? and I'll just keep working out of my repo.

I probably have other new questions around design / structure as well, an initial one being that having all the widgets in a single directory probably won't scale so i'm thinking of splitting them into lower level "Core" Widgets, text, graph etc and higher level based on type such as CPU Memory etc. and i'd like to know your thoughts on that if the answer to the previous question was keep sending stuff.

Thanks again for all the work you've put into polycore, initially when I started looking at doing this I thought i'd have to write my own widget and layout system.

Simon

[simotek]

Also enjoy being able to use mesh patterns, now I understand how conky's binding system works adding extra features doesn't take long. brndnmtthws/conky#1502

[philer]

Hey, those are some big plans! 🚀

First off I'm super happy that I'm not alone with this idea of expanding what conky can do and how to do it. I built the theme to my liking but I've since been itching to try out different visual styles and finding a way to make aesthetic customization possible without hacking the widget implementations.

Building a lua-only config was my original goal and the font rendering was a major blocker. I'm not sure if the cairo font rendering has already been improved since (iirc there was no sub-pixel rendering at the time). If your RFC gets accepted and leads to better and consistent font rendering I'll probably want to migrate polycore to lua only. If you can help with that I'd be happy about PRs.

As for the more long term plans, I envision Polycore as a library/framework for lua only conky configs. That includes:

1. The layout system, with composition widgets like Columns, Rows, Filler and Frame
   This is going to remain the heart of polycore. It could use some more flexibility but I want improvements to be careful and deliberate. For example Added Container widget. #11 suggests an interesting way of using a dedicated widget for conditional rendering. I haven't quite figured out yet if the suggested implementation is a good idea and I need to play around with it some more.
   I'm also curious if there is a way to make widgets behave a bit more like React components.
   Since this is the most complex part of polycore I also want to have proper tests for it. The current testing setup is pretty janky and some of it is broken.

2. A theme system which allows changing the overall look of the config
   This is probably the biggest and most important pending expansion of Polycore. The current "theme" is hard coded directly into the existing widgets and changing the overall look means modifying the widgets' rendering logic.
   I would like to offer an option for creating various "themes" that can be used to modify the overall appearance of existing widgets (see 3.). I'm not sure how to do that yet but I want to find a reasonable ballance between customizability (the extreme would be something like CSS which rofi tried to immitate) and simplicity (which may also be necessary to maintain reasonable performance).
   What I want to avoid is just adding more and more parameters to existing widgets that allow customizing an abitrary set of visual properties.

3. A library of generic widgets like Text, StaticText, TextLine, Bar, Graph, LED, etc.
   These basically replace what conky already has to offer and may be expanded with more common data visualization widgets, like circular bars, dials etc. There isn't even an Image widget yet.

4. A library of specialized widgets like CPU, GPU, etc.
   These are self-contained widgets that are meant to be used "as is" with few parameters. I could see higher level widgets in here as well, which try to auto detect hardware. In that case I'd probably want to keep the visualization widgets and the "smart" part separate.

5. A library of functions to collect various metrics beyond what conky has to offer (currently data.lua)
   Maintaining these is an ongoing effort and can be quite time consuming. The more people use Polycore the more this will need to grow to be compatible with various systems. Some of these might also be better integrated into conky directly. Auto detect features would also need to be built on top of respective functions in here.

6. A collection of examples / ready to use configs and themes

If I build all of this on my own it'll take a while because I have limited time available. So any help (including PRs) that goes towards these goals is welcome. Since I want to understand exactly what each change does my reviews may be a bit slow (although they should speed up if I get more familiar with the project again). I'm very interested in seeing what kind of changes you have in mind, so if you already have a link to the stuff you've built I'd love to take a look.

There is value in integrating polycore with conky directly, assuming they agree. However, I'm not sure if the added complication will be worth the benefits. It probably makes sense to think about this once polycore has become a bit more flexible (mostly by implementing 2. and expanding 1. and 3.).

For now, Polycore is meant to be used by cloning and customizing an example configuration. I'd love for it to grow more "automatic", so it is more likely to run out of the box, but ultimately offering customization is more important than building a one-fits-all solution.

having all the widgets in a single directory probably won't scale

Absolutely. I already have a branch somewhere for splitting the current widget.lua as it's grown fairly long. The distinctions I've made above serve as a guideline for that. I've got a few more ideas for refactoring but they are pretty vague at this point.

enjoy being able to use mesh patterns

I will, although I've honestly completely forgotten what I wanted to use them for when I opened that issue. 😄

Anyway, thanks for sharing your thoughts and your efforts! I look forward to seeing where we can take this.

[simotek]

Thanks, this gives me a good idea of where to work next. I haven't got a lot to show so far although i've been working / thinking on the concept on and off for the last few months in my spare time. I was looking for a better solution because my current config started out as something I got from deviantart here which the original author created 10 years back and has since gone missing. It contained a bunch of lua from all over the place and got around conky's layout limitations by running 7 or 8 conky instances at the same time. Initially I was just looking at replacing that with components that actually had licenses that meant I could distribute them in distro's as a starting point.

Then I found Polycore which addressed many of my issues but also found your big issue which was the lua text problem so I spent the last while when I had some spare time learning how binding and font rendering worked to solve that because I wanted to be pretty sure it was possible first, before investing too much more effort elsewhere. Then I thought i'd start a discussion with you so that I didn't put a whole lot of time and effort into something that would end up being in a slightly different direction to what you were thinking.

1. Split up the widgets file and send you that along with a couple of other minor refactors / improvements that I have sitting here.
2. Create a copy of your Polycore theme that's lua only - mostly for my sanity as I have slightly different fonts and getting everything to line up correctly is painful. I'll probably create widgets for Top CPU and Top Mem as well as that seems like something people want to commonly drop in.
3. For my own testing i'll probably swap everything over to the new text api but i'll keep that in a separate branch and not push it to you until its accepted into conky.
4. I'll recreate my preferred theme which will certainly include some more widgets like an image one and will require experimenting with the "Theme" idea, more on that below.
5. Recreate some more themes to nail down those ideas and widgets.

Now onto some other replies to your comments, I couldn't think of the best way to order this reply as a whole.

With the new font rendering setup it now uses basically the same libraries as the rest of the Linux desktop although I think most are now moving back away from subpixel rendering.

On 1. I haven't used react much so I don't really know how its widget system works, i'm much more familiar with Qt, one related change that i'll push in the next couple of days is I added cairo_surface_create_for_rectangle to conky in this commit which gives each widget its own surface so now widgets can't draw into other widgets spaces. This involved some minor refactoring but nothing too major. An interesting future addition might be some form of "Stack" to allow putting widgets on top of each other thinking particularly about the configs that use a set of "Rings" inside each other.

For 2. i've looked at this theme idea in a bunch of context over time. Having looked at a large number of different conky themes I think we can probably actually do something pretty simple at least for the complex widgets. I think having a maybe 6 color palette will probably be more then enough maybe with some of the widgets having a couple of style options that flip or use different colors, for example the theme I use has 3 different colors to list the top CPU / Mem processes where as yours just uses one. Along side that probably a default and title font. For simpler widgets it might make sense just to allow optionally passing a cairo_pattern_t then people can do whatever they want.

For 3 and 4 thats also roughly what I was thinking and yeah I need to do an image widget based off the imlib2 bindings and see what "rings" implementations exist with licensing that means I could reuse some code, if not i'll just write my own.

On 5 that does sound like a good place for any auto detection I need, although conky can already do some of them, its just you normally can't dynamically create a config based off them. Most of my reason for using conky as a base is because it already does all that backend data stuff reasonably well and I don't want to have to keep it working across a number of different systems

On 6 I agree that is the future and id like the choice and flexibility, from a distro packagers perspective I just want to set it up so that when you run conky out of the box you get something pretty meaningful for your system without needing to modify anything, I might also wind up making scripts and so forth in the future so you can just run conky-polycore and again get something reasonable with that theme for people interested in the basics. At the same time I agree that providing configs that more advanced users can start with and edit is an equally valid usecase so my focus is somewhat on both.

With respect to working with upstream I wouldn't plan on sharing it there and more broadly until most of the above is in a good shape at that point i'll be able to write a thorough and detailed proposal on how everything works and how it could benefit a wider audience.

Finally if I was guessing with the mesh stuff you probably wanted to make a nice custom gradient for the polycore text, thats certainly something it would allow you to do anyway.

[philer]

For the theming I definitely want to find a way to offer more than just color options. For instance, these themes follow a completely different style that isn't possible with the current implementation:
https://www.reddit.com/r/unixporn/comments/a900p7/awesome_mechanical_love/
https://www.reddit.com/r/unixporn/comments/kucuzs/awesome_420_rice_it/
I don't know how much of that can be abstracted but I believe it's worth thinking about.

Also I've remembered what I wanted to use mesh gradients for. Check this out:

Per core temperature gradient for the CpuRound widget. Not the most pressing concern but it's definitely nice to be able to do stuff like that. 😃

[simotek]

For the theming I definitely want to find a way to offer more than just color options. For instance, these themes follow a completely different style that isn't possible with the current implementation: https://www.reddit.com/r/unixporn/comments/a900p7/awesome_mechanical_love/ https://www.reddit.com/r/unixporn/comments/kucuzs/awesome_420_rice_it/ I don't know how much of that can be abstracted but I believe it's worth thinking about.

Ahh yeah, I think we can handle that kind of thing pretty easily, i'd just add an optional style parameter to the required widgets, eg something like round , classic etc along with a global variable that will be used to set the style for all widgets that support it if a style wasn't specified in the constructor. I think that combined with a background image should be all that we need.

Also I've remembered what I wanted to use mesh gradients for. Check this out: Per core temperature gradient for the CpuRound widget. Not the most pressing concern but it's definitely nice to be able to do stuff like that. smiley

That does look cool.