启动时记忆窗口大小位置、小窗模式横纵比锁定#1574
Conversation
|
这个实现看上去不错,但有两个问题
|
|
1.因为要判断上一次是不是从小窗模式意外退出的,所以得读一次记忆的窗口大小,应该需要先show。如果不判断小窗的话,可以移到前面去实现。 |
|
这里变成了一个权衡,也就是在启动闪烁和窗口记忆中二选一 其他 flutter 应用似乎都没有实现这个复杂的窗口记忆功能 |
|
不,记忆不是我实现的,而是原本就有的。 |
|
但是 show 之后设置确实会在低速设备上导致闪烁,这个之前专门修复过 |
|
那直接去掉这一串代码就行了。根据main.cpp和AppDelegate.swift现在的写的内容,第一次启动时Windows尺寸为(1280,720),Mac尺寸为(1280,860),窗口尺寸还算正常,没有必要额外设置尺寸。 |
|
这个实现看上去不够健壮。 kazumi 直接调用 exit(0) 进行强退,这导致在某些情况下,正常退出也可能不触发窗体保存。 以及常量命名存在问题,某些情况下会出现混淆,defaultWindowState 会比 lastWindowState 更好。 |
|
启动时记忆上次窗口大小和位置, |
的确是个问题,不好解决,我没有解决这个问题。 |
|
撤回了Windows和Linux平台的实现,且在WindowOptions里写窗口尺寸和居中,以规避前面提到的低性能设备窗口抖动问题。
经测试,在macOS下可以正常记忆窗口尺寸和位置,在kde plasma下跟随默认窗口规则,在Windows下保持原有行为。 |
1.启动时记忆上次窗口大小和位置;
2.第一次启动、以及从默认尺寸的小窗模式直接退出后,启动时会设置窗口尺寸,逻辑与之前一样;
3.进入小窗模式时记忆正常模式窗口尺寸,退出小窗模式时恢复对应尺寸;
4.小窗模式横纵比锁定为16:9,退出小窗模式后恢复正常;
5.限制桌面端窗口最小尺寸为(320,270),避免调试时窗口太小导致闪退的麻烦,也可以减少开发者在过小宽度下的无用考量。其中320为移动设备安全宽度。现在几乎不存在宽度小于320的手机,Kazumi也没有为这个宽度以下的设备做优化,更小的宽度本就会出现一些布局问题,320宽度给移动设备做参照用应该够了。270为小窗模式默认高度。