The tus-based upload flow (/drive/tus) has been removed upstream in favor
of a new multipart upload protocol. This commit replaces all TusClient
usage with the new FileUploader service that follows the official
/drive/files/upload/{create,chunk,complete} endpoints.
Changes include:
- remove tus_client_dart dependency and related code
- add putFileToPool() backed by FileUploader.uploadFile()
- update uploadAttachment() to call the new putFileToPool
- preserve poolId support, filename, and mimetype handling
- ensure progress callbacks fire at start and completion
This aligns the client with the new upload protocol while keeping the
same Compose UI and settings logic introduced in earlier patches.
Signed-off-by: Texas0295 <kimura@texas0295.top>
- extend AppSettings with defaultPoolId
- add pool filtering utility to exclude media-only pools
- add resolveDefaultPoolId with fallback to safe pool
- update SettingsScreen with default pool dropdown
- integrate uploadAttachment with default pool resolution
Signed-off-by: Texas0295 <kimura@texas0295.top>
- add defaultPoolId to AppSettings + persistence
- extend SettingsScreen with pool dropdown
- update uploadAttachment to use defaultPoolId with fallback
Signed-off-by: Texas0295 <kimura@texas0295.top>
`loadInitial()` fetched 100 messages while `_page_size` was 20,
so `_has_more` turned false too early and history stopped around
10h back. `loadMore()` also used `_currentPage * _page_size`
for offset, causing duplicates.
Use `_page_size` for initial load and rely on current message
count as offset. This removes `_currentPage` entirely and lets
older messages load correctly.
Signed-off-by: Texas0295 <kimura@texas0295.top>
Avoid relying on appWindow.isVisible, which is not trustworthy under
bitsdojo on Linux/Wayland. Instead, always run show → restore → show
sequence to guarantee window is re-mapped and raised.
Signed-off-by: Texas0295<kimura@texas0295.top>
