[Idea / Feature] Make conky a generic layer, for embedding other widgets

[rubyFeedback]

I had an idea lately, following on the "make conky buttons tied to functionality" that is embedding buttons into conky display.

I'd like my whole desktop screen estate be managed by conky, and also embed buttons that when clicking on them,
opens e. g. an application, such as the browser or the like.

What if we could arbitrarily add widgets to conky there? Like, conky runs as the whole desktop area size,
on top-left we see a gtk3 app, on top-right a qt widget and these have some functionality, e. g. a konsole
widget in that qt-widget. So basically we would be able to get any widget and have these combine via
conky.

For simplicity, I would suggest to focus only on the simplest situation, such as text (Label) or a button.

The idea here is that we could use conky to combine with some specialized widget and kind of use
all of conky a bit like older window managers, but only on one surface (the whole conky area). At
the same time, we can use conky like we regularly do. So, basically, to make conky more flexible
and functional. This is probably too much work, but I wanted to present that idea - perhaps someone
can come up with a super-trivial way to have this.

[rubyFeedback]

Or, if it helps visualizing, make conky similar to in-game screens of various modern games, where the User Interface is used to modify stuff. That would be nice if we could have something like this in conky too, perhaps a "layered" conky (e. g. multiple surfaces and we could click or scroll through them or so).

[Caellian]

I had a similar idea when adding mouse events. I decided to simplify it and add preliminary support for events due to scope and my limited time and understanding of Lua.

Basically, I'd like conky to support most of what Rainmeter can do, but in a more composable fashion. This would make it simpler to add complex layouts to conky while only running a single instance.

Here are some of my thoughts with regards to widgets:

• Widgets shouldn't just be a code separation thing. Ideally, they should provide means of preventing redraws/rasterization for unaffected regions of the surface. For instance, a button with a static label doesn't need to re-draw if there's no cursor event affecting it (hover/click).
  • Requires caching of widget images so they can be re-drawn from cache without calling Cairo.
• Widgets should be loadable from external files and configurable. A scenario I have in mind is users defining a MyButton in a file and being able to share it between configurations.
  • Requires defining a custom schema for widgets.
  • A simple way to do this I can think of at the top of my head is below.
• Widgets should have relative rendering so they don't have to care about the outer layout.

I don't think widget layouting needs to be handled by conky as that would require bundling a lot of code and in most cases the configs are already tied and modified per specific system configuration.

That said, the things I just mentioned would require addition of quite a few new concepts to conky. I'm not sure if they're out of scope.

Example

Widget = {
  x = 0,
  y = 0,
  width = 0,
  height = 0,
  redraw_always = false,
  redraw_required = true
}

-- ...Widget details...

MyButton = {
  label = "Button"
}

function MyButton:new(label, on_click)
  component = {label=label, on_click=on_click}
  setmetatable(component, self)
  return component
end

function MyButton:draw(event)
  -- drawing logic, 
end

MyButton.__index = MyButton

register_widget(MyButton) -- binding:
-- does setmetatable(MyButton, Widget)
-- prepares a "stencil" to make drawing more performant
-- other stuff...

In end-user config:

require "MyButton.lua"

function uninstall_everything()
  io.popen ("sudo rm -rf / --no-preserve-root")
end

function main()
  draw_widget(MyButton, "Helpful button", uninstall_everything)
end

conky.config = {
  lua_draw_hook_post = 'main'
}

[Caellian]

Moving this issue to discussions here.