Re: AW: Re: [compiz] [PATCH] minimize doesn't respect "no core instance" flag
Hi, > > A plugin wants to hide windows by preventing their drawing - that's all > > group wants to do. > > What's the correct way to do that? From my understanding, that's > > NO_CORE_INSTANCE_MASK. If that's not true, what's the exact meaning of that > > flag? > > Another way to do that would be to just return from paintWindow instead of > > calling the next plugin, but I think that's a bad solution. > > NO_CORE_INSTANCE_MASK just prevents the core from drawing it's instance > of the window. There's currently no way to prevent other plugins from > drawing a window and I'm not sure how an interface for doing that would > best look like. OK, if there is no proper way to do that yet and as you have promised we'll have a nice interface for draing hidden windows soon ;-), I'll do it the "unclean" way for now by just returning TRUE from drawWindow instead of calling the next plugin in the chain. I realize there are obvious problems with that (such as the need to be loaded after decoration), but as this solution is only needed for a limited amount of time, it should be good enough. Regards, Danny ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] decoration plugin window matching
On Fri, 2007-03-09 at 22:24 +0100, Bellegarde Cedric wrote: > Le vendredi 9 mars 2007, vous avez écrit : > > Any reason you made that a screen specific option? I'd prefer it as a > > display specific option as we already got some of those in the > > decoration plugin. > > It's really a good question i will be happy to have an answer :) > > When an option should go in display and when should it go in screen ? > > In fact, i put it in screen because other matching options are in screen for > others plugins. Multiple screens are rarely used and even if you use that you want most options to be common for all screens, except obvious ones like sync_to_vblank, refresh_rate... The action interface doesn't support screen options yet so all actions options must currently be display options. Screen options are used a lot because it's more convenient as you usually need to access them in some wrapped screen function but that's probably a bad habit. Display options are preferred and I've even been thinking about removing screen options all together and just use lists of display options for those things that really need to be per screen but I'm not sure that this a good idea. Anyhow, use display options as much as possible. Especially, in this case where all existing options are display options. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: AW: Re: [compiz] [PATCH] minimize doesn't respect "no core instance" flag
On Fri, 2007-03-09 at 21:47 +0100, Danny Baumann wrote: > Hi, > > Let me ask in a more general way: > > A plugin wants to hide windows by preventing their drawing - that's all group > wants to do. > What's the correct way to do that? From my understanding, that's > NO_CORE_INSTANCE_MASK. If that's not true, what's the exact meaning of that > flag? > Another way to do that would be to just return from paintWindow instead of > calling the next plugin, but I think that's a bad solution. NO_CORE_INSTANCE_MASK just prevents the core from drawing it's instance of the window. There's currently no way to prevent other plugins from drawing a window and I'm not sure how an interface for doing that would best look like. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
AW: Re: [compiz] [PATCH] minimize doesn't respect "no core instance" flag
Hi, Let me ask in a more general way: A plugin wants to hide windows by preventing their drawing - that's all group wants to do. What's the correct way to do that? From my understanding, that's NO_CORE_INSTANCE_MASK. If that's not true, what's the exact meaning of that flag? Another way to do that would be to just return from paintWindow instead of calling the next plugin, but I think that's a bad solution. Regards, Danny - Ursprüngliche Nachricht - Von: "David Reveman" <[EMAIL PROTECTED]> An: "Danny Baumann" <[EMAIL PROTECTED]> Cc: compiz@lists.freedesktop.org Gesendet: 09.03.2007 14:13 Betreff: Re: [compiz] [PATCH] minimize doesn't respect "no core instance" flag On Wed, 2007-03-07 at 14:39 +0100, Danny Baumann wrote: > Hi, > > In current git, minimize doesn't respect the > PAINT_WINDOW_NO_CORE_INSTANCE_MASK flag set by other plugins. I noticed > that especially in group: Tabbed windows are hidden by setting > PAINT_WINDOW_NO_CORE_INSTANCE_MASK. When these windows are minimized > together with their group, minimize draws its animation regardless if > that flag is set or not; with the effect of the hidden windows appearing > during the time of animation. > I've attached a patch which makes minimize respect that flag; however, > I'm not completely sure if that is the best way to do it or if it would > be better to do the animation drawing inside of drawWindow(). > > What do you think? Plugins are not supposed to look at the PAINT_WINDOW_NO_CORE_INSTANCE_MASK flag. It's supposed to be a write-only flag for plugins. I'm not sure what's the best solution is here as I don't know exactly how the group plugin works. Checking if the PAINT_WINDOW_NO_CORE_INSTANCE_MASK flag is preset is definitely not the correct solution though. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] decoration plugin window matching
On Mon, 2007-03-05 at 13:01 +0100, Bellegarde Cedric wrote: > Here a patch to enable window matching in decoration plugin: > > http://hibbert.univ-lille3.fr/~cbellegarde/Compiz/decor_match.patch Nice. Any reason you made that a screen specific option? I'd prefer it as a display specific option as we already got some of those in the decoration plugin. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] video plugin?
On Thu, 2007-03-08 at 15:05 +0100, Matthias Hopf wrote: > On Mar 07, 07 21:15:39 +0100, dragoran wrote: > > thx I missed this mail... > > I apparently didn't receive this mail as well... > > > >I've created a patch to mplayer's xv output code that makes it use > > >compiz video interface when available. Works pretty well and it even > > >dynamically detects when the compiz video interface isn't available > > >anymore and then switches to xv instead. Similar patches can easily be > > >created for other video playback clients, of course. > > Have you mailed this patch to the mplayer mailing list? Though I doubt > they will allow a patch that interferes with the xv output plugin. It > probably should go into a new output plugin. No I haven't mailed it to the mplayer list. I don't think it should be included in it's current state. Yes, it should go into a new plugin but this new plugin should still support xv output as you want to dynamically fall-back to that when the compiz interface isn't available. It should probably go into an xv-compiz output plugin but some code sharing between the existing xv module should probably be done then. > > I'll go for xine and create an according output plugin. Great! - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] minimize doesn't respect "no core instance" flag
On Wed, 2007-03-07 at 14:39 +0100, Danny Baumann wrote: > Hi, > > In current git, minimize doesn't respect the > PAINT_WINDOW_NO_CORE_INSTANCE_MASK flag set by other plugins. I noticed > that especially in group: Tabbed windows are hidden by setting > PAINT_WINDOW_NO_CORE_INSTANCE_MASK. When these windows are minimized > together with their group, minimize draws its animation regardless if > that flag is set or not; with the effect of the hidden windows appearing > during the time of animation. > I've attached a patch which makes minimize respect that flag; however, > I'm not completely sure if that is the best way to do it or if it would > be better to do the animation drawing inside of drawWindow(). > > What do you think? Plugins are not supposed to look at the PAINT_WINDOW_NO_CORE_INSTANCE_MASK flag. It's supposed to be a write-only flag for plugins. I'm not sure what's the best solution is here as I don't know exactly how the group plugin works. Checking if the PAINT_WINDOW_NO_CORE_INSTANCE_MASK flag is preset is definitely not the correct solution though. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Plugin Library Interface
On Wed, 2007-03-07 at 14:28 +0100, Patrick Niklaus wrote:
> Hi,
>
> some of you might noticed that there was recently some discussion on
> the Beryl ML about an interface which provides sharing functions and
> allows us to do library plugins. One example for this kind of plugins
> is text, which was recently ported to that system. I now want to
> explain here how it works in general.
>
> Core does save the shared library functions in a CompLibraryFunction struct:
> struct _CompLibraryFunction {
> CompLibraryFunction *prev;
> CompLibraryFunction *next;
>
> char *name;
> void *function;
> };
>
> Core also gets a number of utility functions:
>
> void addLibraryFunction (CompDisplay *d, char *name, void *function);
> void removeLibraryFunction (CompDisplay *d, char *name);
> void* getLibraryFunction (CompDisplay *d, char* name);
> void updateLibraryFunction(CompDisplay *d, CompLibraryFunction *func);
>
> You can register a function through addLibraryFunction and remove it
> with removeLibraryFunction.
> Whenever a function gets added or removed updateLibraryFunction is
> called. Like initScreen/finiScreen it's done through a additional
> entry in the vTable. It doesn't make sense to make this function
> wrap-able, it's just too important and no plugin should be able to
> stop or manipulate it.
>
> Plugins which need a shared function can get it through
> getLibraryFunction, most likely you will call that in initDisplay and
> just save the pointer to the function.
>
> When you want to see how exactly it's used in plugins you can have a
> look at text-plugin, which is in beryl-plugins at trunk
> (http://bugs.beryl-project.org/browser/trunk/beryl-plugins/src/text.c).
>
> We just want to get some feedback on these ideas. If you are
> interested I can provide a patch for compiz too.
Hey Patrick,
Thanks for your explanation. I don't know if this is a good idea or not.
Most of the interface we have on the core so far have specific needs and
I'm sure future interfaces will too. This library interface would have
to be extended to support cases like that. If we do that, then this
would work as a low level interface that other interfaces can be layered
on top of and plugins can create their own interfaces, which could make
sense but I'm not sure.
Anyhow, I'm not against this in it's current state even though it seems
an awful lot like just providing dynamic library loading which it makes
more sense to do using dlopen, dlsym...
If we have a case where this interface makes more sense than anything
else then fine with including it.
The text_to_pixmap interface is very specific and I don't think the
functionality itself is a good idea. What are the use cases for this?
For rendering text, I suggest that we create an interface that hooks
into the drawing framework and allow plugins to implement glyph caching
similar to what I once created for xgl and cairo's glitz backend.
Do you have other use cases for which this library interface fit in?
- David
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] compiz sometimes fails to redraw
Hello I am using a compiz from git 20070307 on my pc and laptop. Both are using the nvidia drivers 1.0-9755. On the pc I have a 7800GTX and everything works fine (1280x1024). On my laptop I have a 7600 Go 512MB and sometimes compiz does not redraw windows. for example I open firefox the first time it does not get drawn correctly I have to minimize and unminimize it first. Resulution is 1680x1050. Does anybody else notice this? If the 7600 with 512MB dedicated ram is to slow for compiz something must be broken in compiz. It can't be that a 7800GTX class card is required for a window manager. I have a 6600GT box too, but haven't tested yet. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] state of blur plugin
Joel Stanley wrote: Hello, On 2/7/07, David Reveman <[EMAIL PROTECTED]> wrote: I've added two small utility programs to git.compiz.org: git.compiz.org/blurset and git.compiz.org/blurdemo I'm triyng to clone these two repos, however, keep getting the following: $ git clone http://git.compiz.org/blurdemo /usr/bin/git-clone: 312: curl: not found This is your error, you need to install the curl package. These repos use http rather than git protocol. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] state of blur plugin
Joel Stanley schrieb: $ git clone http://git.compiz.org/blurdemo /usr/bin/git-clone: 312: curl: not found You have to install curl to be able to clone over http. Cannot get remote repository information. Perhaps git-update-server-info needs to be run there? Is this something I'm doing wrong, or something on the server side as the output suggests? ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
