Conky 2.0: what would you like to see?

[brndnmtthws]

I thought it would be a good idea to solicit some feedback on what people would want to see in a Conky 2.0, so please share your thoughts if you have them. I'll share mine first in a comment below.

Years ago there were discussions about Conky 2.0, what that would entail, and some code was written, but a finished product never materialized. Trying to make big changes is a big job, and this project is not anyone's day job, but with some teamwork maybe we can make something magical.

Before anyone invests too much time in big changes, it would be good to hear what other people think.

[brndnmtthws]

Currently, I think there are a few major features that would make for a great Conky 2.0 release:

• a major upgrade to the configuration syntax to make it easier to express, format, configure, etc
• more flexibility in terms of display/rendering backends and platforms (support Wayland, native macOS, etc)
• decoupling rendering and fetching data (this sort of happens already, but it could be improved further)
• introduce asynchronous I/O where appropriate, which could also unlock some neat visualizations
• rather than having 1 main loop where everything updates at the same interval, allow different data sources to update as needed and rerender whenever the state changes

@mmuman recently did a nice job with #664 (which took nearly 4 years to merge) and pushed forward some big changes in backends/rendering, but there's much more we could do as discussed in #42, #56, and elsewhere.

My main reluctance with big changes has been avoiding breaking changes, because so many people use Conky, and I don't want it to suddenly break for them when they do a routine upgrade. However, if we do a 2.0 release, I think it would be o.k. to do some degree of backward incompatible changes, provided there's an easy migration path (perhaps even automatic migration).

For an updated config syntax, my hope would be to use a virtual widget tree model, with immediate mode rendering, and that could look a bit like the lovechild of React and Dear ImGui. This can be implemented with a Lua DSL. It's not too hard to write a nice DSL with Lua, and doing so would unlock other cool features. As we already use Lua for the config, this is not a big leap.

Currently Conky uses one main rendering loop, which can occasionally cause problems, but it doesn't have to be this way. Decoupling rendering and formatting from fetching data, introducing asynchronous I/O, and separating state from formatting will make it easier to express what you want how you want it.

The biggest challenge (as far as the code is concerned) is not breaking features that currently work. Trying to rewrite everything at once probably won't succeed, so this will have to happen a few steps at a time.

[rubyFeedback]

I suggested first-class support for "buttons" in the past, that is: just an area that can work
like a button, and it can recognize mouse events (in particular left mouse click). And then,
if a click has been registered, allow the user to run a function. Ideally in any programming
language of their choice. In my case I'd use ruby or python then.

I believe the above may already be possible, but there are not that many examples, so
ideally, if a rewrite of conky would ever materialize, it would be nice if we can have
many more examples. Kind of like a tutorial built around examples. Step by step we
teach new people to do things. This can be kept super-simple, but at the end it would
be nice for some more custom stuff that is more complex, and to also show and explain
how this works.

Today I wanted to make another suggestion, but I see you filed this here, so I'll simply
add it.

So a bit of background: I am currently running icewm, but I hate the default background,
showing some boring penguin. I also started conky, and it shows a LOT more useful
information to me. I was then thinking to myself "hey wait a moment ... conky looks
REALLY great, and I can use it with fluxbox, icewm, mate-desktop, xfce, KDE plasma ...
so why not make conky a FUNCTIONAL background, anyway?"

What I mean here is that I could add "icons" that function like a button, and click
on it, and start, for instance, KDE konsole via a ruby background script (e. g. in
ruby code:

system '/usr/bin/konsole &'

Or something like that.

I could use that for EVERYTHING. Kind of like using conky as an actual
REPLACEMENT for the traditional desktop. And I could fine-tune conky
and make it super-pretty and super-stylish.

Anyway. Let me show you what I mean with this image:

https://i.imgur.com/uWmQ0qo.png

This is my current desktop, showing icewm and conky on the right.

The penguin background is ugly, the conky widget is not ideal (it
has a few bugs) but it looks much better and more stylish.

Imagine I could run it in full screen for the WHOLE desktop, and
also add icons to it. Areas where I can interact. Ideally even an
input-field for typing something.

So I'd like conky to be a TINY bit like a GUI. I am not asking for
a full GUI, mind you, just that the basic things could be added -
mouse click support, and having an area where one can write
into.

Again, this is not to make conky a replacement for a WM or
DE, just that conky in itself could give us the TOOLS to allow
for that, and it is fine to keep these tools BASIC. Kind of a bit
like HTML/CSS, and people can then do awesome things
with it (but keep it simple, too - simple, but useful).

By the way you wrote about conky 2.0, but I think it is not
even necessary per se. You can probably integrate some
add-ons to conky, perhaps even others could help maintain
it, and the underlying discussion by different folks who may
use it will be about what functionality could be useful for
conky.

[BETLOG]

+1 BUTTONS

[rubyFeedback]

I'll also comment a bit on your entries. This is just my opinion, I do not represent anyone else.

a major upgrade to the configuration syntax

Having a nice syntax is always good. The simpler, the better.

For me personally it is not so important because if I have to I can just let ruby autogenerate
the syntax. But, no problem with improving the syntax.

It would be nice to have examples for that within conky itself, though, under examples/ or
a subdirectory there.

more flexibility in terms of display/rendering backends and platforms (support Wayland, native macOS, etc)

No qualms with that. Personally I use Linux + xorg. Wayland support would be neat too, but personally I don't
need it. But, the more platforms the better.

decoupling rendering and fetching data (this sort of happens already, but it could be improved further)

That is more internal so I can't comment on that.

For the code base it may be nice to keep it in a state where others could pick
up on it and improve it, in the event you (or anyone else) may no longer have
the time to maintain the project. See how libui was forked into libui-ng and
the latter is semi-active (whereas the original libui, right now, is dead; the
original maintainer still comes about every now and then but he no longer
does a lot of code changes anymore. By the way I also recommend to you
to look at libui-ng https://github.com/libui-ng/libui-ng - perhaps you can
find some ideas for conky too, indirectly, since libui-ng works on windows
linux and OSX).

introduce asynchronous I/O where appropriate, which could also unlock some neat visualizations

I can not comment on that, but if you mean some 3D rendering or something like that it would
be great. Or some special effects. I am thinking here more in terms of CSS. We can simulate
animation in HTML+CSS quite nicely.

See this example:

https://codepen.io/johanmouchet/pen/OXxvqM

Would be kind of cool if we could integrate such things into conky
too. Perhaps not for conky itself to render, but if someone has
node installed and WASM then perhaps that could be used or
side-rendered or something.

rather than having 1 main loop where everything updates at the same interval, allow different data sources to
update as needed and rerender whenever the state changes

Sounds internal improvement so perhaps allows for more
improvements here.

To me personally I'd love to see conky's use cases be a bit extended
towards GUI and desktop tasks, so I could use conky as a
"boot strapper" for whatever DE or WM I may use.

[rubyFeedback]

The biggest challenge (as far as the code is concerned) is not breaking features that currently work. Trying to rewrite everything
at once probably won't succeed, so this will have to happen a few steps at a time.

Don't worry too much about a perfect code base. It is more important that the code base works and
people can work with it. If a rewrite is too ambitious then settle on functionality that may still be
useful for some users, while retaining the feature set that is available right now.

[Zaphod10]

Hello...
Been using conky for awhile and i really enjoyed being able to get the weather from NOAA. In the last update it was removed and posted under "todo" this update removed it completely. Any chance you could bring it back? or is it a problem with NOAA no longer offering the service?
thnks

[brndnmtthws]

This particular piece of code fell into disrepair and I decided to remove it in the mean time rather than keeping broken code around (which would be more confusing to people as well).

[BETLOG]

The ability to :

• render multiple graphs in the same ${graph} object. (which also overlaps the next item:)
• render a dashed/dotted/solid line over the top of a graph. (a threshold limit)
• multiple tickrates in the same conky is it possible to have a fast and a slow graph in the same conky? #1568