thanks for reporting about your new-reader-of-pacui-code experience.
i have just added many comments and a bugfix. please reinstall pacui-git to get the latest changes.
$input2 is an important variable in pacui. it gets used all over the place. this is probably the reason you cannot find its definition when searching for it in your code editor (or github) with CTRL+F.
$input2 only contains value(s) when pacui is start from the terminal. it contains the second (and all further) arguments specified in the “pacui” command.
here some examples:
"pacui r firefox" --> $input2 contains "firefox"
"pacui i web browser" --> $input2 contains "web browser"
"pacui h" --> $input2 contains "" (nothing)
"pacui h this isREALLYjunk" contains "this isREALLYjunk". but the "help" option ignores the content of $input2.
here the definition of $input and $input2:
i agree that the code section i have just linked is kind of important for the overall understanding of the code. but unfortunately, it has to be placed there.
do you think a table of contents for the code would improve the situation?
would splitting the code into different files improve the situation?
(i want to prevent this, because it is really handy to download a single file from github, mark it as executable, and run it)
I use PacUI as my daily horse for system maintenance and I really love it.
At the same time I wonder how Manjaro can solve the gap to become really user friendly, if I think about pacnew configurations and the manual way of running pacdiff.
Is there any way to handle this auto-magically for inexperienced users, which could be implemented into pacui or pamac?
yes of course. it would involve a lot more work for maintainers and a lot less freedom for users, but it is possible.
.pacnew files (and how you merge/use them) is tricky. if you want to make this process user-friendly, you simply lock down all config/settings files (by distributing them in packages), which only maintainers can change. then, they can decide whether to use a .pacnew file or use the old configuration files (by looking up, whether the configuration syntax of a package has changed or not). this means the user could only make temporary changes in config/settings files. also, there are no maintainers in the manjaro team to do all this work.
the best place to do something like this would be arch linux package maintainers. they are maintaining the packages anyway. they could maintain the config/settings files, too.
currently, manjaro simply ignores .pacnew files. this works well until the syntax of config/settings files changes. then, the package breaks (partially) and might even stop working completely.
overall, i think this is a consequence of arch linux: arch linux is not meant to be a user-friendly system, but an easy and simplistic system (from the developers point of view).
if you want to change that, you need at least the same number of developers/maintainers as arch linux - and manjaro has nowhere near that many volunteers.
when you can think of improvements (new functionality, better/other code comments, simplifications of code or functionality, etc.) feel free to suggest it in this thread.
i am always happy, when pacui gets improved.
i tried to give a short introduction to pacui on its main github page (and the first post in this topic). pacui offers a lot to power users, who already know what pacui’s options are good for. pacui can be called from the terminal directly. the first command to learn is “pacui h”, which gives you a short overview of all available commands.
i have noticed another problem in pacui: when i use pacui in tty (not in a desktop environment terminal), there are visual problems. it looks like lists displayed using fzf do not properly clear the screen before the display a list of packages. when fzf quits, the screen is not cleared, too.
pacui still works, but it is really hard (especially for people not knowing pacui’s options by heart) to see what they have to do.
as a workaround, i tried to manually use the bugfix mentioned in this old post in order to clear the screen before fzf starts and after it quits. unfortunately, this did NOT work. i have tested the “clear” command and it works.
this means we have a dilemma here. we have to choose one of the following possibilities:
either pacui looks good (and is usable) in tty
or pacui uses the terminal history. you can scroll up and see all previous pacui commands (including their output) and the rest of your terminal history
personally, i think it is more important to fix pacui in tty. what do you (and other people) think?
I would like to mention that the problem in tty does not occur if pacui runs in tmux. A fix is probably still needed, but maybe this can be taken into account in the fix? In this way terminal history would still be available when used with tmux. Maybe trigger the fix only if
i did some tests and found out that “$TERM” is identical on my machine both in tty and terminal.
but the “tty” command is different in tty and non-tty environments.
p.s.: i did some tests in zsh and bash, terminal and tty and adjusted my code. i just did a push to github. “pacui-git” can be built with the latest changes and should preserve history in terminal (and most likely tmux) and fix the visual glitch in tty.
please report back, if something is still broken.
(simply making pacaur a dependency of pacui does not make sense, because pacaur is used by default it is found the user’s system)
(personally, i am strongly against making yaourt a dependency of pacui)
Will it become functional at least for installing from Manjaro repos if you remove yaourt support?
Because without yaourt or pacaur installed I cannot install anything not even from Manjaro repos with pacui 1.8-1.
when i remove yaourt support, pacaur will become a hard dependency of pacui (see below for pros and cons).
currently, pacman-mirrors, reflector, pacaur, and yaourt are OPTIONAL dependencies, but you need (some of) them for pacui.
here is the problem:
when i make yaourt a hard dependency, pacui will always work. you could simply install pacaur when you want to use it instad. personally, i do not like to have yaourt installed when i want to use pacaur instead (and do not need yaourt otherwise). because yaourt has a bad reputation, people are probably annoyed when i make it a hard dependency.
also, i am not using yaourt any longer. i do not want to make it a hard dependency (and therefore first choice) when i never actually test it. pacui could stop working with yaourt completely without me noticing.
when i make pacaur a hard dependency, pacui will always work (except on arch linux when people are not clever enough to install cower (=a dependency of pacaur)). also, pacui will always use pacaur when it is detected. this means that it becomes impossible to use pacui with yaourt only. in this case, i can simply remove yaourt support altogether.
pacui will not work (properly) when pacman-mirrors is not installed. but i cannot make pacman-mirrors a hard dependency, because pacman-mirrors is not available on arch linux.
when nobody really wants yaourt support and tells me within the next couple of weeks (or maybe a month), i will drop yaourt support.
p.s.: what do you think about a warning when neither yaourt nor pacaur is found on the users system?