Wondering if specific support for path_provider for desktop if planned.
import 'package:path_provider/path_provider.dart';
https://github.com/flutter/plugins/blob/master/packages/path_provider/lib/path_provider.dart
For example:
````
Future
final String path = await _channel.invokeMethod('getTemporaryDirectory');
if (path == null) {
return null;
}
return new Directory(path);
}
````
Porting that particular plugin wouldn't make much sense given that two of the three APIs that it provides aren't generally meaningful on desktop, but a path provider plugin for desktop with the user's home directory, temp, and maybe a couple of others would likely be useful.
So a separate package for desktop path provider rather than extend the one inside the flutter standard lib ?
FWIW, Apple unifies mobile and desktop idioms for path provision with the NSSearchPathDirectory enumeration: https://developer.apple.com/documentation/foundation/nssearchpathdirectory
Thanks. Good to know.
I worked around it for now by storing everywhere is a web based file system
and db running locally.
On Fri, 17 Aug 2018, 22:13 krisgiesing, notifications@github.com wrote:
FWIW, Apple unifies mobile and desktop idioms for path provision with the
NSSearchPathDirectory enumeration:
https://developer.apple.com/documentation/foundation/nssearchpathdirectory—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/google/flutter-desktop-embedding/issues/120#issuecomment-413976355,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATuCwi8CHtuTb4luqE0LaO8scWO1Bjolks5uRyPigaJpZM4V7-LJ
.
Thanks. Good to know. I worked around it for now by storing everywhere is a web based file system and db running locally.
What was that?
Porting that particular plugin wouldn't make much sense
I realized I never followed up to correct this; after discovering how common it is for packages to use path_provider as a dependency, I changed my view on implementing it as-is. It would be good to evolve it in the longer term to something less mobile-centric, but for now unlocking the ability to use existing packages that require it in the most important thing.
@stuartmorgan I believe you can remove the os-linux label now, and potentially close this issue?
Yes, nothing is left for FDE here, and https://github.com/flutter/flutter/issues/41715 tracks the remaining non-FDE work.
Most helpful comment
I realized I never followed up to correct this; after discovering how common it is for packages to use
path_provideras a dependency, I changed my view on implementing it as-is. It would be good to evolve it in the longer term to something less mobile-centric, but for now unlocking the ability to use existing packages that require it in the most important thing.