gnome-text-editor issueshttps://gitlab.gnome.org/GNOME/gnome-text-editor/-/issues2023-11-21T17:36:17Zhttps://gitlab.gnome.org/GNOME/gnome-text-editor/-/issues/615Files that are renamed / moved while Text Editor is running are misdetected a...2023-11-21T17:36:17ZJeff FortinFiles that are renamed / moved while Text Editor is running are misdetected as "changed" on diskTo reproduce (with version 45 and earlier):
1. Open `foo.txt` with Text Editor
2. _While Text Editor is still running,_
with Nautilus (or something else, it could be a network process/sync), rename it to `foo (needs rework).txt"
Text...To reproduce (with version 45 and earlier):
1. Open `foo.txt` with Text Editor
2. _While Text Editor is still running,_
with Nautilus (or something else, it could be a network process/sync), rename it to `foo (needs rework).txt"
Text Editor will then show this infobar:
![image](/uploads/ca6d106f3df6e3db7c53a21568bd8cec/image.png)
...however it is not actually aware of the new name/location of the file (as hinted by the tab label and tooltip), and clicking the "Discard Changes and Reload" button will just reload the same version that Text Editor had in memory, not the newly named fileā¦ which may lead the user to think there were no changes in practice, or saving to the wrong place (or overwriting something by mistake), etc.
So basically, the "and reload" part of the infobar's button currently doesn't really do what it's intended to do, in this specific case. Perhaps a solution could be to prompt the user for the new name/location (if it can't be autodetected), or, if that's too complex, just warn the user more specifically about this in the infobar's label and not offer the reload button? i.e. treat vanished files as suchhttps://gitlab.gnome.org/GNOME/gnome-text-editor/-/issues/207Adaptive Layout2024-01-29T07:56:33ZTobias BernardAdaptive LayoutWhile it's not a deal breaker for 42 we'll eventually want this app to be adaptive (i.e. fit onto a width of 360px), so I think it'd be good to start thinking about what that will entail.
The main hurdles I see at the moment are:
- [x] ...While it's not a deal breaker for 42 we'll eventually want this app to be adaptive (i.e. fit onto a width of 360px), so I think it'd be good to start thinking about what that will entail.
The main hurdles I see at the moment are:
- [x] ~~The window itself has a min width of about 500px~~ No longer true on main
- [x] ~~The preferences sidebar is 325px wide so it would fit on mobile, but it might be a bit awkward layout wise. Definitely worth keeping in mind as part of #183~~ The new preferences dialog can shrink to 360px
- [x] The "highlight mode" dialog, which has a min width of about 500px
- [ ] Adaptive tabs (port to Adwaita Tab Overview)
cc @aplazas
- [ ] Search/Replace needs special treatment, maybe as a full-width toolbar at the bottom
- [ ] The headerbar contains too many elements to work well at narrow widths. Perhaps we could have a narrow mode for widths below 400px or so, which does some of the following:
- Replace `Open v` with an icon
- Move `New Tab` to the primary menu
- Show the line numbers outside the headerbar (maybe an overlay in the bottom right?)
- Make `View` a sub-menu in the primary menuBacklog