[Solved]Pythonista built in images, index access Vrs named
ccc last edited by
import os app_path = os.path.abspath(os.path.join(os.__file__, '../../../..')) os.chdir(app_path + '/Textures') print('\n'.join(os.listdir(os.curdir)))
@ccc, thanks so much. It is so cool, almost every problem/issue/want to have , seems to have a solution. I am sure you can access them in a similar way in 1.5 , maybe exactly the same way. In 1.6 I have noticed that the naming of the in built images has changed to something like 'iob:something' or 'cards:something' . I am guessing underneath somewhere @omz is planning to release a Module with dictionary access to these assets.
But what you have given is great. Can still filter etc... But it means more mess out of more testing code which is great!
app_path = os.path.abspath(os.path.join(os.__file__, '../..')) # Pythonista v1.5 app_path = os.path.abspath(os.path.join(os.__file__, '../../../..')) # Pythonista v1.6 Beta
When a post solves your issue, you should click that ^ at the upper right of the answer post. I do have my reputation to consider.
^ done, with kisses.
Joking aside, I do get it.
The second part of your title sticks in my head: index access v.s.named...
I find that when I want a random element from a sequence (tuple, list, dict, etc.) I always tend to favor random.choice() over messing with indexes.
@ccc , yes, this is the way for those who have worked out how to do repos :)
those who have worked out how to do repos :)
Are you asking for a 12 step program?!?
- In Pythonista, click in your latest script and do "Select All".
- Click again and do "Copy".
- Hit the Home button and switch to Safari.
- Go to your old code in your Github repo.
- Click the pencil icon at the upper right of your old code.
- Click in your old code and do "Select All".
- Do "Paste".
- Scroll down below your code underneath the "Commit Changes" label.
- Enter a brief description of the changes made.
- In the box below that, write a more detailed description of the changes made.
- Click the "Commit Changes" button.
- You might have to repeat 11 on the next screen if you are not the owner of the repo (I.e. You are creating a Pull Request).
Try these 12 steps to update your VirtualViews repo and let me know if they work for you.
@ccc , i can see I frustrate you sometimes. But it's ok, frustrating people are often interesting people :)
Yes, I know how to create a manual repo. Maybe my problem is that I have been trying to automate the whole thing. Also dealing with pulls, merges etc... Worry me
But I will create a manual one and see how I go. No VirtualView at the moment though. In culinary terms it's deconstructed at the moment :).
I am on focusing only on the cell at the moment. Threaded and not. With the idea that the cell could be used in other containers other than just in a scrollview.
I don't think you or JonB will like it ;) But I have to try what I think also.
But will try to make a repo of that today or tomorrow.
I also will switch to choice :)
I am actually seldom frustrated. My writing might give the wrong impression but I am quite laid back. The nice thing about a repo is that you can always temporarily add a VirtualView_deconstructed.py to allow others to to look over your shoulder as you experiment. A few daze later when you have it sussed out, you can fold the changes into the main file and delete VirtualView_deconstructed.py.
Phuket2 last edited by Phuket2
Even, my best friends will tell you I am frustrating :) oh, yes, choice is a lot easier, thanks :)
@ccc , btw, I didn't mean it in a bad way. If you didn't care, you will just not speak at all :) I really do get your meaning. As I say, I have friends from all around the world, they all communicate a little differently, written and verbal. I like you care enough to tell me! Silence is not always golden :)
I am a respectful and decent person.from what I have seen, so are most if not all the people here, even the 13 and 14 yr olds. Great to see!
JonB last edited by
In stash this is 4 steps or less
git add VirtualView_deconstructed.py
- type username, email, and commit message when prompted (this could have been included in step 2)
- click the + button for each changed file.
- type a commit message, and press commit
- press the push button.
(though i dont necessarily recomment gitview right now until i update the way branching works, and implement fetch/merge. right now it only includes pull, which gets hosed unless you are diligent about always pulling before committing new work, and pushing after committing, and not making changes on the remote in between... git in stash supports fetch/merge for the times when you have not been careful)
ccc last edited by
You guys missed my humor for my drinking buddy. Even if it took 3 steps or 20 steps, I would have made it a 12 step program.
Git is awesome but it has way too many modes and options. I like the web approach that I described above because it all happens in front of me on a ui that I can look at each step of the way.
On the Mac I use PyCharm to check in/out of repos and it works almost every time but it is not as bulletproof as the manual approach described above.
@ccc , I didn't miss or trip over the 12 step AA humour :)
Look really, I know it seems so easy for you guys. And I am sure it will be easy for me one day also. Hard to put yourself in a place of not knowing something you know so well sometimes.
Ask Stephen Hawkings to explain the universe to you, from at point of view he knows nothing about it. Hmmm, we he tried...failed big time in my opinion. He wrote a book about the Big Bang for beginners. I read it. I have always meant to write to him about that one!