Re: [compiz] video plugin?
On Mon, 2007-03-12 at 17:05 +0100, Matthias Hopf wrote: > On Mar 09, 07 14:20:08 +0100, David Reveman wrote: > > > 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 guess the best thing would be if the new module would call the xv > plugin dynamically if needed. So the code paths would remain clean. > > At least that's what I'll try to do with xine. > > David, one more question about this rendering technique (have to admit > that I haven't looked at the code yet): are overlays still possible, > that is can I render with standard X / OpenGL calls over an YUV image > that has been blitted by compiz? That is needed for about all > on-screen-displays and subtitles, because they are typically rendered in > different resolutions than the main video. No that's not possible. The best solution I could think of right now is to create a top-level ARGB window and position it above your video window. We could add another interface for OSD and subtitles but I think we should just wait until we've got proper retained mode graphics support in compiz before we add that. - 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
Hi, > We've done this before and the problem with this is that there might be > conflicts with other plugins. What if some other plugin also wants to > transform the core instance? Having plugins animate a separate instance > of the window instead of the core instance gives us a well defined > behavior in all situations. If plugins are animating the core instance, > then you have an infinite number of possible states that the core > instance could be in as it's defined by the state of all loaded plugins. > > When writing a plugin, it's always a good idea to consider the case > where two instances of the plugin is loaded. That's of course not > something that has to be supported but if the behavior when having two > instances loaded is well defined, you're off to a good start. Well, this approach has obvious problems, too: With the "only one core instance" approach, the look of an animation could be pretty weird if there were multiple plugins animating at the same time. However, with the "one instance per animating plugin" approach, there would be multiple instances of the same window with different animations, which will look pretty weird as well ;-) It may be a matter of personal preference, but I prefer the "only one instance only" approach because it gives us the opportunity to hide windows completely, which the second approach doesn't provide. Additionally, I think the "look and feel" of this approach would look less weird to the end user than with the "multiple instances" approach. Also, I'm not completely sure what you mean by "possible states". I mean, the transformation of a window isn't a real state machine which needs state machine transitions where action 1 could influence if action 2 could be executed or not. In my opinion, plugins can act completely sepearately on the window transformation and the only question is if the result of the transformations look visually appealing or not. Maybe I am missing something - if I do, please enlighten me :-) Regards, Danny ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] KWD allowed actions
On Mon, 2007-03-12 at 11:43 +0100, Cedric wrote: > Here is a patch to make KWD respect restricted actions. > > http://hibbert.univ-lille3.fr/~cbellegarde/Compiz/kwd_allowed_actions.patch > Thanks, - 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 Sat, 2007-03-10 at 21:15 +0200, Roi Cohen wrote: > Hi, > > I think the problem is that a window should still be considered as a > core instance even if its transformed during the minimizing animation. > The minimize plugin breaks the core instance drawing with the > NO_CORE_INSTANCE mask, and draws its own instance of the window > instead with drawWindow (which skips the NO_CORE_INSTANCE check of > core). > I think a better solution will be painting the animated window as a > transformed version of the core instance. We've done this before and the problem with this is that there might be conflicts with other plugins. What if some other plugin also wants to transform the core instance? Having plugins animate a separate instance of the window instead of the core instance gives us a well defined behavior in all situations. If plugins are animating the core instance, then you have an infinite number of possible states that the core instance could be in as it's defined by the state of all loaded plugins. When writing a plugin, it's always a good idea to consider the case where two instances of the plugin is loaded. That's of course not something that has to be supported but if the behavior when having two instances loaded is well defined, you're off to a good start. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] video plugin?
On Mar 09, 07 14:20:08 +0100, David Reveman wrote: > > 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 guess the best thing would be if the new module would call the xv plugin dynamically if needed. So the code paths would remain clean. At least that's what I'll try to do with xine. David, one more question about this rendering technique (have to admit that I haven't looked at the code yet): are overlays still possible, that is can I render with standard X / OpenGL calls over an YUV image that has been blitted by compiz? That is needed for about all on-screen-displays and subtitles, because they are typically rendered in different resolutions than the main video. CU Matthias -- Matthias Hopf <[EMAIL PROTECTED]>, SuSE R&D, Zimmer 3.2.06, Tel. 74053-715 ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] gwd crash
Uh! I forgot about that: I installed the avant-window-navigator using this repository: http://awn.wetpaint.com/page/Ubuntu+Edgy+Repository Now I reverted to the original ubuntu packages and gwd works great. Sorry, I really forgot about those packages. Thanks, Pierpaolo On 3/12/07, dragoran <[EMAIL PROTECTED]> wrote: > are you using a patched libwnck? if yes with patches are you using? > thanks > -- Pierpaolo Follia http://madchicken.altervista.org/tech ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] Where are we going?
Hello All, The Managing Committee has spent quite a bit of effort over the last two months trying to define the direction and goals of compiz. One of the issues we struggled with was how to define the scope of compiz broad enough to include everything the community is interested in, while still keeping it compact enough to be easily included as a component in a desktop environment (DE). After much discussion we concluded that the best answer was to split compiz into two divisions. Here is a draft proposal that defines how we'd like to do this: Compiz-Core * The Compiz-Core division will include the code of the current core plus core plugins that provide essential functionality (a subset of the current compiz package). * The package will be called "compiz". * Compiz will be extremely stable with the relatively narrow focus of being a compositing window manager that will run on X Server and can be integrated into any DE. * It will not include any functionality or code that replaces similar functionality in a DE unless it is required for compiz to operate correctly. * The Compiz-Core community will focus on core developers and plugin developers and will primarily use the compiz mailing list and the wiki. * The goal of Compiz-Core is for compiz to become a universal compositing and window manager layer on top of X Server, which can be integrated into all major DEs and included by default in all major distributions. Compiz-Extra * The Compiz-Extra division will include plugins and other programs that provide functionality which is not essential to the operation of the core (compiz-extra, plus some plugins from compiz, plus other programs). * We are currently calling this division and package "compiz-extra" but this may change as the community and project scope grows and evolves. * Compiz-Extra will have a broad focus on plugins, decorators, libraries, and other programs and will include stable, developmental, and experimental code. * It will include functionality and code that can be used universally, used with a specific DE, or can be run on compiz without a DE. * The Compiz-Extra community will focus on the developers creating and maintaining the compiz-extra programs and on end users. It will primarily use the wiki and the forum. * The goal of the Compiz-Extra division is to develop compiz related software and support the use of compiz on all desktops. Creating these divisions would have very little immediate effect on our community. Other than moving some code out of the core package, this is really just a definition of what we're doing now. The real benefit comes in the future as the Compiz-Extra division grows and is free to create new desktop programs and libraries without endangering the adoption of compiz by existing DEs. Once everyone has had opportunity to read and discuss this proposal we'll post a final version on the wiki. Shortly after that we'll post a draft roadmap based on the final version which we can work on and discuss. This is also posted on the forum: http://forum.go-compiz.org/viewtopic.php?t=677 Jeff ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] gwd crash
Hi, I have a problem when I right click over the title bar of some windows: often gtk-window-decorator crashes and I have to reload it. Here is the backtrace: #0 0xb7f47677 in wnck_workspace_get_viewport_x () from /usr/lib/libwnck-1.so.18 #1 0x080523b2 in action_menu_map (win=0x0, button=3, time=1170838320) at gtk-window-decorator.c:4261 #2 0x08052b5a in event_filter_func (gdkxevent=0xbfae3848, event=0x80ac510, data=0x0) at gtk-window-decorator.c:4820 #3 0xb7a95021 in gdk_x11_drawable_get_xdisplay () from /usr/lib/libgdk-x11-2.0.so.0 #4 0xb7a9678c in gdk_events_pending () from /usr/lib/libgdk-x11-2.0.so.0 #5 0xb7a983bb in _gdk_events_queue () from /usr/lib/libgdk-x11-2.0.so.0 #6 0xb7a987bf in _gdk_events_init () from /usr/lib/libgdk-x11-2.0.so.0 #7 0xb7785802 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #8 0xb77887df in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #9 0xb7788b89 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #10 0xb7c0f574 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #11 0x08056e6b in main (argc=Cannot access memory at address 0x0 ) at gtk-window-decorator.c:6322 Can someone help me? thanks -- Pierpaolo Follia http://madchicken.altervista.org/tech ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] [PATCH] KWD allowed actions
Here is a patch to make KWD respect restricted actions. http://hibbert.univ-lille3.fr/~cbellegarde/Compiz/kwd_allowed_actions.patch Cedric ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
