img = ui.Image.named('companylogo.PNG')
img = ui.Image('companylogo.PNG')
I think that would work.
Excuse my slow response. I knew, advised by you, that the same discussion was held in this forum 2 years ago. There were many ideas in that discussion as well although I haven't been all through this yet.
I am very new to singleton approach and my understanding is that singleton pattern can be implemented in one running program. Am I right? If I run my program twice and create a thread in each program, then those threads have to be different threads(different instances,) I think.
Given many ideas, I'll keep posting for any update. Thank you so much.
Your solution seems working. Mysterious behavior (which I described) may be caused by my impatient testing. (run a program, close Pythonista, run a program again with no break but only clicking the shortcut icon etc.)
I closed all the tab of my script, and now it works all fine so far.
Yeah, this seems to work somehow, I mean I’m not quite sure why it works.
Anyway, adding your codes, I run my program by shortcut, leave it without closing it, once again I click the shortcut and now the previous view is closed. But this behavior is not stable, sometimes the view is still running behind the new view. I’m trying to find what makes this difference of behavior.
So far, by adding some print statement as follows:
def __init__(self): self.timestamp = time.time() threading.Thread.__init__(self) def run(self): while True: time.sleep(1) print(self.timestamp, console.is_in_background()) if console.is_in_background(): print('closing view') main_view.close() break
Seems like my_thraead closes the view only when the Pythonista itself is re-opened.
For example when I run this program on Pythonista (not from shortcut,) close the view and then again run the program, the output in the console shows like this:
(meaning two threads are still running)
and when I go back to the home screen and reopen Pythonista, the output shows like this:
I’m not sure but it may make sense. What do you think?
Still, I have some mysterious behavior so keep working on it. Thank you for your help. I didn’t think about using “console.is_in_background()”.
I put a home screen icon with shortcut to run a program I made. The program is with a ui view and the problem is that when I leave the view after using it without closing it (which we usually do when using a tablet,) and next time I run a program from the shortcut, a new view is invoked over the same view I opened last time. That seems natural because shortcut is only to open a program and run it, but I wonder if there is any way to avoid opening as many views as I click the icon. It seems difficult to manage a program running in a different thread, but as I believe we should mostly face the same problem when making a shortcut, does anyone have good idea on it?
What I’m doing now is calling a view which is already made using view class (it’s like my original font-picker), so I would rather choose your first sample. I pass a label object when calling a popup view as an argument and it seems almost perfect except one thing.
In case of your first sample (which is without @ui.in_background,) when getting back from popup, the button looks stay grey even though I can still press the button. (so it just looks grey.) I thought putting “@ui.in_background” would solve it, but not really.
When putting “@ui.in_background” before def onBtn, after returning from popup the button now looks ok (I mean the color,) but the button never responds after it. Only after closing the main view, the button’s action occurs.
Yeah! your codes now put the texts back to the main view.
You can't put a wait_modal inside a button action, because the ui thread blocks until the button exits
Ok, so this was the problem.
and this is why the button still looks grey after closing the pop-up?
“@ui.in_background” didn’t work.
“using a "shield" view” > means using add_subview, right? Yes, I believe this would work for handing data.
dialog modules> I didn’t think about. I will check this.
Thanks for your many hints.