[compiz] Put a window on top
I'm developing a new plugin, based on switcher. I have a window created with XCreateWindow. Can I put a window totally on top, even over panels? These are my atoms: state[nState++] = s-display-winStateAboveAtom; state[nState++] = s-display-winStateStickyAtom; state[nState++] = s-display-winStateSkipTaskbarAtom; state[nState++] = s-display-winStateSkipPagerAtom; (this code is copied from switcher.c) Stjepan ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] [non glx_ftp method support in compiz]
I'm currently using r300_dri driver (R9600 card). Compiz use glx_ftp and AIGLX(7.2RC2) unstable with it, it's result in system hardlock very often. Just trued veryl with --use-copy option, and it's very stable for me now. So nonftp method support in compiz would be very desirable. Good luck. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Put a window on top
On Fri, 2007-01-05 at 11:41 +0100, Stjepan Glavina wrote: I'm developing a new plugin, based on switcher. I have a window created with XCreateWindow. Can I put a window totally on top, even over panels? You can set window type to Dock and add StateAbove. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Compiz ignoring changes in gconf in Opensuse 10.2
On Jan 04, 07 16:12:07 +, Mike Dransfield wrote: Matthias Hopf wrote: On Dec 30, 06 19:13:05 -0800, Deni Jelicic wrote: I have recently upgraded to Opensuse 10.2 from 10.1 and all the changes that I am making in gconf have no effect on compiz. I am running compiz as a window manager in kde and I have followed the instructions for running compiz in Opensuse 10.2. compiz is started with the dbus configuration plugin now when running kde. Unfortunately, right now there doesn't seem to be a configuration utility using dbus :-O Dbus is NOT a configuration plugin. It is for IPC, it just communicates the value, it doesnt store it. Well, then the infrastructure is not 100% in place. If you select compiz as the window manager (and not KWin - yes, you can do that in SL10.2), compiz is started with the dbus plugin and nothing more. I don't know whether compiz should be automatically configured afterwards, or whether a different configuration plugin is to be developed. That's something one of the KDE developers should probably comment on. Gconf is still needed and is the only option. :) ;-) Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg(_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715__) |_| __) |__ labs www.mshopf.de ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Annotate, guiding line patches with questions
David Reveman wrote: I see that you're using OpenGL geometry for drawing the guiding lines. That's good enough for now but eventually I think we want the guiding lines to match the final geometry rendered by cairo. This can easily be done using glitz. I havent seen much of glitz so far, it looks interesting. I actually quite liked the basic rendering lines, they are similar to how photoshop works/looks. I'm not sure. How advanced does the text need to be in the annotate plugin? If the toy text API in cairo is good enough, then using it to render text would be very easy. I wasn't too worried about the actual rendering I was thinking more about the user interface for it and how the user would interact with it. If I explain my eventual use for it then it might make things clearer. I would like to have a small app written in python/gtk which would be triggered with a keystroke. The user would hit the keystroke and the application would be launched by the annotate plugin. It could then provide a basic palette and text entering functions (copy/paste, selecting font, style, color). When it is activated it can change the action for annotate so the modifiers are removed, the user can then annotate whatever they like, without worrying about modifiers etc (an arrow tool will be provided which can be used to move/select windows). When they are finished they can click a button which would activate screenshot so that they can then take a screenshot. The screenshot plugin would then save the file and send a signal through dbus to the helper app. This can then pick up the file and launch an email application or anything else which can handle the image (instant messenger/web forum etc etc). The users will ask for these features, so I thought it was probably best to relinquish a lot of power and code over to a helper application early on. We can avoid most direct entering problems by creating a textbox tool which predefines the area, it would still involve a lot of work with buffers to be able to delete, copy/paste etc. I assumed all of this would add to the bloat more than anything, I could be wrong though. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] DBus setting options broken
David Reveman wrote: getScreenData, getWindowData, getWindowList and such methods will return a lot of data that is currently available as X properties on client windows and the root window and part of the EWMH spec. I don't know to what extents that data is available in existing scripting languages. If it's already available, then I wouldn't feel good about adding a new incompatible way to get that data through compiz. However, I can imagine that having all that data available through dbus would be convenient but maybe we should provide it as a netwm object (/org/freedesktop/netwm) instead so that other window managers could provide it too and only put the compiz specific stuff in the compiz object. I have had a look through the spec and it seems like it would be easy to implement this way. The scripting languages I am targeting are things like bash and javascript. This would mean that people could write pagers and taskbars in flash. I am also interested in using xulrunner applications there is a dbus xpcom component in the works, so hopefully soon people can integrate the web into the desktop more easily. As you can probably imagine, there are not many xlib bindings for javascript ;) I am thinking of providing to objects /org/freedesktop/netwm/root and /org/freedesktop/netwm/client These would then provide some getter and setter functions. They would always have to provide a window id to the function. One difference is that compiz currently takes parameters as sequential name/value pairs. In python the functions have to be called something like this. dbus_iface.activate(key1, value1, key2, value2); for the netwm object I think we should define the functions to receive the values in order. They are fairly well defined and consistant so we should be OK in the future. Ill try to write a more concrete dbus api as soon as possible and if it is acceptable, then Ill start coding. There are quite a few possibilities for how it could be done. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Compiz ignoring changes in gconf in Opensuse 10.2
On Jan 05, 07 18:31:51 +, Mike Dransfield wrote: The solution is to write a KDE based compiz configuration plugin for compiz, this would then communicate via dbus. Your startup script seems to be broken, it should start compiz the same way for KDE as it does for Gnome. I'm not talking about startup scripts. The KDE kontroll center in SL10.2 has a switch for switching between KWin and compiz. If you select compiz, compiz dbus is run AFAIK. Again, something for KDE developers to comment on. Not really me :) Matthias -- Matthias Hopf [EMAIL PROTECTED] ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED] Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Annotate, guiding line patches with questions
Mike Dransfield schrieb:
I would like to have a small app written in python/gtk
which would be triggered with a keystroke. The user
would hit the keystroke and the application would be
launched by the annotate plugin.
It could then provide a basic palette and text entering
functions (copy/paste, selecting font, style, color). When
it is activated it can change the action for annotate so
the modifiers are removed, the user can then annotate
whatever they like, without worrying about modifiers
etc (an arrow tool will be provided which can be used
to move/select windows).
Great, this sounds exactly like what the new Vista Snipping Tool does.
It has a lot of cool features and i already thought about how to
implement some of them into compiz.
When they are finished they can click a button which
would activate screenshot so that they can then take a
screenshot.
The screenshot plugin would then save the file and send
a signal through dbus to the helper app. This can then
pick up the file and launch an email application or anything
else which can handle the image (instant messenger/web
forum etc etc).
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?
Cheers. Gerd
diff --git a/plugins/screenshot.c b/plugins/screenshot.c
index ad27772..f3d504e 100644
--- a/plugins/screenshot.c
+++ b/plugins/screenshot.c
@@ -26,19 +26,22 @@
#include stdlib.h
#include string.h
#include dirent.h
+#include unistd.h
#include compiz.h
#define SHOT_INITIATE_BUTTON_DEFAULT Button1
#define SHOT_INITIATE_BUTTON_MODIFIERS_DEFAULT CompSuperMask
-#define SHOT_DIR_DEFAULT Desktop
+#define SHOT_DIR_DEFAULTDesktop
+#define SHOT_LAUNCH_APP_DEFAULT eog
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 +254,7 @@ shotPaintScreen (CompScreen *s,
if (n = 0)
{
char name[256];
+ char *app;
int number = 0;
if (n 0)
@@ -265,12 +269,31 @@ 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 (sizeof(app) + sizeof(dir) + sizeof(name) + 2);
+ if (comm)
+ {
+sprintf (comm, %s %s/%s, app, dir, name);
+
+if (fork () == 0)
+{
+execl (/bin/sh, /bin/sh, -c, comm, NULL);
+}
+
+free (comm);
+ }
+ }
}
else
{
@@ -380,6 +403,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 (SHOT_LAUNCH_APP_DEFAULT);
+o-rest.s.string = NULL;
+o-rest.s.nString = 0;
}
static CompOption *
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [non glx_ftp method support in compiz]
On 1/5/07, Вамненадознать Иэтотоже [EMAIL PROTECTED] wrote: I'm currently using r300_dri driver (R9600 card). Compiz use glx_ftp and AIGLX(7.2RC2) unstable with it, it's result in system hardlock very often. Just trued veryl with --use-copy option, and it's very stable for me now. So nonftp method support in compiz would be very desirable. The right way to fix this is to figure out why it locks up and fix that problem. The texture_from_pixmap extension was designed to not have to copy window contents between server and compositor and if something breaks in that code path we need to fix it, not paper over it. It would be great if you could help track down these lock ups. The best way to debug this is to use a second computer and then log in to your primary machine. Then run the X server under gdb (this doesn't always work, but then sometimes you can attach to the running X server after it's initialized) and when it locks up you can send it a SIGINT from another remote login from the second machine (Ctrl-C doesn't always work from gdb). Once you've done that, typing 'bt' at the gdb prompt will give you a stack trace that will show us where the X server is deadlocked. Good luck. And to you too, Kristian ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
