GNOME Bugzilla – Bug 522199
Make cheese widget work again
Last modified: 2011-03-27 01:06:47 UTC
Now that Cheese is in Gnome it'd be awesome to integrate it into the desktop more. I'd like to see an option to take photos using Cheese wherever my Gnome desktop and Gnome software want me to select an image; About Me, Pidgin, Empathy, other IM clients etc. I'm not sure how this would be best achieved, any ideas?
conduit ;) i had a talk with john stowers yesterday and he wants to get conduit into gnome. once that is achieved, there shouldnt be any problem to share the media files around
Ok, sounds like a good start. I guess I should look at Conduit some more. I'm not just thinking about sharing files though, I'd like to see something like OS X's choose icon widget [1] but also have an option in there to 'Take Photo' and launch cheese returning the image to the calling application. What do you think? Am I making sense? :) 1. http://adiumx.com/images/blogpostimages/climagepicker.png
totally! we already planned such a feature by using dbus which could be used by empathy, gdm, gnome-about-me... though we hadnt had the time to implement such a very cool feature
Excellent! That will be really cool. The next step then will be a dbus interface for Cheese?
unfortunately i am no dbus expert, but i would love to have something like dbus in it. the idea was to open cheese by dbus in a "special mode", where a chosen picture can be returned. this could then be used for gdm, empathy and so on...
Isn't this the same as bug 531968?
not exactly.... i would like to have this bug separate to the other one, because vincent was suggesting an autostart program which checks if there is a webcam and if the about-me picture is empty. In my opinion this has (nearly) nothing to do with cheese, cheese would only be the provider of the new picture (possible via dbus or the future media manager). I suggest closing the other bug, it's not a cheese issue.
Created attachment 116512 [details] [review] patch which brings dbus capabilities to cheese this patch brings dbus capabilities to cheese! please review it... :D it solves bug #527736 too, with dbus!
any news here?
I'm going to invest some time in the next few months... What I think the best solution would be: make a special file (if its possible somehow, anyone who knows that?) which starts cheese. So it would be possible to add the cheese-pic-folder as a "place" (bookmark) to gtk-file-chooser, the folder contains the pictures taken with cheese and this special file which gives the user the possibility to start cheese out of the file chooser. If this is not possible yet, it would be a great feature I think. I have seen such things on windows...probably some can remember the batch files from photoshop? you had the possibility to drag/drop files on the .bat file and the files have been converted. I will definitely need some help with that because I'm no gio/gfs/whatever expert...
I think that this could be best accomplished via a very simple dbus api. The way I see this working is that cheese would have a dbus method to take a picture, and it would return a string with the path to the photo that it took. Would work like this- <application> calls org.gnome.Cheese.take_photo(). Cheese would open and come to front, the user does whatever effects etc they desire, and takes a photo. After the photo has been taken, the user is presented with a dialog displaying the photo and asking if this is the photo they'd like to use for <application>, if they say no, they repeat the process until they're happy. When they say yes cheese closes, and the dbus method returns the path to the photo that was taken in the cheese session, and <application> continues with what it was doing.
hey alex...what you say sounds good! We already thought of it but we didn't have the time to implement it... would you like to implement your feature and post a patch? about the preview dialog you're talking of...what do you think about including it in the live feed from the cam? after taking a picture you don't see the live preview but instead the picture that was just taken and two buttons (accept, try again)
sounds awesome!
(In reply to comment #11) > I think that this could be best accomplished via a very simple dbus api. The problem is that this requires every app to implement it. I still think it would be nicer to implement this as a new location in the file chooser, or as a stand-alone widget which would allow for both file selection and taking pictures. MacOS X' account preferences have: - a drop-down selection of the stock images + an item saying "Edit Image..." - Edit Image spawns a new dialogue where recent Photobooth pictures appear, and a live view of the camera shows, with a button to take the picture - A button at the bottom of the dialogue allows to select a single file in a file chooser I'd like to see a drop-down widget that would replace the photo selection in most apps: For a user management app/about-me, current picture would be a button popping up the dialogue mentioned above. For other apps, the button would be a drop-down with either "Use account default" or "Other Image..." (which would popup the aforementioned dialogue). A D-Bus API, whilst nice, wouldn't make it easier than simply using a widget from cheese.
(In reply to comment #14) > (In reply to comment #11) > > I think that this could be best accomplished via a very simple dbus api. > > The problem is that this requires every app to implement it. maybe i didnt get it, but a cheese widget would also have to be implemented in every app, no?
It would have to be used in every app, but it would certainly be easier to have: filename = cheese_photo_selection_get_filename (widget); than complicated D-Bus code in every app. Implementing pluggable "folders" for the filechooser would probably require each app that cares about the user's face to implement something similar. Especially if you'd also want gravatar support as as been proposed for the control-center.
Created attachment 148615 [details] [review] Add simple webcam widget Add a webcam widget to allow applications to access webcams without putting in too much work.
First pass at a webcam widget. Test application included as well. I think this would be safe to commit once cleaned up. Missing are: - better errors when there's a problem with the webcam - function to allow snapshotting (possibly saving those as pixbufs, rather than files) - allow passing arbitrary filters through to the webcam pipeline
*** Bug 594266 has been marked as a duplicate of this bug. ***
+ * Licensed under the GNU General Public License Version 2 + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. That's self-contradictory. Is it 2-only, or 2+ ?
(In reply to comment #20) > + * Licensed under the GNU General Public License Version 2 > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation; either version 2 of the License, or > + * (at your option) any later version. > > That's self-contradictory. Is it 2-only, or 2+ ? I cut'n'pasted from the other files, so best to file a new bug about that.
Created attachment 148831 [details] [review] First pass at webcam widget for use in other applications
Comment on attachment 148831 [details] [review] First pass at webcam widget for use in other applications Attachment 148831 [details] pushed as c032a30 - First pass at webcam widget for use in other applications
Needs work being done as per comment 18, as well as setting a soname, and addition of pkg-config file.
any news after 8 months ? I heard of something similar planned in next Ubuntu's installer (auto-detect webcam and proposes to take picture for the session avatar), is it related ?
The cheese video widget worked in December 2009 when I committed it. The problem is that it has since regressed.
It does work for me again. I fixed it to use the new CheeseCamera, with clutter-texture (https://bugzilla.gnome.org/show_bug.cgi?id=632337). Are there still plans to use this?
(In reply to comment #27) > It does work for me again. I fixed it to use the new CheeseCamera, with > clutter-texture (https://bugzilla.gnome.org/show_bug.cgi?id=632337). > > Are there still plans to use this? It's already used in the gnome-control-center's user-accounts panel, but it's broken if you build with Cheese support, as it's not been ported to GTK+ 3.x yet.
Could you someone confirm it's okay now, with the port to GTK+ 3 having been completed?
Bastien said its still broken, unfortunately.
What's broken? Can we fix it? I have been only testing with cheese-test-chooser, and this seems to work for me, but I realize it probably doesn't test everything.
That's what I get from cheese-test-chooser. Cheese itself crashes in parsing the GOptions.
+ Trace 226281
I guess I'll try again once I've updated some more.
I get the same problem from the user-accounts panel when using a tarball version of cheese.
Cheese, and gst-plugins-bad from git, vala 0.11.2 and clutter-gst 1.3.6 as tarballs, made it work for me. But there is still a segfault in gnome-control-center, Program terminated with signal 6, Aborted.
+ Trace 226357
Works for me now, with an updated clutter-gtk, clutter-gst, clutter, and co. I committed a patch to make the widget mostly work again (threading problems I believe), but there are still issues: - the video is clipped instead of being scaled with black borders if necessary (which means that the picture once taken doesn't match) - the preview (once the picture is taken) shows up with a blue background instead of black - the flash makes the shell's panel disappear, which probably isn't that great a side-effect - When used within the control-center's user-accounts, my machine hard-locks, probably not a cheese problem, but makes debugging difficult
And as it's used in the control-center [1], I get: Clutter-CRITICAL **: Unable to retrieve the geometry of the foreign window: XGetGeometry() failed (status code: 0)
+ Trace 226362
[1]: http://git.gnome.org/browse/gnome-control-center/tree/panels/user-accounts/um-photo-dialog.c#n287
(In reply to comment #36) > And as it's used in the control-center [1], I get: > > Clutter-CRITICAL **: Unable to retrieve the geometry of the foreign window: > XGetGeometry() failed (status code: 0) > it could be a mismatched visual; clutter-gtk asks for ARGB visuals by default. if this: export CLUTTER_DISABLE_ARGB_VISUAL=1 before launching g-c-c makes embedding work then it's the ARGB visual issue.
(In reply to comment #37) > (In reply to comment #36) > > And as it's used in the control-center [1], I get: > > > > Clutter-CRITICAL **: Unable to retrieve the geometry of the foreign window: > > XGetGeometry() failed (status code: 0) > > > > it could be a mismatched visual; clutter-gtk asks for ARGB visuals by default. > > if this: > > export CLUTTER_DISABLE_ARGB_VISUAL=1 > > before launching g-c-c makes embedding work then it's the ARGB visual issue. Nope, same problem. I think it has to do with the order in which the widgets get realised, or maybe interaction with mutter.
Fixed the use in the control-center by calling gtk_clutter_init() unconditionally in the chooser widget's class init. Which leaves us with: (In reply to comment #35) > Works for me now, with an updated clutter-gtk, clutter-gst, clutter, and co. > - the video is clipped instead of being scaled with black borders if necessary > (which means that the picture once taken doesn't match) This is a problem for cheese itself when used in CheeseCamera, as you might get a clipped preview instead of a resized one by default. > - the preview (once the picture is taken) shows up with a blue background > instead of black That's easily fixable. > - the flash makes the shell's panel disappear, which probably isn't that great > a side-effect Will poke shell people about it.
commit 6f2697c08165a594cd2cd0af7aa97a02298089fe Author: Bastien Nocera <hadess@hadess.net> Date: Thu Mar 24 18:01:32 2011 +0000 lib: Make the flash not hide the gnome-shell panel By using the work area, rather than the fullscreen when it's available (X11 only). https://bugzilla.gnome.org/show_bug.cgi?id=522199 commit e7e67cc0fab32b1784fc9e400a83962fa9799241 Author: Bastien Nocera <hadess@hadess.net> Date: Thu Mar 24 17:36:40 2011 +0000 lib: Don't crop the video preview But resize it, preserving aspect-ratio instead. https://bugzilla.gnome.org/show_bug.cgi?id=522199 commit bf6adc935f05e27c79df3773161ddc3191b4ff54 Author: Bastien Nocera <hadess@hadess.net> Date: Thu Mar 24 18:03:28 2011 +0000 lib: Fix blue background in chooser widget By updating um-crop-area.[ch] from gnome-control-center. https://bugzilla.gnome.org/show_bug.cgi?id=522199
in fall we removed the mx dependency as we were asked to. afaik mx is still not an approved dependency of gnome. is there any other way to fix this instead of using mx? (In reply to comment #40) > commit 6f2697c08165a594cd2cd0af7aa97a02298089fe > Author: Bastien Nocera <hadess@hadess.net> > Date: Thu Mar 24 18:01:32 2011 +0000 > > lib: Make the flash not hide the gnome-shell panel > > By using the work area, rather than the fullscreen > when it's available (X11 only). > > https://bugzilla.gnome.org/show_bug.cgi?id=522199 > > commit e7e67cc0fab32b1784fc9e400a83962fa9799241 > Author: Bastien Nocera <hadess@hadess.net> > Date: Thu Mar 24 17:36:40 2011 +0000 > > lib: Don't crop the video preview > > But resize it, preserving aspect-ratio instead. > > https://bugzilla.gnome.org/show_bug.cgi?id=522199 > > commit bf6adc935f05e27c79df3773161ddc3191b4ff54 > Author: Bastien Nocera <hadess@hadess.net> > Date: Thu Mar 24 18:03:28 2011 +0000 > > lib: Fix blue background in chooser widget > > By updating um-crop-area.[ch] from gnome-control-center. > > https://bugzilla.gnome.org/show_bug.cgi?id=522199
(In reply to comment #41) > in fall we removed the mx dependency as we were asked to. afaik mx is still not > an approved dependency of gnome. is there any other way to fix this instead of > using mx? Given more time, I'm sure somebody could cook up an aspect frame that didn't rely on Mx. For the time being, it was all that could be done. Damien Lespiau went out of his way to get the aspect frame into an Mx branch, from an internal project, and though I was disappointed the feature wasn't in clutter proper, that's the best that could be done at the time. Best file a separate bug about removing the mx dependency.