[compiz] Dbus plugin problem: Setting reset

[Danny Baumann]

Hi,

since quite some time I encounter a problem which I believe is in the
dbus plugin: Sometimes when I load or unload plugins by changing the
configuration, all settings of all plugins are reset. At the same time,
the following message appears multiple times in the terminal I started
Compiz from (which makes me believe the problem is in the dbus plugin):

A handler is already registered for the path starting with path[0] =
org

I haven't been able to track it down yet because it happens rarely (but
regularly).
After this happens, the only ways to restore my custom config are to
reload Compiz or to 'touch' each single setting ('touch' meaning change
it and change it back).
This has happened to me using both ini and ccp as setting storage
backends, so I doubt it's related to that.

Does anyone have any clue about that?

Regards,

Danny

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

[compiz] [PATCH] Window base size calculation problem

[Danny Baumann]

Hi,

I just noticed that Compiz' window base size calculation in the function
recalcNormalHints() is broken. If both PMinSize and PBaseSize are set,
the base size is overwritten by the minimum size first and after that
the minimum size is overwritten by the base size again. This leads to
the base size information being completely lost.
I have attached a patch which fixes this problem, however, I do not yet
fully understand the idea behind the original code. Any objection
against putting this patch in?

Regards,

Danny
diff --git a/src/window.c b/src/window.c
index 6e18579..6265edb 100644
--- a/src/window.c
+++ b/src/window.c
@@ -117,30 +117,18 @@ recalcNormalHints (CompWindow *window)
 window-sizeHints.width  = window-serverWidth;
 window-sizeHints.height = window-serverHeight;
 
-if (window-sizeHints.flags  PMinSize)
-{
-	window-sizeHints.base_width  = window-sizeHints.min_width;
-	window-sizeHints.base_height = window-sizeHints.min_height;
-}
-else
+if (!(window-sizeHints.flags  PMinSize))
 {
 	window-sizeHints.base_width  = 0;
 	window-sizeHints.base_height = 0;
+	window-sizeHints.flags |= PMinSize;
 }
 
-window-sizeHints.flags |= PBaseSize;
-
-if (window-sizeHints.flags  PBaseSize)
-{
-	window-sizeHints.min_width  = window-sizeHints.base_width;
-	window-sizeHints.min_height = window-sizeHints.base_height;
-}
-else
+if (!(window-sizeHints.flags  PBaseSize))
 {
 	window-sizeHints.min_width  = 0;
 	window-sizeHints.min_height = 0;
 }
-window-sizeHints.flags |= PMinSize;
 
 if (!(window-sizeHints.flags  PMaxSize))
 {
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

Re: [compiz] xsltproc, schemas.xslt

[Colin Guthrie]

David Reveman wrote:
 xsltproc is distributed as part of the libxslt package, hence separating
 xsltproc and the libxslt.pc file like ubuntu has done seems like a
 mistake to me but I guess it doesn't hurt to include a check to ensure
 that the binary is present so I've included your patch.

FYI, Mandriva packages it this way too. I did have it installed so
wouldn't have noticed.

Just because a tarball will result in the building of a binary, does not
mean that you have to include all the files created via make install in
that tarball. Most packages have libXXX and libXXX-devel etc.
subpackages created from them and splitting out different
modules/plugins/binaries is fairly common practice too.

The pkgconfig check will check that the library development headers are
installed but I would argue it doesn't mean that an example application
built on that library is installed.

So I think the patch is correct like you say, and to be honest I've no
idea why I even bothered to write this mail as you've put the patch in,
but I just thought I'd wax lyrical for a bit :p

Col

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

Re: [compiz] Dbus plugin problem: Setting reset

[Mike Dransfield]

Danny Baumann wrote:
 Hi,

 since quite some time I encounter a problem which I believe is in the
 dbus plugin: Sometimes when I load or unload plugins by changing the
 configuration, all settings of all plugins are reset. At the same time,
 the following message appears multiple times in the terminal I started
 Compiz from (which makes me believe the problem is in the dbus plugin):

 A handler is already registered for the path starting with path[0] =
 org
   

These warnings were introduced with the dbus introspection, I
doubt they are related to your problem.

They are just warnings because some paths are being reregistered.


 I haven't been able to track it down yet because it happens rarely (but
 regularly).
 After this happens, the only ways to restore my custom config are to
 reload Compiz or to 'touch' each single setting ('touch' meaning change
 it and change it back).
 This has happened to me using both ini and ccp as setting storage
 backends, so I doubt it's related to that.

 Does anyone have any clue about that?

 Regards,

 Danny

 ___
 compiz mailing list
 compiz@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/compiz
   

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

[compiz] Bug in xslt

[Mike Dransfield]

There seems to be a bug in the schemas generation when the XML
file does not contain any options.  The descriptions are not generated
at all, it just produces an empty schema file like this.

?xml version=1.0?
gconfschemafile
  schemalist/
/gconfschemafile

This happens with ini and with the python plugin which both
do not have any options.

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

Re: [compiz] Dbus plugin problem: Setting reset

[Danny Baumann]

Hi,

  since quite some time I encounter a problem which I believe is in the
  dbus plugin: Sometimes when I load or unload plugins by changing the
  configuration, all settings of all plugins are reset. At the same time,
  the following message appears multiple times in the terminal I started
  Compiz from (which makes me believe the problem is in the dbus plugin):
 
  A handler is already registered for the path starting with path[0] =
  org

 
 These warnings were introduced with the dbus introspection, I
 doubt they are related to your problem.
 
 They are just warnings because some paths are being reregistered.

First let me say: That's correct - it really was coincidence. ;-)

  I haven't been able to track it down yet because it happens rarely (but
  regularly).
  After this happens, the only ways to restore my custom config are to
  reload Compiz or to 'touch' each single setting ('touch' meaning change
  it and change it back).
  This has happened to me using both ini and ccp as setting storage
  backends, so I doubt it's related to that.

I finally have found the reason for the problem: It is wrapping into
initPluginFor(Display|Screen) while executing initPluginFor(Display|
Screen).
Let me show this with the call stack. 'storage' in this example is the
option storage plugin.

- d-initPluginForDisplay (plugin.c:300) is called at some point for the
storage plugin
- this calls core's initPluginForDisplay, which calls initDisplay
(plugin.c:189)
- storage WRAPs into initPluginForDisplay
- initPluginForDisplay is called for the next plugin (e.g. dbus ;-) )
- storageInitPluginForDisplay is called
- storage UNWRAPs
- core's initPluginForDisplay is called
- initDisplay for the plugin is called
- plugin WRAPs into initPluginForDisplay
- storage WRAPs into initPluginForDisplay again

This is the reason why the pointer to storageInitPluginForDisplay will
get lost afterwards and newly loaded plugins thus won't get their
settings initialized. 

So in short: We are WRAPping a function while executing it, which is
bad(TM). Does anyone have a suggestion how to fix it?

Regards,

Danny

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

Re: [compiz] Bug in xslt

[Dennis Kasprzyk]

Am Dienstag 15 Mai 2007 15:29:15 schrieb Mike Dransfield:
 There seems to be a bug in the schemas generation when the XML
 file does not contain any options.  The descriptions are not generated
 at all, it just produces an empty schema file like this.

 ?xml version=1.0?
 gconfschemafile
   schemalist/
 /gconfschemafile

 This happens with ini and with the python plugin which both
 do not have any options.

 ___
 compiz mailing list
 compiz@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/compiz

This is not a bug in the xslt file, the plugin simply has no options. We 
should modify the build system not to try generate schema files for plugins 
that have no options.

Dennis

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

Re: [compiz] Window specific actions and edge buttons

[David Reveman]

On Tue, 2007-05-15 at 00:29 +0100, Mike Dransfield wrote:
 There is a problem with some window specific actions like
 scale_group and rotate_with_window when they are activated
 by an edgebutton.
 
 The basic problem is that each of those actions use the window
 option provided to the action.  When an edgebutton is used the
 window id sent is actually the id of the edge window, this means
 that actions which rely on this stop working.
 
 The obvious solution would be to change the affected functions
 to work on the active window rather that the one passed to the
 action.

Yes, I think that's what should be done.

 
 It could also be possible to modify the actions higher up to ignore
 edge windows, but I suppose some people might want that
 functionality.

- David

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

Re: [compiz] Building Compiz

[David Reveman]

On Mon, 2007-05-14 at 19:12 -0700, Grant Patterson wrote:
 Hi Folks,
 
 I work at VMware, where I'm making the multi-monitor feature new in 
 Workstation 
 6.0 (just released!) more robust. Long story short, window managers don't 
 consistently expose a good way for a single window to go fullscreen across 
 more 
 than monitor, which is what we need to do to display the monitors we expose 
 to a 
 guest virtual machine. So we've proposed a new hint for the wm-spec that lets 
 us 
 do this in a clean way; anticipating its approval (or something close to it), 
 I'm implementing the functionality in a variety of window managers, including 
 Compiz.
 
 Anyway, I got the source via git and I'm trying to build it. I'm not having 
 much 
 luck. I'm running Ubuntu Dapper and have the latest version of XFixes 
 according 
 to apt-get, but get this error when I try make:
 cursor.o: In function `addCursor':/src/compiz/src/cursor.c:57: undefined 
 reference to `XFixesHideCursor'
 
 Any idea what's going on?

You'll need a newer version of xfixes and it's a bug that the configure
script doesn't check for this. However, that cursor code is not yet used
so I just disabled the call to XFixesHideCursor for now. If you get the
latest changes it should not be a problem anymore. configure.ac should
be adjusted to require a newer version of xfixes once we enable this
cursor code.

- David

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

Re: [compiz] Dbus plugin problem: Setting reset

[David Reveman]

On Tue, 2007-05-15 at 15:45 +0200, Danny Baumann wrote:
 Hi,
 
   since quite some time I encounter a problem which I believe is in the
   dbus plugin: Sometimes when I load or unload plugins by changing the
   configuration, all settings of all plugins are reset. At the same time,
   the following message appears multiple times in the terminal I started
   Compiz from (which makes me believe the problem is in the dbus plugin):
  
   A handler is already registered for the path starting with path[0] =
   org
 
  
  These warnings were introduced with the dbus introspection, I
  doubt they are related to your problem.
  
  They are just warnings because some paths are being reregistered.
 
 First let me say: That's correct - it really was coincidence. ;-)
 
   I haven't been able to track it down yet because it happens rarely (but
   regularly).
   After this happens, the only ways to restore my custom config are to
   reload Compiz or to 'touch' each single setting ('touch' meaning change
   it and change it back).
   This has happened to me using both ini and ccp as setting storage
   backends, so I doubt it's related to that.
 
 I finally have found the reason for the problem: It is wrapping into
 initPluginFor(Display|Screen) while executing initPluginFor(Display|
 Screen).
 Let me show this with the call stack. 'storage' in this example is the
 option storage plugin.
 
 - d-initPluginForDisplay (plugin.c:300) is called at some point for the
 storage plugin
 - this calls core's initPluginForDisplay, which calls initDisplay
 (plugin.c:189)
 - storage WRAPs into initPluginForDisplay
 - initPluginForDisplay is called for the next plugin (e.g. dbus ;-) )
 - storageInitPluginForDisplay is called
 - storage UNWRAPs
 - core's initPluginForDisplay is called
 - initDisplay for the plugin is called
 - plugin WRAPs into initPluginForDisplay
 - storage WRAPs into initPluginForDisplay again
 
 This is the reason why the pointer to storageInitPluginForDisplay will
 get lost afterwards and newly loaded plugins thus won't get their
 settings initialized. 
 
 So in short: We are WRAPping a function while executing it, which is
 bad(TM). Does anyone have a suggestion how to fix it?

Yes, that's bad. The appropriate fix seems to be to move the plugin
initialization out of initPluginForDisplay and initPluginForScreen. I've
attached a patch that does this, let me know how it works.

Thanks for catching this one,

- David
--- a/src/plugin.c
+++ b/src/plugin.c
@@ -186,15 +186,26 @@ initPluginForDisplay (CompPlugin  *p,
 CompScreen *s, *failedScreen = d-screens;
 Bool   status = TRUE;
 
-if (!(*p-vTable-initDisplay) (p, d))
-	return FALSE;
-
 for (s = d-screens; s; s = s-next)
 {
+	if (p-vTable-initScreen)
+	{
+	if (!(*p-vTable-initScreen) (p, s))
+	{
+		failedScreen = s;
+		status = FALSE;
+		break;
+	}
+	}
+
 	if (!(*s-initPluginForScreen) (p, s))
 	{
 	fprintf (stderr, %s: Plugin '%s':initScreen failed\n,
 		 programName, p-vTable-name);
+
+	if (p-vTable-finiScreen)
+		(*p-vTable-finiScreen) (p, s);
+
 	failedScreen = s;
 	status = FALSE;
 	break;
@@ -202,8 +213,13 @@ initPluginForDisplay (CompPlugin  *p,
 }
 
 for (s = d-screens; s != failedScreen; s = s-next)
+{
 	(*s-finiPluginForScreen) (p, s);
 
+	if (p-vTable-finiScreen)
+	(*p-vTable-finiScreen) (p, s);
+}
+
 return status;
 }
 
@@ -214,9 +230,12 @@ finiPluginForDisplay (CompPlugin  *p,
 CompScreen  *s;
 
 for (s = d-screens; s; s = s-next)
+{
 	(*s-finiPluginForScreen) (p, s);
 
-(*p-vTable-finiDisplay) (p, d);
+	if (p-vTable-finiScreen)
+	(*p-vTable-finiScreen) (p, s);
+}
 }
 
 Bool
@@ -225,12 +244,6 @@ initPluginForScreen (CompPlugin *p,
 {
 Bool status = TRUE;
 
-if (p-vTable-initScreen)
-{
-	if (!(*p-vTable-initScreen) (p, s))
-	return FALSE;
-}
-
 if (p-vTable-initWindow)
 {
 	CompWindow *w, *failedWindow = s-windows;
@@ -268,9 +281,6 @@ finiPluginForScreen (CompPlugin *p,
 	for (w = s-windows; w; w = w-next)
 	(*p-vTable-finiWindow) (p, w);
 }
-
-if (p-vTable-finiScreen)
-	(*p-vTable-finiScreen) (p, s);
 }
 
 static Bool
@@ -297,6 +307,17 @@ initPlugin (CompPlugin *p)
 
 if (d)
 {
+	if (p-vTable-initDisplay)
+	{
+	if (!(*p-vTable-initDisplay) (p, d))
+	{
+		(*p-vTable-fini) (p);
+
+		return FALSE;
+
+	}
+	}
+
 	if (!(*d-initPluginForDisplay) (p, d))
 	{
 	fprintf (stderr, %s: Plugin '%s':initDisplay failed\n,
@@ -317,8 +338,13 @@ finiPlugin (CompPlugin *p)
 CompDisplay *d = compDisplays;
 
 if (d)
+{
 	(*d-finiPluginForDisplay) (p, d);
 
+	if (p-vTable-finiDisplay)
+	(*p-vTable-finiDisplay) (p, d);
+}
+
 (*p-vTable-fini) (p);
 }
 
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

Re: [compiz] Dbus plugin problem: Setting reset

[Danny Baumann]

Hi,

  I finally have found the reason for the problem: It is wrapping into
  initPluginFor(Display|Screen) while executing initPluginFor(Display|
  Screen).
  Let me show this with the call stack. 'storage' in this example is the
  option storage plugin.
  
  - d-initPluginForDisplay (plugin.c:300) is called at some point for the
  storage plugin
  - this calls core's initPluginForDisplay, which calls initDisplay
  (plugin.c:189)
  - storage WRAPs into initPluginForDisplay
  - initPluginForDisplay is called for the next plugin (e.g. dbus ;-) )
  - storageInitPluginForDisplay is called
  - storage UNWRAPs
  - core's initPluginForDisplay is called
  - initDisplay for the plugin is called
  - plugin WRAPs into initPluginForDisplay
  - storage WRAPs into initPluginForDisplay again
  
  This is the reason why the pointer to storageInitPluginForDisplay will
  get lost afterwards and newly loaded plugins thus won't get their
  settings initialized. 
  
  So in short: We are WRAPping a function while executing it, which is
  bad(TM). Does anyone have a suggestion how to fix it?
 
 Yes, that's bad. The appropriate fix seems to be to move the plugin
 initialization out of initPluginForDisplay and initPluginForScreen. I've
 attached a patch that does this, let me know how it works.

A quick testing shows it's working fine. Before I could reproduce the
problem in 100% of all cases, after that it's gone. The fix also looks
pretty obvious once you see it ;-)

Thanks,

Danny

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

Re: [compiz] Fragment interface on Intel

[David Reveman]

On Tue, 2007-05-15 at 07:40 +0800, Sam Spilsbury wrote:
 On 5/15/07, Sam Spilsbury [EMAIL PROTECTED] wrote:
  OK. Just to let you know - it most likely IS the fragment interface
 
  - Water fragmentation worked before the fragment interface was out
 
 On that note - do you think I can get a git revision that includes the
 blur plugin but does not include the fragment interface?

no, there's no such revision.

- David

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

[compiz] kde-window-decorator crashes

[Silvan Calarco]

BAADCAAHDwEHEAEKFwESKwIXNQIaOwIcQQIgSQIpXwM4gAQ8igU/kAVAkwVB
lAVClwVCmAVFngVJpgZKqQZLrQZPtQZQtgZRuQYAAQB1lW3cAXRS
TlMAQObYZgFiS0dEAIgFHUgJcEhZcwAALiMAAC4jAXilP3YH
dElNRQfXAxgNAiAQYlKOHXRFWHRDb21tZW50AENyZWF0ZWQgd2l0aCBU
aGUgR0lNUO9kJW4AAADMSURBVEjHzZbJEsMwCEPpvjfdW9T//89OkktqVxgy
PpSjzLPHQeCIZKGDkGJoFsF0E1EW0XyCaFVA/fl3RvzaTfW6nPTaaQqWP1TP
s9WjVxdgB3ypwHbfqRcAPgBoWvWIlODAoVWfcx8geK9fnXzbbTyX5jsJrZED
SNZYrakVHJVOIeK+WO8Y7osTnKlJVDxkxN290ymRSoTtu5EO83iY+t76Fjag
fwNYRHVAxTd/ShW1beAYPqUHqDyXHA0RzR/xjFacAdF2Dv3QZKsfsUpr0TVL
EzoASUVORK5CYII=
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary=nextPart12284572.cJpNqUBv6N;
  protocol=application/pgp-signature;
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
X-KMail-Recipients: compiz list compiz@lists.freedesktop.org
Message-Id: [EMAIL PROTECTED]
Status: R
X-Status: NQ
X-KMail-EncryptionState:  
X-KMail-SignatureState:  
X-KMail-MDN-Sent:  

--nextPart12284572.cJpNqUBv6N
Content-Type: text/plain;
  charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi,
I've updated compiz to the 0.5.0 release and since my release 0.3.something=
 I=20
keep on seeing seldom crashes from kde-window-decorator when running it bot=
h=20
on Xorg with AIGLX+nvidia card and Xorg+Xgl+ATI card.
The crashes most often happen at desktop login and when loading certain=20
applications (kmail, kaffeine, ...).
The strange thing is that if I try to attach to kde-window-decorator with g=
db=20
it doesn't crash anymore! What might be the reason?
If anybody can tell how I can make more debugging and give you more=20
information. The distribution is openmamba.

Thanks,
Silvan

=2D-=20
mambaSoft di Silvan Calarco - http://www.mambasoft.it
openmamba GNU/Linux development - http://www.openmamba.org

--nextPart12284572.cJpNqUBv6N
Content-Type: application/pgp-signature

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQBGSeXZorjzK0sXTM0RAvdBAKDfnwo6f050K1hLGB0Ac5x+IbGROwCgrcI7
cuYCTYEa2fPtyUPYGN5UFFY=
=yN1R
-END PGP SIGNATURE-

--nextPart12284572.cJpNqUBv6N--
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

[compiz] kde-window-decorator crashes

[Silvan Calarco]

Hi,
I've updated compiz to the 0.5.0 release and since my release 0.3.something I 
keep on seeing seldom crashes from kde-window-decorator when running it both 
on Xorg with AIGLX+nvidia card and Xorg+Xgl+ATI card.
The crashes most often happen at desktop login and when loading certain 
applications (kmail, kaffeine, ...).
The strange thing is that if I try to attach to kde-window-decorator with gdb 
it doesn't crash anymore! What might be the reason?
If anybody can tell how I can make more debugging and give you more 
information. The distribution is openmamba.

Thanks,
Silvan

-- 
mambaSoft di Silvan Calarco - http://www.mambasoft.it
openmamba GNU/Linux development - http://www.openmamba.org


pgpKRrXoFesUC.pgp
Description: PGP signature
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

Re: [compiz] kde-window-decorator crashes

[Diogo Ferreira]

Silvan Calarco wrote:
 Hi,
 I've updated compiz to the 0.5.0 release and since my release 0.3.something I 
 keep on seeing seldom crashes from kde-window-decorator when running it both 
 on Xorg with AIGLX+nvidia card and Xorg+Xgl+ATI card.
 The crashes most often happen at desktop login and when loading certain 
 applications (kmail, kaffeine, ...).
 The strange thing is that if I try to attach to kde-window-decorator with gdb 
 it doesn't crash anymore! What might be the reason?
 If anybody can tell how I can make more debugging and give you more 
 information. The distribution is openmamba.

 Thanks,
 Silvan

   
 

 ___
 compiz mailing list
 compiz@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/compiz
   

Hi, now that you mention kde-window-decorator I thought I would refer
something I notice from time to time and is quite annoying. I believe
it's a problem across all libdecoration because I also get this with
metacity on two (very) different setups (nvidia/64bits and ati/32bits).
What happens is that after some time of using the decorators the
decorations stall, if I click a window it takes input focus but the
decoration stays as if it wasn't. I guess more people have this problem
? Maybe someone who knows about libdecoration can offer some insight.

Regards,

Diogo


___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

[compiz] [PATCH] Descriptions for dbus when plugin not loaded

[Mike Dransfield]

Here is a quick patch for dbus to make it try to load the
metadata from a file if the plugin is not loaded.

I have tested it and it works fine, but I wanted to check to
see if you had something else in mind.
diff --git a/plugins/dbus.c b/plugins/dbus.c
index 811d2d6..8dc6c40 100644
--- a/plugins/dbus.c
+++ b/plugins/dbus.c
@@ -1742,15 +1742,30 @@ dbusHandleGetPluginMetadataMessage (DBusConnection 
*connection,
 
reply = dbus_message_new_method_return (message);
 
-   if (!loadedPlugin  p-vTable-getMetadata)
+   if (p-vTable-getMetadata)
{
CompMetadata *m;
 
-   m = (*p-vTable-getMetadata) (p);
+   if (loadedPlugin)
+   {
+   m = malloc (sizeof (CompMetadata));
+   if (!m)
+   return FALSE;
+   compInitPluginMetadata (m, p-vTable-name);
+   compAddMetadataFromFile (m, p-vTable-name);
+   }
+   else
+   {
+   m = (*p-vTable-getMetadata) (p);
+   }
+
if (m)
{
shortDesc = compGetShortPluginDescription (m);
longDesc  = compGetLongPluginDescription (m);
+
+   if (loadedPlugin)
+   free (m);
}
}
 
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz

Re: [compiz] Building Compiz

[Mike Dransfield]

Grant Patterson wrote:
 That did it, thanks!

 While I'm at it, I'll say I had some other issues building that I'd already 
 gotten past. I'm pretty sure I didn't do anything to screw up the 
 permissions, 
 but I got this:
 cursor.c:197: fatal error: opening dependency file .deps/cursor.pp: 
 Permission 
 denied
   

It looks like you might have compiled as root so some files
may not have write permission, to make sure type this.

(as root)
make clean  git clean

Or just check out a fresh tree :)

Then compile again starting from the ./autogen.sh line.  Make
sure that you are only root for the 'make install' step.

 And before that, it complained about not being able to find [config.h].in, 
 which 
 seems like a problem where a script wasn't removing brackets around a 
 variable 
 when it should. (These configure scripts, autogen, aclocal, etc etc are all 
 Greek to me.) I copied config.h.in to [config.h].in and it worked fine.
   

This probably means something went wrong compiling,
the steps above should help fix it.

 I also had to install moc, which wasn't on the list of packages I'd need, and 
 needed to symlink it from /usr/bin/ to /bin, as that's where make looked for 
 it.
   

You only need moc if you want kde-window-decorator, if you do
not want it then add --disable-kde to your autogen/configure line.


 Now, when I run compiz, it's totally broken. The terminal I run it from says:

 compiz: Unable to parse XML metadata from file core.xml
   

I think the steps above should fix this

 And the X server and all the windows (some of which have disappeared or lost 
 parts of themselves) are totally unresponsive. Any help?
   

It means that compiz crashed or failed to start, if you switch to
another virtual terminal with CtrlAltF1 and type this, then
switch back to VT7 it might give some more debugging information.

export DISPLAY=:0
metacity --replace 



 Let me say that I really appreciate what the open source community does. 
 Heck, 
 without it, I wouldn't have a job! It's the least I can do to contribute some 
 of 
 my time. However, it doesn't bode well for a project when it's as difficult 
 as 
 it's been for me to get working. I'm relatively new to Linux (1 year, and my 
 primary PC is a Mac), but I'm a software developer, and have had problem 
 after 
 problem getting Compiz's source into my work machine, compiling it, running 
 it. 
 I know very little about the challenges of distributing a highly configurable 
 window manager to work with all kinds of Linux flavors, metacity/kde/etc, all 
 that. But my experience has been a real mess.
   

Hopefully the hard work is almost over ;)

Upgrading to Feisty would save you an awful lot of hassle as
Dapper is really too old for Compiz.  Edgy was always the minimum
recommended.


 David Reveman wrote:
   
 On Mon, 2007-05-14 at 19:12 -0700, Grant Patterson wrote:
 
 Hi Folks,

 I work at VMware, where I'm making the multi-monitor feature new in 
 Workstation 
 6.0 (just released!) more robust. Long story short, window managers don't 
 consistently expose a good way for a single window to go fullscreen across 
 more 
 than monitor, which is what we need to do to display the monitors we expose 
 to a 
 guest virtual machine. So we've proposed a new hint for the wm-spec that 
 lets us 
 do this in a clean way; anticipating its approval (or something close to 
 it), 
 I'm implementing the functionality in a variety of window managers, 
 including 
 Compiz.

 Anyway, I got the source via git and I'm trying to build it. I'm not having 
 much 
 luck. I'm running Ubuntu Dapper and have the latest version of XFixes 
 according 
 to apt-get, but get this error when I try make:
 cursor.o: In function `addCursor':/src/compiz/src/cursor.c:57: undefined 
 reference to `XFixesHideCursor'

 Any idea what's going on?
   
 You'll need a newer version of xfixes and it's a bug that the configure
 script doesn't check for this. However, that cursor code is not yet used
 so I just disabled the call to XFixesHideCursor for now. If you get the
 latest changes it should not be a problem anymore. configure.ac should
 be adjusted to require a newer version of xfixes once we enable this
 cursor code.

 - David

 
 ___
 compiz mailing list
 compiz@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/compiz
   

___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz