[compiz] Compiz has been selected as the Window Manager of the Year

2008-02-27 Thread David Reveman
For those who haven't seen this already:

Compiz has been selected as the Window Manager of the Year in the 2007
LinuxQuestions.org Members Choice Awards:

http://www.linuxquestions.org/questions/2007-linuxquestions.org-members-choice-awards-79/window-manager-of-the-year-610196/


Congratulations to everyone who's helped make compiz what it is today!

-David

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


Re: [compiz] Object framework status?

2008-01-23 Thread David Reveman
On Mon, 2008-01-21 at 17:46 +0100, drago01 wrote:
 Hi,
 
 Whats the current status of the work on the object framework branch?
 Is there any ETA for merging it? It has been a while since it was announced.

I have unfortunately not had much time to work on it lately but it
should be in a pretty good state as of now. Some minor additions to the
signal system needs to be done to allow file and timer objects to be
implemented properly. I'll hopefully have time to get that done this
week and after that, I'm all for merging it asap.

-David

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


Re: [compiz] Tooltips show up on all screens of cube

2007-12-04 Thread David Reveman

On Thu, 2007-11-29 at 17:48 +0100, rudolf randal wrote:
 When ever i hover over something that gives me a tool tip - it is
 showing on all sides of my cube - dont want that - is there a cure ?

Not really as we're not allowed to change the location of the tool tip
windows inside compiz. They are override-redirect windows and window
managers are not allowed to touch them.

We could of course just avoid rendering them on more than one side of
the cube but that would be pretty bad unless we also redirected the
input.

-David

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


Re: [compiz] Blur is incredibly slow on the intel i915

2007-12-04 Thread David Reveman

On Sun, 2007-11-25 at 20:15 +0900, Sam Spilsbury wrote:
 I'm getting about 1 frame every 7 seconds with alpha or focus blur
 enabled. Is this normal? I get around 30-40 FPS when using water on
 high settings.

Yes, that's expected. The driver need to accelerate glCopyTexSubImage2D
for blur plugin to be usable.

 
 Would framebuffer_object support for the driver be of any use? Would
 it make things faster?

Framebuffer object support itself isn't going to help but a driver that
supports framebuffer objects is also very likely to accelerate
glCopyTexSubImage2D so switching to such a driver might very well help.

-David

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


Re: [compiz] window stacking bug #1

2007-12-04 Thread David Reveman

On Wed, 2007-11-21 at 22:05 +0100, Bogdan Butnaru wrote:
 Hello!
 
 I'm trying to find where to send a bug report/fix, and this mailing
 list is the best I found.
 
 I noticed several problems in how Compiz handles full-screen windows*,
 and I hacked a bit around the source to try to find their source. (*:
 I use this pretty much as a replacement for full-screen, all the
 time.) The first two are together below, because they seem caused by
 the same code. For the third I'll send another email. In all cases
 below, full-screen windows are NOT un-redirected.
 
 * Problem one
 Say the topmost window is non-full-screen and the window _immediately_
 below it is a full-screen window (so the two are the topmost windows).
 In this case, if the user moves the normal, top-most window by
 dragging its title-bar, the window is immediately hidden below the
 full-screen one. (The move can be continued correctly, but without the
 benefit of actually seeing the window, unless the full-screen one is
 semi-transparent.) However, if the window is moved using alt+drag
 outside the title-bar, everything is normal. Note that this doesn't
 happen if there are at least two normal windows above the full-screen
 window.
 
 * Problem two:
 If the topmost window is a full-screen window, the widget layer is
 displayed below it when the user presses the show widgets shortcut.
 This means the widgets are invisible, unless the full-screen window is
 transparent. (Note that the window is correctly shaded.
 
 
 
 I took a look at the source, and the problem seems to be in
 src/window.h, function raiseWindow(). The function uses
 findSiblingBelow (w, FALSE) to position the window it's called on,
 where the FALSE parameter means that the sibling (on top of which the
 window is moved) cannot be a full-screen window. The result is that if
 the topmost window is full-screen, calling raiseWindow() on a window
 will leave it hidden.
 
 In the case of problem one, here are the two scenarios: When the user
 initiates moving a window using the Alt+drag combination, compiz calls
 (among other things):
 
  updateWindowAttributes(w,CompStackingUpdateModeAboveFullscreen) followed 
 by
  updateWindowAttributes(w,CompStackingUpdateModeNone)
 
 However, when the user initiates a window move by dragging its title
 bar, the calls (excerpted) are:
 
  updateWindowAttributes(w, CompStackingUpdateModeAboveFullscreen)
  raiseWindow(w)
  updateWindowAttributes(w, CompStackingUpdateModeNone)
 
 In this case, the first call puts the window at the very top, and then
 raiseWindow actually moves it downwards, below the full-screen one. I
 believe the raiseWindow is caused by the (standard) behavior of
 raising a window on click. I don't know why it doesn't happen for
 clicks below the title-bar, though, and I couldn't find where it
 originates.
 
 
 For the second problem, it seems the Widget plugin calls raiseWindow
 to put the widget windows (I use screenlets) on top of the screen.
 Which of course can't happen if the topmost window is full-screen,
 because of how raiseWindow is defined.
 
 ***
 
 I'm not sure exactly why raiseWindow is defined the way it is now.
 Unless there's a very good reason for it, I propose changing the
 second parameter of findSiblingBelow to TRUE. This would automatically
 fix the two issues I mentioned above.
 
 However, if there is a really good reason why raiseWindow should stack
 below topmost full-screen windows, we need to find solutions for the
 other two problems.
 
 What do you think?

raiseWindow should probably be allowed to stack above fullscreen
windows. I'm not sure why it's not doing that right now.

I'm not sure what cases we have where we don't want to allow a window to
be stacked above fullscreen windows but for a window that is not a
transient of the fullscreen window to be stacked above it, the
fullscreen window must first be lowered below the dock-window layer
(e.g. gnome-panel) and you don't want that to happen unless it really
makes sense.

The current stacking code is pretty error prune and I've been thinking
about replacing it with some less complex code that validates the
complete stack of windows every time a stacking change need to be made.
It will be easier to handle all these special cases for fullscreen
windows once this gets done. However, I prefer to wait with this until
we have a proper object system in place.

-David

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


Re: [compiz] video plugin update

2007-12-03 Thread David Reveman

On Tue, 2007-09-04 at 15:16 +0200, Dominik 'Rathann' Mierzejewski wrote:
 Hello,
 
 On Friday, 13 July 2007 at 14:11, Colin Guthrie wrote:
  David Reveman wrote:
   I had to update the video plugin interface slightly to fix some bugs.
   I've attached an updated mplayer patch.
  
  David,
  
  Is this patch ever going to make it upstream to mplayer do you think?
  
  Has it been submitted/reviewed by upstream devs?
 
 Any progress here? Users keep coming and asking why they can't use MPlayer
 with compiz. We do not have the resources to implement this (not to mention
 that none of the core developers use compiz). The current patch is
 unacceptable for inclusion in MPlayer (due to unnecessary code
 duplication). See this document for MPlayer patch submission guidelines:
 http://www.mplayerhq.hu/DOCS/tech/patches.txt

There's going to be a new more appropriate video interface soon, for
which support is more likely to be included upstream.

-David

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


[compiz] object framework design

2007-12-02 Thread David Reveman
I'm going to start today by posting the first two, out of a series of
four documents describing the work done in the object-framework branch.

This post is just a heads-up but I'd also like to make sure people
understand that what's described in these docs and what's in the
object-framework branch is not set in stone in any way. It's a proposal
based on my experience with the current compiz code-base and the
research I've done lately for how we can move to what I think is a much
more appropriate architecture. Feedback is much appreciated.

I'm confident that with the object-framework branch work as base,
together we can implement a system that is hugely superior to what we
currently have.

Thanks,

-David

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


[compiz] re-architecting compiz

2007-11-30 Thread David Reveman
I'd like to start with apologizing for my lack of response to the
mailing list for the last couple of months. I'm working my way through
all posts right now...

Here's what I've been up to lately..

I did a critical review of the state of compiz about 6 months ago. I
realized it was pretty bad (not that there's actually anything better
out there but still), it's hard to maintain, hard to write proper code
for and in some ways not dynamic enough for people to do what they want.
None of the features I need to implement can be done properly in the
current architecture.

I spent a lot of time trying to come up with a way for us to re-engineer
the core of compiz and fix all the issues that exist in the current
architecture. I did a fair amount of research and experimenting before I
got an idea of what would be a good future architecture. What's emerging
in the object-framework branch is the result of this work and what I
believe to be the best way forward. There's still some important pieces
missing before I consider merging it to master a good idea but it's now
at least at a stage where I'm comfortable with people starting to look
at it and start discussing merging it to master.

Even though I've made sure that the rewrite allows existing plugins to
be fairly easily ported, it's still going to be the most significant
change to compiz since the initial version was realized. If we ever had
released a 1.0, this would definitely qualify for a 2.0.

Most of the ground work for this new architecture has already been done
in the object-framework branch but even when we've gotten it to a state
where it can be merged, there's still a lot of work left to make the
existing core functionality and plugins take advantage of it. However,
the considerably more modularized nature of this new architecture would
allow us to move to a much smaller core and get it ready for a 1.0
release in a short amount of time.

I'm going to send a series of posts to the list that explains the
different parts of the new architecture in more detail (hopefully the
first one during the weekend) but here's a few key features of the new
architecture:

A strict hierarchical structure. A very well-defined way for how the
different parts of the system communicate with each other (it's obvious
when some code is doing something inappropriate and it's also hard to
write code that is doing something inappropriate). Whether the code is
in the core or in a plugin is of no significant importance, which means
that pretty much anything can be modularized. Plugins can be inserted
into different parts of the object tree and only affect a sub-tree of
objects. An internal communication system that maps efficiently and
conveniently to various IPC systems.

-David

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


Re: [compiz] core improvements

2007-09-09 Thread David Reveman
On Fri, 2007-09-07 at 17:11 -0400, Kristian Høgsberg wrote: 
 On 9/7/07, David Reveman [EMAIL PROTECTED] wrote:
 ...
  - Object model
 
  We need to easily be able to create new types of objects that plugins
  can keep track of and add options to without breaking the API or even
  the ABI.
 
  The initial part of this is already in head. The object system I've
  added is very simple but still sufficient. It allows us to add new core
  objects without having to update any plugins.
 
  Next step is to add an interface that will allow plugins to add their
  own type of objects. This is a simple addition to the current object
  system and you can expect it to land in head shortly.
 
 I browsed the patch, and it look mostly good, but I wondered why you
 decided to go for a 'type' integer instead of the more custom 'class'
 pointer (or objectInfo pointer).  Then you could just do
 
 char *
 compObjectName (CompObject *object)
 {
  return (*nameObject-ObjectInfo) (object);
 }
 
 and the CompObjectInfo structs can be static variables in the relevant
 files (screenObject info in screen.c etc) and the functions they point
 to can be static too.

Yes, I think we want that eventually. However, I currently use the type
integer as a dispatch table index in a lot of places (like the
initObject VTable functions) and some of the current objectInfo
functions need to be called without an instance of the object (e.g.
forEachObject).

The dispatch index can be avoided once we make all wrap-able functions
part of the object type. This is basically just the next step towards
more standard polymorphism.

I don't want to enforce a specific data type for keeping track of
objects. The forEachObject function solves that but it can simple be
moved into the object type vtable instead. Same thing for the findObject
function.

I'll try to come up with a step by step plan for how we accomplish this
and send it to the list sometime soon...

 
  TODO
 
  - Matching interface
 
  The matching interface should be updated to work with all kinds of
  objects and not only window objects. This should be easy to get done as
  I had something like this in mind when I first implemented the matching
  system.
 
 
  - Replace the option system
 
  This sounds like more work than what it is. All I want to do is rename
  existing options to properties and add methods and signals. A property
  will be pretty much exactly the same thing as an option is today except
  that there's not going to be an action property. A method will be
  similar to what an action option is today but it will include a
  signature and the initiate/terminate bs ripped out.
 
  What options provide today is really just a IPC mechanism. D-BUS got a
  very good model for this and I'd like to adjust compiz so it matches
  that model as much as possible.
 
 Sounds cool.
 
  - Output plugin support
 
  The actual rendering should be separated from the core. Most of the
  current rendering code will be moved into a GL output plugin. Multiple
  output plugins can be active at the same time and they shouldn't
  necessarily have to be drawing to the screen. E.g. the screenshot plugin
  will be an output plugin that render to a file instead of the screen. An
  xrender output plugin could easily be created. However, some of the
  existing plugins will rely on the GL output plugin, e.g. blur and video
  plugins.
 
 Interesting.  Where do you see this going?  What's the motivation for
 supporting other output methods?

There's a few things that we like to accomplish.

Some people have asked for xrender output support. These changes would
allow that to be implemented even though some of the more impressive
plugins are not going to work without GL. This might not make a lot of
sense for the regular desktop machine but for some remote composited X
situations (I'll talk about this at XDS) it can make a lot of sense.

It allows me to integrate the remote composited X experiments I've been
playing with properly.

Would make it very easy to support AGL, WGL if desired. It even be
possible to support Direct3D.

It would also provide a well defined way for screen capturing,
printing..

-David

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


[compiz] core improvements

2007-09-07 Thread David Reveman
I've been making a large set of important updates to the code base
recently and there's more stuff on it's way but I'd like to get some
feedback first.

I know that some of the changes I've made and will be making require a
fair amount of work by plugin and config tool developers but I hope you
can bear with me. They are very important for the future of the project.


- API, ABI and plugin interface separation

This is in head already. compiz.h now contains an API that will be kept
fairly stable. It's useless in it's current state but more functions
will be added and simple plugins will be able to use this API and work
across multiple ABI versions. Regular symbol resolution performed by
dlopen and a simple minor version number check is enough to ensure that
a plugin is not accidentally loaded into compiz with an incompatible
API.

The ABI will likely always change rapidly and any plugin that includes
compiz-core.h is also responsible for verifying the ABI version when
being loaded.

The plugin interface can be found in compiz-plugin.h and it will rarely
change. The getCompPluginInfo symbol needs to change every time the
plugin interface changes to ensure that plugins with an old interface
aren't accidentally loaded.


- Object model

We need to easily be able to create new types of objects that plugins
can keep track of and add options to without breaking the API or even
the ABI.

The initial part of this is already in head. The object system I've
added is very simple but still sufficient. It allows us to add new core
objects without having to update any plugins.

Next step is to add an interface that will allow plugins to add their
own type of objects. This is a simple addition to the current object
system and you can expect it to land in head shortly.


- Multiple displays

Being able to manage multiple displays might seem unnecessary but making
sure that it works improves the design of the core and I'm also working
on a related project that will take advantage of it.

I've updated the core and most plugins so they work correctly with
multiple displays. However, our configuration plugins needs some more
work.


- Core object

There's now a core object. This is the only object that is allowed to
be parentless, every other object needs a parent.

A lot of hooks that currently exist in the display object should be
moved into core object. All general object hooks should be in the core
object.


TODO

- Matching interface

The matching interface should be updated to work with all kinds of
objects and not only window objects. This should be easy to get done as
I had something like this in mind when I first implemented the matching
system.


- Replace the option system

This sounds like more work than what it is. All I want to do is rename
existing options to properties and add methods and signals. A property
will be pretty much exactly the same thing as an option is today except
that there's not going to be an action property. A method will be
similar to what an action option is today but it will include a
signature and the initiate/terminate bs ripped out.

What options provide today is really just a IPC mechanism. D-BUS got a
very good model for this and I'd like to adjust compiz so it matches
that model as much as possible.

So basically, each plugin can provide an interface for every object. The
interface contains a set of properties, methods and signals. E.g. a Key
or Button property is just a property that defines a key/button
combination that will trigger invocation of a specific method.

Full interface descriptions that can be used by applications to generate
bindings can easily be created from the compiz meta-data.

Further on, a plugin can be seen as a service and D-BUS could be able to
handle plugin loading and unloading as desired by applications.

The key names used by gconf plugin and group names used by kconfig
plugin needs to change to properly reflect the new object system.

gconf should use
/apps/compiz/'plugin'/'object-path'/'property'
as key name.

kconfig should use
'plugin'_'object-path'
as group name.

'object-path' could be something like this:
display/:0/screen/0

This will break existing configuration tools but it can't be avoided and
the should be easy to update all tools that exist.


- Output plugin support

The actual rendering should be separated from the core. Most of the
current rendering code will be moved into a GL output plugin. Multiple
output plugins can be active at the same time and they shouldn't
necessarily have to be drawing to the screen. E.g. the screenshot plugin
will be an output plugin that render to a file instead of the screen. An
xrender output plugin could easily be created. However, some of the
existing plugins will rely on the GL output plugin, e.g. blur and video
plugins.


-David

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


Re: [compiz] WindowRemoveNotifyProc

2007-09-06 Thread David Reveman
On Wed, 2007-08-22 at 12:53 -0400, Nicolas Viennot wrote: 
 Hello,
 
 I'm doing a C++ wrapper and I need the counterpart of WindowAddNotifyProc
 Every plugin must be rebuild since CompScreen is modified, hence ABIVERSION 
 should be changed as well.
 Would it be possible to implement it ?
 
 Patch attached

Thanks, I applied it to my local branch. However, we need these kind of
hooks for any kind of object so
WindowAddNotifyProc/WindowRemoveNotifyProc has now been replaced by
ObjectAdd and ObjectRemove hooks.

-David

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


Re: [compiz] [ANNOUNCE] compiz-0.5.4

2007-08-21 Thread David Reveman
On Mon, 2007-08-20 at 16:22 -0400, Kristian Høgsberg wrote:
 On 8/20/07, David Reveman [EMAIL PROTECTED] wrote:
  A new compiz release 0.5.4 is now available from:
 
  
  http://xorg.freedesktop.org/archive/individual/app/compiz-0.5.4.tar.gz
 
 Oh... I guess I expected the next development release would be 0.7.0,
 since a 0.6.0 maintenance branch was created.  I hope (and assume) the
 0.5.4 release isn't intended to be a pre-release for the 0.6.0 stable
 release, especially with the new XCB requirement, but the release
 numbering is a little confusing.
 
 We're shipping 0.5.2 in Fedora rawhide now, and I'm expecting to spend
 some time fixing whatever bugs show up and contribute fixes back to
 the 0.6 branch (and head, of course).  And I'm hoping that we can
 release that branch as 0.6 in time for me to pull that into the
 upcoming Fedora 8 release.
 
 What's the roadmap?

0.5.4 is just another development release and part of my new strategy to
push out development releases every second week or when a major new
feature has landed. The release number probably got wrong, though. It
should probably have been 0.7.0. I'll get this right in the next
release.

I'm not sure what will end up in 0.6 and not. I'm not going to be much
in charge of what goes into 0.6 and not. We can revert the commit that
added the XCB requirement and re-base the 0.6 branch on head if people
are interested in that.

-David

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


[compiz] [ANNOUNCE] compiz-0.5.4

2007-08-20 Thread David Reveman
A new compiz release 0.5.4 is now available from:

http://xorg.freedesktop.org/archive/individual/app/compiz-0.5.4.tar.gz

which can be verified with:


http://xorg.freedesktop.org/archive/individual/app/compiz-0.5.4.tar.gz.sha1
761e5ac96426cab48588d14960e84971ad103372  compiz-0.5.4.tar.gz


http://xorg.freedesktop.org/archive/individual/app/compiz-0.5.4.tar.gz.sha1.asc
(signed by David Reveman)

  Additionally, a git clone of the source tree:

git clone git://git.freedesktop.org/git/xorg/app/compiz

will include a signed compiz-0.5.4 tag which points to a commit named:
dacb4c77f110a57185400b0635d8b8b5c985f87e

which can be verified with:
git verify-tag compiz-0.5.4

and can be checked out with a command such as:
git checkout -b build compiz-0.5.4


WHAT'S NEW
==

XCB is now required.

Major improvements to option system that makes
configuration backend integration much less complex.

Kconfig plugin that provides proper KDE configuration
support.

Kcfg files are generated from the meta-data and they can
be used to generate C++ source code that will provide an
API for applications to access all compiz configuration
data used by the kconfig plugin.


-David

Changes since compiz-0.5.2:
Danny Baumann:
  Remove trailing whitespace.
  Formatting fixes.
  Fix possible memleaks.
  Fix typos.

David Reveman:
  Post release version increment.
  Fix typo.
  Remove whitespaces.
  Require x11-xcb.
  Add XCB connection handle to CompDisplay.
  Add CompNoMask to REAL_MOD_MASK.
  Select for focus change events on frame windows.
  Revert Select for focus change events on frame windows.
  Usage of lastFoundWindow in findTopLevelWindowAtDisplay is
  Avoid using lastFoundWindow in findWindowAtDisplay.
  Reduce code by using findWindowAtScreen in
  This should be taken care of by unhookWindowFromScreen.
  Include proper compiler flags and link libdecoration to
  Avoid use of strcasestr and case insensitive matching of
  Rearrange some headers to avoid compile issues on solaris.
  Cleanup.
  Fix many function declarations that were missing the 'const'
  Make compInitOptionValue and compFiniOptionValue available to
  Use equalRange when checking if new value is equal to
  Fix event handle matching. This caused inotify plugin to
  Default alpha value for color options is 1.0.
  Add key-binding option, which is just a key-binding only
  Add button-binding option, which is just a button-binding only
  Add edge option, which is just a edge only action option.
  Add bell option, which is just a bell only action option.
  Add edge modifiers. Deprecates edge button functionality.
  Handle new option types properly.
  Add isActionOption function.
  Add passive grabs and update event handling to trigger
  Switch to new action option types for all core options. Most
  Use new action option types in annotate plugin.
  Use new action option types in blur plugin.
  Use new action option types in clone plugin.
  Use new action option types in cube plugin.
  Use new action option types in move plugin.
  Use new action option types in plane plugin.
  Use new action option types in resize plugin.
  Use new action option types in rotate plugin.
  Use new action option types in scale plugin.
  Use new action option types in screenshot plugin.
  Use new action option types in switcher plugin.
  Use new action option types in water plugin.
  Use new action option types in wobbly plugin.
  Use new action option types in zoom plugin.
  Remove complex action option handling from gconf plugin as
  Remove duplicate initialization of option.
  Action options should no longer be in the schemas
  Print bell action type properly.
  Fix edge string parsing.
  Remove complex action option initialization.
  Update edge option metadata.
  Update parsing of edge metadata.
  Trigger edge button events properly.
  Avoid using binding type when determining if action
  Remove complex action option handling from ini plugin.
  Remove complex action option handling from dbus plugin.
  Remove complex action option handling from fuse plugin.
  Remove unused edgeButton variable from action struct.
  Free list option values properly.
  Cleanup.
  Make sure initiate, terminate and state variables in action
  Use compFiniOptionValue in fuse plugin.
  Cleanup.
  Button actions should be initialized with CompActionStateInitEdge
  Add button action options for all switcher actions.
  Check action type properly when comparing action values.
  Better default colors.
  Clean up.
  Add kconfig plugin and style-sheets that generate a default
  Remove use of kcfg Enum type.
  Add screen

[compiz] configuration updates

2007-08-17 Thread David Reveman
I just pushed out a large set of configuration updates that I've been
working on for the last couple of days.

A major difference from before is that the action options have now been
slit up into key, button, edge and bell options. Action options still
exist but they can only be triggered through dbus or a similar
mechanism.

It's very convenient to have every option type easily represented as a
string and that's now the case. If multiple primitive options are
supposed to be represented as one large option, the metadata should be
used to achieve that.

One benefit is that it simplifies the configuration system a lot and
once this was done I was able to quickly implement a proper kconfig
backend plugin (I'll follow up with another mail regarding this
shortly).  I've also re-written large parts of the gconf plugin and it's
now in a much better state than before.

Any plugin that uses action options will need to be updated but the
changes that need to be made are simple. Each action option needs to be
split up into a key, button, edge and bell option. However, you should
only add the ones that makes sense. E.g. if the option is only supposed
to be triggered using a key-binding, don't add the other options.

I've already updated the core and all plugins in the fdo repository.
Look at these changes to see how to best update other plugins.

By adding the _key suffix to key actions, _button suffix to button
actions etc you'll avoid breaking configuration tools as the gconf
plugin was exposing the old action options like this before anyhow.

I haven't added key, button, edge and bell options for all old action
option. Mostly just the key option but it's trivial to add the other
ones so just let me know if you for example want a button or edge option
for an action that is only exposed as a key option and I'll add it
quickly.

Configuration backends need to be updated as well but the changes there
are also simple, mostly about removing old complex action option
handling code.

-David

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


[compiz] kconfig plugin

2007-08-17 Thread David Reveman
I've added a kconfig plugin and all kde based configuration tools should
rely on it. A file watch plugin like the inotify plugin will have to be
loaded for configuration changes to be picked up by the kconfig plugin
at run-time.

kcfg files are generated from the metadata and they can be used to
generate C++ source code that will provide an API for applications to
access all compiz configuration data.

As an example of how easy it now is to create a kde config tool for
compiz, I've attached a tarball with a simple xslt style-sheet, a
makefile and 20 lines of C++ code that will create a configuration
dialog that can be used to configure all compiz options in the core and
the plugins specified in the makefile.

The xslt style-sheet that is used to generate UI descriptions can be
improved a lot by someone who's interested. As far as configure-it-all
kind of tools goes, I think this auto-generated zero maintain cost
example is the best solution.

Much more interesting would be if someone would write a real kcontrol
module that integrate properly with the kde desktop. E.g. doesn't
present options that are already available in some other kcontrol
module, only expose options that a majority of users are actually
interested in and have the same look and feel as the rest of the
kcontrol modules.

-David


example.tar.bz2
Description: application/bzip-compressed-tar
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz


Re: [compiz] Metadata additions

2007-08-12 Thread David Reveman
On Thu, 2007-07-12 at 03:54 +0200, Dennis Kasprzyk wrote:
 With this mail I would like to make a proposal to add additional informations 
 to the core and plugin metadata files. Currently these tags are already 
 handled in the ccs configuration system. Ccs  automatically adds this 
 informations to the core/plugin option set, but I think that it would make 
 more sense to add this to the official files, to allow similar features in 
 other configuration systems. 
 
 1.) Group and subgroups:
 
 plugin
   display
 option .../
 option .../
 group
   shortThis is a functional group/short
   option .../
   option .../
   subgroup
  shortThis options belong together/short
  option .../
  ...
   /subgroup
 /group
 ...
 There are often a lot of different opinions how options should be grouped, 
 but 
 this could be discussed after we have decided to add group/subgroup tags.
 Currently the core has two lists (opacity_matches and opacity_values) that 
 should be handled together, because the opacity of the opacity_values list 
 will be assigned to the corresponding match in the match list. In ccs we 
 automatically combine such values if all options inside a subgroup have the 
 list type, but we could also add a combine=”true” attribute to the subgroup 
 tag, to make this functionality configurable.

Sure, this seems OK.

It makes a lot of sense to slit up the action options we have today into
multiple less complex options and just group them together using
metadata. It will simplify the configuration system a lot.

 
 2.) Option hints:
 
 A string option (there may be others too) can be used for different things 
 like commands,files, and images. To allow a configuration to handle such 
 options in a spacial way (open a file open dialog), I would like to add a 
 hints tag to such options. The hints tag would contain a semicolon 
 separated list of strings that inform the configuration system to handle this 
 options in a special way. These are the possible hints:
 
 command; = open a file dialog to select an executable file
 image; = open a file dialog that already filters all image files that are 
 currently supported by currently loaded image plugins and shows previews of 
 the images
 file; = open a file dialog that allows you to select any file
 file:txt,doc; = open a file dialog that allows you to select *.txt and *.doc 
 files

Sounds good.

 
 3.) Plugin categories:
 
 Currently we have a lot of plugins and we will have more in the future. I 
 think that it makes sense to group plugins to functional categories 
 like “Effects”, “Window management” and “Image loaders”. A category tag 
 could be added the plugin section to achieve this functionality. There are 
 currently 3 different ways how the contents of this tag could be handled:
 - We define short category definitions like fx,wm and image and the 
 configuration system will need to have the “long” names and their 
 translations.
 - We add directly the English long category names like “Effects”, “Window 
 management” and “Image loaders”, and the configuration system will need to 
 have translations for them. This has the disadvantage that the configuration 
 system would need to have a list of all long names to be able to 
 automatically generate a .pot file for translations.
 - We add long category names to the metadata and translate them with the 
 current translation system like we do for option descriptions. This has the 
 disadvantage that plugins from different sources could also have different or 
 none translations for the same category and the configuration systems would 
 need a way to find the best solution.

I definitely prefer that we add long category names to the metadata. We
can make it possible for external plugins to use the po files from the
core repository when translating metadata.

-David

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


Re: [compiz] [PATCH] Unbound modifiers and CompNoMask

2007-08-07 Thread David Reveman
On Sun, 2007-08-05 at 05:21 -0400, Andy Hefner wrote:
 This patch fixes an undesirable behavior in the comparison of modifier
 bits necessary to initiate an action - if the modifier is not configured
 on the user's X server (thus having CompNoMask in its position in
 d-modMask), the comparison always behaves as though the modifier were
 pressed, due to CompNoMask falling outside the REAL_MOD_MASK 
 ~d-ignoredModMask bitmask. This causes actions to be invoked
 inappropriately (for instance, if the user has no keysyms assigned for
 the Super modifier, the zoom plugin can be triggered on unmodified
 scroll wheel events, interfering with normal scrolling).

Good catch.

I added CompNoMask to the REAL_MOD_MASK define, which should take care
of the problem.

Thanks,

-David

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


Re: [compiz] Focus problem for shaded windows

2007-08-07 Thread David Reveman
On Mon, 2007-08-06 at 10:15 +0200, Danny Baumann wrote:
  today, I noticed a problem in focus handling for shaded windows which is
  pretty easy to reproduce:
  
  - Disable Click to focus
  - Shade a window
  - Hover another window
  - Hover back to the window frame of the shaded window
  - Press Ctrl+Alt+S
  
  Expected behaviour would be that the shaded window is unshaded. What
  happens is that the last active window is shaded.
  
  I investigated this a bit and found the cause for this behaviour, but
  wasn't able to work out a proper fix for that:
  - The function shade() uses d-activeWindow to determine the window to
  (un)shade via the window option.
  - d-activeWindow is set from the FocusIn event handler, but only if
  w-managed is set for the window which is hovered or whose frame is
  hovered
  - As w-managed is unset in the UnmapNotify handler (and so after a
  window is shaded), hovering a shaded window frame does not set
  d-activeWindow to that window.
  
  Any idea regarding that one?
 
  w-managed should not be unset when getting an UnmapNotify event cause
  by shading. The window is still managed by compiz while being shaded.
  w-pendingUnmaps should be greater than 1 when a window is shaded but I
  guess that's broken somehow...
 
 You are right. This also works as intended. I walked a false path there, 
 sorry.
 The real problem is that we don't select for FocusChange events for frame 
 windows and thus never get FocusIn events for them. 
 Correcting this revealed another problem: The lastFoundWindow variable was 
 (IMO incorrectly) sometimes also set to frame windows.
 The attached patch seems to do the trick - any comments?

I applied the FocusChange change just before I realized that it
shouldn't be needed as we'll select for focus change events when the
window gets added using the addWindow function and this change shouldn't
make a difference.

lastFoundWindow is just an optimization to avoid walking the list of
windows when a window is looked up multiple times.

The way lastFoundWindow is updated right now is more correct than what
your patch will do.

-David

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


Re: [compiz] KDE Window decorator offset on maximized windows.

2007-08-07 Thread David Reveman
On Fri, 2007-08-03 at 16:43 +0100, Colin Guthrie wrote:
 Diogo Ferreira wrote:
  On Thu, 2007-08-02 at 10:34 +0100, Colin Guthrie wrote:
  Hi,
 
  Any reason why this would happen that you can think of?
  http://qa.mandriva.com/show_bug.cgi?id=32215
  I have no idea why it happens but I think it depends on the theme,
  kde-window-decorator must be bugged somewhere, sometimes decorations
  won't even appear like in this screenshot:
  http://public.underdev.org/upload/files/no_decoration.png
  
  I've mentioned this before in the kwd-crash thread, hope this time it
  gets some more attention from the people who understand kwd.
 
 It seems that polyester doesn't have this problem but plastik does.
 Perhaps that will help to debug?

no, I used plastik when testing. :(

-David

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


Re: [compiz] Focus problem for shaded windows

2007-08-07 Thread David Reveman
On Tue, 2007-08-07 at 20:44 +0200, Danny Baumann wrote: 
 Hi,
 
today, I noticed a problem in focus handling for shaded windows which 
is
pretty easy to reproduce:

- Disable Click to focus
- Shade a window
- Hover another window
- Hover back to the window frame of the shaded window
- Press Ctrl+Alt+S

Expected behaviour would be that the shaded window is unshaded. What
happens is that the last active window is shaded.

I investigated this a bit and found the cause for this behaviour, but
wasn't able to work out a proper fix for that:
- The function shade() uses d-activeWindow to determine the window to
(un)shade via the window option.
- d-activeWindow is set from the FocusIn event handler, but only if
w-managed is set for the window which is hovered or whose frame is
hovered
- As w-managed is unset in the UnmapNotify handler (and so after a
window is shaded), hovering a shaded window frame does not set
d-activeWindow to that window.

Any idea regarding that one?
   
w-managed should not be unset when getting an UnmapNotify event cause
by shading. The window is still managed by compiz while being shaded.
w-pendingUnmaps should be greater than 1 when a window is shaded but I
guess that's broken somehow...
   
   You are right. This also works as intended. I walked a false path there, 
   sorry.
   The real problem is that we don't select for FocusChange events for frame 
   windows and thus never get FocusIn events for them. 
   Correcting this revealed another problem: The lastFoundWindow variable 
   was (IMO incorrectly) sometimes also set to frame windows.
   The attached patch seems to do the trick - any comments?
  
  I applied the FocusChange change just before I realized that it
  shouldn't be needed as we'll select for focus change events when the
  window gets added using the addWindow function and this change shouldn't
  make a difference.
 
 It does make a difference. We're currently selecting for FocusChange
 events of the _window_, not the _frame_.
 The problem is that although we correctly set the input focus to the
 frame window if the window is shaded (window.c:2870), we never get a
 FocusIn event in response and thus never will set the shaded window
 active (where findTopLevelWindowAtDisplay will retrieve the main window
 for the focussed frame). That's why we IMO need to select for
 FocusChange events also for the frame window.

We do select for FocusChange events on the frame window at
window.c:1974. The frame window will be added to the window list just as
all other windows and we'll then select for FocusChange events, which is
why we don't have to do this when creating the window.

 
  lastFoundWindow is just an optimization to avoid walking the list of
  windows when a window is looked up multiple times.
  
  The way lastFoundWindow is updated right now is more correct than what
  your patch will do.
 
 I disagree. lastFoundWindow is used for both findWindowAtDisplay/Screen
 and findTopLevelWindowAtDisplay/Screen. This has the side effect that
 the behaviour of findTopLevelWindow depends on which window was
 processed by findWindow before:
 - Assumption: findWindowAtScreen is called for a frame window (which is
 a valid scenario)

sure.

 - findWindowAtScreen returns the frame window CompWindow struct and sets
 lastFoundWindow to that

yes.

 - if findTopLevelWindowAtScreen is called after that for the window the
 frame window belongs to, the frame window is returned

No, how can that happen? lastFoundWindow-id will not match the id
passed to findTopLevelWindowAtScreen so it will walk the window list
until it finds the appropriate window with a matching id and return it.

 - if lastFoundWindow would have been unset, the window itself would have
 been returned by findTopLevelWindowAtScreen.

lastFoundWindow being unset doesn't change anything. lastFoundWindow is
only a cache of the last found window. That's all. lastFoundWindow is
only used when lastFoundWindow-id match the id we're searching for.

 
 That's a behaviour change which shouldn't be caused by an optimization. 
 Maybe a better fix for that would be to track the last found top level 
 window and last found window separately (that's what the attached
 patch does).

We could keep a separate cache for top-level windows but they are not
searched for as often so I don't think it will make much of a
difference.

I think I just found the bug that is causing the problem.
findWindowAtScreen and findTopLevelWindowAtScreen are fine. However,
findTopLevelWindowAtDisplay is broken. It shouldn't check
lastFoundWindow. I pushed out changes that will fix this problem and
clean up findTopLevelWindowAtScreen so it will be a bit easier to
understand how lastFoundWindow is used.

Let me know if this fixed your problem.

-David

___
compiz mailing list
compiz@lists.freedesktop.org

Re: [compiz] [ANNOUNCE] compiz-0.5.2

2007-08-07 Thread David Reveman
On Tue, 2007-08-07 at 20:57 +0200, Dennis Kasprzyk wrote:
 Am Dienstag 07 August 2007 20:44:12 schrieb David Reveman:
  On Tue, 2007-08-07 at 19:35 +0200, dragoran wrote:
   On 8/3/07, David Reveman [EMAIL PROTECTED] wrote:
   A new compiz release 0.5.2 is now available
  
   any chance for a 0.6.0 release before 2007/08/28 ?
   (fedora 8 feature freeze)
 
  I wont have time but we could create a 0.6 branch for this if a some
  people are interested in working on it.
 
  -David
 
  ___
  compiz mailing list
  compiz@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/compiz
 
 
 Create a 0.6 branch out of the 0.5.2 (without xcb) version please.

Yes, I don't think we want the xcb dependency if we're doing a 0.6
branch today.

-David

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


[compiz] [ANNOUNCE] compiz-0.5.2

2007-08-03 Thread David Reveman
A new compiz release 0.5.2 is now available from:

http://xorg.freedesktop.org/archive/individual/app/compiz-0.5.2.tar.gz

which can be verified with:


http://xorg.freedesktop.org/archive/individual/app/compiz-0.5.2.tar.gz.sha1
0d0a4a39bfbe0ada770d9206b7a1b6b443c53c29  compiz-0.5.2.tar.gz


http://xorg.freedesktop.org/archive/individual/app/compiz-0.5.2.tar.gz.sha1.asc
(signed by David Reveman)

  Additionally, a git clone of the source tree:

git clone git://git.freedesktop.org/git/xorg/app/compiz

will include a signed compiz-0.5.2 tag which points to a commit named:
65ccbbd18c5028c610042dd552eec0de3a41bde8

which can be verified with:
git verify-tag compiz-0.5.2

and can be checked out with a command such as:
git checkout -b build compiz-0.5.2


WHAT'S NEW
==

Better support for multiple X-screens.

XML-based meta-data system for handling of various kinds
for meta-data like plugin descriptions, default option
values, etc.

Major improvements to option initialization based on the
new meta-data system.

Logging framework.

Support for configurable button layout in metacity themes
has been added to gtk-window-decorator.

Glib plugin that allows plugins that use the glib main
loop to integrate properly with the compiz main loop
without waking up periodically to check for pending
events.

Plugin plugins that make it possible to adjust and extend
the behavior of existing plugins through new plugins.

More dynamic handling of output devices, which allows the
output device configuration used when rendering to be
changed between frames.

Transparency support in cube plugin.

Introspection support in dbus plugin.


-David


Changes since compiz-0.5.0:
Bellegarde Cedric:
  Fix placement mode option.

Cedric:
  Fix typo in matching code.

Daniel Nylander:
  Update swedish translation.

Danny Baumann:
  Check for active screen grabs before unsnapping a maximized window.
  Reflect minimum size hint when adding size changes.
  Add 'group-drag' as an allowed screen grab for edge flipping.
  Merge branch 'master' of git+ssh://[EMAIL PROTECTED]/git/xorg/app/compiz
  Avoid explicit comparison with FALSE constant
  Fix rectangle-in-range calculation for outputDeviceForGeometry.
  Another attempt at correctly fixing the calculations in 
outputDeviceForGeometry.
  Make gwd build without Metacity support.
  Added possibility to call updateWindowAttributes without requesting any 
stack changes.
  Raise windows whenever their fullscreen, above/below or maximization 
state changed.
  Merge branch 'master' of git+ssh://[EMAIL PROTECTED]/git/xorg/app/compiz
  Fix mem leaks
  Fix dangling comma in list writing.
  Some beautification.
  Fix stack corruption caused by an insufficient size of an allocated 
buffer.
  Fixed string length calculations.
  Bump ABIVERSION due to warpPointer() changes.
  Update decoration on map request before core handles the request.
  Added PlaceWindowProc function.
  Merge branch 'master' of git+ssh://[EMAIL PROTECTED]/git/xorg/app/compiz
  Added an Y viewport parameter to the function 
moveWindowToViewportPosition.
  Remove unneeded code.
  Update zoom plugin to use new metadata system.
  Update wobbly plugin to use new metadata system.
  Update water plugin to use new metadata system.
  Update video plugin to use new metadata system.
  Fix typo.
  Make all option info structures const.
  Update switcher plguin to use new metadata system.
  Update svg plugin to use new metadata system.
  Update screenshot plugin to use new metadata system.
  Update scale plugin to use new metadata system.
  Merge branch 'master' of git+ssh://[EMAIL PROTECTED]/git/xorg/app/compiz
  Fix some minor metadata errors.
  Merge branch 'master' of git+ssh://[EMAIL PROTECTED]/git/xorg/app/compiz
  First attempt to focus the window under the pointer if 'click to focus' 
is not enabled.
  Fix typo.
  Merge branch 'master' of git+ssh://[EMAIL PROTECTED]/git/xorg/app/compiz
  Make constrainNewWindowSize return TRUE whenever constraining was applied.
  Don't issue ungrab notify before server side processing is finished.
  Fix typo.
  Track the first grabbed window, not the last one.
  Merge branch 'master' of git+ssh://[EMAIL PROTECTED]/git/xorg/app/compiz
  Don't make fill colors entirely transparent by default.
  Notify other clients of window resizing.
  The fullscreen output is not a real screen output, reflect that in its id.
  Convert usage of restricted string options to int descriptions in scale 
plugin.
  Convert usage of restricted string options to int descriptions in wobbly 
plugin.
  Fix option type for int description options.
  Rename scale's displayPrivateIndex to scaleDisplayPrivateIndex so that 
wrapping plugins

Re: [compiz] Couldn't activate plugin 'rotate'

2007-08-02 Thread David Reveman
On Thu, 2007-08-02 at 17:04 +0200, Dennis Kasprzyk wrote:
 Am Dienstag, 31. Juli 2007 19:45:19 schrieb David Reveman:
  On Tue, 2007-07-31 at 00:19 +0200, Dennis Kasprzyk wrote:
   Am Montag, 30. Juli 2007 16:28:27 schrieben Sie:
On Sun, 2007-07-29 at 20:31 +0200, Dennis Kasprzyk wrote:
 Am Samstag, 28. Juli 2007 00:24:10 schrieben Sie:
  On Mon, 2007-07-16 at 23:44 +0200, Dennis Kasprzyk wrote:
   Am Montag 16 Juli 2007 20:49:32 schrieb Kresimir Kukulj:
First, I would like to compliment you all for a great work you
put in developing compiz. I have it running for more that a
month and it did not crash. Stability is very good. Great work!
   
Today I updated compiz from git tree and found that rotate
generates this error:
   
compiz (core) - Error: Couldn't activate plugin 'rotate'
  
   The problem is that the load after cube got removed from the
   rotate metadata. I reverted it now.
   The ccs configuration system doesn't handle require rules
   automatically as load after rules. There is also a case where
   we have a require and a load before rule for the same plugin
   (3d).
 
  I don't think it should be allowed to ask for some plugin to be
  required but loaded after. Plugins that do this should be fixed so
  they don't have to ask for such a relationship and the load after
  cube information in the rotate metadata should be removed again.
 
  -David

 We removed the whole plugin order system from core to make it more
 flexible. That's the reason why we shouldn't mix now requirements
 with relations and limit the functionality. But if you want I can
 remove the load after cube information in the rotate metadata and
 add this to the internal configuration system metadata file.
   
We're not limiting functionality by having requirements also implicitly
mean that the plugin must be loaded after. We're just making the
existing tags make more sense. If you like some metadata information
that indicate that a plugin must be loaded after, then you can always
add that through a new tag.
   
The reason I like to have the requirement tag also implicitly mean
load after is that a plugin that requires another plugin to be loaded
after seems to be designed poorly and I think we should do our best not
to encourage that. However, you're welcome to prove me wrong and show
that requiring that another plugin is loaded after necessarily isn't
bad design, in which case I'm happy to allow the requirement tag not to
implicitly mean load after.
   
-David
  
   The problem is here that we have a plugin (3d) that has to be loaded
   before cube but also requires cube. It needs to be loaded before cube
   because it's paintTransformedOutput needs to be called for each cube
   face, but it also needs some variables from cube to work correctly. To
   get into cube it uses then init/finiPluginForDisplay.
  
   So we have a plugin that requires another plugin but needs to be loaded
   before that plugin. That is the reason why I don't like requirement tag
   also implicitly mean load after.
 
  cube plugin should provide hooks that allow 3d to be loaded after cube
  and hook in where appropriate and not use paintTransformedOutput.
 
  -David
 
 Maybe we could try to make the plugin plugins system independent of the 
 plugin 
 loading order. My idea is to provide two additional wrapable functions 
 pluginLoaded( CompPlugin *p, CompDisplay *d) and preparePluginUnload( 
 CompPlugin *p, CompDisplay *d). pluginLoaded would be called if a plugin has 
 been fully initialized (display/screens/windows) and preparePluginUnload 
 before compiz calls the fini(window|screen|display) functions of a plugin. 
 
 With such a system a plugin plugin could be loaded before it's main plugin 
 gets loaded and the initialization of the plugin connections would be done 
 in the pluginLoaded/preparePluginUnload functions. This would also increase 
 the flexibility for plugins that offer some functionality but if another 
 plugin gets loaded it hooks into it and provides more features.

It seems over-engineered to me. The simple stack based plugin system
that we have today seems sufficient. I did some experimenting with a
non-stack based plugins system when I first started writing compiz and
that stacked based solution proved much easier to maintain, especially
as long as we allow wrapping of function pointers. Wrapping of function
pointers and a non-stack based plugins system doesn't go well.

 
 Maybe we should also provide a convenience function to hook into other 
 plugins. I'm thinking about something like Bool getPluginPrivateIndex( 
 CompDisplay *, char * name, int abi_version, int * privateIndex);

Yes, this should definitely be done. I'd also like to move the core ABI
version into an option and have the plugins check this in much the same
way

Re: [compiz] [R300] high Xorg process CPU usage

2007-08-02 Thread David Reveman
On Mon, 2007-07-30 at 10:54 +0200, Michel Dänzer wrote:
 On Fri, 2007-07-27 at 23:45 -0400, Andrew J. Barr wrote:
  I am trying out the Compiz Fusion stuff on my PowerBook G4 (RV350) and
  I have the aiglx-zero-copy-tfp patches from here[0] on Mesa 6.5.2,
  xorg-server 1.3, and xf86-video-ati 6.6.191. I notice that the Xorg
  process has a high level of CPU utilization (higher than with metacity
  or vanilla compiz), but the graphics aren't insanely choppy like they
  are without aiglx-zero-copy-tfp. Is this normal?
 
 git-bisecting compiz pointed me to this being related to the translucent
 cube feature, and I discovered that
 the /apps/compiz/plugins/cube/screen0/options/inactive_opacity gconf key
 was set to 90. Changing it to 100 restores sanity for me. Not sure how
 it came to be less than 100 in the first place, but if it can happen by
 default that should probably be fixed.

I haven't been able to reproduce this and I can't see anything
suspicious by looking at the code.

-David

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


Re: [compiz] Dual-screen compiz mostly working

2007-08-02 Thread David Reveman
On Wed, 2007-08-01 at 12:03 +0200, Michel Dänzer wrote:
 On Wed, 2007-08-01 at 07:50 +, Mick Semb Wever wrote:
  
   - my second screen doesn't render properly. Compiz events cause it to 
  redraw but application events do not cause a redraw!
  This is a showstopper for me so i'm still using metacity when in dual-
  screen setup.
 
 That sounds weird, can you create screenshots or something to illustrate
 the problem?
 
 
   - my screens must be vertically positioned. Compiz doesn't render the 
  full width when the screens are side by side. Even when vertically 
  position i cannot have the second screen at 1600x1400 for the same reason.
  Is this a limitation of compiz? Are there plans to fix/improve it?
 
 This is most likely due to the coordinate limits of the hardware 3D
 engine. That could be worked around in the Mesa driver, but there would
 still be the texture size limit others pointed out, and that can't be
 worked around in the drivers with the current
 GLX_EXT_texture_from_pixmap API so it would have to worked around by
 different means by compiz.
 
 
   - my fonts are not nearly as clean and crisp under compiz as they are 
  under metacity. It's like the fonts are thick and fuzzy under compiz. 
 
 I've seen this before, I think it happened
 when /apps/compiz/general/allscreens/options/texture_filter is set to 2
 (maybe also 1)
 and /apps/compiz/plugins/cube/screen0/options/inactive_opacity was set
 to less than 100 (which I think is a bad idea in general).

compiz will always use NEAREST filter when windows aren't transformed
and the texture_filter option will only change the filter that is used
for transformed windows. Anyhow, if the BILINEAR filter happens to be
used when a window isn't transformed, a decent OpenGL implementation
should provide BILINEAR texture filtering that is accurate enough to not
produce a visible difference between NEAREST and BILINEAR filters in the
non-transformed case.

-David

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


Re: [compiz] Couldn't activate plugin 'rotate'

2007-07-30 Thread David Reveman
On Sun, 2007-07-29 at 20:31 +0200, Dennis Kasprzyk wrote:
 Am Samstag, 28. Juli 2007 00:24:10 schrieben Sie:
  On Mon, 2007-07-16 at 23:44 +0200, Dennis Kasprzyk wrote:
   Am Montag 16 Juli 2007 20:49:32 schrieb Kresimir Kukulj:
First, I would like to compliment you all for a great work you put in
developing compiz. I have it running for more that a month and it did
not crash. Stability is very good. Great work!
   
Today I updated compiz from git tree and found that rotate generates
this error:
   
compiz (core) - Error: Couldn't activate plugin 'rotate'
  
   The problem is that the load after cube got removed from the rotate
   metadata. I reverted it now.
   The ccs configuration system doesn't handle require rules automatically
   as load after rules. There is also a case where we have a require and
   a load before rule for the same plugin (3d).
 
  I don't think it should be allowed to ask for some plugin to be required
  but loaded after. Plugins that do this should be fixed so they don't
  have to ask for such a relationship and the load after cube
  information in the rotate metadata should be removed again.
 
  -David
 
 We removed the whole plugin order system from core to make it more flexible. 
 That's the reason why we shouldn't mix now requirements with relations and 
 limit the functionality. But if you want I can remove the load after cube
 information in the rotate metadata and add this to the internal configuration 
 system metadata file.

We're not limiting functionality by having requirements also implicitly
mean that the plugin must be loaded after. We're just making the
existing tags make more sense. If you like some metadata information
that indicate that a plugin must be loaded after, then you can always
add that through a new tag.

The reason I like to have the requirement tag also implicitly mean load
after is that a plugin that requires another plugin to be loaded after
seems to be designed poorly and I think we should do our best not to
encourage that. However, you're welcome to prove me wrong and show that
requiring that another plugin is loaded after necessarily isn't bad
design, in which case I'm happy to allow the requirement tag not to
implicitly mean load after.

-David

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


Re: [compiz] Read commandline defaults from a file?

2007-07-28 Thread David Reveman
On Sat, 2007-07-28 at 10:46 +0200, dragoran wrote:
 David Reveman wrote:
  On Thu, 2007-07-12 at 10:42 +0200, dragoran wrote:

  Right now compiz has hardcoded defaults for command line options like 
  direct vs indirect rendering etc.
  Because most users use scripts like gnome-wm to start compiz its not 
  that easy for them to change this options. My solution would be to have 
  a file (~/.compizrc) where the default values are saved. So that compiz 
  checks for the file first and pic up this values. If no file is found it 
  fails back to the hardcoded one.
  Would this cause any problems? If not I can implement it and send patches.
  
 
  We should just make all these command line options real options with
  metadata attached to them. That way you can easily patch the metadata
  files to change the default values for them or override them by putting
  you're own metadata files in ~/.compiz.
 

 but can settings like direct/indirect rendering be set this way?

Sure, we probably don't want to go through the trouble of making such an
option adjustable after initialization but that's not a problem, it can
be read-only.

-David

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


Re: [compiz] [PATCH] Resize plugin not finishing resizing

2007-07-27 Thread David Reveman
On Sat, 2007-06-23 at 19:53 +0200, Bellegarde Cedric wrote:
 In current git, when starting a resize and finish it without any change, 
 resizeTerminate() need to do a resizeDamageRectangle().
 
 This patch fix the issue...

ok, should be fixed in head now.

thanks,

-David

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


Re: [compiz] [PATCH] Always use mipmaps in cube plugin

2007-07-27 Thread David Reveman
On Wed, 2007-06-27 at 01:35 +0200, Bartosz Taudul wrote:
 Currently, the cube plugin uses mipmapping only when cube is unfolded.
 When the cube is rotated, mipmaps are not used, which leads to ugly look
 of textures.

Yeah, using mipmap filtering in those cases should be optional. I've
avoided it so far because it adds a significant overhead compared to
bilinear filtering as the mipmap levels needs to be updated every time a
texture changes.

 
 The attached patch fixes this. This leads to another kind of artifacts,
 which are fixable with anisotropic filtering.
 
 http://team.pld-linux.org/~wolf/aniso.png
 The leftmost image is the current state of cube plugin. The center image
 is with mipmaps enabled. The rightmost is with mipmaps and anisotropic
 filtering.

Sure, anisotropic filtering should be added as well if we allow mipmaps
to be used in cases where it makes a difference. So far mipmap filtering
have only been used in cases where it doesn't make any difference.

It might make sense to add this as a global filter method instead. E.g.
used automatically when core texture_filter is set Best.

-David

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


Re: [compiz] [PATCH] Correct linking for png-plugin

2007-07-27 Thread David Reveman
On Sun, 2007-07-08 at 22:14 +0200, Hanno Böck wrote:
 If compiled with LDFLAGS=-Wl,--as-needed, compiz fails to correctly link 
 the 
 png-plugin.
 
 Attached patch fixes it (though I don't know if this is the correct way to do 
 this in autotools).

I made some changes that should have taken care of this. Let me know if
it's still a problem.

-David

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


Re: [compiz] video plugin update

2007-07-24 Thread David Reveman
On Fri, 2007-07-13 at 10:32 +1000, Christopher Halse Rogers wrote:
 On 7/12/07, David Reveman [EMAIL PROTECTED] wrote:
  I had to update the video plugin interface slightly to fix some bugs.
  I've attached an updated mplayer patch.
 
 Just to check, since I'm interested in applying this to Ubuntu's
 mplayer, but this patch is still not ready for upstream mplayer,
 right?  I remember the last such thread ending in we should probably
 wait for the retained-mode interface - do the same comments apply
 here?
 
 In a related question, any news on such an interface? :)

The communication mechanism will be slightly updated but the mplayer
patch will look much like it does today unless someone wants to put more
work into it.

Upstream mplayer might want to put this in a compiz-xv output backend
rather than in the xv backend itself but that's just some cut-n-paste
work that anyone could do...

-David

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


Re: [compiz] [PATCH] Case insensitive matching for the regex plugin

2007-07-11 Thread David Reveman
On Wed, 2007-06-20 at 14:53 +0200, Danny Baumann wrote:
 Hi,
 
 I have created an addition to the regex plugin that allows case
 insensitive matching for title/class/name/role. To enable the case
 insentive matching, I chose to prepend an 'i' before the tag (ititle=,
 iclass=, ...). The patch is obviously attached ;-)
 
 Are there any objections against putting this code in?

No, but instead of adding a second set of tags maybe we should allow the
expressions to end with /i for case insensitive matching like perl.
I'm ok with either solution and not really sure which one I actually
prefer.

-David

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


Re: [compiz] KWD Maximize bug and crash

2007-07-11 Thread David Reveman
On Sun, 2007-06-24 at 18:58 +0100, Diogo Ferreira wrote:
 Hi, KWD is crashing regularly here when closing a window (especially 
 mplayer), I've attached the debugging information.
 
 Also, there's this bug when windows are maximized, in some themes the 
 decoration is drawn incorrectly, sometimes it's not drawn at all, I'm 
 not sure if it's a known bug.

I've seen this bug before and the debugging information is unfortunately
not that useful in this case. If you could reproduce this when running
kwd in valgrind, that might be more useful.

Use something like:

valgrind --tool=memcheck kde-window-decorator 

in case you haven't used valgrind before..

-David

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


Re: [compiz] Focus problem for shaded windows

2007-07-11 Thread David Reveman
On Mon, 2007-06-25 at 15:35 +0200, Danny Baumann wrote:
 Hi,
 
 today, I noticed a problem in focus handling for shaded windows which is
 pretty easy to reproduce:
 
 - Disable Click to focus
 - Shade a window
 - Hover another window
 - Hover back to the window frame of the shaded window
 - Press Ctrl+Alt+S
 
 Expected behaviour would be that the shaded window is unshaded. What
 happens is that the last active window is shaded.
 
 I investigated this a bit and found the cause for this behaviour, but
 wasn't able to work out a proper fix for that:
 - The function shade() uses d-activeWindow to determine the window to
 (un)shade via the window option.
 - d-activeWindow is set from the FocusIn event handler, but only if
 w-managed is set for the window which is hovered or whose frame is
 hovered
 - As w-managed is unset in the UnmapNotify handler (and so after a
 window is shaded), hovering a shaded window frame does not set
 d-activeWindow to that window.
 
 Any idea regarding that one?

w-managed should not be unset when getting an UnmapNotify event cause
by shading. The window is still managed by compiz while being shaded.
w-pendingUnmaps should be greater than 1 when a window is shaded but I
guess that's broken somehow...

-David

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


Re: [compiz] Features for image loader plugins

2007-07-11 Thread David Reveman
On Thu, 2007-07-12 at 01:41 +0200, Patrick Niklaus wrote:
 Hi,
 
 I just had a look at the old beryl plugin tree and found out that it
 originally was imagemime:image/png (for using mime types as
 identification) and imageext:png (of file extension identification).
 
 While porting the features to metadata imagemime has become
 imageext (probably just a little cp mistake).
 
 So actually it makes sense to have a mime-type and extension identification.
 
 I attached an updated patch which should fix the typo.

applied.

thanks,

-David

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


Re: [compiz] window walking interface

2007-06-21 Thread David Reveman
On Tue, 2007-06-12 at 19:27 +0200, Dennis Kasprzyk wrote:
 Am Dienstag 12 Juni 2007 14:52:53 schrieb Danny Baumann:
  Hi,
 
Thanks for putting these changes in git, it indeed makes more sense
than the way I did it first.
I re-made the transparent cube patches to work now with this new
interface. Tell me what you think about it.
 
  I re-did Roi's patches for latest cube plugin changes and coding style.
 
  Attached are the following:
   0001-cube-painting-order.txt:
  
   This is good to go in if you're able to help fix any regressions that
   may appear. There's some coding style changes that need to be made
   before I can let this go in, though.
  
   Please replace all C++ comments with C comments, keep declarations at
   the beginning of each scope and make sure lines are no longer than 80
   columns.
 
  This one is replaced by
  0001-Improve-cube-paint-order-calculations.patch.
 
   0002-plugin-events.txt:
  
   This is not OK. Plugin events should not be used at all now that 3d and
   rotate plugins can hook into the cube plugin directly. Just add whatever
   hooks that are appropriate to the cube plugin.
 
  Replaced by 0002-Added-rotation-state.patch. With that patch, there is a
  rotation state variable in CubeScreen that is written by the plugin
  rotating it, rotate in the current case.
 
   0003-transparent-cube.txt:
  
   Looks OK. The same coding style changes need to be made here too,
   though.
 
  Replaced by 0003-Add-cube-transparency.patch (which adds the cube
  transparency) and
  0004-Added-option-to-enable-cube-transparency-only-on-but.patch (option
  to enable transparency only on 'manual' rotation).
 
  Are these patches ok to go in?
 
  Regards,
 
  Danny
 
 Hi,
 
 here are some additional transcube patches.
 
 0005:
 Fixes the FrontToBack calculation for inside cube mode.
 
 0006:
 Makes the checkFTB function wrapable to allow other plugins like cubereflex 
 to 
 change the result of this function.

Yep, this is what I had mind for proper integration of the 3d plugin
functionality.

 
 0007:
 Separates paintTopBottom into individual functions and fixes normals and 
 painting order of the top and bottom caps.
 
 0008:
 Adds a wrapable paintInside function to allow other plugins to render 
 something inside of the transparent cube.
 

All good. Please commit.

Thanks.

-David

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


Re: [compiz] window walking interface

2007-06-21 Thread David Reveman
On Tue, 2007-06-12 at 21:16 +0200, Dennis Kasprzyk wrote:
 Am Dienstag 12 Juni 2007 19:27:41 schrieb Dennis Kasprzyk:
  Am Dienstag 12 Juni 2007 14:52:53 schrieb Danny Baumann:
   Hi,
  
 Thanks for putting these changes in git, it indeed makes more sense
 than the way I did it first.
 I re-made the transparent cube patches to work now with this new
 interface. Tell me what you think about it.
  
   I re-did Roi's patches for latest cube plugin changes and coding style.
  
   Attached are the following:
0001-cube-painting-order.txt:
   
This is good to go in if you're able to help fix any regressions that
may appear. There's some coding style changes that need to be made
before I can let this go in, though.
   
Please replace all C++ comments with C comments, keep declarations at
the beginning of each scope and make sure lines are no longer than 80
columns.
  
   This one is replaced by
   0001-Improve-cube-paint-order-calculations.patch.
  
0002-plugin-events.txt:
   
This is not OK. Plugin events should not be used at all now that 3d and
rotate plugins can hook into the cube plugin directly. Just add
whatever hooks that are appropriate to the cube plugin.
  
   Replaced by 0002-Added-rotation-state.patch. With that patch, there is a
   rotation state variable in CubeScreen that is written by the plugin
   rotating it, rotate in the current case.
  
0003-transparent-cube.txt:
   
Looks OK. The same coding style changes need to be made here too,
though.
  
   Replaced by 0003-Add-cube-transparency.patch (which adds the cube
   transparency) and
   0004-Added-option-to-enable-cube-transparency-only-on-but.patch (option
   to enable transparency only on 'manual' rotation).
  
   Are these patches ok to go in?
  
   Regards,
  
   Danny
 
  Hi,
 
  here are some additional transcube patches.
 
  0005:
  Fixes the FrontToBack calculation for inside cube mode.
 
  0006:
  Makes the checkFTB function wrapable to allow other plugins like cubereflex
  to change the result of this function.
 
  0007:
  Separates paintTopBottom into individual functions and fixes normals and
  painting order of the top and bottom caps.
 
  0008:
  Adds a wrapable paintInside function to allow other plugins to render
  something inside of the transparent cube.
 
  Regards,
  Dennis
 
 This is an additional patch that compines the two orientation checking 
 function into one. It also disables the orientation checking functions for 
 the inside cube mode. In inside cube mode some points of the orientation 
 checking function get projected outside of the visible range and this 
 produces wrong results.

Sounds good. You know the related code better than me so feel free to
make adjustments as you like.

-David

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


Re: [compiz] new release?

2007-06-21 Thread David Reveman
On Thu, 2007-06-07 at 09:53 +0200, dragoran wrote:
 It has been a while since 0.4.0 and 0.5.0 has been released...
 any plans for a new release (0.6.0/0.7.0) in the near feature?

I think we should try to make one or two developer releases before a
stable 0.6 release. 0.5.2 within a week or so sounds good to me.

-David

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


Re: [compiz] [PATCH] fixes for =libwnck-2.19.3

2007-06-21 Thread David Reveman
On Thu, 2007-06-07 at 10:45 -0500, [EMAIL PROTECTED] wrote:
 Hi.
 
 libwnck broke API with the 2.19.3 release.  This effects compiz as the
 WNCK_WINDOW_MODAL_DIALOG is no longer supported by it.  The attached patch 
 allows compiz to
 build against the library.

Thanks.

I made it check for libwnck 2.19.4, as we're already checking for that
version. I hope that's good enough.

-David

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


Re: [compiz] Problem with new cube and scale with ini

2007-06-21 Thread David Reveman
On Fri, 2007-06-08 at 11:44 +0100, Mike Dransfield wrote:
 I think I have a slight problem with the new hookable plugins
 and the ini plugin.
 
 I haven't looked into it too much, but the plugins use an option to
 store their abi version.  This value is stored so that when the cube/scale
 plugins are updated it will not be changed and things will not work.

I'm not sure I understand. In what way doesn't it work? The cube/scale
plugins should always be able to set the abi option properly,
independent of how options are stored.

 
 Do we need some sort of flag to tell ini not to save these options?  I
 assume that it is OK for gconf because the option is not stored
 because it is not added to the schema.

There's a read-only metadata hint that should be sufficient for this.

 
 The other option would be to get the cube plugin to set its options
 when they change internally, but ideally these things shouldn't
 be written to disk at all.

-David

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


Re: [compiz] [PATCHES] Fixes for java apps and firefox in scale, switcher and wobbly

2007-06-07 Thread David Reveman
On Thu, 2007-06-07 at 01:17 +0200, Treviño wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 David Reveman ha scritto:
  On Wed, 2007-06-06 at 19:42 +0200, Treviño wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  I've made these patches that basically, make the java apps and firefox
  items well being recognized by some compiz plugins (scale, switcher
  and wobbly), I don't know if those can be considered workaround, but
  this helps in using your desktop tools.
 
  Basically java apps are seen as:
   * name=sun-awt-X11-XFramePeer (default windows = Normal)
   * name=sun-awt-X11-XDialogPeer (secondary - child - dialogs = Dialog)
   * name=sun-awt-X11-XWindowPeer (Menus, tooltip, OSD  co...)
 
  While firefox items as:
   * type=Normal  override_redirect=1
 
  These are all workarounds for apps that are not setting window hints
  correctly and I think most people agree that it's not a good idea to
  adjust our default option values for this. Feel free to add the
  workarounds to the compiz.org wiki, though.
 Yeah, I suspected they were workarounds, but I don't think that either
 java or firefox will release fixes soon, however you're right not
 including them upstream, but I think that's a good thing for
 distributiors waiting for official fixes, isn't it!?

Yes, this information is very useful for distributors.

-David

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


Re: [compiz] [PATCH] Use X-Fleur cursor on move

2007-06-06 Thread David Reveman
On Wed, 2007-06-06 at 18:56 +0200, Treviño wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hi all, I'm Treviño (AKA Trevinho, AKA 3v1n0, AKA trevi55 ;P) it's my
 first message here, also if I'm reading the ML from the archives since
 long time...
 I maintened a beryl-svn (then git) repository, and I'm planning to do
 the same as soon as I can for compiz-git (BTW, some pre-release
 packages are at http://tinyurl.com/396up9), however for doing so I'm
 applying some patches to compiz; mostly of them are the ones already
 posted here or taken from the ubuntu gutsy source package, but I've
 made some of them too.
 
 The first one, that I've attached here is a patch for the move plugin
 to make it show the X-fleur mouse cursor while moving a windows
 instead of the X-plus.
 This is needed to use the same cursor used by the most common Desktop
 Environments like KDE and GNOME (I don't know in xfce and others).
 
 Simply take the patch and apply it (it's only 1 line); then you won't
 have anymore the bad (imho) + cursor ;)

OK, we'll use the fleur cursor for now. We'll have to add a cursor
option to the move plugin if someone isn't happy with this new cursor,
though.

-David

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


Re: [compiz] [PATCHES] Fixes for java apps and firefox in scale, switcher and wobbly

2007-06-06 Thread David Reveman
On Wed, 2007-06-06 at 19:42 +0200, Treviño wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 I've made these patches that basically, make the java apps and firefox
 items well being recognized by some compiz plugins (scale, switcher
 and wobbly), I don't know if those can be considered workaround, but
 this helps in using your desktop tools.
 
 Basically java apps are seen as:
  * name=sun-awt-X11-XFramePeer (default windows = Normal)
  * name=sun-awt-X11-XDialogPeer (secondary - child - dialogs = Dialog)
  * name=sun-awt-X11-XWindowPeer (Menus, tooltip, OSD  co...)
 
 While firefox items as:
  * type=Normal  override_redirect=1

These are all workarounds for apps that are not setting window hints
correctly and I think most people agree that it's not a good idea to
adjust our default option values for this. Feel free to add the
workarounds to the compiz.org wiki, though.

I suggest that you submit java and firefox bug reports for this if you
haven't already. That way it might get fixed where it's supposed to be
fixed.

-David

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


Re: [compiz] status of input redirection

2007-06-05 Thread David Reveman
On Tue, 2007-06-05 at 00:17 +0300, Daniel Stone wrote: 
 On Mon, Jun 04, 2007 at 05:06:20PM -0400, David Reveman wrote:
  On Sat, 2007-06-02 at 04:29 +0300, Daniel Stone wrote:
   On Fri, Jun 01, 2007 at 03:47:17PM -0400, David Reveman wrote:
+   switch (events[i].u.u.type) {
+   case MotionNotify:
+   case ButtonPress:
+   case ButtonRelease:
+   case KeyPress:
+   case KeyRelease:
+   case EnterNotify:
+   case LeaveNotify:
   
   Hi,
   This needs to be aware of Xi events.
  
  Yea, I forgot about that. Will the attached patch work or are those
  device events not using the keyButtonPointer structure?
 
 Unfortunately, they're not using keyButtonPointer, and you can't put it
 in a case, as the event numbers are non-constant.  They use
 deviceKeyButtonPointer, but you also need to check deviceValuator.  See
 dix/getevents.c, and mi/mieq.c.

I've adjusted the patch for deviceKeyButtonPointer. Like in my previous
patch, device events are checked for in the default so that they are not
constant should already be handled fine. Not sure exactly what to do
about deviceValuator events yet.

-David
--- a/dix/events.c
+++ b/dix/events.c
@@ -4686,8 +4686,9 @@ WriteEventsToClient(ClientPtr pClient, int count, xEvent *events)
 
 for (i = 0; i  count; i++)
 {
-	WindowPtr pWin;
-	int	  x, y, dx, dy;
+	deviceKeyButtonPointer *deviceEvent;
+	WindowPtr	   pWin;
+	int		   x, y, dx, dy;
 
 	switch (events[i].u.u.type) {
 	case MotionNotify:
@@ -4720,6 +4721,34 @@ WriteEventsToClient(ClientPtr pClient, int count, xEvent *events)
 		events[i].u.keyButtonPointer.eventY += dy;
 	}
 	break;
+	default:
+	if (events[i].u.u.type == DeviceMotionNotify  ||
+		events[i].u.u.type == DeviceButtonPress	  ||
+		events[i].u.u.type == DeviceButtonRelease ||
+		events[i].u.u.type == DeviceKeyPress	  ||
+		events[i].u.u.type == DeviceKeyRelease)
+	{
+		deviceEvent = (deviceKeyButtonPointer *) events[i];
+
+		pWin = LookupIDByType (deviceEvent-event, RT_WINDOW);
+		if (pWin)
+		{
+		x = deviceEvent-root_x;
+		y = deviceEvent-root_y;
+
+		CompositeXYScreenToWindowRootCoordinate (pWin, x, y,
+			 x, y);
+
+		dx = x - deviceEvent-root_x;
+		dy = y - deviceEvent-root_y;
+
+		deviceEvent-root_x  += dx;
+		deviceEvent-root_y  += dy;
+		deviceEvent-event_x += dx;
+		deviceEvent-event_y += dy;
+		}
+	}
+	break;
 	}
 }
 #endif
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz


Re: [compiz] A little patch to make scale's show-desktop behaviour optional

2007-06-05 Thread David Reveman
On Sat, 2007-06-02 at 23:25 -0400, Quinn Storm wrote:
 This particular behaviour drives me nuts, its so easy to accidentally click 
 on 
 desktop during scale and then all of your windows get minimized, which is no 
 fun.  This little patch just makes this optional, leaving the default to be 
 the normal behaviour.

Applied. Thanks.

-David

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


Re: [compiz] A little patch to make scale's show-desktop behaviouroptional

2007-06-05 Thread David Reveman
On Tue, 2007-06-05 at 11:54 +0200, Andrea Volani wrote:
 Hi, I'm only a compiz user, but just a question:
 
 is possible to have scale plugin to undo the window expose just with a
 re-push the desktop corner, just like macos do. 
 I remember this happens in the early versions of compiz 
 Sometimes my mouse goes accidentally on the corner and i'll like to
 undo the scale by hitting the corner again.

This should now work OK for the non DnD case. DnD needs some additional
work.

-David

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


Re: [compiz] N_ macro

2007-06-05 Thread David Reveman
On Sun, 2007-06-03 at 15:37 +0100, Mike Dransfield wrote:
 I have just updated the place plugin to use integers
 rather than strings with restrictions (as per the other
 plugins).
 
 The only thing which is now using the N_ macro is
 windowTypeString which I think can be removed.
 I think some plugins may still be using this so I have
 not removed it just yet.
 
 Once this is gone it will be possible to remove the N_
 macro as well, is this OK?

Yep, please remove it and if all occurrences of string restrictions have
been removed from the FDO repo, string restrictions should also be
removed completely from the CompOptionRestriction union.

-David

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


Re: [compiz] Direct and Indirect: Difference in rendering quality

2007-06-05 Thread David Reveman
On Tue, 2007-06-05 at 18:01 +0100, Matt Russell wrote:
 Hi
 
 Why is the quality of scaled textures/objects using --indirect-rendering
 much worse than direct rendering? Also, vsync does not work with
 indirect-rendering.

Scaled texture quality problem might be caused by
GLX_EXT_framebuffer_object extension not being supported when using
indirect rendering. This means that mipmap filter can't be used with
pixmaps bound to textures.

GLX_SGI_video_sync extensions is used for vsync and that extension will
only work properly with direct rendering.

-David

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


Re: [compiz] window walking interface

2007-06-05 Thread David Reveman
On Tue, 2007-06-05 at 16:01 +0300, Roi Cohen wrote:
 Hi,
 
 Thanks for putting these changes in git, it indeed makes more sense
 than the way I did it first.
 I re-made the transparent cube patches to work now with this new interface.
 Tell me what you think about it.

0001-cube-painting-order.txt:

This is good to go in if you're able to help fix any regressions that
may appear. There's some coding style changes that need to be made
before I can let this go in, though.

Please replace all C++ comments with C comments, keep declarations at
the beginning of each scope and make sure lines are no longer than 80
columns.


0002-plugin-events.txt:

This is not OK. Plugin events should not be used at all now that 3d and
rotate plugins can hook into the cube plugin directly. Just add whatever
hooks that are appropriate to the cube plugin.


0003-transparent-cube.txt:

Looks OK. The same coding style changes need to be made here too,
though.

-David

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


Re: [compiz] status of input redirection

2007-06-04 Thread David Reveman
On Sun, 2007-06-03 at 05:26 +0200, Dennis Kasprzyk wrote:
 Am Freitag, 1. Juni 2007 21:47:17 schrieb David Reveman:
  On Fri, 2007-06-01 at 13:28 -0400, Kristian Høgsberg wrote:
   On 5/31/07, David Reveman [EMAIL PROTECTED] wrote:
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.
  
   Can we merge the server patch as is and punt on the pluggable picker
   idea for now?  I mean, can we do this in a way that lets the
   interested parties add this support in a second step without breaking
   backwards compatibility?  If that's doable, I don't think we need to
   block on the pluggable picker idea now.
 
  I've attached a new patch with a more appropriate change to
  WriteEventsToClient.
 
  I'm OK with merging the patch in it's current state. Pluggable pickers
  can definitely be added later without breaking backwards compatibility.
 
  There's a few things that needs to be improved but I think the current
  patch is good enough for common use in compositing managers.
 
  TODO:
 
  I've tried to move the event coordinate transformation into
  FixUpEventFromWindow, which means making copies of events in a lot of
  places as FixUpEventFromWindow is sometimes called multiple times with
  the same xEvent. However, I never got that to work correctly and I
  haven't had time to figure out exactly why yet.
 
  The pointer grab code might need some more work but the patch should of
  course not affect non-transformed input in any way.
 
  I think that transformed input of non top-level windows isn't working
  correctly. This should be easy to fix though, I just need to write a
  good test app.
 
  -David
 
 After playing with this patches I thought that maybe this interface could 
 also 
 be extended to some basic real input redirection. Instead of a mapping from 
 the transformed coordinate space to the real window coordinate space, 
 there could be an additional value, that tells the xserver to redirect and 
 transform the input from the transformed coordinate space to another window 
 coordinate space. With something like this we could realize something like 
 cloned windows in different stack positions (using input only windows and 
 the composite manager).
 
 I think about somethink like this:
 XCompositeSetTriangularCoordinateMesh(Display *dpy, Window source, Window 
 destination, XTriangle *triangle, int ntriangle);
 
 I don't know enough about the xserver internals to tell if something like 
 this 
 is possible, but I think that this could extend the range for possible 
 effects. 

It might be a good idea to add a destination window. It shouldn't be
very hard to implement. The destination window can't be an ancestor,
though.

-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

2007-06-01 Thread David Reveman
On Fri, 2007-06-01 at 08:22 +0800, Sam Spilsbury wrote:
 Does this mean that cube zoom will be implimented?
 I remember a while back it was implimented using switchers zoom
 functionality, probably not implimented the right way.
 
 3D still requires PAINT_WINDOW_FRONT_TO_BACK_MASK to work properly
 however. Is there a chance that anyone can get this and transcube
 fixed up?

PAINT_WINDOW_FRONT_TO_BACK_MASK is not going to be added but I
definitely like to see both the window elevation and translucent cube
functionality supported sometime soon. It should be a lot easier to get
this working properly now that the cube plugin can export any hooks we
find useful.

-David

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


Re: [compiz] status of input redirection

2007-06-01 Thread David Reveman
On Fri, 2007-06-01 at 13:28 -0400, Kristian Høgsberg wrote:
 On 5/31/07, David Reveman [EMAIL PROTECTED] wrote:
  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.
 
 Can we merge the server patch as is and punt on the pluggable picker
 idea for now?  I mean, can we do this in a way that lets the
 interested parties add this support in a second step without breaking
 backwards compatibility?  If that's doable, I don't think we need to
 block on the pluggable picker idea now.

I've attached a new patch with a more appropriate change to
WriteEventsToClient.

I'm OK with merging the patch in it's current state. Pluggable pickers
can definitely be added later without breaking backwards compatibility.

There's a few things that needs to be improved but I think the current
patch is good enough for common use in compositing managers.

TODO:

I've tried to move the event coordinate transformation into
FixUpEventFromWindow, which means making copies of events in a lot of
places as FixUpEventFromWindow is sometimes called multiple times with
the same xEvent. However, I never got that to work correctly and I
haven't had time to figure out exactly why yet.

The pointer grab code might need some more work but the patch should of
course not affect non-transformed input in any way.

I think that transformed input of non top-level windows isn't working
correctly. This should be easy to fix though, I just need to write a
good test app.

-David
--- a/composite/compalloc.c
+++ b/composite/compalloc.c
@@ -141,6 +141,7 @@ compRedirectWindow (ClientPtr pClient, WindowPtr pWin, int update)
 	cw-oldy = COMP_ORIGIN_INVALID;
 	cw-damageRegistered = FALSE;
 	cw-damaged = FALSE;
+	cw-pInputMesh = NULL;
 	pWin-devPrivates[CompWindowPrivateIndex].ptr = cw;
 }
 ccw-next = cw-clients;
--- a/composite/compext.c
+++ b/composite/compext.c
@@ -512,6 +512,45 @@ ProcCompositeReleaseOverlayWindow (ClientPtr client)
 return client-noClientException;
 }
 
+static int
+ProcCompositeSetTriangularCoordinateMesh (ClientPtr client)
+{
+CompWindowPtr cw;
+WindowPtr	  pWin;
+int		  n, status;
+
+REQUEST (xCompositeSetTriangularCoordinateMeshReq);
+REQUEST_AT_LEAST_SIZE (xCompositeSetTriangularCoordinateMeshReq);
+
+pWin = (WindowPtr) LookupIDByType (stuff-window, RT_WINDOW);
+if (!pWin || !pWin-parent)
+{
+	client-errorValue = stuff-window;
+	return BadWindow;
+}
+
+cw = GetCompWindow (pWin);
+if (!cw)
+{
+	client-errorValue = stuff-window;
+	return BadWindow;
+}
+
+n = (client-req_len  2) -
+	sizeof (xCompositeSetTriangularCoordinateMeshReq);
+if (n  (n % (sizeof (xTriangle) * 2)))
+	return BadLength;
+
+n /= sizeof (xTriangle);
+
+status = CompositeSetTriangularCoordinateMesh (client, pWin, n,
+		   (xTriangle *) stuff[1]);
+if (status)
+	return status;
+
+return client-noClientException;
+}
+
 int (*ProcCompositeVector[CompositeNumberRequests])(ClientPtr) = {
 ProcCompositeQueryVersion,
 ProcCompositeRedirectWindow,
@@ -522,6 +561,7 @@ int (*ProcCompositeVector[CompositeNumberRequests])(ClientPtr) = {
 ProcCompositeNameWindowPixmap,
 ProcCompositeGetOverlayWindow,
 ProcCompositeReleaseOverlayWindow,
+ProcCompositeSetTriangularCoordinateMesh
 };
 
 static int
@@ -646,6 +686,19 @@ SProcCompositeReleaseOverlayWindow (ClientPtr client)
 return (*ProcCompositeVector[stuff-compositeReqType]) (client);
 }
 
+int
+SProcCompositeSetTriangularCoordinateMesh (ClientPtr client)
+{
+int n;
+REQUEST(xCompositeSetTriangularCoordinateMeshReq);
+
+swaps (stuff-length, n);
+REQUEST_AT_LEAST_SIZE(xCompositeSetTriangularCoordinateMeshReq);
+swapl (stuff-window, n);
+SwapRestL (stuff);
+return (*ProcCompositeVector[stuff-compositeReqType]) (client);
+}
+
 int (*SProcCompositeVector[CompositeNumberRequests])(ClientPtr) = {
 SProcCompositeQueryVersion,
 SProcCompositeRedirectWindow,
@@ -656,6 +709,7 @@ int (*SProcCompositeVector[CompositeNumberRequests])(ClientPtr) = {
 SProcCompositeNameWindowPixmap,
 SProcCompositeGetOverlayWindow,
 SProcCompositeReleaseOverlayWindow,
+SProcCompositeSetTriangularCoordinateMesh
 };
 
 static int
--- a/composite/compint.h
+++ b/composite/compint.h
@@ -85,6 +85,21 @@ typedef struct _CompClientWindow {
 intupdate;
 }  CompClientWindowRec, *CompClientWindowPtr;
 
+typedef struct _CompTriangle {
+xTriangletri;
+xFixed_48_16 area;
+} CompTriangle;
+
+typedef struct _CompTriangleMap {
+CompTriangle parent;
+CompTriangle child;
+} CompTriangleMap;
+
+typedef struct _CompTriangularMesh {
+CompTriangleMap *map;
+int		nMap

Re: [compiz] Changing gconf-key/apps/compiz/plugins/water/allscreens/options/initiate_keydoes not work

2007-05-31 Thread David Reveman
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

2007-05-31 Thread David Reveman
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.

2007-05-31 Thread David Reveman
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] commit a50d2f9e0f66f445338eb5ad7361b48d48446b29 brokecompiz for me

2007-05-31 Thread David Reveman
On Sun, 2007-05-27 at 13:02 +0200, dragoran wrote: 
 Sam Spilsbury wrote:
  How are you launching compiz? If you are using GConf, then you need to
  launch compiz like this from now on : $ENVIRONMENT_ARGS compiz
  --replace --sm-disable --indirect-rendering glib gconf
 
 If I start it using this command it works. but when I let gnome-session 
 start it it doesn't.
 but this looks wrong anywhy...
 when a plugin depends on some other plugin compiz core should load the 
 plugin for it and not rely on the user to do it.

In a sane system, the user isn't launching compiz manually and launching
compiz with glib gconf arguments doesn't look more wrong to me than
launching it with just the gconf argument.

Plugin order is just a metadata detail that the core shouldn't be aware
of. I don't see any good reason for changing that.

-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

2007-05-31 Thread David Reveman
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

2007-05-31 Thread David Reveman
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

2007-05-31 Thread David Reveman
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

2007-05-31 Thread David Reveman
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


Re: [compiz] place plugin

2007-05-25 Thread David Reveman
On Fri, 2007-05-25 at 20:00 +0200, dragoran wrote:
 David Reveman wrote:
  That's a bug in the decoration plugin. It's not adjusting the position
  of windows properly when adding decorations to them. There were some
  issues before that made it a bit hard to fix this but I think it should
  be easy to fix in the current code.
 

 are you planning to fix this? or should I try to play with the code a 
 bit to see what can be done?

please go ahead and play with it.

-David

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


Re: [compiz] Window specific actions and edge buttons

2007-05-21 Thread David Reveman
On Fri, 2007-05-18 at 15:14 +0100, Mike Dransfield wrote:
 David Reveman wrote:
  On Wed, 2007-05-16 at 11:51 +0100, Mike Dransfield wrote:

  David Reveman wrote:
  
  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.


  OK - I did that for those two.
 
  I am just about to push out similar changes for close_window,
  minimize_window and maximize_window.  If they reduce some
  functionality then please let me know and I will write it so that
  it checks for an edge and only uses activeWindow then.
  
 
  This is likely not what you want when a button press triggered an action
  and it removes the possibility to remotely trigger those actions for
  specific windows.

 
 OK - I didn't think of that possibility.  I'll change it back to
 the old way.
 
 I would like to keep the ability to do both without breaking
 either method.  How about adding edge_window to the list of
 options which are sent?  If the action was edge+button then it
 would be set to the id of the edge window.  The window option
 could be set to active window in this case.

Yes, that sounds pretty good. Maybe it's better to add a more general
event_window to the list instead.

 
  For scale_group and such I think you want to only use the active window
  if the provided window is an edge window or a maybe a window that isn't
  managed. I don't see any reason why close_window, etc should be changed.

 
 I think it is a useful accessibility feature, there are lots of
 people who find it hard to click precisely on the decorator
 buttons.  Pushing to the corner and clicking is easier because
 it does not require such fine motor skills.

OK, I didn't get that this was the reason you wanted to change those
functions. Yes, it seems useful. Adding an event_window argument will
allow those functions to work with screen edges without modifying them.

-David

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


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

2007-05-21 Thread David Reveman
On Fri, 2007-05-18 at 15:17 +0100, Mike Dransfield wrote:
 David Reveman wrote:
  On Tue, 2007-05-15 at 19:23 +0100, Mike Dransfield wrote:

  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.
  
 
  Yes, I think we should load/initialize and read the metadata from
  plugins. Some minor changes need to be made to the plugin system before
  we're able to load and initialize a plugin without activating it but it
  should be easy to fix.

 
 I thought you might have something like that in mind, I shall
 wait for that to be done.

I looked at the code and you should be able to implement this without
any changes to the plugin loading system.

The dbus plugin will have to manually call 
p-vTable-getVersion, p-vTable-init and p-vTable-fini when
retrieving metadata from an non-active plugin but that's fine.

 
  BTW, I'm not very interested in just returning the descriptions.
  The GetPluginMetadata method should return an array of full meta data
  documents. This needs to be supported by the dbus plugin before we can
  remove plugin dependencies from the core.

 
 Once the above is done, I can look at modifying the getMetadata
 function.  I think it would be appropriate to change this function
 to return a dictionary because its likely that it will be modified
 and it will save breaking scripts.

You can go ahead and add this right now. If you don't know exactly how
to do the plugin loading and meta data reading then just leave that to
me.

-David

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


Re: [compiz] kde-window-decorator crashes

2007-05-21 Thread David Reveman
On Tue, 2007-05-15 at 18:50 +0100, Diogo Ferreira wrote:
 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.

Could be related to this bug:

http://bugs.freedesktop.org/show_bug.cgi?id=9526

I think someone reported that the workaround we have in libdecoration
doesn't always work.

I should probably go ahead and commit that fix to libXrender.

-David

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


Re: [compiz] place plugin

2007-05-21 Thread David Reveman
On Thu, 2007-05-17 at 14:06 +0200, dragoran wrote:
 The place plugin has a bug:
 when compiz is restarted or started to replace another wm it the windows 
 are placed in weird positions ( titlebar behind the panel etc.)
 
 shouln't the place plugin loop over all open windows and place them 
 correctly when loaded? this should solve this issues.
 any reason why this isn't done? have I missed something or is this just 
 a bug?

compiz should not place existing windows at startup. compiz doesn't
really try to avoid weird positions. the move plugin have some code that
avoids moving windows to weird positions but that's only for when moving
windows.

A plugin that makes sure that windows are never placed at weird
positions could be written for this purpose.

-David

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


Re: [compiz] place plugin

2007-05-21 Thread David Reveman
On Mon, 2007-05-21 at 20:34 +0200, dragoran wrote: 
 David Reveman wrote:
  On Thu, 2007-05-17 at 14:06 +0200, dragoran wrote:

  The place plugin has a bug:
  when compiz is restarted or started to replace another wm it the windows 
  are placed in weird positions ( titlebar behind the panel etc.)
 
  shouln't the place plugin loop over all open windows and place them 
  correctly when loaded? this should solve this issues.
  any reason why this isn't done? have I missed something or is this just 
  a bug?
  
 
  compiz should not place existing windows at startup.
 but it seems that it does (they get moved to weird position if compiz is 
 started while some windows are open).. it should atleast leave them at 
 their old position. (metacity does not do this)

It's a bug if they gets moved.

   compiz doesn't
  really try to avoid weird positions. the move plugin have some code that
  avoids moving windows to weird positions but that's only for when moving
  windows.
 
  A plugin that makes sure that windows are never placed at weird
  positions could be written for this purpose.
 

 how would this fix the problem for windows gets misplaced at startup?

It doesn't. I can't reproduce the misplacement issue on my system and I
don't know what's causing it.

-David

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


Re: [compiz] Crash in blur.c (SIGSEGV)

2007-05-21 Thread David Reveman
On Sat, 2007-05-19 at 12:14 +0200, Artur Uszyński wrote:
 Hello.
 
 System info:
 OS: FC6 x86_64
 video: Nvidia GF 7900 GT, driver version 97.55
 compiz version: git
 config backend used: ccp
 
 I can reproduce this crash every time on my system. When blur plugin is 
 active and I try to access any right-click menu, regular application menu or 
 drop-down list, compiz crashes. Backtrace produced by crashhandler plugin 
 shows crash in blur.c in function blurWindowResizeNotify, in the following 
 line:
 
 if (bw-state[BLUR_STATE_CLIENT].threshold ||
 
 The values of bw seem to be wrong and IMO indicate classic problem with null 
 or uninitialized pointer (although I'm not a programmer):
 
 bw = (BlurWindow *) 0x0
 
 Sometimes instead of 0x0 I get values like 0x40 or 0x33373b3338393932, which 
 don't seem to be right either.
 
 After restarting compiz and immediately accessing exactly the same object 
 (for example repeating right-click on desktop) crash does not happen, but 
 then accessing other similar object crashes compiz again.
 
 After commenting out the whole if statement mentioned above compiz no 
 longer crashes, but probably graphics glitches are introduced instead.
 
 There was a report including similar description sent on Wed Feb 21 04:34:20 
 PST 2007:
 
   When I start blurdemo, that works too.  The problem is that sometimes
   changing the filter type crashes compiz.  If I run it under a debugger
   it starts working again.  All the filter types work with blurdemo.
 
 changing the filter type might be a symptom of the same problem (accessing 
 drop-down list).

This crash is likely caused by decoration and blur plugins calling
wrapped functions from initWindow. I just pushed out some code that
solves this by adding a new WindowAddNotify function that these plugins
now hooks into. I'm pretty sure that this will fix your crash. Give the
latest code a try and let me know.

Thanks,

-David

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


Re: [compiz] place plugin

2007-05-21 Thread David Reveman
On Mon, 2007-05-21 at 21:45 +0200, dragoran wrote:
 David Reveman wrote:
  don't know what's causing it.
 

  It doesn't. I can't reproduce the misplacement issue on my system and I
 try this:
 start metacity open a maximized window
 start compiz
 titlebar is behind the top panel (need to press alt to move it back to 
 its original place, because its impossible to grab the titlebar for moving).

That's a bug in the decoration plugin. It's not adjusting the position
of windows properly when adding decorations to them. There were some
issues before that made it a bit hard to fix this but I think it should
be easy to fix in the current code.

-David

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


Re: [compiz] place plugin

2007-05-21 Thread David Reveman
On Mon, 2007-05-21 at 22:06 +0200, Guillaume Seguin wrote:
 2007/5/21, David Reveman [EMAIL PROTECTED]:
  On Mon, 2007-05-21 at 20:35 +0200, Guillaume Seguin wrote:
   2007/5/21, David Reveman [EMAIL PROTECTED]:
On Thu, 2007-05-17 at 14:06 +0200, dragoran wrote:
 The place plugin has a bug:
 when compiz is restarted or started to replace another wm it the 
 windows
 are placed in weird positions ( titlebar behind the panel etc.)

 shouln't the place plugin loop over all open windows and place them
 correctly when loaded? this should solve this issues.
 any reason why this isn't done? have I missed something or is this 
 just
 a bug?
   
compiz should not place existing windows at startup. compiz doesn't
  
   Would it be possible to change that startup behaviour? Switching from
   metacity to compiz is quite awful at the moment. And there are also
   some minimize problems (windows that are mapped but are known as
   minimized by X, so that you just can't do anything)
 
  Whatever bugs that exist should of course be fixed. If there's other
  things than bugs that is causing it to be awful, please explain more.
 
  -David
 
 
 The startup problems are the placement one (which was described above)
 and the minimized windows problem : When switching from metacity to
 kwin, minimized windows are mapped (I mean visible and updating) but
 they are still in minimized state (wnck menus show Unminimize
 window, but triggering that doesn't help), so that all you can do
 with them is close them (input is impossible, and you can't unminimize
 them). I'll try to get some xprop feedback and screenshots next time
 it happens.

It's a bug in compiz. Minimized windows should always be mapped when the
WM closes down.

-David

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


Re: [compiz] about matchbox + compiz solution

2007-05-20 Thread David Reveman
On Fri, 2007-05-18 at 16:42 +0800, Zhu, Jack wrote:
 Instead of use compiz windows manager, I want to use matchbox, but I want 
 reuse compiz plugins, means I use matchbox + compiz  as  windows manager + 3D 
 desktop effect solution,  would you please give me some suggestion about my 
 plan.
 What about the effort? Would you please give me some suggestion. 
 Thanks. 

I assume you want to use matchbox because it's lightweight and designed
to work well with small displays.

The effects that exist in compiz plugins require OpenGL so there's no
way you can avoid that dependency. Other than that, compiz's modular
design allows it to be as lightweight as matchbox and whatever special
functionality you need that matchbox provides could be added to compiz
through plugins. If there's anything in compiz core, other than the
OpenGL dependency, that makes matchbox more appropriate for you, I'm
very interested in fixing that.

My suggestion is that you use compiz as windows manager and we'll make
sure it fits your needs. Its modular design should make that
straightforward.

- David

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


Re: [compiz] compiz run on DISPLAY :2 error: No composite extension

2007-05-20 Thread David Reveman
On Fri, 2007-05-18 at 17:00 +0800, Zhu, Jack wrote:
 I can enable compiz on default DISPLAY :0  on gnome on FC6,  all
 features are OK, but when I set up a DISPLAY :2 with Xnest,  try to
 run compiz in DISPLAY :2, fail, 
 
 Error info: 
 
  
 
 compiz: No composite extension 
 
  
 
 I check compiz source code: 
 
 if (!XQueryExtension (dpy,
 
   COMPOSITE_NAME,
 
   d-compositeOpcode,
 
   d-compositeEvent,
 
   d-compositeError))
 
 {
 
  fprintf (stderr, %s: No composite extension\n,
 programName);
 
  return FALSE;
 
 }
 
  
 
 NAME
 
XQueryExtension, XListExtensions, XFreeExtensionList - list
 available extensions
 
 ARGUMENTS
 
display   Specifies the connection to the X server.
 
name  Specifies the extension name.
 
 DESCRIPTION
 
The  XQueryExtension  function  determines  if  the  named
 extension is present.  If the extension is not
 
present, XQueryExtension returns False;  otherwise,  it
 returns  True.   If  the  extension  is  present,
 
XQueryExtension  returns  the major opcode for the extension to
 major_opcode_return; otherwise, it returns
 
zero.  
 
  
 
  
 
 who can help me ?

Xnest simply doesn't support the composite extension that is required to
run compiz. Compiz is a compositing window manager and none of the
effects that compiz plugins provide could be implemented without this X
server extension.

You can use Xgl if you want to run an X server in a window that support
all the extensions required by compiz.

- David

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


Re: [compiz] Window specific actions and edge buttons

2007-05-17 Thread David Reveman
On Wed, 2007-05-16 at 11:51 +0100, Mike Dransfield wrote:
 David Reveman wrote:
  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.

 
 OK - I did that for those two.
 
 I am just about to push out similar changes for close_window,
 minimize_window and maximize_window.  If they reduce some
 functionality then please let me know and I will write it so that
 it checks for an edge and only uses activeWindow then.

This is likely not what you want when a button press triggered an action
and it removes the possibility to remotely trigger those actions for
specific windows.

For scale_group and such I think you want to only use the active window
if the provided window is an edge window or a maybe a window that isn't
managed. I don't see any reason why close_window, etc should be changed.

 
 If close_window is used with edge+edgebutton then it crashes
 which is obviously a problem elsewhere.  Is it fairly obvious to
 you where this bug would be?  Otherwise I'll track that down too,
 I assume it must be just a case of setting the correct allowed
 actions hint on edges?

It probably crashes because close_window will try to terminate the
client that created the window and that happens to be compiz itself.
close_window action should be updated to only close managed windows.

- David

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


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

2007-05-17 Thread David Reveman
On Tue, 2007-05-15 at 19:23 +0100, Mike Dransfield wrote:
 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.

Yes, I think we should load/initialize and read the metadata from
plugins. Some minor changes need to be made to the plugin system before
we're able to load and initialize a plugin without activating it but it
should be easy to fix.

BTW, I'm not very interested in just returning the descriptions.
The GetPluginMetadata method should return an array of full meta data
documents. This needs to be supported by the dbus plugin before we can
remove plugin dependencies from the core.

- David



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


Re: [compiz] Window specific actions and edge buttons

2007-05-15 Thread 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

2007-05-15 Thread 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

2007-05-15 Thread 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] Fragment interface on Intel

2007-05-15 Thread David Reveman
On Tue, 2007-05-15 at 07:36 +0800, Sam Spilsbury wrote:
 OK. Just to let you know - it most likely IS the fragment interface
 
 - Water fragmentation worked before the fragment interface was out

OK, I guess those extra instructions that fragment interface adds might
be the cause of this or it could be the changes made to the water
fragment program to make it work with the fragment interface. Whatever
it is, it can be fixed. What someone needs to do is to compare the
different fragment programs generated with and without the fragment
interface and track down what's causing it not to work.

 - Blur seems to be doing something as my framerate slows down to about
 5fps which sounds about right. (No visible blurring however)

Yes, it's likely doing the framebuffer to texture copying but the actual
fragment shading that produce the blur effect is not possible.

 
 Is it possible to have water and blur and/or the fragment interface
 not generate more than this limit of fragment operations or is that
 out of the scope?

As the water effect worked before, it should be possible for that effect
but to make the blur fragment code work might not be possible. Either
way, it's not very interesting to try and make the blur code work as
long as glCopyTexSubImage2D isn't accelerated as you wont be able to get
any decent performance without that anyhow.

- David

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


Re: [compiz] Fragment interface on Intel

2007-05-15 Thread 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


Re: [compiz] removing string restrictions

2007-05-14 Thread David Reveman
On Fri, 2007-05-11 at 18:53 +0200, Dennis Kasprzyk wrote:
 Am Freitag, 11. Mai 2007 17:15 schrieb David Reveman:
  On Fri, 2007-05-11 at 11:45 +0200, Dennis Kasprzyk wrote:
   Am Donnerstag, 10. Mai 2007 21:24 schrieb David Reveman:
We've previously discussed if we should add some sort of selection
option type and not use string options and string restrictions for that
purpose.
   
I don't think we need a new option type for this. The integer type
should do just fine. The attached patch changes the blur plugin's
filter option from string to integer type and adds the relevant
metadata. I suggest that we change all existing options that use string
restrictions in a similar way and remove the string restrictions
completely.
   
Questions? Does it sounds OK?
   
- David
  
   I like the idea, but I would prefer a different XML style.
   desc
 _name value=1Foo/_name
 _name value=2Foo2/_name
 _name value=3Foo3/_name
   /desc
 
  I wanted the desc tag to look the same for every option type and not
  all option type values can be represented as strings. e.g. actions. All
  option values in the meta data are currently within tags, hence it makes
  sense to keep these values within tags as well.
 
  - David
 
 Maybe you should provide some kind of final layout description (also for the 
 dependency rules), so that we can start to implement it. Getting everything 
 together from different mails is painfull. 

The dependency rules are unrelated to this and should be implemented
independently. I don't see any reason for merging the changes or the
discussions.

This string restriction change is easy as it can be done incrementally
once we've agreed on what XML style to use.

Someone could maintain a .dtd with all standard tags but plugins and
configuration tools are always allowed to extend it in whatever way they
want.

- David

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


Re: [compiz] [PATCH] Water fixes

2007-05-14 Thread David Reveman
On Sun, 2007-05-13 at 18:03 -0500, Erkin Bahceci wrote:
 Hi,
 
 I had a look at some problems I saw in the Water plugin. Here are the
 patches fixing those.
 
 The file names should be self-descriptive.

Great, I've committed all patches except
Stop-Water-drawing-right-after-waves-disappear as I'm not sure how you
came to the conclusion that the count variable could be decremented at
that rate. Did you make any calculations to come up with that or is it
just based on testing on your machine?

- David

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


Re: [compiz] xsltproc, schemas.xslt

2007-05-14 Thread David Reveman
On Mon, 2007-05-14 at 15:08 -0500, Travis Watkins wrote:
 On 5/14/07, David Reveman [EMAIL PROTECTED] wrote:
  libxslt.pkg seem to be the pkg-config file we need to check for. I've
  updated configure.ac. Is this accurate with how ubuntu packages
  xsltproc?
 
 No, having libxslt.pc does not guarantee xsltproc will be installed.
 You have to actually check for the binary like my patch does.

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.

- David

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


Re: [compiz] meta data update

2007-05-11 Thread David Reveman
On Fri, 2007-05-11 at 11:52 +0200, Dennis Kasprzyk wrote:
 Am Montag, 7. Mai 2007 18:22 schrieb David Reveman:
  The switch to the new metadata system is almost complete. All plugins in
  the fdo repo except plane and ini have been converted. I'll probably go
  ahead and convert those plugins as well sometime soon unless the
  original authors of those plugins tells me not to.
 
  The horrible gconf-dump plugin has been removed and replaced by a simple
  xslt stylesheet. gconf schemas are now generated from the xml meta data
  files as part of the build process and the stylesheet and a compiz-gconf
  pkg-config file is installed so a command similar to this:
 
  xsltproc -o compiz-plugin.schemas `pkg-config --variable=xsltdir
  compiz-gconf`/schemas.xslt plugin.xml
 
  can be used to generate a schema file for a plugin outside the fdo
  repository.
 
  Plugin dependencies have not yet been moved to the meta data system. I'd
  like some feedback before we do this. I suggest that we use tags similar
  to this:
 
  compiz
  plugin name=cube
  featurelarge-desktop/feature
  deps
  requirement
  pluginpng/plugin
  featuresome-feature/feature
  some_propertyname-of-required-property/some_property
  /requirement
  conflict
  pluginplane/plugin
  featuresome-other-feature/feature
  /conflict
  /deps
  /plugin
  compiz
 
  It will make it easy to add new meta data tags that can be used as
  requirements or conflicts.
 
 I like the idea but we should really define before and after tags. 
 
  The other thing that needs to be discussed related to this is whether
  the core should be aware of any of these dependencies. I think that not
  having the core be aware of any dependencies is definitely the best
  solution. 
 I would also like this, but I see here problems with users that don't use a 
 config tool and create a wrong active plugin list directly in gconf/ini and 
 report bugs because there are problems with some plugins.

If there's actually bugs, then those should be fixed and not avoided
through dependencies. If it's not working the way they want it to
because they're miss-configuring it that's not our problem. They should
use a configuration tool if they can't configure it manually.

 
  It's up to the plugins to deal with conflicts. Whether that is 
  to fail when loading or lack functionality doesn't matter but they will
  of course not be allowed to crash.
 If each plugin will have it's own conflict checking code, it will end that 
 each plugin will have nearly the same conflict checking system, and we will 
 have to move it to core.

Most plugins are not going to need any conflict checking at all. Some
might need a simple check to see if some other plugin is loaded and bail
out if that's the case. I believe that a good plugin shouldn't need any
checking at all, it should work in well-defined way no matter what other
plugins are loaded. It's important that the core is designed in a way
that allow this.

I'm convinced that not having the core provide support for any
dependency checking is good in the long run. It will give us better
plugins and make sure that the hooks provided by the core are properly
designed.

- David

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


Re: [compiz] meta data update

2007-05-11 Thread David Reveman
On Tue, 2007-05-08 at 07:28 +0200, Danny Baumann wrote:
 Hi,
 
  Plugin dependencies have not yet been moved to the meta data system. I'd
  like some feedback before we do this. I suggest that we use tags similar
  to this:
  
  compiz
  plugin name=cube
  featurelarge-desktop/feature
  deps
  requirement
  pluginpng/plugin
  featuresome-feature/feature
  some_propertyname-of-required-property/some_property
  /requirement
  conflict
  pluginplane/plugin
  featuresome-other-feature/feature
  /conflict
  /deps
  /plugin
  compiz
  
  It will make it easy to add new meta data tags that can be used as
  requirements or conflicts.
 
 Sounds good. What I am missing in your suggestion, however, is the
 definition of load order hints. Following your suggestion for
 requirements  conflicts, I would suggest the following:
 
 compiz
 plugin name=someplugin
 loadorder
 beforesomeotherplugin1/before
 aftersomeotherplugin2/after
 /loadorder
 /plugin
 /compiz

Sure but I would prefer something like this:

compiz
plugin
 deps
 relation type=before
 pluginsomeplugin/plugin
 /relation
 /deps
/plugin
/compiz

 
  The other thing that needs to be discussed related to this is whether
  the core should be aware of any of these dependencies. I think that not
  having the core be aware of any dependencies is definitely the best
  solution. It's up to the plugins to deal with conflicts. Whether that is
  to fail when loading or lack functionality doesn't matter but they will
  of course not be allowed to crash.
 
 Sounds fine to me.

Good, it's seems like everyone is OK with this so I think we can start
updating plugins.

- David

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


Re: [compiz] meta data update

2007-05-11 Thread David Reveman
On Fri, 2007-05-11 at 18:50 +0200, Dennis Kasprzyk wrote:
 Am Freitag, 11. Mai 2007 17:09 schrieb David Reveman:
  On Fri, 2007-05-11 at 11:52 +0200, Dennis Kasprzyk wrote:
   Am Montag, 7. Mai 2007 18:22 schrieb David Reveman:
The switch to the new metadata system is almost complete. All plugins
in the fdo repo except plane and ini have been converted. I'll probably
go ahead and convert those plugins as well sometime soon unless the
original authors of those plugins tells me not to.
   
The horrible gconf-dump plugin has been removed and replaced by a
simple xslt stylesheet. gconf schemas are now generated from the xml
meta data files as part of the build process and the stylesheet and a
compiz-gconf pkg-config file is installed so a command similar to this:
   
xsltproc -o compiz-plugin.schemas `pkg-config --variable=xsltdir
compiz-gconf`/schemas.xslt plugin.xml
   
can be used to generate a schema file for a plugin outside the fdo
repository.
   
Plugin dependencies have not yet been moved to the meta data system.
I'd like some feedback before we do this. I suggest that we use tags
similar to this:
   
compiz
plugin name=cube
featurelarge-desktop/feature
deps
requirement
pluginpng/plugin
featuresome-feature/feature
   
some_propertyname-of-required-property/some_property /requirement
conflict
pluginplane/plugin
featuresome-other-feature/feature
/conflict
/deps
/plugin
compiz
   
It will make it easy to add new meta data tags that can be used as
requirements or conflicts.
  
   I like the idea but we should really define before and after tags.
  
The other thing that needs to be discussed related to this is whether
the core should be aware of any of these dependencies. I think that not
having the core be aware of any dependencies is definitely the best
solution.
  
   I would also like this, but I see here problems with users that don't use
   a config tool and create a wrong active plugin list directly in gconf/ini
   and report bugs because there are problems with some plugins.
 
  If there's actually bugs, then those should be fixed and not avoided
  through dependencies. If it's not working the way they want it to
  because they're miss-configuring it that's not our problem. They should
  use a configuration tool if they can't configure it manually.
 
 Currently there is one one system that provides automatic sorting of plugins 
 and this is the ccs (compiz configuration system) at git.opencompositing.org 
 and it is still under heavy development. But I would really happy if 
 the current dependency checking code would be removed from the core.

Whether one, zero or a bunch of systems currently support sorting
doesn't matter.

 
It's up to the plugins to deal with conflicts. Whether that is
to fail when loading or lack functionality doesn't matter but they will
of course not be allowed to crash.
  
   If each plugin will have it's own conflict checking code, it will end
   that each plugin will have nearly the same conflict checking system, and
   we will have to move it to core.
 
  Most plugins are not going to need any conflict checking at all. Some
  might need a simple check to see if some other plugin is loaded and bail
  out if that's the case. I believe that a good plugin shouldn't need any
  checking at all, it should work in well-defined way no matter what other
  plugins are loaded. It's important that the core is designed in a way
  that allow this.
 
  I'm convinced that not having the core provide support for any
  dependency checking is good in the long run. It will give us better
  plugins and make sure that the hooks provided by the core are properly
  designed.
 
 For such basic checks we should really add a screenGrabExists function to 
 core.

I was talking about bailing out at initialization time. Refuse to load
if some other plugin is already loaded.

- David

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


Re: [compiz] meta data update

2007-05-11 Thread David Reveman
On Fri, 2007-05-11 at 17:36 +0100, Mike Dransfield wrote: 
 Dennis Kasprzyk wrote:
  Am Freitag, 11. Mai 2007 17:09 schrieb David Reveman:

  On Fri, 2007-05-11 at 11:52 +0200, Dennis Kasprzyk wrote:
  
  Am Montag, 7. Mai 2007 18:22 schrieb David Reveman:

  The switch to the new metadata system is almost complete. All plugins
  in the fdo repo except plane and ini have been converted. I'll probably
  go ahead and convert those plugins as well sometime soon unless the
  original authors of those plugins tells me not to.
 
  The horrible gconf-dump plugin has been removed and replaced by a
  simple xslt stylesheet. gconf schemas are now generated from the xml
  meta data files as part of the build process and the stylesheet and a
  compiz-gconf pkg-config file is installed so a command similar to this:
 
  xsltproc -o compiz-plugin.schemas `pkg-config --variable=xsltdir
  compiz-gconf`/schemas.xslt plugin.xml
 
  can be used to generate a schema file for a plugin outside the fdo
  repository.
 
  Plugin dependencies have not yet been moved to the meta data system.
  I'd like some feedback before we do this. I suggest that we use tags
  similar to this:
 
  compiz
  plugin name=cube
  featurelarge-desktop/feature
  deps
  requirement
  pluginpng/plugin
  featuresome-feature/feature
 
  some_propertyname-of-required-property/some_property /requirement
  conflict
  pluginplane/plugin
  featuresome-other-feature/feature
  /conflict
  /deps
  /plugin
  compiz
 
  It will make it easy to add new meta data tags that can be used as
  requirements or conflicts.
  
  I like the idea but we should really define before and after tags.
 

  The other thing that needs to be discussed related to this is whether
  the core should be aware of any of these dependencies. I think that not
  having the core be aware of any dependencies is definitely the best
  solution.
  
  I would also like this, but I see here problems with users that don't use
  a config tool and create a wrong active plugin list directly in gconf/ini
  and report bugs because there are problems with some plugins.

  If there's actually bugs, then those should be fixed and not avoided
  through dependencies. If it's not working the way they want it to
  because they're miss-configuring it that's not our problem. They should
  use a configuration tool if they can't configure it manually.
 
  
  Currently there is one one system that provides automatic sorting of 
  plugins 
  and this is the ccs (compiz configuration system) at 
  git.opencompositing.org 
  and it is still under heavy development. But I would really happy if 
  the current dependency checking code would be removed from the core.
 

 
 This is not strictly true.
 
 My web based settings tool does automatic plugin ordering based
 on the data provided by dbus.
 
 I think RYX also has a python library which does this.
 
  It's up to the plugins to deal with conflicts. Whether that is
  to fail when loading or lack functionality doesn't matter but they will
  of course not be allowed to crash.
  
  If each plugin will have it's own conflict checking code, it will end
  that each plugin will have nearly the same conflict checking system, and
  we will have to move it to core.

  Most plugins are not going to need any conflict checking at all. Some
  might need a simple check to see if some other plugin is loaded and bail
  out if that's the case. I believe that a good plugin shouldn't need any
  checking at all, it should work in well-defined way no matter what other
  plugins are loaded. It's important that the core is designed in a way
  that allow this.
 
  I'm convinced that not having the core provide support for any
  dependency checking is good in the long run. It will give us better
  plugins and make sure that the hooks provided by the core are properly
  designed.
 
  
  For such basic checks we should really add a screenGrabExists function to 
  core.

 
 I think the point is that plugins should not be aware of other
 plugins at all and should not do anything bad if those plugins
 are not loaded.
 
 They should be written in such a way that it does not matter if
 the dependencies are not loaded, they will just lack some
 functionality.  ie.  It should be possible to load rotate without
 cube and it would not behave badly, the same for loading rotate
 before cube.

Eventually, I'd like to see no conditionals or code at all that depend
on the existence of other plugins.

Cube/rotate is always a bad example. That separation started out as a
test and it's a shame that it still works like that. The rotate
functionality should be part of the cube plugin. If we want to be able
to separate that kind of functionality into different plugins, it should
be done through

Re: [compiz] White boarders on size 32 shadows. Intel platform only

2007-05-10 Thread David Reveman
On Sun, 2007-05-06 at 13:59 +0800, Sam Spilsbury wrote:
 So, wait, does that change the shadow *size* to another value other
 than 32?

It's the radius of the gaussian function used to generate the shadow. A
small change might not change the number of pixels required for the
shadow but a large one will.

 
 On 5/4/07, David Reveman [EMAIL PROTECTED] wrote:
 On Thu, 2007-05-03 at 07:02 +0800, Sam Spilsbury wrote:
  Is it possible for the user to specify how big they want
 thier shadow 
  to be in gconf? I know its possible in the emerald window
 decorator
 
 yes, shadow_radius key.
 
 - David
 
 
 
 
- David

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


Re: [compiz] [PATCH] Transparent cube

2007-05-10 Thread David Reveman
On Mon, 2007-05-07 at 21:24 +0300, Roi Cohen wrote:
 Hi.
 
 I re-created my patches to work on latest git, and use the order system.
 David, what do you think of these patches now?

Did we solve all issues with the order interface? How can multiple
plugins use that interface reliably? I'd like to make sure that we at
least have a good plan for how to deal with that before we add this.

- David

 
 Regards,
 Roi.
 
 On 5/4/07, David Reveman [EMAIL PROTECTED] wrote:
  On Tue, 2007-05-01 at 23:06 +0200, Dennis Kasprzyk wrote:
   Am Dienstag, 1. Mai 2007 22:54 schrieben Sie:
On Tue, 2007-05-01 at 23:29 +0300, Roi Cohen wrote:
 Hi David.

 I thought about your suggestion a bit more, and i think it has a
 problem, although it's a bit hard to explain it.
 How will plugins exactly wrap this function? I mean, obviously they
 will just call the WRAP / UNWRAP macros, but what i'm asking is, what
 will they actually do inside this function?
 I guess it needs to be something like this:

 nextInStack(w)
 {
   if (Plugin makes an effect and needs to change order)
   return next;

   UNWRAP;
   call;
   WRAP;
 }

 If one plugin needs to change painting order, plugins loaded before it
 won't get the chance to change their painting order.

 3D and cube will still work together, but only because of luck - 3d
 needs to be loaded before cube (it needs the openGL matrices of the
 cube's transformations to know how to reorder the painting) which
 means that theoretically, 3d's paint order won't be executed. However,
 it will work because 3d doesn't need to change painting order for ftb
 faces, and cube doesn't need to change painting order for btf faces.
 Again, I consider this as a lucky coincidence, both 3d and cube will
 work, but it shows why I think wrapping this function is somewhat
 problematic.

 Dennis Kasprzyk suggested another approach to this problem - instead
 of wrapping this function, we will pass another argument to
 paintTransformedScreen which is:
 struct CompWindowListSort {
   // Function pointers
   FirstInStackProc* first;
   LastInStackProc* last;

   NextInStackProc* next;
   PrevInStackProc* prev;
 }
 This way, plugins won't wrap this function, and the plugin which is
 loaded first gets the call on painting order, instead of the last
 plugin which is loaded last.
 It fixes the problem with 3d and transcube - 3d's paint order will
 always be prefered over cube's one.
 I'm not really sure this is the best solution - there isn't really a
 reason to prefer the first loaded plugin over the last loaded one.

 Do you think we should stay with your original idea, ignoring the
 problems that will occur when 2 different plugins want to change
 painting order (after all, similar problems occur with window
 transformations etc), or do you have another idea?
   
Yes, maybe it's better to just require a depth buffer and destination
alpha for these kind of effects and construct an proper interface for
that instead.
   
- David
  
   But this could also cause problems with something like skydome. I think 
   that
   every solution can cause problems with other plugins, but I think it is
   better to add a solution that will not add additional dependencies. And I
   think that the order change system is more flexible so that we could use 
   it
   for another effects later.
 
  I fail to see how it could cause problems with the skydome but using
  destination alpha is definitely not going to work with the blur plugin.
  We're going to have to address the problem with drawing intersecting
  translucent objects at some point but as we don't have a perfect
  solution for that yet, the order system seem like a good idea to start
  with.
 
  - 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


[compiz] removing string restrictions

2007-05-10 Thread David Reveman
We've previously discussed if we should add some sort of selection
option type and not use string options and string restrictions for that
purpose.

I don't think we need a new option type for this. The integer type
should do just fine. The attached patch changes the blur plugin's filter
option from string to integer type and adds the relevant metadata. I
suggest that we change all existing options that use string restrictions
in a similar way and remove the string restrictions completely.

Questions? Does it sounds OK?

- David
--- a/include/compiz.h
+++ b/include/compiz.h
@@ -3087,6 +3087,12 @@ matchPropertyChanged (CompDisplay *display,
 
 /* metadata.c */
 
+#define STRINGIFY(x) #x
+#define TOSTRING(x) STRINGIFY (x)
+#define MINTOSTRING(x) min TOSTRING (x) /min
+#define MAXTOSTRING(x) max TOSTRING (x) /max
+#define RESTOSTRING(min, max) MINTOSTRING (min) MAXTOSTRING (max)
+
 typedef struct _CompMetadataOptionInfo {
 char		   *name;
 char		   *type;
--- a/metadata/blur.xml.in
+++ b/metadata/blur.xml.in
@@ -38,15 +38,24 @@
 		_longBlur behind translucent parts of windows/_long
 		defaulttrue/default
 	/option
-	option name=filter type=string
+	option name=filter type=int
 		_shortBlur Filter/_short
 		_longFilter method used for blurring/_long
-		default4xBilinear/default
-		allowed
-		value4xBilinear/value
-		valueGaussian/value
-		valueMipmap/value
-		/allowed
+		default0/default
+		min0/min
+		max2/max
+		desc
+		value0/value
+		_name4xBilinear/_name
+		/desc
+		desc
+		value1/value
+		_nameGaussian/_name
+		/desc
+		desc
+		value2/value
+		_nameMipmap/_name
+		/desc
 	/option
 	option name=gaussian_radius type=int
 		_shortGaussian Radius/_short
--- a/plugins/blur.c
+++ b/plugins/blur.c
@@ -37,11 +37,10 @@ static CompMetadata blurMetadata;
 
 #define BLUR_GAUSSIAN_RADIUS_MAX 15
 
-typedef enum {
-BlurFilter4xBilinear,
-BlurFilterGaussian,
-BlurFilterMipmap
-} BlurFilter;
+#define BLUR_FILTER_4X_BILINEAR 0
+#define BLUR_FILTER_GAUSSIAN1
+#define BLUR_FILTER_MIPMAP  2
+#define BLUR_FILTER_LAST	BLUR_FILTER_MIPMAP
 
 typedef struct _BlurFunction {
 struct _BlurFunction *next;
@@ -121,8 +120,7 @@ typedef struct _BlurScreen {
 
 Bool blurOcclusion;
 
-BlurFilter filter;
-intfilterRadius;
+int filterRadius;
 
 BlurFunction *srcBlurFunctions;
 BlurFunction *dstBlurFunctions;
@@ -190,17 +188,6 @@ typedef struct _BlurWindow {
 
 #define NUM_OPTIONS(s) (sizeof ((s)-opt) / sizeof (CompOption))
 
-static BlurFilter
-blurFilterFromString (CompOptionValue *value)
-{
-if (strcasecmp (value-s, gaussian) == 0)
-	return BlurFilterGaussian;
-else if (strcasecmp (value-s, mipmap) == 0)
-	return BlurFilterMipmap;
-else
-	return BlurFilter4xBilinear;
-}
-
 /* pascal triangle based kernel generator */
 static int
 blurCreateGaussianLinearKernel (int   radius,
@@ -280,11 +267,11 @@ blurUpdateFilterRadius (CompScreen *s)
 {
 BLUR_SCREEN (s);
 
-switch (bs-filter) {
-case BlurFilter4xBilinear:
+switch (bs-opt[BLUR_SCREEN_OPTION_FILTER].value.i) {
+case BLUR_FILTER_4X_BILINEAR:
 	bs-filterRadius = 2;
 	break;
-case BlurFilterGaussian: {
+case BLUR_FILTER_GAUSSIAN: {
 	int   radius   = bs-opt[BLUR_SCREEN_OPTION_GAUSSIAN_RADIUS].value.i;
 	float strength = bs-opt[BLUR_SCREEN_OPTION_GAUSSIAN_STRENGTH].value.f;
 
@@ -293,7 +280,7 @@ blurUpdateFilterRadius (CompScreen *s)
 
 	bs-filterRadius = radius;
 } break;
-case BlurFilterMipmap: {
+case BLUR_FILTER_MIPMAP: {
 	float lod = bs-opt[BLUR_SCREEN_OPTION_MIPMAP_LOD].value.f;
 
 	bs-filterRadius = powf (2.0f, ceilf (lod));
@@ -561,7 +548,7 @@ blurSetScreenOption (CompPlugin  *plugin,
 		 CompOptionValue *value)
 {
 CompOption *o;
-int	   index;
+int	   index, filter;
 
 BLUR_SCREEN (screen);
 
@@ -613,9 +600,8 @@ blurSetScreenOption (CompPlugin  *plugin,
 	}
 	break;
 case BLUR_SCREEN_OPTION_FILTER:
-	if (compSetStringOption (o, value))
+	if (compSetIntOption (o, value))
 	{
-	bs-filter = blurFilterFromString (o-value);
 	blurReset (screen);
 	damageScreen (screen);
 	return TRUE;
@@ -624,7 +610,8 @@ blurSetScreenOption (CompPlugin  *plugin,
 case BLUR_SCREEN_OPTION_GAUSSIAN_RADIUS:
 	if (compSetIntOption (o, value))
 	{
-	if (bs-filter == BlurFilterGaussian)
+	filter = bs-opt[BLUR_SCREEN_OPTION_FILTER].value.i;
+	if (filter == BLUR_FILTER_GAUSSIAN)
 	{
 		blurReset (screen);
 		damageScreen (screen);
@@ -635,7 +622,8 @@ blurSetScreenOption (CompPlugin  *plugin,
 case BLUR_SCREEN_OPTION_GAUSSIAN_STRENGTH:
 	if (compSetFloatOption (o, value))
 	{
-	if (bs-filter == BlurFilterGaussian)
+	filter = bs-opt[BLUR_SCREEN_OPTION_FILTER].value.i;
+	if (filter == BLUR_FILTER_GAUSSIAN)
 	{
 		blurReset (screen);
 		damageScreen (screen);
@@ -646,7 +634,8 @@ blurSetScreenOption (CompPlugin  *plugin,
 case 

[compiz] meta data update

2007-05-07 Thread David Reveman
The switch to the new metadata system is almost complete. All plugins in
the fdo repo except plane and ini have been converted. I'll probably go
ahead and convert those plugins as well sometime soon unless the
original authors of those plugins tells me not to.

The horrible gconf-dump plugin has been removed and replaced by a simple
xslt stylesheet. gconf schemas are now generated from the xml meta data
files as part of the build process and the stylesheet and a compiz-gconf
pkg-config file is installed so a command similar to this:

xsltproc -o compiz-plugin.schemas `pkg-config --variable=xsltdir 
compiz-gconf`/schemas.xslt plugin.xml

can be used to generate a schema file for a plugin outside the fdo
repository.

Plugin dependencies have not yet been moved to the meta data system. I'd
like some feedback before we do this. I suggest that we use tags similar
to this:

compiz
plugin name=cube
featurelarge-desktop/feature
deps
requirement
pluginpng/plugin
featuresome-feature/feature
some_propertyname-of-required-property/some_property
/requirement
conflict
pluginplane/plugin
featuresome-other-feature/feature
/conflict
/deps
/plugin
compiz

It will make it easy to add new meta data tags that can be used as
requirements or conflicts.

The other thing that needs to be discussed related to this is whether
the core should be aware of any of these dependencies. I think that not
having the core be aware of any dependencies is definitely the best
solution. It's up to the plugins to deal with conflicts. Whether that is
to fail when loading or lack functionality doesn't matter but they will
of course not be allowed to crash.

- David

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


Re: [compiz] meta data update

2007-05-07 Thread David Reveman
On Tue, 2007-05-08 at 00:48 +0100, Mike Dransfield wrote:
 David Reveman wrote:
 
 The switch to the new metadata system is almost complete. All plugins in
 the fdo repo except plane and ini have been converted. I'll probably go
 ahead and convert those plugins as well sometime soon unless the
 original authors of those plugins tells me not to.
   
 
 
 The attached patch should save you the trouble.  I cannot
 commit it at the moment.

Thanks. I've now also updated the plane plugin.

 
 The horrible gconf-dump plugin has been removed and replaced by a simple
 xslt stylesheet. gconf schemas are now generated from the xml meta data
 files as part of the build process and the stylesheet and a compiz-gconf
 pkg-config file is installed so a command similar to this:
   
 
 
 I suppose we will need to work out an xslt for the ini plugin,
 but I am not in any hurry at the moment.  I assume everything
 will continue to work because the default values are loaded
 from the metadata, so maybe this would not be needed at all?

Not unless you like to store some default values in a system wide
directory. I would avoid that if possible. You can read the default
values for options at run-time from the meta data objects provided by
each plugin. I remember that you were interested in this earlier.

- David

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


Re: [compiz] [PATCH] Option for activation behaviour on window close

2007-05-03 Thread David Reveman
On Thu, 2007-05-03 at 14:51 +0200, Danny Baumann wrote:
 Hi,
 
   please find attached a patch that makes the behaviour of window
   activation when a window is closed optional.
   Currently, always the last active window is activated. Sometimes this
   might not be the desired behaviour, but users (like me ;-) ) would like
   the window under the pointer to be activated. This patch adds the latter
   behaviour as an option while still keeping the former behaviour as
   default.
   
   Questions / concerns / objections / opinions anyone?
  
  Is there any reason someone using click-to-focus would want this? Is
  there any reason someone not using click-to-focus wouldn't want this?
 
 From my point of view: Two times no. Alyone got a different opinion?
 
 David, so you are fine with adding this code, but not making it depend
 on its own option, but on the click_to_focus option?

Yes, let's add this as part of the click_to_focus option and we'll
improve it if someone complains. Please use the word Pointer instead
of Mouse in the focusMouseTarget function name.

- David

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


Re: [compiz] Bug in otherScreenGrabExist?

2007-05-03 Thread David Reveman
On Fri, 2007-05-04 at 00:49 +0100, Mike Dransfield wrote:
 I am fairly sure that this is just a bug in the codes logic, but
 I thought I should check first

hm, I think the code is currently doing the correct thing.

 
 I noticed that the function was always returning true if only
 one grab is checked for (maybe other cases too)

I fail to see why. Can you provide some more details of what you're
doing?

- David

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


Re: [compiz] White boarders on size 32 shadows. Intel platform only

2007-05-02 Thread David Reveman
On Sun, 2007-04-29 at 17:43 +0800, Sam Spilsbury wrote:
 Recently, I brought up a topic about white boarders being drawn
 instead of shadows in Gnome-Window-Decorator. A patch was made up by
 gandalfn to correct this by making 32 pixel shadows 33 pixels, however
 the patch was not committed because it was a workaround. 
 
 This is a huge functional annoyance to us intel users and needs to be
 cured. There are two soultions I can think of:
 
 1 Get in contact with the X.org i810 team and ask them to correct the
 issue in their driver which does not allow 32 pixel shadows to be
 drawn. 
 2 Allow the user to specify in GConf or something the depth of the
 shadows that GWD creates. Emerald from Beryl currently allows this so
 I don't understand why it would be too hard to implement.
 
 Yes I *know* #2 is more like a workaround but at least it allows the
 user to specify how big they want this shadows to be. (Please dont
 confuse this with X-offset adn Y-Offset). 

I did some quick testing and the problem indeed seem to be a driver
issue but I haven't had time to track down exactly what's causing it.
There's nothing we can do until someone have been able to track it down.
You can enter a intel 3d driver bug for this if you want and if we're
lucky someone might be able to help us track this down.

- David

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


Re: [compiz] Wobbly jerkyness

2007-05-02 Thread David Reveman
On Sun, 2007-04-29 at 17:54 +0800, Sam Spilsbury wrote:
 About a month ago, David made a commit to wobbly to the spring engine
 which has introduced some bugs. They are hard to explain so bear with
 me.
 
 In a sense, the wobbly plugin does not seem as smooth as it used to be
 and the windows jerk all over the place. For example, I sometimes
 notice that when I move a large window (around 2/3 of the size of the
 desktop window), If I moved it down, the top of the window would jerk
 up then come down quickly. If you want me to explain further then let
 me know 

I didn't change anything in the wobbly plugin, I changed how the move
plugin works.

The jerkyness and high CPU load is actually expected behavior. The high
CPU load is caused by the move plugin changing the server-side window
attributes to reflect the current position of the window in real-time.
The move plugin doesn't have to do this but it's important that things
don't break when it does. I've already been able to fix a number of
performance issues after making this change and I think there's some
more low hanging fruit that can be taken care of quickly.

Eventually, I'll make it possible to not have the move plugin update the
window attributes in real-time and I can guarantee that performance will
be at least as good as before I did these changes to the move plugin.
However, before I can make this possible we need to improve the way
window animations are performed. What the move plugin was doing before
was wrong and I'm not going to change back to that.

You're very welcome to help out with testing, profiling and fixing
issues related to how the move plugin currently works. If you're not
interested in that and if you can't live with the issues and performance
of the current move plugin, you're welcome to use an older version of
the move plugin with the bad but better performing behavior.

- David

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


Re: [compiz] Re: Plugin Interface for Decoations

2007-05-02 Thread David Reveman
On Mon, 2007-04-30 at 17:24 +0200, Patrick Niklaus wrote:
 I realized some major problems with this approach. To give you a
 better idea of what I'm actually talking about, take a look at this
 schema:
 http://media.beryl-project.org/Decoration-Schema.png
 
 As you can see KWD, GWD and Emerald would run in the same
 applications, as plugins.
 This might cause problems because the main loops of Qt and Gtk are
 conflicting here, which was actually one of the reasons why the
 decorator was not a own plugin in compiz.
 
 Another problem is the settings backend. To integrate into the desktop
 each plugin uses its own backend. For example the emerald plugin uses
 ini/gkey files + libemeraldengine but GWD gconf + metacity functions.
 So basically we would end up with a complete window decorator, ported
 to a plugin, which is not really what I had in mind.
 
 An alternative would be, remaining the current structure of having
 several decorator running as an own application and expand emerald to
 an highly-customizeable and extentable decorator, which relies on
 plugin architecture. The main goal of that decorator would be to
 provide an independently theme and other rather experimental things
 like animations.
 
 This architecture is shown in this schema:
 http://media.beryl-project.org/Decoration-Schema2.png
 
 I'm not really sure which one would fit our needs best here (or if
 there would be other solutions), so it would be the best if we could
 discuss that here.
 
 Regrads,
 Patrick
 
 2007/4/29, Patrick Niklaus [EMAIL PROTECTED]:
  Hi,
 
  this email is basically the result of a small discussion which made me
  think what the real end-goal of my work on Emerald-2 would be. Since
  Emerald has already a extensible system (Engines) I thought about
  giving the engines wider access, so that they are more like plugins.
  However the first thing needed is a nice plugin API. The base for that
  is the new settings backend of Emerald-2. Settings backend might not
  be the right word here, since it handles a lot more, it could also be
  called engines backend. (= libemeraldengine)
 
  The next step is, taking GWD (which has a proper usage of
  libdecoration), port it to that system and also port most of Emerald
  features to it. This includes pixmap buttons and usage of the button
  interface for libdecoation, which will described in detail in another
  mail.
 
  Basically we would end up with a better Emerald, working name Emerald-2.
  Now, if we got that working properly we need to think about what will
  be moved to a plugin and what will stay in core. At this point we also
  need an exact definition of the plugin API. A first general definition
  can be found below.
 
  It would be really nice if I could get some feedback or suggestions on my 
  plans.
 
  BTW. Please do not start a flame war because of the working name, it
  will be probably changed and I don't want to decide about it yet, but
  since it shares most of its features I choose this name for now.
 
   The Plugin Interface 
 
  * Settings:
- make use of libemeraldengien settings backend
  = could cause problems because Metacity and KDE have different backends
- maybe extent it so it would better fit our needs
- but keep in mind that we won't need a second implementation of the
  compiz options system
 
  * Event handling:
- provide notifies for plugins for some specific events
- not sure which one will be needed
- however resize/move/enter/leave will probably be included
 
  * Integration into Emerald-2:
- standard button drawing will be probably handled by plugins
- window title drawing probably too
- we need a system so plugins can sign up for providing functions
  = wrapping stack like in compiz
  = slot system, so only one plugin at the same time can sign up for it
 
  * Integration into DE's:
- add a plugin for Metacity support
- maybe port the KDE decoration also to a plugin (if thats possible)
 
  Regards,
  Patrick
 

You're welcome to improve emerald, rewrite it or write a completely new
decorator, I'm definitely not going to stand in the way of that.
However, I suggest that you avoid duplicating work when not necessary
and avoid creating alternatives to existing solutions.

libdecoration contains code that is used by all decorators. If you find
some code that makes sense for more than one decorator, it likely makes
sense to put that code in libdecoration.

What's missing in current decorators? The following is what I think is
missing and how it's most properly fixed.

KDE - Expose a few things in kwd that will make is possible for kwin
plugins to use alpha channels and less resources. That's it, the kwin
plugin API is flexible enough do do pretty much anything so I don't see
a need to create an alternative here.

GNOME - The existing metacity theme system is pretty limited but
extending it with something like theme engines, which would allow
metacity themes to look fancier 

Re: [compiz] gtk-window-decorator Wnck warnings

2007-05-02 Thread David Reveman
On Mon, 2007-04-30 at 01:22 -0500, Erkin Bahceci wrote:
 Hi,
 
 I'm getting a lot of warnings like this one:
 (gtk-window-decorator:8442): Wnck-WARNING **: Unhandled action type (nil)
 
 Does anyone else see these warnings or know what causes these?

That warning is caused by compiz setting the new ACTION_ABOVE hint on
windows and old versions of libwnck doesn't recognize that hint. It's
harmless and if you upgrade to a newer version of libwnck (I think you
need the svn version) it will disappear. That libwnck spits out a
warning just because it doesn't recognize an action type is sort of bug.

 
 Also, it seems that this lost textures bug
   https://bugs.freedesktop.org/show_bug.cgi?id=10789
 usually happens only when these warnings are spitted out, so the bug
 is probably related to these wnck warnings.

I haven't looked at the lost textures bug but I can guarantee that
it's not related to this libwnck warning.

- David

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


Re: [compiz] Re: [PATCH] Transparent cube

2007-05-01 Thread David Reveman
On Fri, 2007-04-27 at 03:13 +0200, Dennis Kasprzyk wrote:
 Am Donnerstag, 26. April 2007 23:08 schrieben Sie:
  On Wed, 2007-04-25 at 23:48 +0200, Dennis Kasprzyk wrote:
   Am Mittwoch, 25. April 2007 23:21 schrieb David Reveman:
On Sun, 2007-04-22 at 14:22 +0300, Roi Cohen wrote:
 Hi,
 I re-generated the patches, so it will work now against latest git.
 Please note that the vertical rotation bug is now fixed, due to this
 commit:
 http://gitweb.freedesktop.org/?p=xorg/app/compiz.git;a=commit;h=36ca8
bf25 9d79ef5ee3630e1741a213163ebbfb6

 David, what do you think of these patches?
 Some feedback is still appreciated.
   
I'm interested in the transparent cube feature but I'm not very happy
about the set of patches that is required to get this working in the
current drawing framework. I don't want to push that additional
complexity into the core and force all plugins to support it. It makes
more sense to provide this functionality using an interface that allow
you to push painting of a set of objects to an off-screen surface. Such
an interface will likely not be added until other major drawing
framework changes are in place but it's definitely something that
should be added eventually.
  
   I don't see a reason to do this with offscreen rendering. This still
   wouldn't solve the problem that windows have to be painted in the
   reversed order to make the faces in the background look right. Another
   disadvantage would be that transparent cube would be only supported on
   cards that have offscreen rendering support (fbo's). The only advantage
   would be be that we wouldn't need to redraw each face on each repaint.
   Correct me If I'm wrong here.
 
  You're right, I don't know what I was thinking of yesterday. Off-screen
  rendering is not going to be of much help here. I clearly didn't look at
  this closely enough yesterday.
 
  I think I got a better understanding now and it seems that the BTF / FTB
  patch is a solution for some special cases where windows should not be
  rendered using their server side stacking order. A more general solution
  that makes it possible for plugins to adjust the order in which windows
  are rendered would make more sense to me.
 
  Here's a suggestion:
 
  Instead of just walking the list of windows when rendering them like
  this:
 
  for (w = s-window; w; w = w-next)
 
  we can do something like this:
 
  for (w = (*s-stackFuncs.first) (s); w; w = (*s-stackFuncs.next) (w))
 
  and the core version of stackFuncs.next would just look like this:
 
  CompWindow *
  stackNext (CompWindow *w)
  {
  return w-next;
  }
 
  plugins can provide any stacking order they want when rendering windows
  by wrapping the stackFuncs struct with it's own stack functions. This
  should be good for transparent cube and things similar to what the 3d
  plugin is doing, right?
 
  What do you guys think? My biggest concern with the BTF / FTB patch is
  the way the screen can first be painted with BTF order and then with FTB
  order and some plugin must then prevent the core from painting the
  window twice.
 
  - David
 
 Great idea but we also should have stackFuncs.last and prev to do the 
 occlusion detection right and maybe a MASK to be able to disable the 
 occlusion detection.

yes, .last and .prev are in that struct too of course.

 
 This should be enough to realize transparent cube and most parts of the 3d 
 plugin.
 
 The last point we should look here are the wrapable clipping planes patches. 
 I 
 think the attached picture describes what we have now and what we would like 
 to have. Sorry but I'm a very bad painter ;-)

yes, I know what you mean. I'm trying to figure out what's the best
solution here. Maybe it's to add the clip planes as arguments to
paintTransformedScreen function. I'm not sure.

- David

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


Re: [compiz] Re: [PATCH] Transparent cube

2007-05-01 Thread David Reveman
On Tue, 2007-05-01 at 23:29 +0300, Roi Cohen wrote:
 Hi David.
 
 I thought about your suggestion a bit more, and i think it has a
 problem, although it's a bit hard to explain it.
 How will plugins exactly wrap this function? I mean, obviously they
 will just call the WRAP / UNWRAP macros, but what i'm asking is, what
 will they actually do inside this function?
 I guess it needs to be something like this:
 
 nextInStack(w)
 {
   if (Plugin makes an effect and needs to change order)
   return next;
   
   UNWRAP;
   call;
   WRAP;
 }
 
 If one plugin needs to change painting order, plugins loaded before it
 won't get the chance to change their painting order.
 
 3D and cube will still work together, but only because of luck - 3d
 needs to be loaded before cube (it needs the openGL matrices of the
 cube's transformations to know how to reorder the painting) which
 means that theoretically, 3d's paint order won't be executed. However,
 it will work because 3d doesn't need to change painting order for ftb
 faces, and cube doesn't need to change painting order for btf faces.
 Again, I consider this as a lucky coincidence, both 3d and cube will
 work, but it shows why I think wrapping this function is somewhat
 problematic.
 
 Dennis Kasprzyk suggested another approach to this problem - instead
 of wrapping this function, we will pass another argument to
 paintTransformedScreen which is:
 struct CompWindowListSort {
   // Function pointers
   FirstInStackProc* first;
   LastInStackProc* last;
   
   NextInStackProc* next;
   PrevInStackProc* prev;
 }
 This way, plugins won't wrap this function, and the plugin which is
 loaded first gets the call on painting order, instead of the last
 plugin which is loaded last.
 It fixes the problem with 3d and transcube - 3d's paint order will
 always be prefered over cube's one.
 I'm not really sure this is the best solution - there isn't really a
 reason to prefer the first loaded plugin over the last loaded one.
 
 Do you think we should stay with your original idea, ignoring the
 problems that will occur when 2 different plugins want to change
 painting order (after all, similar problems occur with window
 transformations etc), or do you have another idea?

Yes, maybe it's better to just require a depth buffer and destination
alpha for these kind of effects and construct an proper interface for
that instead.

- David

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


Re: [compiz] [PATCH]Make wobbly's bezier patch to work with grids that aren't 4x4.

2007-05-01 Thread David Reveman
On Thu, 2007-04-26 at 17:30 +0300, Roi Cohen wrote:
 Hi,
 
 Recently, I started taking a look at wobbly's source (I was interested
 in it's physics... ;-))
 I noticed that GRID_WIDTH and GRID_HEIGHT were defined to be 4, and I
 wanted to see how the physics look like with grid sizes that aren't
 4x4.
 I changed the defines to my new grid size, but unfortunately it didn't work.
 I investigated this bug (it's not exactly a bug because users can't
 change the grid size), and found out the bezier patch was written for
 specifically 4x4 grids.
 The attached patch makes the bezier patch to work on every grid size
 defined (grid sizes could even be an option, although i think 4x4
 indeed gives the best effect).

I think the bezierPatchEvaluate function that your patch modifies is one
of the most CPU intensive functions that exist in the fdo compiz
plugins. Hence, I'm concerned about how this patch affects performance.
As the 4x4 grid still gives best results it might be better to just
remove those defines from the top of the file and add a comment about
the code being hard-coded to a grid size of 4x4.

- David

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


Re: [compiz] Re: Maximized windows dissappear

2007-05-01 Thread David Reveman
On Sun, 2007-04-29 at 15:17 +0100, Mike Dransfield wrote:
 Jesper Andersen wrote:
  Replying to my own email here:
 
  On Fri, 2007-04-27 at 09:05 +0200, Jesper Andersen wrote:

  I am using the lastest git version of compiz and just run in to a new
  problem after switching to using the ini configuration plugin over the
  gconf-one. When I maximize a window and then try to move it to another
  viewport, the cube rotates but the maximized window disappears instead
  of moving along to the new viewport. The maximized window can be found
  using the scale plugin (only on show-all action). Further, if I then try
  to unmaximize the window, the window again disappears and I have to use
  scale's show-all action. Now, however the window appears in some random
  almost out of viewport location and I have to drag it back into
  position.
 
  I do not know whether it was my switch to the ini plugin that caused
  this annoying change in behavior.
  
 
  I now tried with either gconf and ini (with the same settings) and
  nothing changes. However I noticed the following: whenever I move a
  window with some contents below the bottom edge of the screen to another
  viewport, it is immediately displaced on the new viewport so that most
  of the window's content is above the top edge of the screen. How much
  seems related to how much was hidden below the bottom edge before the
  move (this is only when moving a window to a new viewport by
  AltShiftLeft/Right and similar, not for the usualy mouse-dragging of
  windows and also not for windows that are beyond any other screen
  edges). I have tried toggling the Constrain y option in the
  move-plugin to no avail. I also tried changing the detect outputs in
  the general options, also to no avail.
 
  I am not sure when this strange behavior was introduced and I am
  wondering whether I am really the only one seeing this?
 

 
 No you are not.
 
 I can see both of these problems now and I have tracked the
 problem down to the moveWindowToViewportPosition function
 OR the w-output.top calculation.
 
 The exact line is this one
 
 if (m - w-output.top  w-screen-height - vHeight)
 
 In the case I just tested this variables had these values.
 
 m = 20
 w-output.top =23
 
 w-screen.height and vHeight are both 1050.  This if statement
 returns true because -3  0 and it shifts the window down.
 
 Sorry, I am not sure how to best fix this one but it is a reproducible
 problem.
 
 I also see the offset problem as well and suspect its related to the
 same thing.

It should now be fixed. Thanks for tracking this down, Mike.

- David

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


  1   2   3   4   >