CLI Database Discussions

Discuss anything related to command line tools here.
Message
Author
User avatar
vevy
Posts: 752
Joined: Tue Sep 10, 2019 11:17 am

Re: CLI Database Discussions

#211 Post by vevy » Wed Sep 09, 2020 5:53 pm

Use a unified text for the same type of warning in all applicable entries. A checkbox to show the template in the entry, so that if the wording is changed, the change is automatically reflected in all selected entries.

Easier contribution. Easier maintenance.
Help make the comprehensive CLI database happen:
                    Vote for filters/badges!

User avatar
vevy
Posts: 752
Joined: Tue Sep 10, 2019 11:17 am

Re: CLI Database Discussions

#212 Post by vevy » Wed Sep 09, 2020 6:13 pm

Expanding on the previous point:
vevy wrote:
Wed May 20, 2020 10:43 am
You are right about the internet-facing tools. Perhaps I should add a "deal with care and keep your version updated" caution to any inherently-risky tool even if they are still being updated. Better do it now rather than chasing after them later.


I want to draw attention to a relevant point here: The vast majority of the ports are also available in Cygwin and MSYS2. Those versions are usually the most recent, the fastest in operation and the most dependable. We want to add the following phrase to all the relevant entries: "You can also get this from Cygwin and MSYS2." We have two options:
  • Add it manually when we do each entry.
  • Have a checkbox in the entry editing screen for Cygwin, one for MSYS2, and one for both. Or, for simplicity's sake, just one for both. This checkbox adds the phrase automatically to the entry in a specified area; for example: under an "Available in:" section. This option will require more work upfront (on poor Andrew of course :mrgreen:).
Now imagine that Cygwin changed their website for some reason or got hijacked or whatever. With option one, you will have to go to all the entries and update the entries manually. With option two, you make the change only once, or disable the section with a click.

---------------------------------------------------------------------------------------------------------------------------------------------
entry_id entry_date parent_id (FK>entry_id)
123 2020 123
124 NULL 123

Code: Select all

SELECT a.entry_id,
       b.entry_date
  FROM table a
       LEFT JOIN
       table b ON a.parent_id = b.entry_id;

RESULT:
entry_id entry_date
123 2020
124 2020
Help make the comprehensive CLI database happen:
                    Vote for filters/badges!

User avatar
Andrew Lee
Posts: 2555
Joined: Sat Feb 04, 2006 9:19 am
Contact:

Re: CLI Database Discussions

#213 Post by Andrew Lee » Thu Sep 10, 2020 5:14 pm

vevy wrote:
Wed Sep 09, 2020 6:13 pm
entry_id entry_date parent_id (FK>entry_id)
123 2020 123
124 NULL 123

Code: Select all

SELECT a.entry_id,
       b.entry_date
  FROM table a
       LEFT JOIN
       table b ON a.parent_id = b.entry_id;

RESULT:
entry_id entry_date
123 2020
124 2020
Thanks for the tip! I will check it out soon.

User avatar
Andrew Lee
Posts: 2555
Joined: Sat Feb 04, 2006 9:19 am
Contact:

Re: CLI Database Discussions

#214 Post by Andrew Lee » Thu Sep 10, 2020 5:17 pm

vevy wrote:
Wed Sep 09, 2020 6:13 pm
Now imagine that Cygwin changed their website for some reason or got hijacked or whatever. With option one, you will have to go to all the entries and update the entries manually. With option two, you make the change only once, or disable the section with a click.
I am thinking this might be easier to implement with additional bbcode tags in the description field.

What do you have in mind in terms of presentation?

User avatar
vevy
Posts: 752
Joined: Tue Sep 10, 2019 11:17 am

Re: CLI Database Discussions

#215 Post by vevy » Fri Sep 11, 2020 3:07 am

Andrew Lee wrote:
Thu Sep 10, 2020 5:14 pm
Thanks for the tip! I will check it out soon.
Sure. I hope it works alright.

Of course, this may facilitate other relations too. I'll try to figure out the simplest way to use it for multiple fields.
Andrew Lee wrote:
Thu Sep 10, 2020 5:17 pm
I am thinking this might be easier to implement with additional bbcode tags in the description field.

What do you have in mind in terms of presentation?
I'm still working out the best way to do a "Get it from" field(s). Like, for sure using parent entry ID, but allowing flexibility for entering versions (of the port), notes, etc without being too complicated. See the current entries to get my point. Unix ports are in the hundreds, but they won't end up the majority of tools, so, I don't want to crowd the edit/view with too many fields that most tools won't need.

If you mean for the warning templates, you can use an easy-to-do simple presentation for now. How they should look will be much clearer when we see them implemented, I think. I have some ideas to preserve space (like using icons/badges with the warning as popup/hover text), but I am not sure if that will be clear enough. I have a tendency to nanny the user, mind you! :D
Last edited by vevy on Fri Sep 11, 2020 3:13 am, edited 4 times in total.
Help make the comprehensive CLI database happen:
                    Vote for filters/badges!

User avatar
vevy
Posts: 752
Joined: Tue Sep 10, 2019 11:17 am

Re: CLI Database Discussions

#216 Post by vevy » Fri Sep 11, 2020 3:08 am

[Moderator note: the discussion referred to below about about defining CLI and GUI were given their own thread.]
SYSTEM wrote:
Thu Sep 10, 2020 7:38 pm
webfork wrote:
Thu Sep 10, 2020 6:22 pm
SYSTEM wrote:
Thu Sep 10, 2020 12:14 pm
At this point I'd like to hear opinions from other people...
I had some notes but before I add more to that, would all parties be comfortable with a separate thread for the comparison of CLI vs. GUI discussion? There's starting to be a lot of subject overlap in this thread could confuse visitors.
Sure, a dedicated thread would be good. :)
You have my blessings! 😇


While you are at it, could you move these to the CLI forums?
viewtopic.php?t=24525
viewtopic.php?t=381
viewtopic.php?t=22865
Help make the comprehensive CLI database happen:
                    Vote for filters/badges!

User avatar
Midas
Posts: 5627
Joined: Mon Dec 07, 2009 7:09 am
Location: Sol3

Re: CLI Database Discussions

#217 Post by Midas » Fri Sep 11, 2020 4:02 am

vevy wrote:Could you move these to the CLI forums?

viewtopic.php?t=24525
viewtopic.php?t=381
viewtopic.php?t=22865

I disagree on the first case; the remaining two topics have been moved to "CLI submissions". :arrow:

User avatar
vevy
Posts: 752
Joined: Tue Sep 10, 2019 11:17 am

Re: CLI Database Discussions

#218 Post by vevy » Fri Sep 11, 2020 7:19 am

Midas wrote:
Fri Sep 11, 2020 4:02 am
vevy wrote:Could you move these to the CLI forums?

viewtopic.php?t=24525
viewtopic.php?t=381
viewtopic.php?t=22865

I disagree on the first case; the remaining two topics have been moved to "CLI submissions". :arrow:
You are right! I had this in my notes for a while. I probably judged by the title.


------------------------
I said before I was going with 3 years to call a tool discontinued, but this seems too short to me considering the update intervals of many tools I have seen. I am going with 5 years. Does this work for you, guys?
Help make the comprehensive CLI database happen:
                    Vote for filters/badges!

User avatar
webfork
Posts: 9640
Joined: Wed Apr 11, 2007 8:06 pm
Location: US, Texas
Contact:

Re: CLI Database Discussions

#219 Post by webfork » Fri Sep 11, 2020 7:53 pm

vevy wrote:
Fri Sep 11, 2020 7:19 am
I said before I was going with 3 years to call a tool discontinued, but this seems too short to me considering the update intervals of many tools I have seen. I am going with 5 years. Does this work for you, guys?
It's a great pleasure when I see tools come back from what I thought was dead status like Explorer++ or Asuite. I guess I can see some exceptions for an intensive alpha or beta process, but I think north of even two years without any developer activity is safe to consider discontinued.

Maybe it's a different standard for CLI developers, who knows?

User avatar
Andrew Lee
Posts: 2555
Joined: Sat Feb 04, 2006 9:19 am
Contact:

Re: CLI Database Discussions

#220 Post by Andrew Lee » Fri Sep 11, 2020 9:13 pm

vevy wrote:
Fri Sep 11, 2020 3:07 am
If you mean for the warning templates, you can use an easy-to-do simple presentation for now. How they should look will be much clearer when we see them implemented, I think. I have some ideas to preserve space (like using icons/badges with the warning as popup/hover text), but I am not sure if that will be clear enough. I have a tendency to nanny the user, mind you! :D
I did mean for the warnings. I am thinking having new bbcode tags eg. [warningNet] or [warningCompression], which will expand into whatever text in the description.

User avatar
vevy
Posts: 752
Joined: Tue Sep 10, 2019 11:17 am

Re: CLI Database Discussions

#221 Post by vevy » Sat Sep 12, 2020 8:28 am

webfork wrote:
Fri Sep 11, 2020 7:53 pm
but I think north of even two years without any developer activity is safe to consider discontinued.
There could be developer activity, but is more difficult to monitor that. I was talking more about releases. For example, you can see the jumps in time between releases with patch or make or sed.

Maybe it's a different standard for CLI developers, who knows?
I think that may be true, too. Remember the discussion about maintainability and how CLI tools tend to have a shorter path to maturity and stability than GUI tools.
Help make the comprehensive CLI database happen:
                    Vote for filters/badges!

User avatar
SYSTEM
Posts: 1957
Joined: Sat Jul 31, 2010 1:19 am
Location: Helsinki, Finland

Re: CLI Database Discussions

#222 Post by SYSTEM » Sat Sep 12, 2020 8:37 am

vevy wrote:
Sat Sep 12, 2020 8:28 am
webfork wrote:
Fri Sep 11, 2020 7:53 pm
but I think north of even two years without any developer activity is safe to consider discontinued.
There could be developer activity, but is more difficult to monitor that. I was talking more about releases. For example, you can see the jumps in time between releases with patch or make or sed.
I agree. You examples show how e.g. patch has recently had releases around every 3 years.

I think it indeed takes around 5 years without releases before we can judge a CLI program dead. Like you said, they get into a mature state with little need for updates fairly quickly.
My YouTube channel | Release date of my 13th playlist: August 24, 2020

User avatar
vevy
Posts: 752
Joined: Tue Sep 10, 2019 11:17 am

Re: CLI Database Discussions

#223 Post by vevy » Sat Sep 12, 2020 8:43 am

Andrew Lee wrote:
Fri Sep 11, 2020 9:13 pm
I did mean for the warnings. I am thinking having new bbcode tags eg. [warningNet] or [warningCompression], which will expand into whatever text in the description.
  • As long as it satisfies "edit once, update all", the main point is achieved.
  • It won't allow for filtering, but this can wait.
  • Is there a way to use a predetermined placement (at the top) regardless of where the tag was entered in the description field?
  • Maybe it can be given a visual distinction for the warning ones (like a grey background or so). We want it to be visible but not too stark, because we'd want the user to notice other, more-specific and more important warnings (avoid warning fatigue/indifference).
  • You can use a drop list like that of text size in the forums: Tiny, Small, Normal, etc.
Help make the comprehensive CLI database happen:
                    Vote for filters/badges!

User avatar
vevy
Posts: 752
Joined: Tue Sep 10, 2019 11:17 am

Re: CLI Database Discussions

#224 Post by vevy » Sat Sep 12, 2020 2:38 pm

300
Help make the comprehensive CLI database happen:
                    Vote for filters/badges!

User avatar
Andrew Lee
Posts: 2555
Joined: Sat Feb 04, 2006 9:19 am
Contact:

Re: CLI Database Discussions

#225 Post by Andrew Lee » Sat Sep 12, 2020 6:02 pm

vevy wrote:
Sat Sep 12, 2020 8:43 am
  • As long as it satisfies "edit once, update all", the main point is achieved.
  • It won't allow for filtering, but this can wait.
  • Is there a way to use a predetermined placement (at the top) regardless of where the tag was entered in the description field?
  • Maybe it can be given a visual distinction for the warning ones (like a grey background or so). We want it to be visible but not too stark, because we'd want the user to notice other, more-specific and more important warnings (avoid warning fatigue/indifference).
  • You can use a drop list like that of text size in the forums: Tiny, Small, Normal, etc.
Which is why I wanted to see what kind of presentation you had in mind.

Correct me if I am wrong, but you and I seem to take polar opposite positions on this point, which is you prefer to have a lot of information or minutiae associated with each entry (everything but the kitchen sink approach), and everything should be filterable, whereas I am less enthusiastic about this approach.

My reasoning is that if you start overwhelming people with information they don't need, it is going to be off-putting to readers to editors alike. Right now, you seem to be want to add a lot of additional information without asking anyone else if they need it or will find it useful. And every other day, you dream up more fields to be added!

Post Reply