Replies: 5 comments 8 replies
-
|
These are some really good suggestions! Some of the points like
I think we should maintain both
Good idea! Not sure how useful bash unit tests will be but worth a shot. At the very least, it will give us a tiny safety net against introducing new bugs.
We can already create a build output with this ->
Not sure about this one since it adds very little value and increases the surface area of changes we need to maintain. Doesn't seem worth the effort. Feel free to create low priority issues for these (except for shell completion which I'm not convinced is worth it). |
Beta Was this translation helpful? Give feedback.
-
glad you like them 😊
yep definitely!
yes, we should keep the # bsp-layout
bash /usr/local/lib/bsp-layout/layout.shwhereas
exactly the purpose of such tests! 😉
oooh really?
ok, that is true 😕
i'll create issues as we go 😋 not sure i can add labels to issues though 😕 |
Beta Was this translation helpful? Give feedback.
-
|
to keep track of the ideas and their progress 😋 legend:
the ideas:
|
Beta Was this translation helpful? Give feedback.
-
|
i thought about something, a new idea generate different versions: right now,
The idea would be to use the tags in the worktree to generate the exact versions automatically:
is that something you would like in the project? 😊 |
Beta Was this translation helpful? Give feedback.
-
No. That is just the default version for use during development. Both AUR packages use install.sh and you can see in there that the version is the last git tag. But yes, I agree there is some room for improvement. The reason, I didn't do this inside the Makefile was because bsp-layout-git and bsp-layout will have different versions so specifying that externally made sense. Also, I think we need to rethink the install process and maybe sunset the install.sh file completely. This would solve the problem as both of them calling make would specify the version of the package itself so no room for error. |
Beta Was this translation helpful? Give feedback.
-
wow... to be honest, i did not even notice that
not sure i get the idea... are we talking about the versions of the AUR packages or the command they ship? 🤔
yeah... this script is quite confusing and looks, to me, quite redundant with both the makfile and the AUR packages 🤔 i add that refactor to the list above 😉 |
Beta Was this translation helpful? Give feedback.
-
|
Hi @phenax 👋 😋 in order to prepare some of the ideas above, i thought about changing the argument parsing a bit 🤔 i've written a little demo on my personal parsing-demo branch 👌 the script should be used as if the main reason for that branch demo to exist is that i feel not comfortable with passing hope you'll find that useful 😊 |
Beta Was this translation helpful? Give feedback.
-
|
What if a desktop's name can contains the
I think it's offers a lot more flexibility if each sub-command has the ability to parse the arguments it needs and perform validations. But yes, this is a tradeoff between flexibility and having a single source of truth on the cli's api. I'm fine either way since the cli is simple enough but I don't think we should have any custom parsing methods for the internal apis because of the desktop names which can break the parser. Another thing to consider is that, there's 2 layers to this. The core sub-commands arg parsing and the layout specific arg parsing (Eg - |
Beta Was this translation helpful? Give feedback.
-
that is a great remark 🤔
not sure about which way to choose, the local parsing in each function or the global parsing and give exactly the arguments needed by the functions 🤔 maybe the local parsing is a good thing here though! 👍 |
Beta Was this translation helpful? Give feedback.
-
|
i had another idea, regarding installing and compiling the code 😋 i like to print debug statements when developing, to understand the code and what it's doing! 👌 however, we do not want such debug statements to end up in production code 🤔 so i need to remove all these each time i commit and write them again later when needed 😕 what about doing the following:
... some code
echo "value: $value" # {{DEBUG}}
... some other code
... some code
... some other codewhereas ? i think that would be kinda cool, very practical, easy to implement and just a matter of finding the same convention for everyone 😋 |
Beta Was this translation helpful? Give feedback.
-
|
Good idea. But, I'm not a big fan of this sed templating trick being used in too many places tho since it is a little too messy. Can we abstract it all out into another script that given a set of key-value pairs, compiles the template for us? Handlebars but much simpler. |
Beta Was this translation helpful? Give feedback.
-
|
coool 😋 i add that to the list above 👌 |
Beta Was this translation helpful? Give feedback.
-
|
not sure to understand what would a
be 🤔 we'll probably talk about that in depth in an issue some day 😉 |
Beta Was this translation helpful? Give feedback.
-
As i was going through the issues and the PRs to get a gist of the current state of the project, i had the following ideas.
These are mainly enhancement propositions, i've already directly opened issues for the bugs i encountered! 👍
DISCLAIMER: these ideas are not of a high priority but would, to me at least, improve the experience a bit, from the point of view of either a user or a dev. 😊
THE IDEAS:
bsp-layout getall the desktops: add the possibility to pass anallargument tobsp-layout getto get a list of the layouts of each and everyone of the desktops in the currentbspwmsession. That would essentially be an alias to something likecurrentas an argument to the subcommands ofbsp-layoutin addition to the implicite way with no extra argument, e.g. makebsp-layout getandbsp-layout get currentequivalentbspwm, the socket of the manager itself, and (2)bspc, the controller of the socket. I think it would be more coherent with the base project to shipbsp-layoutandbsp-layout-gitwith thebsplcommand instead of the currentbsp-layoutcommand, which essentially means to modify theMakefile! For backcompatibility concerns, the packages should also come with thebsp-layoutcommand which would only callbsplafter printing a deprecation warning tostdout.bsp-layout, e.g.getandremoveonceorset, e.g.monocleandeven1,2, ... aftergetbspc: to help new users and new devs to get up to speed with the source code and especially complex commands likebspc, that could be a usefull thing to use the full switches of thebspccommand, e.g. replacebspc query -Dbybspc query --desktopsbsp-layout, the idea would be to save the previous native layout used bybspwm, e.g.alternate,spiralorlongest_sideaccording to the README ofbspwm. When the user would unregister, i.e.bsp-layout remove, the layout, the previous one would be restored and the windows rearranged accordingly.bspwmrequires a graphical server to run, but having a workflow in~/.githubwould help catch some bugs. even just a spellcheck!bsp-layout! however, i think there is never really enough documentation 😉 more comments, docstrings for functions, to explain the arguments, etc, etc... that kind of stuff. no real plan on that 🙂bsp-layout"builds" thebashsource code into a usable script. the use of{{VERSION}}and{{SOURCE_PATH}}for instance is very smart to change the behaviour of the final program though theMakefile! However, from a dev point of view, or even someone just trying to build the application from source, that is quite overkill to be only able tosudo make install🤔 you need to enter the user password and possibly mess around with the system installation of the script... that would be nice to have some more layers of installation. e.g.makeormake buildormake bsp-layoutto "build" the script, namely giving access to a usable executablebsp-layoutin the root of the repo,make cleanto remove "build" files andsudo make installto finally install the built script.Hope you'll find these ideas interesting, usefull in some way!
Again, these are not top priority as they're only new extra features, just things i thought of for the long run of the project! 😉
cheers @phenax 😋 👋
Beta Was this translation helpful? Give feedback.
All reactions