New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Fix/Feature] Restructured The Way Adding Display Opts Works | Added The Structure For A Sharable Command Feature #8
Conversation
…eypress. Related to the previous fix regarding UI navigation.
…o feat-win64-winfriendly
Removed 2 Newlines Because LOL
…ged a lot of code surrounding adding options to the app option vector. I added functions that test the existance of incoming option variants and particular functionality to determine what should happen with incoming options. For instance, some options should replace existing ones however, some should simply be added on top of existing ones. Finally, others should be toggled on and off. The desired functionality works for URL currently, but is not yet implemented for other option types.
Fixed Option Adding Functionality For URL's, And Built The Foundation For Other Kinds Of Options To Be Properly Added And Removed As Desired.
Please dont merge this yet i just saw a really dumb mistake |
…the actual variant type and so it was a condition where has_display_option would basically always be true.
[Fix] has_display_option is no longer always true
That last commit should have fixed it, but maybe im crazy and it wasnt broken anyway idk. Now im confident it works. |
Fixed The If-Let Problem
Should be good. |
NVM: I'll fix the conflicts. Looks good man Yo I fucking commented: Somehow that made it into the fucking commit dude. look at 209fd9d |
Lol this is why testing... That little slip up would have got merged into main and gone unnoticed (till someone compiled locally but still) From now on, tests have to be included for every feature at the bottom of the respective file. if there becomes too many, we'll have to create a whole dir |
Yeah i was confused. Lol, I'm doing a little abstraction and moving things around into modules because app.rs is getting dangerously long. |
Ok feel free to create a tests dir and put the tests in there. Or if you want to split that up to 2 diff files. it's up to you, i'll review it and if i dont like it we can do something else :) |
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.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.
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
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.