About 'redraw', it doesn't happen from within menus.

Also it might just be a "useless" clear screen while just rewriting everything, making the terminal going through black state before redrawing. You might be able to remove that if it is explicitly invoked.

Bests.

In sboui, the left and right lists are drawn in their own ncurses windows. When it needs to scroll, it does a wclear on that window and redraws it, including the outside frame. So there is a little bit of wasted redrawing there, and I'm thinking maybe the wclear call causes flickering even if it's only clearing one subwindow of the application. Maybe I can be a little more stingy with that and only do a complete redraw when really necessary.

Anyway, these are all good suggestions that I will try to fix or improve in the next release.

I just did a quick test in tmux with the wclear being commented out, and it seemed to completely solve the flickering problem. So that seems to have been it. I will just have to figure out if there are cases where it is actually needed.

1 members found this post helpful.

Pretty much universally the Unix convention is that environment variables (volatile) override config files (static).

Are you sure? That seems non-intuitive to me that an environment variable that you may not have specifically set would override a config setting that you presumably did specifically set.

Since Midnight Commander was brought up earlier, let's take that as an example. It has an option to use the internal editor. If you enable that, files will be edited with mcedit, even if you have set $EDITOR to something else. Same thing with the internal viewer. So if that behavior is standard, it is definitely not universal.

You must be new here

Nice shot for the redraw.

About the $EDITOR, my problem is not the "actual behavior" although, yes the Env var should be "first class".

My problem might not be with the 'code' of the tool but the slackbuild (from sbo I guess) which set the configuration variable, without asking, with an arbitrary value...

The slackbuild should NOT set the editor in the config, OR it should use the actual $EDITOR to set it up with the user preference instead of a "niche factory choice" .

When I say problem, it's not the end of the world. I just explain what I find unnatural, vs what I'd expect as a "end user".

My problem is that the process:
And bam! vi is launched, whereas my EDITOR points to something else, and I need to "guess" that there are option and find it, and change it (so change is mandatory if you don't use vi). I think not forcing user with developer preference is a better user experience .

Okay, so the problem in your mind boils down to the fact that sboui ships with a default value set for the "editor" config variable. If that were not the case, your $EDITOR would have been used from the get go. That is a very easy thing to fix. I will just change the default config file to not set anything for editor.

I still don't like the idea of an environment variable overriding the config setting, though. If I edit a program's config file, I am telling it that I expect it to behave in the way that I set. It's no different than my mc example: if I set it to "Use internal editor," then I expect it to do so, even though $EDITOR is set to something else.

1 members found this post helpful.

As has been already mentioned (but I already typed most of this up before I realized there was another page)... Basically, having that option in the config file as a default overrides any system defaults. If a user has gone through the motions to switch the EDITOR/VISUAL variables, programs should utilize them by default. It does make sense to have an option to override it, but IMHO, that override shouldn't be used by default and should be something the user chooses to override.

Think about it this way, if a user has vi set as the default editor in the config, then launches sboui with EDITOR=pico sboui, what program do you think the user would expect to be the editor?

Now, we already know there are default system editors that can be set with the EDITOR and VISUAL variables. Maybe a compromise could be to use those unless the editor= option in the conf file is set, but to also allow overriding that editor using something like SBEDITOR=pico sboui (which the variable could be documented in the man page/help files). Basically, this would allow overriding something that may be set in the config, while still allowing the system defaults if nothing is set.

Just some food for thought...

1 members found this post helpful.

I'm starting to think that maybe the best solution is just to get rid of that option completely and just rely on the environment variables, with a sensible fallback in case those are not set. This would of course be documented in the manpage.

Hi , im testing a little , but im not found option to set custom TAG.

By default sbo use _SBo TAG for packages , is possible to set custom TAG ?

Thanks for this little fantastic tool !

There is a setting called repo_tag, but it is just meant for identifying packages from the repository. It doesn't override the TAG variable from the SlackBuild. Do you need it to do that?

Edit: I was just thinking, you could use build options for that. Those are just custom environment variables that are set when sboui invokes the install or upgrade command. Just hit Enter with the software you want selected in the right pane and select Build Options, then enter TAG=whatever as one of them.

Hi , the option repo_tag , is not help me.

I can enter in to build options , but tired to edit all times , i want permanent in config.

I love "slackbuilds" TAG , ... is not important , but think arround some developer with custom repo packages needing tagged.

Im not like enter custom tag all times.

Wheni say custom repos, i talk arround , repos with packages built , like ponce or alienbob , that people probably not use automated tools for provide "build" packages to not lost time building , but my request is that simply , permanent TAG option in config.

Thanks!

Use space to add a new build option. If you want to change the tag for all builds, set it in install_vars and upgrade_vars in the config file.

Alternatively, this seems like something the underlying package manager (e.g. sbopkg out sbotools) should be able to do.

@montagdude

Thanks fro your patience.

Thanks one more time !!!