On Tue, 2016-10-11 at 09:52 -0400, Bastien Nocera wrote: > > > ----- Original Message ----- > > > > > > > > > > > > > ----- Original Message ----- > > > > > > Yup. The "normal" mount contains nothing that normal users > > > should access. > > > Accessing the photos will leave ghosts on the device, and there > > > have been > > > no > > > ways to update the music database in Linux for a few iOS > > > releases. > > > > I very much doubt that anyone would release any code to touch an > > idevice > > music database due to fear of > > legal action from the manufacturer. It may exist already. > > > > The ability to sync contacts, calendars and events, meeting info, > > notes, > > pictures etc ( anything that would be considered the personal data > > entered > > by the idevice owner is another matter entirely. Anything that the > > law > > provides in most countries such as the IP to that person or the > > copyright of > > documents or photos etc, and yes it can be a very grey area > > between the laws > > in different countries. This is just the other side of the coin > > but this > > time from the owners perspective and legal rights. > > What Linux applications support syncing those contacts? Are you sure > they actually > require the mounted filesystem? These do not need the exposure of the mounted filesystem in nautilus. Command line application do exist to sync phone contact's from evolution data server to an idevice. one-way sync only at present and is still work in progress and requires work to extend to other sync operations. https://github.com/gitsop01/eds-to-idevice Spring Board Manager Sbmanager from https://github.com/libimobiledevice/sbmanager - original gtk2 code proof of concept for libimobiledevice library. Still a work in progress with lots of refactoring and updating of code to do. https://github.com/gitsop01/sbmanager- Updated gtk3 port > > > > > > > > is > > > > > > > > > > > > You can still access the device by editing the URL in the > > > "Documents on..." > > > location. Just remove the ":3" at the end. > > > > Thanks for this info, > > > > > > > > > > > > If you have use cases that aren't the 2 mentioned above, or > > > using your > > > iDevice > > > as a thumb drive, please file bugs against gvfs in the upstream > > > GNOME > > > Bugzilla. > > > > > > Cheers > > > > > > While I agree for the normal non developer user, the removal, to > > be able to > > access what you could originally access, on the idevice before the > > code > > change, may be of little value. > > > > It is frustrating if you are developing applications and need > > access to these > > areas for debugging, checking directory, files and structure etc > > of the > > idevice. > > > > It is even more frustrating when the Fedora workstation is being > > targetted as > > a developer's platform, and it also affects any downstream > > distribution > > developers in the same way. > > How do you develop iOS applications on Linux? In any case, it's not > a target > of Fedora Workstation. It could be, but it's not. This is more to do about developing applications for linux to access the idevice that about iOS development on Fedora Workstation but it may just help this also. > > > > > > > > While nautilus still exposes the pictures on an idevice > > through gphoto2 > > system does not seem to have changed. > > I can't parse that. > > > > > > > As far as I am aware it is possible to copy pictures from the > > idevice but > > transfers of pictures to the idevice will succeed, but will not be > > shown on > > the idevice by native apps without further hacking. This is only because a camera roll management needs implementation to parse the file format. > > > So it doesn't work. Sure you could use, and you can still use, the > partition > as storage. But I don't see the point in doing that. And it will stay that way if we do not allow developers easy access to these area on the idevice. So everyone looses. > > > > > > > > The other mount exposes the so called document folder of some user > > installed > > apps on the idevice and may be useful for someone developing > > It's useful for adding files to applications, for example, music, > photos, or > documents in most 3rd-party applications. > Agreed. > > > > > > > but is off > > limited use to a normal non developer user, unless the normal non > > developer > > wants to use the phone as a usb drive to transport files without > > carrying an > > extra usb drive. > > > > The removal of the nautilus properties page on an connected > > idevice does have > > an effect that a nautilus-ideviceinfo extension that has been in > > gnome git > > for many years cannot be easily exposed and used and a gnome > > bugzilla entry > > has been active from last year without even a comment to date. > > That's unrelated. > Actually it is not unrelated at all as supports the subject of the email. The fact that a properties dialogue is not available in nautilus in the side bar is a problem as it stops any user from displaying the extra properties of a idevice using the mentioned extension. > > > > > > > https://bugzilla.gnome.org/show_bug.cgi?id=741302 > > > > https://git.gnome.org/browse/nautilus-ideviceinfo/log/?ofs=100 > > > > http://blog.sukimashita.com/2015/01/09/gtk-3-support-for-nautilus- > > ideviceinfo/ > > > > I hope this can be resolved in the short term as it provides all > > users of > > idevices with info that is expected today and further benefits > > the foss community and the goals of Fedora, Gnome and downstream > > distributions etc. > > Showing all the possible partitions doesn't help anyone, that I can > see. Explain > how the data on that partition is useful to the large majority of > iOS/Linux users, > and we can investigate. The data from the idevice partition is useful for a developer not for a regular user. As I have explained above about the properties dialogue is not available for a mounted idevice means that all user cannot get this info easily without writing an application to get it. This info is convenient to know for all users. It is available for other usb connected devices why not an idevice. Regards Timothy Ward > > > Cheers > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
