Wanted: Feedback on TUI

Hello

Couldnt think of a better place than "What is on your Mind".

So me have that project http://www.unix.com/shell-programming-and-scripting/253496-tui-text-user-interface-framework-scripts.html.

Eventhough i tried to describe it well in its thread and its README.md on github, i've been asked what for it is.
Where i already fail to understand why "a line based Text User Interface for scripts" isnt a good description???
To me that question sounds like: "What is the command 'echo' and 'printf' good for?"

What i'd like to get, if you already tried out, is feedback to keep improving it.

Reason i'm asking is, i have one feedback telling me how easy it is to apply, and one feedback telling me its all but natural or easy approach and that he wouldnt know how to start or use it.
Beeing asked what they liked or dislike, neither of them replied.

Now, having only 2 feedbacks which are quite opposite to eachother and beeing left alone when trying to get more details from those 2 guys, i feel the urge to ask here.

Actualy I have two questions, for either of which i hope you already did at least try TUI.

1. Could someone please help me to get a technicly correct description on TUI?
   I seem to even fail describing it good enough in (swiss-)german which is my mothers tounge.
2. Could you please share your collected impression/opinion on TUI?
   [list]
3. Is the help text (-h) unclear?
4. Is there too less info in the manpage/s?
5. Is the README.md misleading?
6. Is the wiki usefull?
   [/list]
   

A last 'question'.
If you have TUI installed, please post your system here, and if some commands giving trouble - name them, so i'd know which files need to be fixed for which systems.
As obvious visible some errors might look, on another system they may not occour at all.

I start figuring, the hardest part to contribute one owns project to "the community" is to get a large enough 'range/amount' of people using it, so feedbacks/requres/suggestions/errors are reported back 'automaticly'.

And to have the proper description, to attract only those who can handle it.
(As in: It makes no sense to have the bank accountant using Photoshop CS3000 (idk, wc), and the artist to use the latest Abacus)

Any advice/feedback?
Thank you in advance.

I haven't tried it before, here's my thoughts on the installation process:

1) I find it ironic that I must edit a config file to get a text UI installed where I want it to.

2) It's disquieting that it would default to installing in /usr/ and have no easy way to change it.

Perhaps it could accept a PREFIX like ./configure does, and default it to /usr/local ? This is not what everyone would want, but could prevent big problems in the future, and would be much easier to change than editing 8 different lines.

        app=tui

        [ -f install.sh ] || cd "$(dirname "$0")"

        if [ -z "$PREFIX" ]
        then
                echo "You have not specified a PREFIX, so $app will install in /usr/local ." >&2
                echo "This is probably not what you want.  Run PREFIX=/usr $0 to install in standard paths." >&2
                PREFIX="/usr/local/"
        fi

        DIR_BIN="$PREFIX/bin"
        # Default paths:
        DIR_COMPL="/etc/bash_completion.d"
        DIR_APP=$PREFIX/share/$app
        DIR_CFG=/etc/$app
        DIR_DOC=$PREFIX/share/doc/$app
        DIR_MAN1=$PREFIX/share/man/man1
        DIR_TPL=$DIR_APP/templates

Thank you Corona.
That is one of the points why i'm asking, on RedHat based systems, these paths are the system defaults and are used by the packaging system (rpm) too.

Might i ask what system you are using / did install TUI on?

Note to self:
Need to store the PREFIX from within the installation script, and reuse it for those installed command rely on "/usr/share/$app/*".

My Gentoo system uses /usr too, which is kind of the issue -- I want to do a temporary installation, not a root installation. I want to easily differentiate between things I've installed with emerge and things I've installed by hand.

When you install via RPM, emerge, or whatever other official package manager, /usr is normal. When you install from source, by hand, /usr/local/ is normal (and much easier to clean up should anything go wrong.)

Did anyone try with the updated install.sh script yet?
Or did experience any unexpected behaviour (bugs/errors, help 'screen' outputs) otherwise?

Thank you

I have yet to try your package but this caught my attention:

A line based Text User Interface for scripts is indeed sounding like "printf and echo" and many might ask why, with "echo" and "printf" at hand, they should use this instead. How about finding a title which reflects what sets the package apart from these standard instruments of output? Something like (ok, i admit this is not meant seriously, but i can't resist):

The blinking underlined coloured flashing eye-catching script-library of doom!

bakunin

Getting your point.
Seems the strive for a the best descriptional title was counter-productive.

But i'm a bit confused...
I mean, ncruses its short-description is: "Ncurses support utilities"
And to be honest, the full package description is beyond my understanding, regarding that i understand this to be a 'cli 3d window' environment kind of thing...
Saying: I would not expect this behind such a description.
Please correct me if i'm wrong.

Some ideas:
Simple-Description: "Text User Interface - framework for script"
Hyper-Enthusiast-Selling: "TUI - A scripters heaven"
Realist: "TUI - tools for scripters

Catch-phrase-attempt: "TUI :: Why Code & Compile when you can Script & Run."

Otherwise, only similar ideas such as yours come to mind

Have a nice weekend

Sorry for taking some time - some urgent project followed by some even more urgent illness took my attention.

My suggestion is to abandon "TUI" for some catchy name. Like, for instance, "Samba" - derived from "SMB", yes, but still more rememberable than, maybe, "SFMU - SMB filesystem mounting utilities" or something such.

How about:

"HardCore - the core of script programming made easy and reliable"
"Riot - a robust I/O toolset for your scripts"
"IOdine - the antidote for your scripts I/O goitre"
"CLIO - let the muse kiss your script to make it famous" *)

You might want to consult a latin dictionary for verbs of the fourth (-i) conjugation. The first person singular indicative praesens active (like "i do" for "to do") ends in "-io" so there are many possible plays on words.

bakunin

________
*) actually the meaning of the name of the muse of history, "Clio" (greek '') means "made famous".

Just in case someone is interested in an ironic fact of my life: This is about the second time in my life that 4 years of learning ancient greek in Gymnasium (similar to Highschool) has helped me anything.

tcusses

Was too early to write.

---------- Post updated at 12:39 ---------- Previous update was at 10:27 ----------

I thought i asked for a 'catchphrase', refering to the project name 'comment', not its very own name.
But should have expected new names along the way.

Noone wants to rename their 3.5 year old child.
Specialy when its already used in other projects (of mine at least).

But since i'm currently rewriting the internal core functions/variables, NOW would be the time to rename it along the way...

If/when i consider renaming the project, I do like:

• "HardCore - the core of script programming made easy and reliable" ((hc / cosp))
• "Riot - a robust I/O toolset for your scripts"
• "IOdine - the antidote for your scripts I/O goitre"
• "CLIO - let the muse kiss your script to make it famous" *)
• ---
• "CIF / CLIF - Cool / (Command line) Interface Framework"
• "STAN - Script Tools And Noobs"
• "EASY - enthusiastic automated script yells/yawns"
• LINUX - Lazy Interface neglects Unix eXperience
• UNIX - Universaly narrowed interface experience

Bold ones beeing my favorites.

Any thoughts?

swarm - shell wrapper and runner modificator

Issue is, i want something meaningfull to use as prefix for the 40+ commands.

And (for example) riot belongs to a list of words i dont want to repeat in my mind without a reasonable reason.
swarm, would be too long to type before each command, wouldnt it?

Well that is my opinion.

Would you like to type: (top 3)
clio-echo or clio-conf-get or clio-browser
clif-echo or clif-conf-get or clif-browser
swarm-echo or swarm-conf-get or swarm-browser

Or could i just leave the command-names as they are now, and just rename the project?
I'd very much like this idea, as this would cause much less work for me, and preserve the (imo) meaningfull command prefixes i currently use (tui-*).

What do you think?

No, i think you should undergo the extra effort. The problem is that the "good names" are usually already used and the more common your names are the more likely you are clashing with something already existing.

Personally i am a fan of Hungarian Style Notation, although i stripped it down and modified it for my personal needs, so take the following as a template and modify it until it suits you. Here is my (personal) convention for my own library and internal script functions:

f_Name - external function, all of these come from /usr/local/lib/ksh
pName - internal function in a script returning <void> (aka "procedure")
fName - internal function returning something meaningful (aka "function")

So i can tell from the name alone where i will have to look. If you would at least provide a common beginning, like, for instance, "hcFunctionOne", "hcFunctionTwo", etc. or "ClioFunctionOne", "ClioFunctionTwo" and so on it would help immensely. Not only because it helps keeping track of where a function came from but also because it would avoid possible name clashes. How many functions are out there named "Clio*" or "hc*"?

I hope this helps.

bakunin

You misunderstand the concept there is, i think.

tui-<*> IS the function, procedure, command or whatsoever.

ls /usr/bin/tui*|wc -l
44

Functions i used in more than one script, became scripts themself.
tui-printf was the very first 'exported' function, and stuff like tui-str-extension from tui-str-genfilename are the most recent ones.

Thats why i think it still makes sense to keep the command names 'as-is': tui-echo, tui-header, tui-dd, etc.
As they represent that these commands belong to each other, and have a meaningfull prefix while reading a script.

The only files the user (you ; is supposed to) change/s are the config files in $HOME/.config (default), or the theme in the rc file.
Other than that, in some sense, its like grep, echo, dd, and read or select, just matching the same output-theme.

There is a naming sheme, like:

$ tui-bol-
tui-bol-dir   tui-bol-gui

They will return true (0) or false(1) wether the last item is valid/applies.

$ tui-conf-
tui-conf-editor  tui-conf-get     tui-conf-set    

Gets or sets a value of a variable within a conf file.

$ tui-str-
tui-str-bol-conv     tui-str-encrypt      tui-str-extension    tui-str-genfilename  tui-str-usb

They return strings according to their description, tui-str-usb could even be used to select a connected/pluged in usb-storage.

Guess i'm missing this part in the README?

In fact i misunderstood your question. Whatever you finally decide your package to be named, it will be a good idea to have the naming consistent. If you stick with "tui", then name them "tui*" (or maybe "tu*"), if you want to change the name to any other of the mentioned alternative you should rename them (hc*, clio* [maybe cl* or cli*], etc.). But to get the connection between "tui" and, maybe, "riot" or whatever is putting additional burden at the user.

i would have no problem typing any of the mentioned variants. The only thing i'd want as a user is consistency.

bakunin

In fact, my initial question was ment to be:

"What is a good catch phrase." (In reference/assuming that a phrase is not a project/application-name)

And according to what was posted then, my new question is:
.... nevermind... found the answer.
Just figured, i could apply the non-abrevihated text without causing a name change.

rpm-spec:
name: tui
description: <yet to decide>

Like:
Name: whiptail
description: display dialog boxes from shell scripts

Guess i should have used the word description rather than catchphrase.