General bug report thread

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.

dgelessus

Two more things:

When in the interactive console, tapping an autocomplete suggestion (that is not a callable) will always add an extra space after the name. This makes sense for assignments and most operators, but for attributes and function calls it will produce strange results, such as something .attrib .do_stuff(arg1 , arg2 ). I know it's just a minor style thing, but the code just looks wrong with the extra space. And it doesn't work the same as the completion in the editor does.
Large files can (and will) lock you out of the app. Accidentally opening one causes Pythonista to practically hang on the "loading file" screen, and although the app isn't considered as "crashed" or "hung up" by the system, no input is accepted anymore until the file is loaded. Quitting and restarting the app won't help either, as it will try to open the large file before displaying any UI. Would it be possible to add a warning before opening a file larger than X megabtyes, or a switch in the external Settings sheet for the app that disables opening the last file temporarily? The latter is common for apps with file management and viewing capabilities to prevent these kinds of lockouts.

omz

@dgelessus I know this isn't ideal, but for now, if you're "locked out", you could open Pythonista by entering pythonista:// in Safari. This will skip the "reload last file" step.

dgelessus

Thanks, that works perfectly! Now to clean up the C lexer cache files that caused this...

dgelessus

Yet another thing: when typing any kind of opening parenthesis inside a string or comment without "closing" it in the same line, the next line will be indented like e. g. with multiline dicts. For example:

dict = { # expected indentation
        "a": "b",
        "c": "d",
        "e": "f",
}

if char == "{": # curly brace inside string should be ignored
             # gets indented up to here
    # but should only be up to here