Advise best practices for widgets

[duarm]

Widgets shared here are in a free for all state, they are developed independently and each one has it's own instructions, nothing wrong, but it would help if the repo advised some simple practices for the scripts to follow.

My motivation for this was basically, I have some widgets, let's say a calendar and a ram widget, both are just simple text widgets with the information I want, so simple I made my own with one line of lua. I found this repo and would like to use the notification feature of both the calendar and ram widget when I click on them in the wibox. The calendar widget provides an easy and modular way of doing that, it has the widget which displays in the wibox, and a convenient .toggle() method to only show the notification, it even has an example on how to connect to the left click and call the .toggle() to display the notification. The ram widget has no such option. The solution is as simple as pulling the notification call out of the worker method into a function and calling that new function inside the worker, but most scripts don't do that.

I was thinking of a CONTRIBUTING.md, with some best practices like: Separate the wibox.widget from the notification display, have a standard .toggle() method to show the notification and so on, nothing too fancy,

[streetturtle]

Thanks for a feedback!

The reason of lacking consistency across widgets is that they were created using learning-by-doing approach) So the ones which were created first are not as good in terms of code quality and best practices as the ones created later on. I totally agree with providing a list of best practices, or, ideally, a dummy template widget. I'll work on this.

I was thinking to maybe convert this repo to an organization, and move each widget to it's own repository. I think this will give lots of benefits, like:

• widgets will have independent releases
• support luarocks
• template project - new widget can be created using a template project which will improve consistency (template repository)

But I'm not sure how good this idea is, what do you think?

[duarm]

sounds wonderful, adding a new widget would be different I suppose, just a PR wouldn't work anymore, the organization would have a "widget-add-request" repo for people to open issues requesting new widgets perhaps?

[Aire-One]

But I'm not sure how good this idea is, what do you think?

I'll play the devil advocate and argue that we don't need to have widget independent repositories. 😈

A monoreposity can produce multiple packages. I'll go with the idea that there is only one big Luarocks package, tho.
It should be fine to have only one package with all the widgets. None of them is autostarting something or working on the background without the user explicitly using the said widget. So, in the worst scenario, the end user pulled a package with widgets that they are not using.

A major advantage of the monorepo is that we can easily share code.
Let's take the scenario where have a shared base widget (e.g. a clickable container) used by multiple widgets. When updating the base widget, there is no need to go to each individual widget repository to update the dependency to the base and rebuild a new package. (*)

Also, if you want to enforce coding style, implementation pattern, CI checks, Luarocks package build/submit, ... Any improvement in the chain needs to be ported to every repository. This is a big issue because it is a very time-consuming work.

(*) This scenario is a lie because there is no code sharing between widgets currently. Every widget in the repository is treated as a standalone module, and in this regard, I have to agree that an organization with multiple repositories would be a cleaner way to organize.

[duarm]

although im not confortable with complicating everything by separting into different repositories, I think this can be fixed by one more repo called "awesome-utils" or something like that, which every widget repo would add as a submodule. The major argument against multiple repos are icons, sharing icons would complicate things a lot, This can be solved by giving up tho, you just duplicate the icons, All icons sums up to 356K currently, just the video in the run-shell widget, which I'm not even using, is 2.4M