Re: [compiz] Zoom plugin changes
Kristian Lyngstøl wrote: I'm sorry for being rude, but I am quite upset by this, because it has gone too far. I posted a few weeks ago that I was going to be working on zoom over the summer to improve the accessibility, and I have already begun to do that. Every step of the way I have made frequent commits to opencompositing.org and described the progress in my blog. I asked for information about what your (David) plans was, you thanked me for informing me on what I was going to work on and said you'd get back to me. You never did. Now today you commit 11fe37b7673b15e5cbd4be21759311087d9d8694 which introduce major changes to the zoom plugin. You did NOT give a heads up on this, even though you should have known I was working on this. To be fair he did mention that he was going to add this functionality months ago, it was also demonstrated at brainshare recently (before your initial email). Also your email (from what I understand) just related to orca integration and input redirection, it didn't seem to have anything to do with todays changes. Also from what I understand, you have forked zoom.c which lost all the git history? If this is the case then you should have branched it so that these changes would be merged. I dont think they impact your changes, do they? This is simply unacceptable. When you are going to make changes and people have already told you they are working on that code, you have to actually communicate with them, not drop a 1k diff on them. It's not just your time that matters here, but ours too. This is not how people are supposed to co-operate. And also, when you write something, you have to document it. The question of documentation was discussed very recently (and before that too). Davids position is that HE is not prepared to spend a lot of time documenting things because there is a good chance his efforts will be wasted if the code changes, personally I'd rather he spent time coding rather than documenting. Someone else could document things. That does not stop anyone from submitting patches to document certain functions which might not be clear. I did exactly that a few weeks ago. A few lines for each function, explaining what it does. You don't have to explain how or why, just WHAT. This is a common practice that I should NOT have to explain to an experience developer. Its not common developer practice to document each function. Most people do not seem to have much problem understanding whats what, and David is always prepared to answer questions. The documentation is by example at the moment, I have 3 example plugins, the helloworld one is documented as well as I can, and I try to keep it up to date. Please document your changes to the zoom plugin properly so our USERS don't have to choose between two different feature sets when they want to zoom. Because this is about the users, not my pride. If you understood the original zoom code enough to make an enhanced version of it then it should be easy to understand the new changes, they seem to be reducing code and increasing readability to my untrained eyes. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Changing gconf-key/apps/compiz/plugins/water/allscreens/options/initiate_keydoes not work
On Sat, 2007-05-19 at 11:27 +0200, dragoran wrote: Mike Cook wrote: On Fri, May 18, 2007 at 11:06 AM, dragoran [EMAIL PROTECTED] wrote: Hello, I noticed that the control+super key kombi no longer works with the rain plugin.. I went to check why and found out that its disabled in gconf. so I tryed to change it back to ControlSuper (which is the default) but it changes itself back to disabled... any idea why? Hm, I see the same problem with the Shift modifier trying to active snapping with wobbly. If it try to set it to ShiftT or something, then it seems to take the Shift and it works. I'm not sure if this is a GConf problem or something in the Compiz metadata that's not allowing just modifiers without another key. any solution? it was working before and I have not updated gconf so it looks like a compiz bug Should now be fixed. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Some suggestions for extra metadata
On Mon, 2007-05-21 at 14:01 +0100, Mike Dransfield wrote: Here are a few extra attributes which I have not seen mentioned yet which I think would be useful. Any comments would be appreciated. *Version* The version of the plugin, I think the reasons for this are obvious. version major0/major minor1/minor patch0/patch /version *Addition to features* Just add an attribute to the features tag so that features can be unique or non-unique. This will mean that we can add lots more features like 'config', 'matchhandler', 'imageloader' etc etc. They need to be defined somewhere so that plugin developers can check a list of official features like this (whilst still adding their own if needed). feature unique=truelargedesktop/feature This should default to true if not provided. *Match Handler Tag* If a plugin provides window matching functionality then it could provide tags like this. matchhandler handler matchtitle/match !-- optional command to be run to get the attribute for a window -- commandxprop | grep ^WM_NAME | .../command /handler handlername/handler etc... /matchhandler *Option Group* Some plugins and the core have options which work in groups. Hints can be provided to group these options so that configuration tools will be able to display them as a grid rather than as individual options. optiongroup option name=opacity_match / option name=opacity_values / /optiongroup *Web based information* I think it would be a very nice feature to add some web based attributes which means things can be easily updated without the user updating the plugin. There are probably others that could be added. info !-- xml file with update info -- updateurlhttp://www.example.com/plugin-update.xml/updateurl !-- html page with additional information about the plugin -- infourlhttp://www.example.com/plugin-info.html/infourl /info screenshots screenshot mime=text/htmlhttp://www.example.com/plugin.html/screenshot screenshot mime=image/jpeghttp://www.example.com/plugin.jpg/screenshot screenshot mime=application/swfhttp://www.example.com/plugin.swf/screenshot /screenshots Some good ideas here. I suggest that we add things as a use for it is implemented and not add everything we can think just in case it might be used. I recommend that any configuration or control utility that is interested in compiz metadata is implemented in such a way that in can include it's own set of additional metadata for known plugins. New tags can first be added to the additional metadata files and if they make sense and are useful for other configuration utilities we'll move them into the official metadata files. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Fix imageBufferToTexture for MSBFirst platforms.
On Wed, 2007-05-23 at 15:37 +0200, Michel Dänzer wrote:
Fixes icon colours on my PowerBook.
Given that the preprocessor test was reversed when the code was reorganized
and
nobody on !MSBFirst platforms complained, one code path should suffice.
Hm, I'm not sure what's going on here. I fixed the mistake from the
reorganization. If byte order doesn't actually matter for the icon data
then I think the iconToTexture function should be changed to reflect
that and not imageBufferToTexture.
---
src/texture.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/src/texture.c b/src/texture.c
index 4170c70..7021643 100644
--- a/src/texture.c
+++ b/src/texture.c
@@ -164,13 +164,8 @@ imageBufferToTexture (CompScreen *screen,
unsigned int width,
unsigned int height)
{
-#if IMAGE_BYTE_ORDER == MSBFirst
-return imageToTexture (screen, texture, image, width, height,
-GL_BGRA, GL_UNSIGNED_BYTE);
-#else
return imageToTexture (screen, texture, image, width, height,
GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV);
-#endif
}
Bool
--
1.5.2-rc3.GIT
-David
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] add 'sticky' mode to cube to allow sticky+not-on-bottom windows to stick to the screen when the screen is transformed
On Sun, 2007-05-27 at 19:41 -0400, Quinn Storm wrote: I've attached the patch since I don't yet have an easy way to make git format-patch and kmail play nice together. The basic idea is during a rotate/other cube transform, 'sticky' windows stick to the screen instead of being redrawn once per face (its an option, the default is the old behaviour) Consider this, please, essentially an RFC - this particular behaviour was available previously in Beryl, and was (at least according to screenshots/casts) widely used. Yea, this behavior makes a lot of sense for sticky windows. The problem is that during cube motion these windows suddenly becomes on top of windows that they are normally stacked below and that looks pretty bad unless it's animated. I think it will look better if the cube is moved back a bit during motion like when windows are being elevated and maybe it makes more sense to make this functionality part of the 3D plugin, which btw should hook into the cube plugin the same way rotate plugin now does. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] status of input redirection
On Tue, 2007-05-29 at 08:53 +0200, dragoran wrote:
There where some patches to implement input redirection in xorg a while
ago...
what happend to them? are they still beeing worked on?
The attached patches work well. The server patch needs some more work if
we want to allow different pickers and I haven't had time to do that
yet.
-David
--- a/composite.h
+++ b/composite.h
@@ -63,8 +63,9 @@
#define X_CompositeNameWindowPixmap 6
#define X_CompositeGetOverlayWindow 7
#define X_CompositeReleaseOverlayWindow 8
-#define X_CompositeRedirectCoordinate 9
-#define X_CompositeTransformCoordinate 10
+#define X_CompositeSetTriangularCoordinateMesh 9
+#define X_CompositeRedirectCoordinate 10
+#define X_CompositeTransformCoordinate 11
#define CompositeNumberRequests (X_CompositeTransformCoordinate + 1)
--- a/compositeproto.h
+++ b/compositeproto.h
@@ -192,6 +192,15 @@ typedef struct {
CARD8 compositeReqType;
CARD16 length;
Window window B32;
+} xCompositeSetTriangularCoordinateMeshReq;
+
+#define sz_xCompositeSetTriangularCoordinateMeshReq 8
+
+typedef struct {
+CARD8 reqType;
+CARD8 compositeReqType;
+CARD16 length;
+Window window B32;
BOOLredirect;
BYTEunused1;
CARD16 unused2 B16;
--- a/configure.ac
+++ b/configure.ac
@@ -24,7 +24,7 @@ dnl
dnl Process this file with autoconf to create configure.
AC_PREREQ([2.57])
-AC_INIT([CompositeProto], [0.3], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([CompositeProto], [0.4], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
--- a/configure.ac
+++ b/configure.ac
@@ -34,7 +34,7 @@ dnl protocol, so Xcomposite version l.n.m corresponds to protocol version l.n
dnl that 'revision' number appears in Xcomposite.h and has to be manually
dnl synchronized.
dnl
-AC_INIT(libXcomposite, 0.3.1, [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], libXcomposite)
+AC_INIT(libXcomposite, 0.4.0, [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], libXcomposite)
AM_INIT_AUTOMAKE([dist-bzip2])
AM_MAINTAINER_MODE
@@ -52,7 +52,7 @@ if test $VERSION = ; then
fi
COMPOSITEEXT_VERSION=[`echo $VERSION | sed 's/^\([0-9][0-9]*\.[0-9][0-9]*\).*$/\1/'`]
AC_SUBST(COMPOSITEEXT_VERSION)
-PKG_CHECK_MODULES(XCOMPOSITE, [compositeproto = $COMPOSITEEXT_VERSION] x11 xfixes xext fixesproto)
+PKG_CHECK_MODULES(XCOMPOSITE, [compositeproto = $COMPOSITEEXT_VERSION] x11 xfixes xext fixesproto xrender renderproto)
AC_SUBST(XCOMPOSITE_CFLAGS)
AC_SUBST(XCOMPOSITE_LIBS)
--- a/include/X11/extensions/Xcomposite.h
+++ b/include/X11/extensions/Xcomposite.h
@@ -47,6 +47,7 @@
#include X11/extensions/composite.h
#include X11/extensions/Xfixes.h
+#include X11/extensions/Xrender.h
#include X11/Xfuncproto.h
/*
@@ -92,6 +93,12 @@ XCompositeGetOverlayWindow (Display *dpy, Window window);
void
XCompositeReleaseOverlayWindow (Display *dpy, Window window);
+void
+XCompositeSetTriangularCoordinateMesh (Display *dpy,
+ Window window,
+ _Xconst XTriangle *triangle,
+ int nTriangle);
+
_XFUNCPROTOEND
#endif /* _XCOMPOSITE_H_ */
--- a/src/Xcomposite.c
+++ b/src/Xcomposite.c
@@ -391,3 +391,40 @@ XCompositeReleaseOverlayWindow (Display *dpy, Window window)
UnlockDisplay (dpy);
SyncHandle ();
}
+
+void
+XCompositeSetTriangularCoordinateMesh (Display *dpy,
+ Window window,
+ _Xconst XTriangle *triangle,
+ int nTriangle)
+{
+XCompositeExtDisplayInfo *info = XCompositeFindDisplay (dpy);
+xCompositeSetTriangularCoordinateMeshReq *req;
+int n;
+long len;
+
+XCompositeSimpleCheckExtension (dpy, info);
+LockDisplay (dpy);
+while (nTriangle)
+{
+ GetReq (CompositeSetTriangularCoordinateMesh, req);
+ req-reqType = info-codes-major_opcode;
+ req-compositeReqType = X_CompositeSetTriangularCoordinateMesh;
+ req-window = window;
+ n = nTriangle;
+ len = ((long) n) * (SIZEOF (xTriangle) 2);
+ if (!dpy-bigreq_size len (dpy-max_request_size - req-length))
+ {
+ n = (dpy-max_request_size - req-length) /
+ (SIZEOF (xTriangle) 2);
+ len = ((long) n) * (SIZEOF (xTriangle) 2);
+ }
+ SetReqLen (req, len, len);
+ len = 2;
+ DataInt32 (dpy, (int *) triangle, len);
+ nTriangle -= n;
+ triangle += n;
+}
+UnlockDisplay (dpy);
+SyncHandle ();
+}
--- a/src/xcompositeint.h
+++ b/src/xcompositeint.h
@@ -51,6 +51,7 @@
#include X11/Xlib.h
#include X11/Xlibint.h
#include X11/Xutil.h
+#include X11/extensions/renderproto.h
#include X11/extensions/compositeproto.h
#include X11/extensions/Xcomposite.h
@@ -83,4 +84,16 @@ XCompositeFindDisplay (Display *dpy);
#define XCompositeSimpleCheckExtension(dpy,i) \
if (!XCompositeHasExtension(i)) { return; }
+/*
+ * Xlib uses long for 32-bit values. Xcomposite uses int. This
+ * matters on alpha. Note that this macro assumes
Re: [compiz] who know how to debug compiz with gdb or Eclipse
On Tue, 2007-05-29 at 23:01 +0800, Zhu, Jack wrote: All, Intel SSG/OTC/UMD PRC Software EngineerglRotated You can use gdb with compiz as with any other app but you probably want to be logged in from a remote machine when running gdb and compiz as you will of course not be able to get any output on the local machine when the compiz process is stopped by gdb. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Zoom plugin changes
On Thu, 2007-05-31 at 02:19 +0200, Kristian Lyngstøl wrote: I'm sorry for being rude, but I am quite upset by this, because it has gone too far. I posted a few weeks ago that I was going to be working on zoom over the summer to improve the accessibility, and I have already begun to do that. Every step of the way I have made frequent commits to opencompositing.org and described the progress in my blog. I asked for information about what your (David) plans was, you thanked me for informing me on what I was going to work on and said you'd get back to me. You never did. Now today you commit 11fe37b7673b15e5cbd4be21759311087d9d8694 which introduce major changes to the zoom plugin. You did NOT give a heads up on this, even though you should have known I was working on this. This is simply unacceptable. When you are going to make changes and people have already told you they are working on that code, you have to actually communicate with them, not drop a 1k diff on them. It's not just your time that matters here, but ours too. This is not how people are supposed to co-operate. And also, when you write something, you have to document it. A few lines for each function, explaining what it does. You don't have to explain how or why, just WHAT. This is a common practice that I should NOT have to explain to an experience developer. Please document your changes to the zoom plugin properly so our USERS don't have to choose between two different feature sets when they want to zoom. Because this is about the users, not my pride. I never intended my zoom plugin to be the zoom plugin. It's just a zoom plugin that implements some zoom functionality. I hope that people haven't been under the impression that any zoom functionality that could be written would have to go into my zoom plugin. That's definitely not what I'd like to see. I'd like to see different zoom plugins that implement different zoom functionality. There's no reason the user should have to choose between them, they should be able to use them all at the same time if they want that. I always though that my zoom plugin was useless and more for demo purposes. I wrote a more useful zoom plugin a while ago and I though it made sense to replace the existing zoom plugin with this one, which is what I did yesterday. If someone found the old functionality useful or if you've been able to build something useful from it then I'm happy to see it available as an additional zoom plugin. The things I wanted to get back to you on related to the zoom work you do has very little to do with the implementation of zoom plugins and more to do with how other changes are important to make zoom functionality useful. E.g. changes I'd like to make to the core which will allow applications to incrementally move towards using resolution independent retained mode rendering etc. but I have unfortunately not had time to do that yet. You can ignore my recent changes to the zoom plugin in the fdo repo and keep working on your zoom plugin. I don't want my changes to cause you any unnecessary pain and I'm sorry if they got you upset. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
