This topic created to show progress that we have with bringing mobile UI to desktop platforms.
(Inspired by thread about Nix from @pedro)
Why we aim for single UI?
- it is inconvenient to add new features in two UIs
- it is hard to make fixes in two UIs
- it is harder to test
- it would be nice to bring 2-pane UI to mobile platform (for tablets)
Why didn’t we have single UI from start?
Status Desktop implemented with react-native-desktop technology that wasn’t mature enough when we started work on desktop.
What has been done for merge?
So far we have a PR with basic implementation. It is fully functional for chatting but has review notes that need to be fixed.
That PR combines changes in
- Added getInitialUrl function to Linking module
- Fixed color processing for inline styles
- Added support to flexbox values in percents
- Added default values for styling
- Fixed backgroundColorSetting when border color defined
- Fixed issue with multiline textinput resizing
- TextInput defaultValue property fixed
- temporary disabled: wallet, qr scan, avatar changing
- fixed links and tags color
- chat text input lags
- send by enter for desktop
- context popup menus fixed for desktop
PR review revealed issues:
unsent text not saved when switching chats
no way to open user profile from public chat
search box lags
no context menu for messages in chats
some actions in popup menus don’t work
- messages preview not truncated
- bad scrollview performance in chat
- UI glitch - last two messages in chat overlapped
Currently in desktop UI you can’t click on user’s avatar and open profile. Working on the underlying problem in
react-native-desktop - https://github.com/status-im/react-native-desktop/issues/469
Nice! Are chat commands usable too?
@julien, not yet. Thanks for mentioning them. Will add to list of issues.
Problem with nested
TouchableHighlight was solved, so now on desktop it is possible to open profiles from avatar in chat.
Also fixed lags in chat search box and removed context menu options and buttons that call actions specific for mobile, like “share”, “invite friends”, “scan qr code”
Context menu for chat messages now called by right mouse click.
Next step will be investigation of poor FlatList performance on desktop.
@volodymyr.kozieiev Thanks for this thread and the updates. Do you think we could create an issue in Github (possibly with multiple issues linked to it) that outlines the known steps to getting mobile UI into desktop? Any thoughts on rough timeline for doing this? With our without poor perf.
Wrike milestone: https://www.wrike.com/open.htm?id=342148749
@oskarth, I’ll create an issue. Mobile UI already works, so without FlatList optimization I’d say it is not more than week needed to check/merge it with some additional fixes. As for FlatList - can’t say for sure, I don’t know where is the source of a problem yet.
FlatList performance update:
It is turned out that laggy behavior consist of at least two different issues.
First of them - long delays before dynamic loading next chunk of data. For this issue solution was found yesterday. There is discrepancy between mobile and desktop events flow. Desktop sends only one onScroll event per scroll and doesn’t trigger js implementation code as many times as it should.
Second issue - FlatList scroll position jumps when elements dynamically added to it while it scrolls. Will work on this right after fixes needed for mobile UI.
Having mobile UI on desktop seems like a good milestone to push marketing content about, even if it creates little material different for users. wdyt @jonathan @oskarth @volodymyr.kozieiev? Am I wrong about impact for users? Will there be any performance upsides?
And also, @volodymyr.kozieiev @andrey perhaps we can chat about implications for core UI, i.e. with mobile UI on desktop, how much easier is it to build for feature parity?
I think that mobile UI, especially when it will be 2-pane is a good point for desktop release.
how much easier is it to build for feature parity?
At least from UI standpoint that would be easier. No ui code duplication.
I agree that this is a nice update to push. It certainly makes the entire Status ecosystem much more cohesive.
We can and should definitely plan some comms around it. Do we have timing for the release?
It’s a bit early, because at first, the Mobile UI won’t be the default. It would be a good step from the technical perspective (we actually have the same UI implementation for both platforms), but we’ll need to fix 2 column view before we will actually make a real switch and get rid of the separate Desktop UI.
Until that, idk if we should communicate that.
Perhaps we can enlist some support from the community? If we communicate the fact that we are doing this and want to introduce the mobile UI on desktop, we can put up some issue & bounties and get people involved?
IMO - enlisting developer contribution is the best form of comms anyway.
I dont want to create more work for you all though so let me know if this is viable. If not, I can plan a different approach.
Idea about bounties is always good! But currently I don’t quite understand what task we can share with a community. We have 3 things to do: merge exisiting PR for mobile UI, improve FlatList performance, create 2-pane UI. And these tasks aren’t easily splittable into smaller ones to share with external contributors.
Probably it would be better to create bounties for fixes or desktop-specific UI features when at least minimal 2-pane UI is in place.
Mobile UI PR:
Few more regressions on mobile platforms were found yesterday that need to be fixed before merging mobile UI PR.
Latest profiling shown that scroll stuttering happens at the time of dynamic qml controls creation. I made that creation asynchronous and scroll fluidity is much better now. But there are still a lot of moments when FlatList shows blank spaces while controls loading. React Native documentation mentions blank spaces as a known tradeoff but anyway they shouldn’t happen that often.
Overall dynamic qml controls creation takes too much time. So I’m thinking on how to improve this.
Also I setup windows dev environment to check FlatList there and found out that it is buggier than on mac and crashes from time to time. So this platform needs additional attention
I agree, so far our experience with bounties was that polishing and bugfixing is the best way to at least get initial contributions (taking the initial dev env setup into account). So if there are few things to fix that aren’t urgent but it is good to have them fixed, we can make bounties.
For bigger tasks we aren’t there yet in terms of non-core contributors.
Just my suggestion: we could merge mobile UI first, and then just push our own flatlist implementation in status-react as a temporary solution ( i mean it will be the same component, but implementation inside will be different for desktop, simple one) , and then we could split 2-pane UI into small issues, i can help with it ,and bountify them
@andrey, we already have custom ScrollView implementation in react-native-desktop. And this implementation used in current desktop UI. It is far from ideal but better than current FlatList. If no quick improvements for FlatList found, we can use it.