General bug report thread

ccc

ui.measure_string needs to be called in the main thread within a drawing context. Does this bug occur when ui.measure_string() is called in the main thread within a drawing context?

omz

@ccc It looks like those are two separate bugs.

dgelessus

The console input alert variants only take title, message and hide_cancel_button as keyword arguments. The other arguments need to be passed positionally. For example, this is not possible:

console.input_alert("Enter something", ok_button_title="Uzbekistan")

Instead, this has to be done:

console.input_alert("Enter something", "", "", "Uzbekistan")

However, this is possible:

console.input_alert("Enter something", hide_cancel_button=True)

Oh, and hiding the cancel button causes the input dialog to always raise a KeyboardInterrupt("canceled"), even though it should return the input string.

coolius

Pythonista crashes when I try to save a PIL Image. No python errors, but a real crash. I think this happens at a memory leak, I've had pythonista crash before when using too big PIL Images.

omz

@coolius A few more details would be helpful – what type of image file are you trying to save (png, jpeg...), where did the image come from, how big is it, what kind/generation of device are you using...?

JonB

ui.covert_point, et al, does not work right in fullScreen, converting to/from Screen coordinates.

Here's an example.


import ui        

class testconvert(ui.View):
    def __init__(self):
        self.t1=ui.Label(frame=(0,60,400,20))
        self.t2=ui.Label(frame=(0,90,400,20))
        self.t3=ui.TextView( frame=(0,120,100,20),bg_color=(1,0,0))
        self.t3.begin_editing()
        self.t3.text='textview for kb'
        self.t1.text='touch to begin'
        [self.add_subview(s) for s in [self.t1,self.t2,self.t3]]
    def touch_began(self,touch):
        self.t1.text='touch in view:={0:1}'.format(touch.location)
        self.t2.text='touch in screen:={0:1}'.format(ui.convert_point(touch.location,self,None))
    def draw(self):
        kb=ui.get_keyboard_frame()
        ui.set_color((0,1,0,0.5))
        ui.fill_rect(kb[0]-10,kb[1]-10, kb[2]+20,kb[3]+20)
        
    def keyboard_frame_did_change(self,frame):
        ui.delay(self.set_needs_display,0.5)
    def touch_moved(self,touch):
        self.touch_began(touch)

V=testconvert()
V.present('fullscreen',hide_title_bar=True)

In fullscreen, we'd expect both screen and view coordinates to match. But it seems like convert is using landscape, button left, as the coordinate system, both for origin and orientation.

This may be related to some of the keyboard funniness, seems like maybe keyboard frame related functions might be using a similar convention, except I think keyboard frame is fixed in portrait! The keyboard frame in this example is drawn in green, slighty bigger than real frame so you can see it... Setting the keyboard to split and moving it up/down shows how the kb thinks it is moving... Things seems to be fixed to portrait, except it seems to switch between right side up and upside down depending on how it is rotated in landscape...

JadedTuna

A bug in the scene module?

If you set frame_interval to 0.1 in scene.run, it will give you an error.<br>
If after that you change frame_interval to 0 and try to run script again, nothing happens.<br>
If you try to run the script again, Pythonista crashes (often)<br>

Smallest example:

import scene

scene.run(scene.Scene(), frame_interval=0.1)

techteej

When using the UI Editor...

1.) Place a segmented control in the center of your view.

2.) Place a label underneath segmented control, also in the center of your view.

3.) Present as a sheet, and you'll see the label gets auto positioned under right segment.

JonB

Tech, not a bug. label defauls to no flex, segmented control defaults to LR. Just go into attributes/resizing, snd select the left and right parts to force LR flex.

Actually, this does bring up something confusing: in the ui editor, where you select flex settings, the convention seems to be reversed for WH compared to TBL or R. In other words, when you have W or H selected, those arrows show up as dark/solid. When you have T, B, L, or R selected, they show up as light/dashed.

omz

@JonB True, that can be a bit confusing. I'm following Interface Builder's conventions in the UI, see this StackOverflow answer for a couple of examples (screenshots with explanations).

JonB

@omz wow, bizarre! The IB convention makes no sense!

JonB

Can't remember if this was reported... In ui builder, if the resizing options dialog is open (the flex animation thingie), then you click in the button which toggles between editor and ui builder, pythonista crashes

Kenbo01

I often find Pythonista crashes when I copy text from a web page directly into the editor. Is this a well known bug or should I provide examples?

ccc

sys.exit() does not put a \n after its output

Put the following into an Empty Script: import sys ; sys.exit()
When run three time, it genereates the output: EXIT (0)EXIT (0)EXIT (0)
Instead of the output: EXIT (0)\nEXIT (0)\nEXIT (0)\n

Sebastian

Sometimes, in the editor, when I write two equal signs in an if condition and quickly touch space, the last equal sign will be replaced by a whitespace. I don't know if anyone else have stumbled upon this bug, but it really bugs me (pardon the pun).

JadedTuna

@Sebastian, yes, I am expecting the same behaviour. I thought it was me pressing spacebar instead of another = sign accidentally

inoddy

This bug has been reported before - Windows style carriage returns can cause Pythonista to crash. The report said that happened when using the delete key. I have found that too. But also I have found the crash simply upon opening a script.

The interesting bit is that it was only a small section of code that caused the crash. Deleting a couple of lines on a PC avoided the crash.

If you want a copy of the file I can supply it as a zip archive.

yusuke

Hi, we found a bug for input from external bluetooth keyboard.
We have a japanese layout bluetooth keyboard.
When use the keyboard for coding in Pythonista, the keyboard is recognized as US layout, can't enter some marks as printed including double-quote, brackets brabrabra.
We've checked another applications then they accept the characters as printed.

I think this can be happened with a AZERTY layout keyboard. But I don't have it.

dgelessus

It is possible that your keyboard layout is set incorrectly. In the Settings app, go to General > Keyboard > Hardware Keyboard, and check the settings for the Japanese layout you're using. I don't know anything about Japanese, but I can set my hardware layout to "Kana", that may be what you're looking for.

If this didn't help, try pressing Cmd+Space until the right keyboard layout is selected.

smath

@inoddy - Thank you! I was wondering what was causing me to crash when hitting backspace on a carraige return. I would have never guessed.