Getting a view/subviews frame before calling .present()

Phuket2

Is there a form of a preflight to get the frame of a view before presenting it? Maybe it obvious, however I can't see how to do it. If I could say something like get_frame(popover) or get_frame(panel) etc.. Before I did a call to view.present(whatever mode) would be fantastic. Otherwise I am not sure how to code a little bit device independent.

ccc

You can always do...

w, h = ui.get_screen_size()  # caution: the values for w and h will change on portrait/landscape changes

And then use w and h to look up window dimension values in a dict that you create.

Phuket2

@ccc, sorry, I don't understand your answer. If I run


import ui

if __name__ == '__main__':
	v = ui.View()
	v.present('sheet')
	print v.width, v.height

On my iPad Air 2, I get 540,576
Same code on my iphone 6 is 320,504
I am sure a iPhone 5 would be different again.
v.present() is obviously doing something hardware specific, and will continue to do so in the future I guess. So I would be nice to know what it is going to do before it does it.

ccc

In the current beta, you will ALWAYS get (100, 100) on all screens. That is even smaller than an iWatch screen!! To be future-proof, you should set your own v.width and v.height to be some reasonable fraction of w and h respectively. Don't hard code to sheet View sizes but instead calculate the View size that makes sense for your app given the screen size.

Phuket2

@ccc, sorry, I stil don't get it. I guess maybe I didn't say it clear. But for example the 'sheet' presentation mode or 'popover' mode is very nice, as he calculates it, device independently. Omz code is calculating what he think the correct size for the device for each one of his presentation views at runtime (or more likely from Apples User Interface Guidlines). I am happy with his metrics, would just like to be able to query what the resulting size before calling the .present() method. I did a few things like trying to hide the view and calling .present('sheet') for example so I could get his frame values for what he calculated his view to be. But, It didn't look nice.
Oh, also have my apple watch... Got it in the first week out. Was lucky, got an import from Japan. Price was way up, but fun to have it so early in Thailand 😎

ccc

# In the current v1.6 beta on an iPad in landscape mode, the output is:
# ui.get_screen_size(): 1024.0,  768.0
#          full_screen: 1024.0,  704.0
#                sheet:  100.0,  100.0
#              popover:  100.0,  100.0
#              sidebar:  100.0,  100.0

import ui

fmt = '{:>20}: {:>6}, {:>6}'

def view_sizer(view_type='full_screen'):
    view = ui.View()
    view.present(view_type)
    print(fmt.format(view_type, view.width, view.height))
    view.close()
    view.wait_modal()

if __name__ == '__main__':
    w, h = ui.get_screen_size()
    print(fmt.format('ui.get_screen_size()', w, h))
    for view_type in 'full_screen sheet popover sidebar'.split():
        view_sizer(view_type)

Phuket2

@ccc, I can see what you saying here. But do you think it's just a bug that no one has bothered to report? I think it is. I can see no reason that presenting a 'sheet' should be 100,100. Somewhere in the docs (1.5) for example omz talks about the approximate size of the 'sheet' view relative to the device. If I am wrong I am, but I think the reporting of the 100,100 is a bug in 1.6

JonB

in the beta, the sheet size is no longer fixed based on screen size, as it was in 1.5.

this was documented in the release notes. it has the advantage that you can change the size of the sheet to suit your needs, though the disadvantage that the defaults were nice for some cases. I don't think it automatically slides up anymore when the keyboard is present, but I'm not sure.

(actually... sheet was only ever valid on iPad, I believe it simply used full screen on iPhone)