Re: [compiz] Annotate, guiding line patches with questions
Another approach could be to add an option to the screenshot plugin
which launches an external app. This could launch your helper app or
something else. I'm using this to upload screenshots to my flickr account.
Here is a patch for screenshot.c which adds a launch_app option.
What do you think?
Seems like a simple and useful solution. Some comments to the patch:
allocating storage for the command line using:
+ comm = malloc (sizeof(app) + sizeof(dir) + sizeof(name) + 2);
is not going to work well as app and dir are just pointers and the
size of the memory that they are pointing to is not known at compile
time. You also need to make sure that you allocate enough memory to
store the terminating `\0' character.
haha, yes of course.
I would change that line to:
+ comm = malloc (strlen (app) + strlen (dir) + strlen (name) + 3);
You should use:
runCommand (s, comm);
instead of calling execl directly. runCommand does things like exporting
the DISPLAY environment variable and setting the session id.
I don't like to have eog as the default. I'd rather like to see it be
set to nothing by default.
I thought eog is a good default, as it should be present on all distros,
but that's not true if you don't you use gnome.
btw, the patch wouldn't have worked anyway, cause I forgot to change
SetDisplayOption.
I should have tested it before submitting. Sorry.
Here is another one.
Thanks, Gerd.
diff --git a/plugins/screenshot.c b/plugins/screenshot.c
index ddb9b52..5245c18 100644
--- a/plugins/screenshot.c
+++ b/plugins/screenshot.c
@@ -36,9 +36,10 @@
static int displayPrivateIndex;
-#define SHOT_DISPLAY_OPTION_INITIATE 0
-#define SHOT_DISPLAY_OPTION_DIR 1
-#define SHOT_DISPLAY_OPTION_NUM 2
+#define SHOT_DISPLAY_OPTION_INITIATE 0
+#define SHOT_DISPLAY_OPTION_DIR1
+#define SHOT_DISPLAY_OPTION_LAUNCH_APP 2
+#define SHOT_DISPLAY_OPTION_NUM3
typedef struct _ShotDisplay {
int screenPrivateIndex;
@@ -251,6 +252,7 @@ shotPaintScreen (CompScreen *s,
if (n = 0)
{
char name[256];
+ char *app;
int number = 0;
if (n 0)
@@ -265,12 +267,30 @@ shotPaintScreen (CompScreen *s,
sprintf (name, screenshot%d.png, number);
+ app = sd-opt[SHOT_DISPLAY_OPTION_LAUNCH_APP].value.s;
+
if (!writeImageToFile (s-display, dir, name, png,
w, h, buffer))
{
fprintf (stderr, %s: failed to write
screenshot image, programName);
}
+ else if (*app != '\0')
+ {
+ char *comm;
+
+ comm = malloc (strlen (app) +
+ strlen (dir) +
+ strlen (name) + 3);
+ if (comm)
+ {
+sprintf (comm, %s %s/%s, app, dir, name);
+
+runCommand (s, comm);
+
+free (comm);
+ }
+ }
}
else
{
@@ -380,6 +400,15 @@ shotDisplayInitOptions (ShotDisplay *sd)
o-value.s = strdup (SHOT_DIR_DEFAULT);
o-rest.s.string = 0;
o-rest.s.nString = 0;
+
+o = sd-opt[SHOT_DISPLAY_OPTION_LAUNCH_APP];
+o-name = launch_app;
+o-shortDesc = N_(Launch Application);
+o-longDesc = N_(Automatically open screenshot in this application);
+o-type = CompOptionTypeString;
+o-value.s= strdup ();
+o-rest.s.string = NULL;
+o-rest.s.nString = 0;
}
static CompOption *
@@ -414,6 +443,10 @@ shotSetDisplayOption (CompDisplay*display,
case SHOT_DISPLAY_OPTION_DIR:
if (compSetStringOption (o, value))
return TRUE;
+ break;
+case SHOT_DISPLAY_OPTION_LAUNCH_APP:
+ if (compSetStringOption (o, value))
+ return TRUE;
default:
break;
}
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Thumbnail plugin
Le mercredi 10 janvier 2007 17:55, David Reveman a écrit : Let me know what you think about the my suggestions and keep up the good work. It should be cool to have a way to get thumbnail of minimized windows too... Beryl has just fork thumbnail plugin (so sad...), they seems to use pixmap to get thumbnail of minimised window (with some beryl core modifications). I think i prefer no thumbnail than a mix with live/pixmap thumbnails. So, it will be cool to have a way to temporaly get the texture of a window without unminimising it. Cedric ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Thumbnail plugin
David Reveman wrote: I suggest that we add a plugin and a simple interface that allows any application to request that a set of client windows should be composited on top of a different client window. Its probably a good time to point you in the direction of the miniwin plugin, in case you are unaware of it :) http://www.anykeysoftware.co.uk/compiz/plugins/miniwin.tar.gz It actually creates the window as well as painting a scaled window. It also handles rotation so may be a good source of code/ideas for this plugin. It is a very popular and highly requested feature, people want to ditch the taskbar and have miniwin manage minimized windows. On the point of modifying the taskbars to support thumbnailing, this seems like a good long term goal, but can I request that something like this is kept around for legacy reasons. Ubuntu users will likely have first access to modified packages but it would become a nightmare for support if these modifications were not accepted upstream to each taskbar (gnome is probably a given, but I am not too sure if KDE would be willing to accept it unless it was standardized). Please think of the KDE using non-ubuntites :) Regards Mike ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Question about extending screengrabs
Danny Baumann wrote: Hi, Wouldn't it be better to add this kind of functionality through different interface than the current screen grab interface? We can always expose the current screen grabs through a new interface if we want that. I'm not sure exactly how this interface should look like but seems like it would makes sense to be able to not just check if some state is present but also be able to prevent a state from being entered. E.g. instead of the rotate plugin checking for some showdesktop state, the showdesktop plugin could check for a rotate state and prevent it from being entered while being in showdesktop state. What do you think? Do you think that extending the screen grab interface is the best way to do this anyhow? I'm not sure if we would gain a lot from that. The idea sounds very nice, but thinking about it I have the impression that such an interface would be much more complicated than what we have now. I can think of two use cases for the whole checking: - A plugin wants to check if other plugins are active which could be disturbing ... otherScreenGrabExist is perfectly suited for that by whitelisting non-disturbing plugins. I think this problem is related to my earlier question about action options and the return value. My idea was that every time an action returned true, a signal would be sent which other plugins could listen for in the normal way. My requirements were that each signal would send the following information about what just happened. The plugin name The action option name The method for how it was initiated (mouse/key/edge/other) My initial method involved patching handleActionEvent and changing triggerButtonPressBindings to set the index of the option that was initiated. If triggerButtonPressBidings returned true then I would send an initiateActionOption notification which would modify the options to include the plugin name and the method (ie button). It would then pass through the pointer to the option that was initiated. The same would happen for terminate bindings so other plugins can keep an internal track of all other plugins (even if the author didnt write their plugin specifically for them). I realize that this isn't perfect, but my reasoning is that if a plugin ate a mouse or keypress then there is a good chance it did something. Reading the state doesn't provide enough information and relies on the plugin authors playing by the rules. BTW - I think that in the showdesktop example you could easily check if the screen is in showdesktop mode. There is probably a reason for it, but showdesktop does not use the correct enterShowDesktopMode function so you cannot check. AFAIK showdesktop needs to be fixed in this particular case. It sounds like its a problem with minimized windows again. Regards Mike ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Question about extending screengrabs
Hi, The same would happen for terminate bindings so other plugins can keep an internal track of all other plugins (even if the author didnt write their plugin specifically for them). The problem is that this method (which also came to my mind yesterday ;-) ) can't be used at all for replacing otherScreenGrabExist - given the fact that you don't want to have a string list of active plugins in each plugin. Maybe I'm also misunderstanding you a bit - how would you think should the plugins store the information of active plugins? BTW - I think that in the showdesktop example you could easily check if the screen is in showdesktop mode. No, you're mixing up the showdesktop mode and the showdesktop plugin ;-) (Confusing naming, I have to admit...) Regards, Danny ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Question about extending screengrabs
Danny Baumann wrote: The problem is that this method (which also came to my mind yesterday ;-) ) can't be used at all for replacing otherScreenGrabExist - given the fact that you don't want to have a string list of active plugins in each plugin. Maybe I'm also misunderstanding you a bit - how would you think should the plugins store the information of active plugins? I wouldn't want it to replace otherScreenGrabExist because I feel that is for a slightly different purpose. My approach was to try to add cooperation, but not dependencies between plugins. My examples are: 1. 3D, Beryl uses IPCS for this which is not recommended. I would like 3D to be able to listen for rotate - initiate with mouse only and then use that signal to raise the windows. 2. Zoom on cube rotate. This could easily be added to the cube plugin and it is a highly requested feature. I thought it would be nicer if zoom could listen for the same signal and use that to zoom out. It would mean that the users zoom settings could be used and everything would be more consistent. If your plugin needs to maintain a list of all plugins that have activated then you could always store the index in the active_plugins setting but I would suspect that there is another problem somewhere if you need to do this. No, you're mixing up the showdesktop mode and the showdesktop plugin ;-) (Confusing naming, I have to admit...) I think this is one case where the fix lies in the plugins rather than something that is needed in core. If you are referring to showdesktop mode then you can read the hint on the root window. If you are referring to the showdesktop plugin then the plugin needs to be fixed so that you can do that. Maybe something could be done in core or there is something we are missing which can make animated showdesktop plugins easier? Regards Mike ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Question about extending screengrabs
Hi, I wouldn't want it to replace otherScreenGrabExist because I feel that is for a slightly different purpose. My approach was to try to add cooperation, but not dependencies between plugins. My examples are: 1. 3D, Beryl uses IPCS for this which is not recommended. I would like 3D to be able to listen for rotate - initiate with mouse only and then use that signal to raise the windows. 2. Zoom on cube rotate. This could easily be added to the cube plugin and it is a highly requested feature. I thought it would be nicer if zoom could listen for the same signal and use that to zoom out. It would mean that the users zoom settings could be used and everything would be more consistent. Ok, understood - having both besides each other sounds sensible. Having the ability to block certain actions makes this approach even more powerful. I think this is one case where the fix lies in the plugins rather than something that is needed in core. If you are referring to showdesktop mode then you can read the hint on the root window. If you are referring to the showdesktop plugin then the plugin needs to be fixed so that you can do that. Yes, you are right to a certain degree - the root problem here is that moveWindow is used for both window animations and viewport changes, what makes it hard to distinguish both. Maybe something could be done in core or there is something we are missing which can make animated showdesktop plugins easier? Interesting question ;-) I thought of only drawing it at another place (with the xTranslate/yTranslate members), but in this case, no screen interaction would be possible. Regards, Danny ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Question about extending screengrabs
Danny Baumann wrote: Yes, you are right to a certain degree - the root problem here is that moveWindow is used for both window animations and viewport changes, what makes it hard to distinguish both. I have just had a quick look at moveScreenViewport and it looks like you could tell a viewport move from a showdesktop move by checking the immediate variable. Obviously this only fixes this particular case, but I think plugin incompatibilities need to be assessed case by case :) Regards Mike ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] Re (sort of): Strange issue
I have the same problem, but apart from that it appears to happen randomly and it then shows all windows on all workspaces. To solve the problem i have to logout and in. -- Fredrik ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
