Yeah heres your problem

  = note: /usr/bin/ld: cannot find -lxcb-shape: No such file or directory
          /usr/bin/ld: cannot find -lxcb-xfixes: No such file or directory
          /usr/bin/ld: cannot find -lxcb-shape: No such file or directory
          /usr/bin/ld: cannot find -lxcb-xfixes: No such file or directory
          collect2: error: ld returned 1 exit status

adding this in the build sequence should help

 sudo apt-get install libxcb-render0-dev libxcb-shape0-dev libxcb-xfixes0-dev

I executed a basic request to google.com, which returns a status 300, page has moved or whatever because thats how they prevent people from scraping google. I was just testing all the different options, and when I tried to view the response headers we crash trying to unwrap what is an error. So we should be matching that result there and do some error checking.

• Fixed Issue Where We Had The Cursor Rolling Off The Screen If You Kept Hitting The Down Arrow.
• Fixed Build Issues On Windows.
• Put All Screen Code In Their Own Files
• Added New Input Screens But Left The Old Ones In Tact
• Added Debug Menu For Testing New Screens.

closes #27

Whatever the same issue that was being caused by App tests on our build before, is now happening locally on my machine after I pulled your latest code.

Im getting an error related to the inability to open the SQLite3 file. When I check the directory that its in on Windows C:\Users\username\AppData\Local\CuTE\CuTE.db CuTE.db is showing up as a directory not a SQLite database file.

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: SqliteFailure(Error { code: CannotOpen, extended_code: 14 }, Some("unable to open database file: C:\\Users\\k.mastroluca-clark\\AppData\\Local\\CuTE\\CuTE.db"))', src\app.rs:72:36

This is happening on startup before anything happens, its blocking my ability to open the app at all.

Issue

When navigating back to the method screen from the request screen we didn't clear the options vector. I think it's reasonable for the opts vector to persist from the request page down to the view response page but not back upward, it should be cleared to make room for the user to change their mind and make another choice. Otherwise, you have situations where you go back to the home screen with your previous response body or request options stuck on the bottom of the page.

Solution

This is how I fix this in app.rs

I add a previous_screen field to App with type Option which allows us to init with previous_screen == None which seems logically correct to me.

pub struct App<'a> {
    /// toml config file
    pub config: Config,
    /// is the app running
    pub running: bool,
    /// cursor position (veritcal)
    pub cursor: usize,
    /// current screen (stack.pop)
    pub current_screen: Screen,
    /// screen stack
    pub screen_stack: Vec<Screen>,
    // Previous Screen 
    pub previous_screen: Option<Screen>,
    /// index of selected item
    pub selected: Option<usize>,
    /// command (curl or wget)
    pub command: Option<Box<dyn CMD>>,
    /// vec of applicable options
    pub opts: Vec<AppOptions>,
    /// Input struct for tui_input dependency
    pub input: Input,
    /// vec for user input to push into
    pub messages: Vec<String>,
    /// input mode (normal or editing)
    pub input_mode: InputMode,
    /// vec of list items to select from
    pub items: Vec<ListItem<'a>>,
    /// list state for tui
    pub state: Option<ListState>,
    /// http response from executed command
    pub response: Option<String>,
    /// database connection
    pub db: Box<DB>,
}

You can see we clearly do init with previous_screen == None here.

impl<'a> Default for App<'a> {
    fn default() -> Self {


        Self {
            config: Config::default(),
            running: true,
            cursor: 0,
            screen_stack: vec![Screen::Home],
            previous_screen: None,
            selected: None,
            command: None,
            input_mode: InputMode::Normal,
            messages: Vec::new(),
            opts: Vec::new(),
            items: Screen::Home.get_opts(None),
            input: Input::default(),
            state: None,
            current_screen: Screen::Home,
            response: None,
            db: Box::new(DB::new().unwrap()),
        }
    }
}

Finally in App::go_to_screen() we take this approach, setting the previous screen, then matching on screen to see, if we have just navigated to the method screen, what was our previous screen? And if it was anything but Home, lets clear the opts vector. This might not be the best way to do this but it was what made sense to me i guess.

    pub fn goto_screen(&mut self, screen: Screen) {

        // Record Current Screen As Previous Screen 
        self.previous_screen = Some(self.current_screen.clone());

        // Push New/Next Screen Onto The Screen Stack
        self.screen_stack.push(screen.clone());

        // Set The Current Screen
        self.current_screen = screen.clone();

        self.cursor = 0;
        match screen {
            Screen::Method => {
                // If The Screen We're Going To Is The Method Screen
                // And Our Previous Screen Is Not The Home Screen, Meaning We're Backing Out  
                // Not Moving Forward
            
                if self.previous_screen != Some(Screen::Home) {
                    // Clear Our Options
                    self.remove_all_app_options();
                }   
            }

The return to home button on the response screen calls this remove_all_app_options() function as well, so this should cover our bases for now.

Like if I drill down all the way to URL input, then back all the way out to the main menu, then go all the way back down, and back up, after like 2 cycles I cant move back anymore. I think it has to do with unexpected behaviors related to hitting esc to go back on the home screen where there is nothing to go back to.

Most likely this is in JSON format. So we should think about possibly emulating the functionality of header input where we create a screen that allows adding and removing key/value pairs. The only thing is we should allow for raw text input as an option and if we do key/value pairs, we might have to figure out a way for a value to be another set of key/value pairs, which might get....complicated.

Im thinking the following:

• 1 Line Text Input (URLs, Raw Body Input, Etc)
• Multi-line Text Input (Not Sure What The Use Case Might Be Yet) ?
• Key/Value Input, 2 Text Boxes Side By Side, i to begin input on the key, enter brings you to value input, enter again confirms the input, Escape brings you to the previous input and eventually backs out of the screen.
• Data Add/Remove/Edit I see this one as kind of a list and you can hit a to add a new item, r to remove an item, and e to edit an existing item which would take you into one of the input/edit screens.

I think this will need a far more clever name before it gets released. Chat gippity has offered some pretty horrible suggestions. These are a few that came to mind

RUSTfull    (lawsuit?)

fetchMate

tuiFetch

Post-it

Ehko

Qwest

I think offering HTTP requests with any of those 3 options (HTTP custom, cURL, or wget) is just pointless, as I cannot see any reason why someone would want to send a GET or POST request with wget as opposed to cURL.

I think I am going to strip all the functionality of WGET aside from recursive downloads (the only thing it can do that curl cannot.) AND remove the option for custom HTTP requests (using reqwest) unless someone can provide me with a good reason not to. Because i just cannot think of any. Whether you use libcurl or some custom client.. it's all the same. and curl allows you to save the command and share it to run on servers or anything else you might want to do with it.

Fix

Before, when you tried to add a URL, and then add a second URL, literally you would have 2 URLs rendered next to each other in the Options window. That didnt make sense to me, so I restructured some key components of the options adding operation.

The following is the new add_display_option() function.

    pub fn add_display_option(
        &mut self,
        mut opt: DisplayOpts, /* We Make This Mutable Because We Need To Compare It To A Mutable Reference Later */
    ) {
        if self.should_replace_or_add(opt.clone()) {
            // TRUE = We Should Add An Option
            // Adding The New Test Here. should_replace_or_add
            // The user has not yet added this command option yet, and so therefore, we push it to the opts vector.
            // I need a copy of the option before we move it
            let match_opt = opt.clone(); // Lets refactor all this later.
            self.opts.push(opt);
            // We also need to add it to the sharable command
            // but we need to know what kind of option it is
            // the best way I can think of right now is to match it but I'm sure there's a better way
            match match_opt {
                // Im cloning this to shut the borrow checker up, there is probably a better way
                DisplayOpts::Verbose => {
                    // Just add the verbose flag to the command
                    self.shareable_command.as_mut().unwrap().set_verbose(true);
                }
                DisplayOpts::Headers((key, value)) => {
                    // Push Header To Shareable Command
                    self.shareable_command
                        .as_mut()
                        .unwrap()
                        .push_header((key, value));
                }
                DisplayOpts::URL(url) => {
                    // Set URL To Sharable Command
                    self.shareable_command.as_mut().unwrap().set_url(url);
                }
                DisplayOpts::Outfile(outfile) => {
                    // Set Outfile To Shareable Command
                    self.shareable_command
                        .as_mut()
                        .unwrap()
                        .set_outfile(outfile);
                }
                _ => {
                    // Nothing
                    // This display opt does not factor into the sharable command.
                }
            }
        } else {
            // FALSE = We Should Replace An Option
            // The user has already added this command option, and so therefore, we should replace the old value with the new value.
            //self.opts.retain(|x| x != &opt);
            // Sorry, this is my way to do this idk if its the right way, but this is what makes sense to me in my head
            for element in self.opts.iter_mut() {
                // Same thing down here, I only care if its the same KIND of option, not the same value
                // Again, this is annoying, I tried to do this an easier way
                // but mem::discriminant doesnt like element as a comparison so I need to be particular
                // Sorry lets refactor this
                // TODO: Refactor This.

                // We Want To Just Replace A URL
                if let DisplayOpts::URL(_) = element {
                    *element = opt.clone(); // Copy The New URL Into The Old One
                    return;
                }

                // TODO: Headers Will Be Handled Differently.

                // TODO: Outfile Will Be Handled Differently.

                // TODO: Verbose & Save Command Will Be Handled Differently.

                // TODO: Other Shit
            }
        }
    }

It took me a while to figure out that, a lot of the ways that we were testing if options had already been added was kinda broken. It could be that I just didnt understand it, but It didnt make sense to me, and so to make some actual progress, I just implemented a process that made sense to me.

These are the new tests for if we have a given option in the option vector.

    // Display option is some state that requires us to display the users
    // current selection on the screen so they know what they have selected
    // Lorenzo - Changing this because I dont think its doing what I want it to do.
    pub fn has_display_option(&self, opt: DisplayOpts) -> bool {
        // this is what we were doing before - self.opts.iter().any(|x| &x == &&opt)
        // I think this is what we want to do instead
        // We want to check if the option is in the vector
        // If it is, we want to return true
        // If it is not, we want to return false
        // We can do this by iterating over the vector and checking if the option is in the vector
        for element in self.opts.iter() {
            // I only care if its the same KIND of option, not the same value
            // This is annoying, I tried to do this an easier way
            // but mem::discriminant doesnt like element as a comparison so I need to be particular
            // im sorry i really dont like this
            // TODO: Lets refactor this.
            if let DisplayOpts::URL(_) = *element {
                return true;
            }

            if let DisplayOpts::Headers(_) = *element {
                return true;
            }

            if let DisplayOpts::Outfile(_) = *element {
                return true;
            }

            if let DisplayOpts::Verbose = *element {
                return true;
            }

            if let DisplayOpts::SaveCommand = *element {
                return true;
            }

            if let DisplayOpts::Response(_) = *element {
                return true;
            }

            if let DisplayOpts::ShareableCmd(_) = *element {
                return true;
            }
        }
        // Otherwise, its not there.
        false
    }

    // Lorenzo - Im adding this function as a slightly more
    // robust version of has_display_option, to test if we should be replacing a value or adding a new one
    fn should_replace_or_add(&self, opt: DisplayOpts) -> bool {
        // Lets match the type of display option
        // We know that only 1 URL should ever be added,
        // So if we're adding a URL we should replace it if it already exists
        match opt {
            DisplayOpts::URL(_) => !self.has_display_option(opt.clone()), // URL Should Be Replaced If It Already Exists
            DisplayOpts::Headers(_) => true, // Headers Should Be "Pushed" or Added
            DisplayOpts::Outfile(_) => !self.has_display_option(opt.clone()), // Outfile Should Be Replaced
            DisplayOpts::Verbose => !self.has_display_option(opt.clone()), // Verbose Should Be Toggled
            DisplayOpts::SaveCommand => !self.has_display_option(opt.clone()), // Save Command Should Be Toggled
            DisplayOpts::Response(_) => !self.has_display_option(opt.clone()), // Response Should Be Replaced
            DisplayOpts::ShareableCmd(_) => !self.has_display_option(opt.clone()), // Shareable Command Should Be Replaced With The New Version
            _ => false, // Anything Else Should Be Replaced.
        }
    }

My comments sort of explain myself as I go. I tried to do variant comparison with a function called std::mem::discriminant() but for whatever reason, it didnt like the element variable from self.opts.iter()? So this is kinda my hacky fix. I know theres a better way to do this, but for now, its verbose and clear what I mean. But its also kinda redundant and Im sure theres an easier way to do the same thing.

As you can see, ive also added additional functionality for the sharable curl command. That has been implemented as follows, but ive yet to touch any UI code having anything to do that yet, so basically, the data structure is there, but I havent thoroughly tested it yet. It shouldnt interfere with the operation of the application tho.

Sharable Command Structure / Implementation

impl ShareableCommand {
    pub fn new() -> Self {
        Self {
            command: "".to_string(),
            url: "".to_string(),
            headers: Vec::new(),
            outfile: "".to_string(),
            verbose: false,
        }
    }

    pub fn set_command(&mut self, command: String) {
        self.command = command;
    }

    pub fn set_verbose(&mut self, verbose: bool) {
        self.verbose = verbose;
    }

    pub fn set_url(&mut self, url: String) {
        self.url = url;
    }

    pub fn set_headers(&mut self, headers: Vec<(String, String)>) {
        self.headers = headers;
    }

    pub fn push_header(&mut self, header: (String, String)) {
        self.headers.push(header);
    }

    pub fn set_outfile(&mut self, outfile: String) {
        self.outfile = outfile;
    }

    pub fn render_command_str(&self) -> Option<String> {
        if self.command.is_empty() {
            return None;
        }

        if self.url.is_empty() {
            return None;
        }

        // This assembles the simplest possible command string
        let mut command_str = self.command.clone();

        // Check For Verbose Flag
        if self.verbose {
            // Verbose Flag Including Whitespace
            command_str.push_str(" -v");
        }

        // Whitespace
        command_str.push_str(" ");
        // URL
        command_str.push_str(&self.url);

        // Next We Check For Headers
        if self.headers.len() > 0 {
            for (key, value) in &self.headers {
                // Whitespace
                command_str.push_str("");
                // Header Flag
                command_str.push_str("-H ");
                // Open Quote
                command_str.push_str("\"");
                // Header Key
                command_str.push_str(&key);
                // Delimiter
                command_str.push_str(":");
                // Header Value
                command_str.push_str(&value);
                // Close Quote
                command_str.push_str("\"");
            }
        }

        // Check For Outfile
        if !self.outfile.is_empty() {
            // Whitespace
            command_str.push_str(" ");
            // Outfile Flag
            command_str.push_str(" -o ");
            // Outfile Name
            command_str.push_str(&self.outfile);
        }

        // Return Command String
        Some(command_str)
    }
}

Ill make a note that this structure is somewhat similar to your existing Command structure, but it has the curl command string formatting function, which I imagine will be getting plenty more complicated as we add new features.

With the version of CuTE I have in my path, I can currently hit my companies ec2 instance that has Canvas LMS, which requires a Bearer token API Key.

With the latest pull from main, I am getting an error immediately.

This project is full of horrendous practices due to still being in pre-0.1 release stage, many of those are examples of poor error handling, such as flagrant use of .unwrap() (although there are quite a few that are justified, like app.command.as_ref().unwrap().some_method() where there will always be a command field when those methods are called.

However, there is still much to do in terms of error handling. This is simple stuff and I really wish this was hacktoberfest still so people could get some easy PR's merged (on a rust project no less :D )

If I go from screen A to screen B, and enter some invalid information (such as an invalid path to an SSL certificate), when I go back to screen A (the request screen) there will be an appropriate error message on the top of the screen letting me know I have entered an invalid path. If I then navigate to another page (such as the "More Options" page) and then navigate back to screen A.. I will be presented with the same error on the top of the screen letting me know I entered an invalid path, even though that path was never actually input, so I need not be reminded about that again.

I didn't really know where to put this, this fixes my issue of recursive downloading support on Windows, I just wrote it in rust. I didn't implement it yet, idk maybe we give the user a choice, depending on what they have available vs what they want to use. The point is , this will just work without issues on windows. Either way it's there.