Feature request: Gphoto2 plugin in gvfs-0.2.3u1 missing

[martinp]

Binary package hint: gvfs-backends

I'm currently missing the gphoto2 plugin in version 0.2.3ubuntu1 whereas 0.2.2ubuntu1 contains this.
I'm aware that there is currently a bug report filed on a crash regarding gvfsd-gphoto2 however I have currently deinstalled 0.2.3u1 and installed the later version 0.2.2ubuntu1 which works flawlessly for me. Reading, writing...
Is it intended to leave this plugin out or was it simply forgotten during the build/deploy phase?

Thank you!

[Sebastien Bacher (seb128)]

Thank you for your bug report. Usually reading the changelog is a good idea before opening bug to ask such questions

[martinp (martin-piayda)]

Ah yeah, thank you for your valuable input. No need to be rude... I read the changelog and having read my request would suggest, that I did, because I already referred to the existing bug.
Nonetheless I cannot really confirm this issue as I intensively make use of this plugin and never had any locking issues described there. If you think we have an issue (bug) here that conflicts with my request feel free to close this request. I will then compile and host the debs myself.

Thank you.

[Sebastien Bacher (seb128)]

I don't think that I've been rude and it was not my intend, but you ask fir the plugin was intended to not be built or if that was a mistake, the changelog is pretty clear about those. We get hundred of bugs every bugs and the team is really small so we try to deal quickly with user questions and focus on issues. Anyway to reply to your question about the locking issue, mount your camera using gvfs and then try to get photos from it using f-spot or an another application using gphoto, you will get a locking error. The other issue is that the software have not been ported to gvfs, which means than double clicking on a picture in a gvfs location will give you an error about the URI not being correct, which is confusing and gives users an impression to get buggy non tested softwares, that's why we prefer stay to working methods for this cycle and continue gvfs work next cycle and ship it when standard applications will use gvfs rather

[martinp (martin-piayda)]

Well your tone was a typical RTFM-One... I'm a dev myself and have very few time myself, so I get your point anyway. But humans are humans. :-)

That's what I did in 0.2.2. I'm aware that the location identifier does not integrate with several tools e.g. eog, f-spot etc. However I never got any locking issues while retrieving nor has it ever been any trouble writing to the location. I have a great amount of RAWs which go through and never stumbled upon such issues. Perhaps it may help to provide some information to get onto this. Perhaps I can help here. There are quite some other things I'd call confusing (e.g. crashing of wammu in several cases...) besides this rather harmless one...

Well, two options:
- Do you need infos?
- Any efforts to follow up on this "bug". Otherwise we can leave it and I will stick to compiled dev-packages.

Thank you.

[Sebastien Bacher (seb128)]

Hum, maybe what I call locking is not clear. It's not possible to run several gphoto applications on the camera are the same time, so once it's mounted by gvfs f-spot will not be able to use the camera for example and give a locking error message which is not clear to the user.

There is no information required no, the backend has been disabled because it's not usuable in a normal user sense (they expect to be able to open photos by using double click for example) and we don't want to give a lack of polish and testing impression to users running the issue so we prefer to not enable the code for now

[martinp (martin-piayda)]

Honestly I don't think we can solve this here nor will I be able to give you an impression of other locks and freezes some current applications do. F-spot tends to hang itself without doing anything, maybe it's not even the gphoto part here but some constellation those "i only want to double click windows affected" users induce. I use the plugin quite often and never had such issues (I copy the files, delete some, work with gimp on raws directly from the cam etc.). I'm not the typical user myself and I don't think you can make out the actual "lock issue" here. As of its obvious nature in which the "lock" occurs I just wonder why I never encountered it altough I use it really often with different apps. Perhaps I compile it differently... who knows.
Just let me know when you know more than "it locks" so we can start solving this issue and take the real developers into account to provide them with a reproducible scenario. Can you please also remove F-Spot, Wammu, Firefox, Totem, too? They crash quite often on my hardy. It is hard to make out why they crash, because there is no evidence in either log-files or console, when starting off there... sorry, for this, but this is really creepy..

Just do me a favor and close this, so I don't need to wait for a solution....

[Sebastien Bacher (seb128)]

You seem to not understand what I'm writting. It doesn't freeze, it takes a lock on the device in the sense of exclusive access. It means that only one application can access to the device, when this one is gvfs then other photo management software are not able to download pictures. That's not a bug but a design decision from libgphoto. The way to resolve that is to have reliable unmount for gvfs and make all the software using libgphoto to use the unmount call before accessing the device. Is it clear?

[martinp (martin-piayda)]

First it does not say "you do not understand" but "perhaps i didnt explain myself clearly", ok? Esp. If you do not know with whom you are writing.
Second if you had read my postings you should have understood that I'm quite well are what "locks" are. I never claimed gphoto "freezes".
And it's not a "sense" of exclusive access but actually IS exclusive otherwise it's using semaphores which is quite common for i/o. Oh well it might be ok to not allow other applications to write. To be honest - no professional does this. When editing the raws or maybe jpegs you usually create a copy of this locally and never touch the original. In even more usual case is copying all files from the cam to the local disk. However I experienced such a phenomenon with gtkam. My cam went to standby after some seconds while not using it and gtkam was not able to reacquire access. I had to do a rescan and click thru the media-tree. Afterwards my pictures have been logically doubled (in the view, not the flash-media). And you tell me the lock issue confuses people? What about having gtkam not being able to access the cam anymore (just do a replug) and/or seeing a multiple of your pictures where some of them are not eben accessible.
There functionality that does not really work has been rolled out while you make a mountain of a molehill. And if it's not a "bug" as you say, why don't you insist,what you did in the first post: "RTFM". If it's obviously not a bug, then it's a feature and features are usually documented. Lol, we have software with bugs in hardy but not software that may confuse people. This is really awful. This is what will make ubuntu fuck up against fedora in the long term...creepy, really creepy.

[Sebastien Bacher (seb128)]

ubuntu doesn't use gtkam by default but you should report the bugs you are having upstream or in launchpad. the locking issue is not a writte one, just mount the camera using gvfs and try to download photos using the gthumb import then, that will return an error about the device being busy and not work as expected. the do not understand statement was refering to the previous comment without implication on whether that was due to the comment not being clear or not and was not against you. not sure what you are arguing about there and how the distribution comment is revelant, the gvfs gphoto backend will be used in ubuntu next cycle, we just don't think it has been tested enough and has the suffisant quality to be distributed in a lts version yet, anyway enough comments about the issue, that's what has been decided for ubuntu and you are free to use an another distribution if you think the ubuntu choices are wrong

[martinp (martin-piayda)]

Well, the error is not unique anyway...