https://kotlinlang.org logo
Join Slack
Powered by
With the latest versions of Compose (desktop) I ob...
# compose-desktop
m
With the latest versions of Compose (desktop) I observe a very strange behaviour. After launching the application a whole view of my application is simply not rendered anymore although there is no error message or anything. Normally the screen looks like in screen1.png (only a fraction of the full screen is shown here) but now it looks like in screen2.png. As you can see, the whole part with the search field and the gray area where a tree view appears once data is loaded, is simply gone. If, however, I switch to another screen and then come back to this one, it is rendered normally. This change in behaviour happened between 1.4.0-alpha01-dev984 and 1.4.0-alpha01-dev985 and is still apparent in later versions. Does anybody have a clue what might have triggered this and what might be a possible workaround? The app has been working nicely for weeks now and this is really throwing me back.
i
Could you provide a small code or project (if possible), so we can look at the issue? Any regressions in the latest versions are high priority for us.
m
I can give that a try but this may be difficult. The code is part of a real-world application and this kind of problems offen vanishes as soon as you try to strip out “seemingly unrelated” stuff.
i
Is it reproducible in 1.4.0-alpha01-dev980? We can check which fixes are between dev980 and dev984
m
I am not sure I am understanding you. The app worked correctly until and including version dev984. Since dev985 up and including dev1000 it is broken. So you would have to compare the changes between 984 and 985.
i
But could you check with dev980? It will help us to narrow the issue (we can look at the list of the changes between 980 and 984 then)
Ahh, sorry, I misread you. It works correctly in 984, got it
k
One thing I did notice going from 984 to 985 is that the windows are now being composed for the first time at size 0x0, no matter what the 
WindowState.size
is. Don’t know if this is relevant here, but maybe just in case.
m
This is indeed a valuable hint. The vanishing part is the whole left part of my VerticalSplitView and a 0x0 initial size may very well spoil the whole size calculation for the two parts. What sense does such a 0x0 size make? For me that looks like fishing for trouble in many places.
k
That change might have been a side effect of work on https://github.com/JetBrains/compose-multiplatform/issues/2676
a
@Kirill Grouchnikov Can you make a reproducer for this? I don’t think that should be happening.
k
For initial size 0x0?
a
Yes
i
Created an issue
a
Ok, I’ll take a look.
m
I guess the issue already contains the reproducer for 0x0.
a
When I worked on the Dp.Unspecified issue it was only measuring twice if the size was indeed unspecified. The first time at screenWidth x screenHeight and the 2nd time at the measured size from the 1st time.
Should be fixed very soon.
m
I also found the problem on my side which was triggered by the 0x0 input. I use a modified version of this SplitView in my code. The variable 
barPosition
determines the sizes of the parts. The problem is that the computation is unconditionally remembered. The fix is to just replace 
remember
by 
remember(constraints)
so that the barPosition is correctly recomputed when the constraints change. My code now works for all versions up to 1.4.0-alpha01-dev1000. Thanks everybody for the help and especially Kirill for the crucial hint. It’s the right moment now to slide into the weekend 😉.
a
m
I actually looked into that first but the other one was easier to change for me.
i
In 1.4.0-alpha01-dev1003 it should be fixed
7 Views
Open in Slack
PreviousNext
Powered by