gap_mult_client support

[sunyuechi]

releated https://github.com/awesomeWM/awesome/issues/3582

hope support disable gap when mult client, support gap when single client

[Aire-One]

Hello, @hleft

Thank you for the PR!

Something I don't like when adding new flags to enable features is that it can't scale with all the features request we can have in the long term. (And also, it makes the code base unnecessary complex to manage every corner case)

I think it would be more future-proof to expose a skip_gap function at the tag level. This would allow wrapping both gap_single_client and gap_mult_client behavior (and more derivates we haven't thought of yet) with only one property.

[raven2cz]

Hello, @hleft

Thank you for the PR!

Something I don't like when adding new flags to enable features is that it can't scale with all the features request we can have in the long term. (And also, it makes the code base unnecessary complex to manage every corner case)

I think it would be more future-proof to expose a skip_gap function at the tag level. This would allow wrapping both gap_single_client and gap_mult_client behavior (and more derivates we haven't thought of yet) with only one property.

Configuration Hell

After 30 years with configuration design, I would have a few points that have helped many companies and frameworks. In general, configurations are poorly learned in IT fields and are mainly part of cybernetics lessons and studies, which are unfortunately a problem for IT programmers.

• Configuration is an essential part of the API, and if poorly designed, there are major problems in using the resulting product, especially if it is a framework.
• Configuration must be considered in design time of component, service or package. FIRST, It is always necessary to design the features as DISABLED (completely with all deps!) and after it solve activation of features and deps! NEVER do anything without the possibility of a complete deactivation (plus logging of activity/deactivity too).
• The biggest mistake for non-cybernetics programmers is that they think the configuration belongs to the object/class (or lua table). This is a big mistake! The configuration belongs to aspect oriented programming. It is an aspect, an abstraction of a given object or service instance. Imagine that you get green glasses (like Emerald city in OZ land, there was no green, it was caused by green glasses only) which you look at the component you need to configure. These green glasses contain configuration properties for a given object, but they are defined separately as a configuration aspect and are injected into the object as an aspect. Lua has good resources for outsourcing features. It is also possible to be inspired in the Kotlin programming language now, where this is already at the core of the language. Configurations are thus kept separate, they can be much better described, aggregated, activated/deactivated, do documentation and most importantly make a hierarchy (see next points below). However, due to the aspect injection, they are still present in the object, which can use them directly, but only in the presence of green glasses.
• Aspect configuration creates the separation of groups and thus the separation of information. Configuration belongs to the so-called cross-concern problems and is the main reason why not solve configurations directly per object, or worse, as a global configuration!
• I often get the question, but how to deal with a global configuration, or a configuration that affects some package and not just separate service or component? There are several types of configurations. The basic division is to configure the properties of the object and the second level is to configure the behavioral group. Here again, companies and open source make the biggest mistake in describing the group's configuration by table listing, for example, 6 parameters to be set to achieve the appropriate behavior. Big mistake! The configuration is not just about the property of the object, but about the 2nd level is the behavioral group. It's just adding the second aspect (say blue glasses). You define a configuration parameter for a behavioral group and its simple string values that internally contains, according to its parametrization, a table of parameters of the properties of individual objects, as they are to be configured according to the value of the behavioral group parameter. The user thus gets only one simple parameter that correctly controls some part of the unit/package/complex-service. It can be also easily overload it and add its own/user-specific added value. The key/trick is that if you ask for parameterization INSIDE in any object instance, you will get the correct setting value directly from it due to the aspect dependence and injection. There is no need to search for anything, everything works simply and most importantly dynamically! What does dynamically mean? You can easily update the configuration on-the-fly and change the behavior of the services without having to restart them. Which is a nightmare for all no-cybernetics developers.
• Is it possible to do this with ready-made/older applications and frameworks? The answer, of course, is yes. There is no need to redo anything, for new components and packages it is possible to go straight to this method. After understanding the basic principles, you can start redesigning older components per partes (step by step).
• ATTENTION. The configuration determines the usability of the whole project and its dependencies. Don't take it lightly. On the contrary. There are many projects that have ended due to complexity, and this is becoming mainly the growth of applications/frameworks, as everyone puts in their configuration features there, as they like and simple ignore cross-concerns.

I would like this "article" to help you in the design of frameworks and applications. The specific implementation and design of this approach depends on the agreement of the main developers and the organization of the main libraries and documentation. It is mainly about the mind change and approach to configuration and to understand these problems, which arise especially during the lifetime of the framework and incoming cross-concern features.

[codecov[bot]]

Codecov Report

Merging #3603 (71d3ea6) into master (c539e0e) will increase coverage by 0.00%. The diff coverage is 80.00%.

@@           Coverage Diff           @@
##           master    #3603   +/-   ##
=======================================
  Coverage   90.63%   90.63%           
=======================================
  Files         853      853           
  Lines       54744    54757   +13     
=======================================
+ Hits        49615    49629   +14     
+ Misses       5129     5128    -1     

Flag	Coverage Δ
gcov	90.63% <80.00%> (+<0.01%)	:arrow_up:
luacov	93.43% <80.00%> (+<0.01%)	:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
lib/awful/tag.lua	78.86% <72.72%> (-0.11%)	:arrow_down:
lib/awful/layout/init.lua	94.34% <100.00%> (+0.51%)	:arrow_up:
spawn.c	86.09% <0.00%> (-0.07%)	:arrow_down:
tests/examples/screen/template.lua	96.73% <0.00%> (+0.21%)	:arrow_up:
lib/awful/layout/suit/corner.lua	91.15% <0.00%> (+0.88%)	:arrow_up:
lib/awful/layout/suit/max.lua	100.00% <0.00%> (+4.34%)	:arrow_up: