Bug 410352 - Noticeable delay before FormLayout relayouting
Summary: Noticeable delay before FormLayout relayouting
Status: CONFIRMED
Alias: None
Product: frameworks-kirigami
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.59.0
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: Not decided
Assignee: Marco Martin
URL:
Keywords:
: 476816 500572 502100 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-07-29 13:02 UTC by Alexander Potashev
Modified: 2025-04-01 20:40 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
screenshot during the first second after dialog shows up (28.06 KB, image/png)
2019-07-29 13:04 UTC, Alexander Potashev
Details
screenshot when the dialog had already been on screen for more than one second (30.81 KB, image/png)
2019-07-29 13:05 UTC, Alexander Potashev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Potashev 2019-07-29 13:02:45 UTC
SUMMARY
Noticeable delay before FormLayout relayouting.

STEPS TO REPRODUCE
1. Build ktimetracker from this Git commit: https://cgit.kde.org/ktimetracker.git/commit/?id=2b535e8c1ec36ff968df1de5d9cbfdda4a35221d
2. Run ktimetracker
3. Create a task with a long description in ktimetracker.
4. Select the task in task list and press E (or select "Edit Time..." from context menu).

OBSERVED RESULT
"Edit Time" dialog opens in desktop layout, then it changes to mobile layout by itself after about 1 second.

EXPECTED RESULT
The appropriate layout of "Edit Time" dialog should be applied immediately, without changing it over time.

SOFTWARE/OS VERSIONS
Operating System: Fedora 30
KDE Plasma Version: 5.15.5
KDE Frameworks Version: 5.59.0
Qt Version: 5.12.4
Kernel Version: 5.1.17-300.fc30.x86_64
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-6700HQ CPU @ 2.60GHz
Memory: 15,4 ГиБ

ADDITIONAL INFORMATION
If I close the dialog and open it again without restarting ktimetracker, the layout won't jitter anymore, because the appropriate layout has already been calculated and applied on the previous appearance of the dialog.
Comment 1 Alexander Potashev 2019-07-29 13:04:35 UTC
Created attachment 121811 [details]
screenshot during the first second after dialog shows up
Comment 2 Alexander Potashev 2019-07-29 13:05:57 UTC
Created attachment 121812 [details]
screenshot when the dialog had already been on screen for more than one second
Comment 3 Marco Martin 2019-09-19 13:18:20 UTC
do you know if is due to that task name being so long? (should be elided btw)

i would see that window to have always the desktop layou (and perhaps the title/name part being outside the formlayout)

with that code in particular with the super long label, the "correct" behavior should be going to single column layout immediately and that should be adressed, tough that issue of long label should be adressed on ktimetracker part
Comment 4 Alexander Potashev 2019-09-19 13:34:17 UTC
(In reply to Marco Martin from comment #3)
> do you know if is due to that task name being so long? (should be elided btw)

Yes, relayouting happens only if task description is long. If it's short, then layout is always mobile (side-by-side).
Comment 5 David Edmundson 2025-03-31 22:23:04 UTC
*** Bug 476816 has been marked as a duplicate of this bug. ***
Comment 6 Nate Graham 2025-03-31 22:32:40 UTC
*** Bug 502100 has been marked as a duplicate of this bug. ***
Comment 7 Nate Graham 2025-03-31 22:32:44 UTC
*** Bug 500572 has been marked as a duplicate of this bug. ***