Re: [compiz] Coding standard
In compiz++ I've made few little changes that do not follow the our previous
coding style:
- allow variable definition in for loops:
for (int i = 0; i foo; i++)
In the C version of compiz we've tried to follow the C89 rules, but this is
not necessary anymore and should improve readability.
- define variables not at the top of a function:
For references we have to define a variable at the point where it gets
initialised. I would like the keep the define the variables at the top of a
function style, but we should allow in body variable definition, at places
where it improves readability of the code.
- indent case statements inside of switch statements:
in the C version of compiz we aligned the case statements at the same level
like its switch statement:
switch (foo)
{
case foo1:
break;
case foo2
break;
}
I think that indenting the case statement is a better style here:
switch (foo)
{
case foo1:
break;
case foo2:
break;
}
Another style rule that I would like to add to our coding style is to provide
a consistent system to mark differences between function local variables,
function parameters, class member variables and global variables.
I have already two possible solutions here:
Solution 1:
postfix member and global variables with a _
prefix function parameter with a _
Solution 2:
prefix member variable with m_
prefix global variables with g_
For my diploma thesis I'm currently working on a C++ tool that already uses
the first rule, and I've realized that it really improves readability of the
code, because it's pretty clear where a variable is coming from. I would
really like to get the opinions and solutions of other developers here.
Dennis
Am Dienstag 03 Februar 2009 16:46:27 schrieb Kristian Lyngstol:
I've been trying to come up with some good coding standards, but I've
realized that most of us already know most of this. So instead of trying to
define every aspect of how we code Compiz-code, I'll try to outline some of
the finer points. For a more complete list, you can review any of the many
coding-standard documents out there (For Linux, FreeBSD or any other
project).
Part of this draft is designed to document the already undocumented code,
which means some additional work for developers working on existing code.
I hope the degree of work expected is acceptable.
Note that this is a very rough draft.
1. Maintainability
Your code will be used by thousands of users, and it will be used even if
you no longer find yourself working on Compiz. Design your code with this
in mind. Remember that if you can get 90% of the functionality with 10% of
the work, that's a good thing.
Split your code into logical pieces. Ideally, functions span 1-3 screens
on a 80x25 terminal. Complex functions should strive for a smaller size,
while simple functions (like initialization of large structures) could be
quite long. If your function is one big if-elseif-elseif-...else-
statement, each block should be tiny or split out into separate functions.
Performance-wise, there's nothing stopping you from using an
inline-function to achieve the same performance with increased readability.
To reduce complexity, clear and well defined interfaces are needed. The
fewer interfaces we need, the better. This goes for both core-plugin
interaction, and interaction between different parts of core or a plugin.
If you can't avoid complexity, attempt to separate it from the rest of the
code as much as possible, and make sure it's well-documented in-line in
your code. Any special exceptions you have to make should be documented in
the code. Which brings us to...
2. Document your code
Note that from now on, it is your responsibility to document code you work
on, even if you aren't the original author. Commits that lack the necessary
documentation is likely to be revoked. There are exceptions to this, but
read on.
This does not mean writing on the wiki, writing a seperate text file or
publishing a book. It means that you stick a little comment in each file
under the license explaining very briefly what the plugin does, and if
there are any special tricks used. And it means that if you work on any
non-trivial function, make sure you stick a comment on top of it explaining
what it does and how to use it, if it isn't evident.
If in doubt, make a comment.
There's a formula for when to do this, which is loosely based on
complexity, importance and how exposed your function is. This basically
means that ANY core function that is not declared static should be
documented. For core functions, you should also mention where you want this
function to be used, even if it might already be obvious from header-files.
This is specially important with functions that are only safe or valid in
certain contexts.
As for exceptions: If you are only tweaking an existing function, for
instance to adjust it to an API change, it is not required to comment. If
you are
Re: [compiz] [ANNOUNCE] Compiz feature branch compiz++
Colin Guthrie wrote: 'Twas brillig, and Dennis Kasprzyk at 24/12/08 12:48 did gyre and gimble: snip Just a quick query, is this an all-or-nothing proposal or can some bits be split out? e.g. the C++ bit... I'd imagine it's the most controversial part of the proposal. I have some proove of concept code for things like the reparenting support, a new wrapping system and the copy to pixmap code, but nothing really ready. In the compiz++ branch I've simply combined all the things I've played with in the last 2 years. I'm in no position to comment in any sort of educated way about C vs. C++ in compiz, but I'd generally suspect that C would still be the preferred route by most developers even if it is more effort. Col ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [ANNOUNCE] Compiz feature branch compiz++
Kristian Lyngstol wrote: On Wed, Dec 24, 2008 at 01:48:17PM +0100, Dennis Kasprzyk wrote: - No direct access to member variables: Everything is now done with getter and setter functions. This helps with the problem where every variable addition broke the plugin ABI. While this usually is not a problem in the development tree, we can not do it in a stable tree. Even if it is needed to fix a bug. It also gives us more control what other plugins can do, so that broken plugins can not mess up our core structures. How does this relate to the fundamental issue where we simply have way too many variables available under one or two data structures? I believe the biggest problem we've had is the sheer size of the core structures and their lack of documentation which has led to misuse. The get/set for ABI compatibility is not unimportant, but it doesn't solve the underlying problem. The separation of the compositing and opengl rendering into individual plugins, creates already smaller data structures. With the drop of the multi-display and multi-screen support, also all the X Atoms and GL function pointers/properties have been moved out into namespaces, and are not part of the data structures anymore. The use of setter/getter functions also helps us to reduce API here, because I've only added this functions for variables, that are currently needed in other plugins (there might still be some functions missing for other plugins). This doesn't fix the problem of missing documentation, but at provides a cleaner API. - Composite/OpenGL seperation: All XComposite handling is moved into the composite plugin and the opengl rendering into the opengl plugin. This allows compiz to run also as normal window manager without compositing (still needs some work and a few new plugins), but also the creation of other rendering backends (XRender, clutter, ...). What are the specifics for this interface? The composite plugin only provides 3 base functions preparePaint, paint and donePaint (same functionality like preparePaintScreen, paintScreen, donePaintScreen in C compiz) for normal plugins. For rendering plugins like the opengl one it has an additional prepareDrawing and paintOutputs function interface. PrepareDrawing is called before any rendering starts and paintOutputs is called in the core implementation of the screen paint function chain. This interface should be flexible enough to support any rendering system, even scene graph APIs. The opengl plugin then implements all the other drawing functions that are currently in the C version of compiz. - Tiled textures: Modifications to the texture system allow to have more than one texture per pixmap and also to have other plugins that provide texture from pixmap functionality. The new copytex uses the (slow) copy pixmap content to texture approach to provide texture from pixmap functionality. It's main advantage is that it supports pixmaps bigger than the maximum texture size. In this cases a pixmap is split into multiple textures. Compiz will use the glx texture-from-pixmap extension for pixmaps/windows but will fall back to the copytex plugin if thex are bigger than the maximum texture size. What are the specifics for this interface? The opengl plugin allows other plugins to hook into the pixmap binding system (GLTexture::BindPixmapHandle registerBindPixmap (GLTexture::BindPixmapProc);). All pixmap bind and image load (not finished yet) functions now return a list instead of a single texture. Each of the returned textures can represent a part of the original pixmap/image. In most cases only one texture will be returned. C++ make here the whole system a little smarter. Copying the the texture list increments automatically the reference counters of the textures and deleting the list automatically frees all the texture objects. The GLTexure class is only a base class for the different Texture types (TfpTexture, CopyTexture) and avoids a complex wrapping system / a lot of function pointers, that would be in a C implementation. - Reparented decorations: Like other window managers, compiz now supports reparented window decorations. This will allow compiz to run as a normal window manager and to be able to have decorations for windows that are bigger than the maximum texture size (copytex plugin). (Currently only implemented in the kde4-window-decorator) What specific bugs does this solve, what are the concerns that it will bring? What is the reason for the original design? Pros and cons. Reparenting is the only way to get window decorations in sync with the window during movement in a non composited environment. I've tried different ways for window decorations in the last 2 years, but reparenting is the only really working system. Is this an optional feature, or is it always enabled in your branch? Is it implemented as a plugin? No really. The normal (current C compiz) decoration system is still
[compiz] [Annoucement] Compiz feature branch compiz++
of compiz is something that everyone involved in compiz should make. Espesially because it would need a huge amount of work to get all plugins ported. In my opinion, it would be better to stay with the old system if such change would create a fork again. I've also pushed compiz++ branches into the libcompizconfig, bcop and crashhandler repositories. They contain some initial work for the compiz++ branch. The crashhandler branch also contains a modified (not finished) version of the universal Makefile. Merry Christmas Dennis Kasprzyk * multi display: Connect to multiple x servers multi screen: seperated screens (usually different graphic cards) not connected with xinerama multi head: multiple monitors in a xinerama/randr 1.2 configuration (still supported) ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] [ANNOUNCE] Compiz feature branch compiz++
of compiz is something that everyone involved in compiz should make. Espesially because it would need a huge amount of work to get all plugins ported. In my opinion, it would be better to stay with the old system if such change would create a fork again. I've also pushed compiz++ branches into the libcompizconfig, bcop and crashhandler repositories. They contain some initial work for the compiz++ branch. The crashhandler branch also contains a modified (not finished) version of the universal Makefile. Merry Christmas Dennis Kasprzyk * multi display: Connect to multiple x servers multi screen: seperated screens (usually different graphic cards) not connected with xinerama multi head: multiple monitors in a xinerama/randr 1.2 configuration (still supported) ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] [ANNOUNCE] compiz-0.7.6
A new compiz release 0.7.6 is now available from: http://xorg.freedesktop.org/archive/individual/app/compiz-0.7.6.tar.gz which can be verified with: http://xorg.freedesktop.org/archive/individual/app/compiz-0.7.6.tar.gz.sha1 be55dada77dc0716a040c2b9e2d16a0fbc736180 compiz-0.7.6.tar.gz http://xorg.freedesktop.org/archive/individual/app/compiz-0.7.6.tar.gz.sha1.asc (signed by Dennis Kasprzyk) Additionally, a git clone of the source tree: git clone git://git.freedesktop.org/git/xorg/app/compiz will include a signed compiz-0.7.6 tag which points to a commit named: 9b739fd78cb3f43fa56e14294b171b695340952e which can be verified with: git verify-tag compiz-0.7.6 and can be checked out with a command such as: git checkout -b build compiz-0.7.6 WHAT'S NEW == Rewrite of place plugin, which significantly improves multi-output behaviour. Configurable multi-output behaviour in place. Removed plane plugin. Former plane plugin users are encouraged to use the wall plugin of Compiz Fusion. Removed cube wallpaper painting. Users are encouraged to use the Compiz Fusion wallpaper plugin instead. Place plugin viewport placement viewport numbers are now 1-based. Panel and desktop selection mode in switcher plugin. Improved painting behaviour when using overlapping outputs. Gtk-window-decorator now emits accessibility events when switching. Gtk-window-decorator behaviour when using Metacity themes has been improved to match Metacity better. KDE4-window-decorator has been adapted to current KDE4 API. Various bugfixes. Regards, Dennis Changes since compiz-0.7.4: C-F Language team (2): translation updates translation updates Daniel Lea (1): Fix skydome animation tilt behaviour. Danny Baumann (71): Always also add the opposite button when adding a stick/above/shade button. Also set shaded flag. If we got an empty rect, assume the button is not present. Keep Valgrind silent. Above, shade, stick buttons are not available in Metacity = 2.16. Factor out adjustment of configure requests for gravity in a separate function and use this function to also adjust ConfigureRequest events of unmanaged windows for gravity. Remove unused code. Better function grouping / ordering. Improve define order. Replace get_window_[width|height] functions by helper macros. Improve macro usage. window - w Improve looping over all visible windows. Consistently use Compiz coding style. Skip override_redirect windows during smart placement. Factor out cascade placement into separate function. Drop glib dependency of place plugin. Replace placeWin function by a better structured placeDoWindowPlacement function. Placement strategy (What should placement do to this window?) and output determination as well as work area constraining have been factored out to separete functions. Minor optimization. Pass work area into cascade placement functions. Add helper macro for looping over all placement relevant windows. Initialize count variable correctly. Fix typo. Improve readability of placement relevance helper macro. Added option for multi output behaviour of place and added a Place on output which has the pointer mode. Place dialogs centered on current output device rather than centered on screen. Fix warning. Make the placeGetPlacementOutput function return a CompOutput pointer. Clamp new position if a viewport match was given. If the new position was outside the visible screen area before, the window would be placed on a viewport different to the one specified otherwise. Fix whitespace. Move style window offscreen to make sure it never is visible on screen. Minor cleanup. Added panel selection mode to switcher plugin. Update default window match to account for panel selection mode. Reduce code duplication. Cleanup. Properly destroy popup windows on unload. Keep switcher window property at an invalid value as long as the switcher is not active. Only update accessibility helper label if switched window has actually changed. Only accept USPosition on non-normal windows during validation if workarounds are disabled. Also use the multi output mode selection option when placing centered. Disable resize handles for the directions the window is maximized to (leave only left and right enabled for vertically maximized windows, top and bottom for horizontally maximized windows). Remove plane plugin. Don't allow to minimize/showdesktop unmanaged windows. Don't prevent focus for windows on other viewports if they are excluded from focus stealing prevention. Only set CWX / CWY if the position was actually changed. Don't adjust configure
[compiz] [ANNOUNCE] compiz-0.7.0
A new compiz release 0.7.0 is now available from: http://xorg.freedesktop.org/archive/individual/app/compiz-0.7.0.tar.gz which can be verified with: http://xorg.freedesktop.org/archive/individual/app/compiz-0.7.0.tar.gz.sha1 59b019b6cd627140f44006876ee2b0c3ab92f150 compiz-0.7.0.tar.gz http://xorg.freedesktop.org/archive/individual/app/compiz-0.7.0.tar.gz.sha1.asc (signed by Dennis Kasprzyk) Additionally, a git clone of the source tree: git clone git://git.freedesktop.org/git/xorg/app/compiz will include a signed compiz-0.7.0 tag which points to a commit named: a6763350ba9a578e9df6adbdb7eadc174015c960 which can be verified with: git verify-tag compiz-0.7.0 and can be checked out with a command such as: git checkout -b build compiz-0.7.0 WHAT'S NEW == A core plugin has been added that allows handling certain core APIs, such as querying the ABI version, similarly to plugin APIs, allowing sharing more code. Added a simple object system, which generalize the privates mechanism and the plugin system. It allows to share more code between display, screen and window objects. It also makes it possible to properly introduce new object types without changing the plugin interface or breaking the API. Multi-display support. Various fixes in ICCCM compliance, window stacking and focus handling. Validity checking of ConfigureRequest events. Fixes to transient children placement in place plugin. Hooks have been added to the cube plugin which allow better control of viewport drawing. Middle and right click actions have been made configurable in gtk-window-decorator. Gtk-window-decorator now optionally allows mouse wheel title bar actions, such as shading. A KDE4 port of the kde-window-decorator has been added. Frequent crashes of kde-window-decorator for some people have been fixed. Regards, Dennis Changes since compiz-0.5.4: Alyssa Hung (1): * Also account for window borders when ensuring that transient windows are fully visible on the current workspace. C-F Language team (3): translation updates translation updates translation update Compiz Fusion l10n team (1): Translations update Danny Baumann (168): Add edge action for Show desktop. Never modify w-state outside changeWindowState function. Don't save last window state in CompWindow structure. Coding style adjustments. Added button bindings for initiating scale. Added button bindings for rotating left/right. Only show resize rectangle on the screen the resized window is on. Re-add rotate_right_key option to metadata which was removed by accident. Only assign the default shadow to windows which use default decorations. Fix copy'n'paste mistake. Free core private index, not display private index. Remove frame window property on removing the window frame. Minor cleanup. Remove Metacity bell settings integration. Added mouse wheel handling to g-w-d. Integrate Metacity's configurable middle and right click actions. Correct default behaviour of middle mouse button: It should be lowering the window, not raising it. Added minimization as title bar button action. Fixed Gconf setting parsing for title bar button actions. XineramaQueryScreens is not guaranteed to set the number parameter to zero if it returns NULL, so better initialize the parameter properly. Properly remove window decorations on plugin unload. Use normal mode for maximized windows. Translation update for pt by Nicolau Goncalves. Translation update for it by Milo Casagrande. Check for changes to the override_redirect flag on window map. Recalculate window type and window actions if override_redirect state changed. Handle MapRequest event after core so that decorWindowUpdate sees window type and override_redirect state changes that might have happened during event processing. Re-query Xinerama information on root window reshape. Always update event windows when the allowed actions have changed. Revert Handle MapRequest event after core so that decorWindowUpdate sees window type and override_redirect state changes that might have happened during event processing. Call matchPropertyChanged handler when the override_redirect flag changed. Allow plugins to not only clear allowed window actions, but also to add allowed actions. Bump ABIVERSION. Whitespace and formatting improvements. Only copy structures when needed. Formatting fix. Include compiz-core.h before Xrender.h because newer versions of Xrender headers need Xlib.h included first. Fix whitespace. Minor cleanup. Add minimum and maximum restrictions for opacity values. Only apply clipping planes when the cube is actually rotated. Fix
Re: [compiz] fonts unreadable on resize
Am Freitag, 28. Dezember 2007 23:51:41 schrieb Bill Moseley: I have the Resize info feature enabled on my desktop and on my laptop both running Gutsy. on the desktop the fonts are impossible to read: http://hank.org/resize.png but are very clear on the laptop. And tips to fix? Do you have a nvidia card in your desktop? I had the same problem with the 100.x.x driver and it's gone with the 169.x driver. Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Tooltips show up on all screens of cube
Am Mittwoch, 26. Dezember 2007 06:50:36 schrieb Erkin Bahceci: On Dec 4, 2007 1:01 PM, David Reveman [EMAIL PROTECTED] wrote: 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 Hi, Won't the user always be on the same viewport where the tooltip/menu is actually shown? (since it opens because the user is interacting with an application on that viewport). If that's the case, the user will always be able to interact with the menu, so we could just not paint override_redirect windows (menus, tooltips) on all viewports, with the attached patch. If there is any case where the menu opens up on another viewport (is that even possible?), I think only then we should render it on all viewports (or at least on the active viewport), so that the user can interact with it. Regards, Erkin I don't think that this patch is the final solution. We will need a system to detect the main application window of a override redirect window and then only show it on the same viewport. I know that your patch fixes the problem, but I'm already thinking about input redirection. Once we have input redirection we will need to have a system to detect that a override redirect window belongs to given application window, because we want to transform menus/tooltips in the same way like the main application window. I think that there will be an (we should define one ;-) EWHM spec in the future that will give us this information, but we will need to find a solution for older applications anyway. I'm not saying that your patch shouldn't be included, because this is a decision that David should make, but maybe you could also try to find a more generic solution for both probelms. Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] GL_MAX_TEXTURE_SIZE and dual-screens
Am Samstag, 1. Dezember 2007 12:10:51 schrieb Xavier Bestel: Hi, I'm running compiz on a r300, dual-screens setup. The r300 driver has a GL_MAX_TEXTURE_SIZE = 2048 limit, and it shows: the nautilus backdrop window doesn't cover both screens. Is there a mean to let compiz sort of split the nautilus window to stay within the 2048 limit on each screen ? I've posted a patch to this mailing list a while ago (WARNING ONLY A PROOF OF CONCEPT: copy texturing to fix maximum texture size restrictions) that was using copy to texture to fix this problem. But compiz will need some internal changes to allow an implementation of such system in a clean way. I'm sorry, but you will have to wait. Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Open issues with localisation/internationalisation by Compiz Fusion KDE 0.6.2-3.1?
Am Montag 19 November 2007 19:53:38 schrieb Markus Elfring: 1.1 The context/actions menu that appears after a right click on the window title is displayed in English despite German is my primary language in the regional settings. I assume that translations will be improved in the near future. Suse issue... The entries are correctly translated before Compiz Fusion is started. Is there any GUI synchronisation involved via the desktop communication protocol to retrieve the correct labels? Regards, Markus ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz I've currently commited a fix for the window menu translation to master and the compiz-0.6 branch. Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [ANNOUNCE] compiz-0.5.4
Am Mittwoch 22 August 2007 00:20:37 schrieb Kristian Høgsberg: On 8/21/07, Danny Baumann [EMAIL PROTECTED] wrote: Hi, 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. I think 0.6 got branched at a good time. The XCB requirement is something I'd like to avoid for this release. Yeah, I also think we definitely don't want the XCB requirement in the 0.6 release (sidenote: When will the libX11 1.1.2 specfile in CVS land in rawhide? ;-) ). Built :) The options rewrite looks like a big improvement, but it breaks compiz-fusion compatibility, so I think it makes sense to not include that in 0.6 either. The CF compatibility is no big deal, we just need a few days to adapt the code. The plugins, libcompizconfig and the backends are already done; just the python bindings and ccsm is missing at the moment. Is there a 0.6 branch for the CF plugins? Plugins-(main,extra,unsupported),bcop,ccs(libcompizconfig,backends,python bindings, ccsm) have been branched. Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [ANNOUNCE] compiz-0.5.2
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. Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Couldn't activate plugin 'rotate'
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). Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Core option sorting in metadata
Am Donnerstag 12 Juli 2007 00:40:41 schrieb David Reveman: On Wed, 2007-06-13 at 16:48 +0200, Danny Baumann wrote: Hi, currently, all sorting order of the core and core plugin options inside the metadata files is based on the order they are listed in the C source files. Unfortunately, that's not optimal for automatic settings manager GUI generation. DO you think it's ok to sort them by functional groups? This would have the advantage of settings managers being aware of the functional grouping, which would help a lot in creating them. I have attached a patch which re-sorts the core options a bit to reflect that - what do you think about it? Is this change ok to go in? A function attribute or function element should be added to the option element if functional groups are desirable. We already do grouping with the group/subgroup tags. We also add this information to the core/plugin options inside of the ccs configuration system. The problem here is that, if the options a,b,c,d,e are stored in this order in the metadata file and we group b,d,e, then they will also have the b,d,e order in the group even if e,b,d would make more sense (e,b,d,a,c could also make more sense without grouping). Changing the order inside of the configuration system will unnecessary increase complexity. The inclusion of the group/subgroup tags to the core metadata files should be handeled in a separate thread. Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] Metadata additions
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. 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 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. Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] CompComm has a real name!
Am Mittwoch 20 Juni 2007 18:52:28 schrieb Colin Guthrie: Jeffrey Laramie wrote: I'm pleased to announce that the chosen name of our project and community is: Compiz Fusion Just a few quick questions from a packagers perspective! Is the name Compiz Fusion as in both words or will it be referred to as just Fusion, but colloqually as Compiz Fusion etc. I'm thinking more along the lines of package names: e.g. Should you call the package compiz-fusion-plugin-zoom or fusion-plugin-zoom? (assuming zoom was packaged individually which I'm guessing it wont be but that's another point!) What will be the components of [Compiz] Fusion? I know there are several libs and other such stuff in git, but just wondering how the tarballs will look? Just trying to get a heads up so I can ensure I've got packaging working ahead of official release! Cheers Col Here a short nonfinal definition how the releases will look like: compiz-fusion-(main/extra/unsupported) : The automerged plugin repositories. compiz-bcop: The settings code generator that is needed to compile most of the plugins The alternative Compiz configuration system: libcompizconfig: The main library including the ini backend and the compiz configuration plugin compizconfig-backend-(kconfig/gconf): The desktop environment dependent configuration backends compizconfig-python: Python bindings for the configuration library compizconfig-settings-manager or ccsm: The python configuration tool for compizconfig. This can still change and we hope to finalize the naming stuff during the next days. Be also prepared that some of the git directories may also change during the next days. Regards, Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] window walking interface
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
From dbdda65693a002017eec3e058d45c9a56b2d2f90 Mon Sep 17 00:00:00 2001
From: Dennis Kasprzyk [EMAIL PROTECTED]
Date: Tue, 12 Jun 2007 17:59:28 +0200
Subject: [PATCH] Fixed FTB calculation for inside cube mode.
---
plugins/cube.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/plugins/cube.c b/plugins/cube.c
index 5e5eab3..ae3bf31 100644
--- a/plugins/cube.c
+++ b/plugins/cube.c
@@ -973,7 +973,7 @@ cubeCheckFTB (CompScreen *s,
ortho[1] = vecA[2] * vecB[0] - vecA[0] * vecB[2];
ortho[2] = vecA[0] * vecB[1] - vecA[1] * vecB[0];
-if (ortho[2] 0.0f)
+if (ortho[2] 0.0f pntC[2] DEFAULT_Z_CAMERA)
{
/* The viewport is reversed, should be painted front to back. */
return TRUE;
--
1.5.0.5-dirty
From 2c707d7bb1746ec7c856c2f7967a3e5f6000dd6b Mon Sep 17 00:00:00 2001
From: Dennis Kasprzyk [EMAIL PROTECTED]
Date: Tue, 12 Jun 2007 19:19:47 +0200
Subject: [PATCH] Added a wrapabble paintInside function to allow plugins to render something inside of the transparent cube.
---
include/cube.h |7 +++
plugins/cube.c | 20
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/include/cube.h b/include/cube.h
index 74cb360..0a87626 100644
--- a/include/cube.h
+++ b/include/cube.h
@@ -81,6 +81,12 @@ typedef void (*CubePaintBottomProc) (CompScreen *s,
CompOutput *output,
int size);
+typedef void (*CubePaintInsideProc) (CompScreen *s,
+ const ScreenPaintAttrib *sAttrib,
+ const CompTransform *transform,
+ CompOutput *output,
+ int size);
+
typedef Bool (*CubeCheckFTBProc) (CompScreen *s,
const ScreenPaintAttrib *sAttrib,
const CompTransform *transform,
@@ -121,6 +127,7 @@ typedef struct _CubeScreen {
CubeClearTargetOutputProc clearTargetOutput;
CubePaintTopProc paintTop;
CubePaintBottomProc paintBottom;
+CubePaintInsideProc paintInside;
CubeCheckFTBProc checkFTB;
CubeCapDirectionProc capDirection;
diff --git a/plugins/cube.c b/plugins/cube.c
index 5e3e8c5..dda6ea8 100644
--- a/plugins/cube.c
+++ b/plugins/cube.c
@@ -1367,6 +1367,13 @@ cubePaintBottom (CompScreen *s,
}
static void
+cubePaintInside (CompScreen *s,
+ const ScreenPaintAttrib *sAttrib,
+ const CompTransform *transform,
+ CompOutput *output,
+ int size) {}
+
+static void
cubePaintTransformedOutput (CompScreen *s,
const ScreenPaintAttrib *sAttrib,
const CompTransform *transform,
@@ -1508,14 +1515,24 @@ cubePaintTransformedOutput (CompScreen *s,
{
glNormal3f (0.0f, -1.0f, 0.0f);
if (cs-desktopOpacity != OPAQUE)
+ {
(*cs-paintBottom) (s, sa, transform, outputPtr, hsize);
+ glNormal3f (0.0f, 0.0f, -1.0f);
+ (*cs-paintInside) (s, sa, transform
[compiz] KDesktop 3 transparency patch
+ rc);
+
bool x_root_hack = args-isSet(x-root);
bool wait_for_kded = args-isSet(waitforkded);
@@ -194,11 +272,11 @@
testLocalInstallation();
// Mark kdeskop as immutable if all of its config modules have been disabled
-if (!app.config()-isImmutable()
+if (!myApp-config()-isImmutable()
kapp-authorizeControlModules(KRootWm::configModules()).isEmpty())
{
- app.config()-setReadOnly(true);
- app.config()-reparseConfiguration();
+ myApp-config()-setReadOnly(true);
+ myApp-config()-reparseConfiguration();
}
// for the KDE-already-running check in startkde
@@ -209,7 +287,8 @@
args-clear();
-app.dcopClient()-setDefaultObject( KDesktopIface );
+myApp-dcopClient()-setDefaultObject( KDesktopIface );
-return app.exec();
+
+return myApp-exec();
}
Index: kdesktopapp.h
===
--- kdesktopapp.h (Revision 0)
+++ kdesktopapp.h (Revision 0)
@@ -0,0 +1,67 @@
+/* This file is part of the KDE project
+ Copyright (C) 2007 Dennis Kasprzyk [EMAIL PROTECTED]
+
+ This library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Library General Public
+ License as published by the Free Software Foundation; either
+ version 2 of the License, or (at your option) any later version.
+
+ This library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Library General Public License for more details.
+
+ You should have received a copy of the GNU Library General Public License
+ along with this library; see the file COPYING.LIB. If not, write to
+ the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+ Boston, MA 02110-1301, USA.
+*/
+
+#ifndef __kdesktopapp_h__
+#define __kdesktopapp_h__
+
+#include config.h
+#include kuniqueapplication.h
+
+#if defined(Q_WS_X11) defined(HAVE_XRENDER) QT_VERSION = 0x030300
+#define COMPOSITE
+#endif
+
+#ifdef COMPOSITE
+# include X11/Xlib.h
+# include X11/Xatom.h
+# include fixx11h.h
+#endif
+
+class KDesktopApp : public KUniqueApplication
+{
+Q_OBJECT
+public:
+KDesktopApp();
+KDesktopApp(Display * dpy, Qt::HANDLE visual = 0,
+Qt::HANDLE colormap = 0);
+
+#ifdef COMPOSITE
+bool x11EventFilter (XEvent *);
+
+bool cmBackground ()
+{
+return m_bgSupported;
+}
+#endif
+
+signals:
+void cmBackgroundChanged(bool supported);
+
+#ifdef COMPOSITE
+private:
+void initCmBackground();
+
+private:
+
+Atom m_cmBackground;
+Bool m_bgSupported;
+#endif
+};
+
+#endif
Index: kdesktop.kcfg
===
--- kdesktop.kcfg (Revision 671918)
+++ kdesktop.kcfg (Arbeitskopie)
@@ -31,6 +31,11 @@
labelBackground cache size/label
whatsthisHere you can enter how much memory KDE should use for caching the background(s). If you have different backgrounds for the different desktops caching can make switching desktops smoother at the expense of higher memory use./whatsthis
/entry
+entry key=BackgroundOpacity type=Int
+ default100/default
+ labelBackground Opacity/label
+ whatsthisHere you can the opacity of the background (0-100). A composite manager can then render something behind it./whatsthis
+/entry
/group
group name=General
entry name=DesktopEnabled key=Enabled type=Bool
Index: kdesktopapp.cpp
===
--- kdesktopapp.cpp (Revision 0)
+++ kdesktopapp.cpp (Revision 0)
@@ -0,0 +1,95 @@
+/* This file is part of the KDE project
+ Copyright (C) 2007 Dennis Kasprzyk [EMAIL PROTECTED]
+
+ This library is free software; you can redistribute it and/or
+ modify it under the terms of the GNU Library General Public
+ License as published by the Free Software Foundation; either
+ version 2 of the License, or (at your option) any later version.
+
+ This library is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ Library General Public License for more details.
+
+ You should have received a copy of the GNU Library General Public License
+ along with this library; see the file COPYING.LIB. If not, write to
+ the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+ Boston, MA 02110-1301, USA.
+*/
+
+#include kdesktopapp.h
+
+KDesktopApp::KDesktopApp():
+KUniqueApplication()
+{
+#ifdef COMPOSITE
+initCmBackground();
+#endif
+}
+
+KDesktopApp::KDesktopApp(Display * dpy, Qt::HANDLE visual, Qt::HANDLE colormap):
+KUniqueApplication(dpy, visual, colormap)
+{
+#ifdef COMPOSITE
Re: [compiz] status of input redirection
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. Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Some suggestions for extra metadata
Am Montag 21 Mai 2007 15:01:49 schrieb Mike Dransfield: 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 A more general plugin info struct should be better info authorbob [EMAIL PROTECTED]/author authoralice [EMAIL PROTECTED]/author licenseGPL/license version0.1.0-git/version infourlhttp://www.example.com/plugin-info.html/infourl /info *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 We should handle feature not as uniqe and use conflict feature rules for features that should be unique. 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. I see no reason for this. matchhandler handler matchtitle/match !-- optional command to be run to get the attribute for a window -- commandxprop | grep ^WM_NAME | .../command This is a big security risk. /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 What about the subgroup tag that we already use in the opencomposite.org plugins? subgroup shortFoo/short option name=opacity_match ... /option option name=opacity_values ... /option /subgroup The setting application should detect if all options in a subgroup have the list type and provide the right interface for it. *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 Security risk again. Distributions don't like individual binary update systems. !-- 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 This should be on the plugin info page and not part of the metadata. Regards Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Some suggestions for extra metadata
Am Montag 21 Mai 2007 17:37:25 schrieben Sie: Dennis Kasprzyk wrote: Am Montag 21 Mai 2007 15:01:49 schrieb Mike Dransfield: 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 A more general plugin info struct should be better info authorbob [EMAIL PROTECTED]/author authoralice [EMAIL PROTECTED]/author licenseGPL/license version0.1.0-git/version infourlhttp://www.example.com/plugin-info.html/infourl /info Thats OK too, but the version should be split up or we end up with 1001 different versioning schemes and 1001 parsers for them. Autotools and pkgconfig seam to work well with one version string. Info is basically metadata so we probably don't need the extra info tags at all. But this improves readability. *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 We should handle feature not as uniqe and use conflict feature rules for features that should be unique. 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. I see no reason for this. It would allow a config app to know what window matching features are available and provide a gui for them. matchhandler handler matchtitle/match !-- optional command to be run to get the attribute for a window -- commandxprop | grep ^WM_NAME | .../command This is a big security risk. In what way? The app can decide whether or not to trust the source of the xml. Its only a suggestion to the app, it does not have to run it but it would be easier than telling the user to execute that in a terminal, or each app providing its own database of how to get each piece of information. Untrusted software can include xml files too so if people install unknown software from unknown sources, it can do whatever it likes anyway. /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 What about the subgroup tag that we already use in the opencomposite.org plugins? subgroup shortFoo/short option name=opacity_match ... /option option name=opacity_values ... /option /subgroup The setting application should detect if all options in a subgroup have the list type and provide the right interface for it. Its a different type of grouping. Your way would stop whatever you are using subgroup for from working if there are 2 list options in a group which are not grouped in this way. A simple example would be cube cap images and cube face images. They are both lists and could both be categorized as Appearance - Images. They would not have to have their order related in the same way. Maybe you should not use beryl-settings here as example here. But if you want we could add a autojoin=true attribute to the subgroup tag. *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 Security risk again. Distributions don't like individual binary update systems. The updates can always go into ~/.compiz/plugins which is nothing to do with the distributions. Something like this can work for python plugins but not for compiled c binaries. !-- 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 This should be on the plugin info page and not part of the metadata. This would allow config apps
Re: [compiz] place plugin
Am Montag 21 Mai 2007 21:34:26 schrieb Mike Dransfield: David Reveman wrote: 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. I am also seeing the minimized window problem. Any windows which are minimized when compiz is running disappear from the taskbar when switching to kwin. They come back after switching to compiz again. This is the reason why beryl has a Map minimized window on shotdown option. Kwin only manages mapped windows on startup and also maps minimized windows on shutdown. -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 mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Bug in xslt
Am Dienstag 15 Mai 2007 15:29:15 schrieb Mike Dransfield: There seems to be a bug in the schemas generation when the XML file does not contain any options. The descriptions are not generated at all, it just produces an empty schema file like this. ?xml version=1.0? gconfschemafile schemalist/ /gconfschemafile This happens with ini and with the python plugin which both do not have any options. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz This is not a bug in the xslt file, the plugin simply has no options. We should modify the build system not to try generate schema files for plugins that have no options. Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] meta data update
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. 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. Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] removing string restrictions
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 Would be much shorter but I'm not sure that this would work with the translation system. Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] WARNING ONLY A PROOF OF CONCEPT: copy texturing to fix maximum texture size restrictions
Hi,
this mail contains a core patch that enables wrapping of texture functions and
a plugin that uses this functions to realize the so called copy mode. The
pure copy code is quite simple and mostly clean. The most hacky part is
the code that fixes the maximum texture size limitations of some graphic
cards. But maybe we can use this as a basis to create a proper interface to
this problem. The pure copy part of the plugin can also be used to provide a
system that replaces the texture from pixmap extension for some buggy graphic
card drivers.
DO NOT USE THIS FOR PRODUCTIVE WORK !
Dennis
diff --git a/include/compiz.h b/include/compiz.h
index 5e52c8c..dd4f2df 100644
--- a/include/compiz.h
+++ b/include/compiz.h
@@ -26,7 +26,7 @@
#ifndef _COMPIZ_H
#define _COMPIZ_H
-#define ABIVERSION 20070506
+#define ABIVERSION 20070510
#include stdio.h
#include sys/time.h
@@ -1250,11 +1250,12 @@ typedef Bool (*DrawWindowProc) (CompWind
Region region,
unsigned int mask);
-typedef void (*AddWindowGeometryProc) (CompWindow *window,
- CompMatrix *matrix,
- int nMatrix,
- Region region,
- Region clip);
+typedef void (*AddWindowGeometryProc) (CompWindow *window,
+ CompMatrix *matrix,
+ int nMatrix,
+ CompTexture *texture,
+ Region region,
+ Region clip);
typedef void (*DrawWindowTextureProc) (CompWindow *w,
CompTexture *texture,
@@ -1325,11 +1326,12 @@ moreWindowIndices (CompWindow *w,
intnewSize);
void
-addWindowGeometry (CompWindow *w,
- CompMatrix *matrix,
- int nMatrix,
- Region region,
- Region clip);
+addWindowGeometry (CompWindow *w,
+ CompMatrix *matrix,
+ int nMatrix,
+ CompTexture *texture,
+ Region region,
+ Region clip);
void
drawWindowTexture (CompWindow *w,
@@ -1373,31 +1375,32 @@ typedef enum {
} CompTextureFilter;
struct _CompTexture {
-GLuint name;
-GLenum target;
-GLfloatdx, dy;
-GLXPixmap pixmap;
-GLenum filter;
-GLenum wrap;
-CompMatrix matrix;
-Bool oldMipmaps;
-Bool mipmap;
-intrefCount;
+GLuint name;
+GLenum target;
+GLfloat dx, dy;
+GLXPixmap pixmap;
+GLenum filter;
+GLenum wrap;
+CompMatrix matrix;
+BoololdMipmaps;
+Boolmipmap;
+int refCount;
+ CompPrivate *private;
};
void
-initTexture (CompScreen *screen,
+compInitTexture (CompScreen *screen,
CompTexture *texture);
void
-finiTexture (CompScreen *screen,
+compFiniTexture (CompScreen *screen,
CompTexture *texture);
CompTexture *
-createTexture (CompScreen *screen);
+compCreateTexture (CompScreen *screen);
void
-destroyTexture (CompScreen *screen,
+compDestroyTexture (CompScreen *screen,
CompTexture *texture);
Bool
@@ -1429,7 +1432,7 @@ iconToTexture (CompScreen *screen,
CompIcon *icon);
Bool
-bindPixmapToTexture (CompScreen *screen,
+compBindPixmapToTexture (CompScreen *screen,
CompTexture *texture,
Pixmap pixmap,
int width,
@@ -1437,11 +1440,11 @@ bindPixmapToTexture (CompScreen *screen
int depth);
void
-releasePixmapFromTexture (CompScreen *screen,
+compReleasePixmapFromTexture (CompScreen *screen,
CompTexture *texture);
void
-enableTexture (CompScreen*screen,
+compEnableTexture (CompScreen*screen,
CompTexture *texture,
CompTextureFilter filter);
@@ -1456,7 +1459,36 @@ enableTextureClampToEdge (CompScreen
CompTextureFilter filter);
void
-disableTexture (CompScreen *screen,
+compDisableTexture (CompScreen *screen,
+ CompTexture *texture);
+
+
+typedef void (*InitTextureProc) (CompScreen *screen,
+ CompTexture *texture);
+
+typedef void (*FiniTextureProc) (CompScreen *screen,
+ CompTexture *texture);
+
+typedef CompTexture * (*CreateTextureProc) (CompScreen *screen);
+
+typedef void (*DestroyTextureProc) (CompScreen *screen,
+ CompTexture *texture);
+
+typedef Bool (*BindPixmapToTextureProc) (CompScreen *screen,
+ CompTexture *texture,
+ Pixmap pixmap,
+ int width,
+ int height,
+ int depth);
+
+typedef void (*ReleasePixmapFromTextureProc) (CompScreen *screen,
+ CompTexture *texture);
+
+typedef void (*EnableTextureProc) (CompScreen*screen,
+ CompTexture *texture,
+ CompTextureFilter filter);
+
+typedef void (*DisableTextureProc) (CompScreen *screen,
CompTexture *texture);
@@ -1966,6 +1998,16 @@ struct _CompScreen {
OutputChangeNotifyProc outputChangeNotify;
+
+InitTextureProc initTexture;
+FiniTextureProc finiTexture;
+CreateTextureProccreateTexture;
+DestroyTextureProc destroyTexture;
+BindPixmapToTextureProc
Re: [compiz] meta data update
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. 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. Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] removing string restrictions
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. Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Re: [PATCH] Transparent cube
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.
Dennis
___
compiz mailing list
compiz@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Re: [PATCH] Transparent cube
Am Samstag, 28. April 2007 15:35 schrieb Vasek Potocek: Hello, is there any way of utilizing OpenGL's depth test instead of the paint order? If I understand it well, the aim here is to get it looking _like_ with depth test. I understand that shifting windows by an infinitesimal offset in the z direction would lead to various problems, but isn't is possible to persuade OpenGL somehow to use different coordinate for the depth test than for the perspective projection? (It would require a little bit more math than I outlined here, but should be possible.) V. For transparency effects you can't use a depth test, you have to paint the whole screen from back to front. Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Re: [PATCH] Transparent cube
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=36ca8bf25 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. So, I'm not interested in adding transparent cube support to the cube plugin I maintain until there's a more appropriate way to do it. I'm sure the transparent cube feature is popular and there's an interest in having it available today. There's no nice solution to this but you should be able to create a plugin that is loaded before all other plugins and implement the same screen painting solution as what's provide with your patch to the core. - 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] Commit mailing list
Is there a way to get a public commit mailing list for compiz? Dennis Kasprzyk ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] re-work option initialization
Am Sonntag, 1. April 2007 18:30 schrieb David Reveman: On Sun, 2007-04-01 at 01:39 +0200, Dennis Kasprzyk wrote: Am Samstag, 31. März 2007 10:12 schrieben Sie: On Thu, 2007-03-29 at 17:23 +0200, Dennis Kasprzyk wrote: Am Donnerstag, 29. März 2007 11:02 schrieb David Reveman: Dennis Kasprzyk and I have been discussing some changes to how options are initialized. Problems with how options are currently initialized. 1. Helper functions are not used to initialize options, which means that if we make a change to the option structure, all option initialization code needs to be updated. Using helper functions will also reduces the amount of duplicate code. 2. No convenient way to get the initial value of an option once it's been modified. 3. An option can't be initialized without compiz running. 2 and 3 are of interest to configuration backends that like to be able to do offline readout of option information and some kind of standard default value. 3, might be hard to provide for all kind of plugins as some might rely on a unique plugin loader to be present so I'm not sure that I want to recommend a configuration backend to do this. However, it's easy to provide for plugins built as shared libraries and I don't want to prevent anyone from doing this if they wish to. Here's our current idea for how we can solve these issues: Add typedef Bool (*InitPlugin(Display|Screen)OptionProc) (CompOption *o, int index); or typedef Bool (*InitPlugin(Display|Screen)OptionsProc) (CompOption **o); and the number of display and screen options to the plugin vTable. I prefer the function prototype with the index as it's a bit more flexible. We can add a set of option initialization macros to compiz.h or helper functions to a library, which will make the initPluginOption function in each plugin minimal. Action options will be changed to contain a string or KeySym instead of the current key-code. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz Currently there are two types of configuration tools. Some with fixed functionality and some autogenerated. To improve the quality of the autogenerated tools I would like to make this proposal about additional values in the CompOption struct and the plugin vtable. Additions to the CompOption struct: char * group/char * subgroup : Ability to group sets of options and to give this sets a name. char *hints : A semicolon separated list of string that inform the configuration tool to handle this option in a special way. A string value could have a hint image or file to inform the configuration tool to open a file dialog when the user wants to set this option. We all could workout here a set of hints, that all configuration tools would understand. Additions to the plugin vTable: char* category: A plugin can define to belong to a category like effects or accessibility, so that a configuration tool can group plugins together. We could workout possible categories later here. All this values would be optional and could be exposed over the dbus plugin or any other configuration system. I've read the whole thread. To summarize, there's a desire to assign much more meta-data than the current short/long descriptions to plugins, which to me seems like a very valid request. Question is how we allow this in the best possible way. Mike made a good point about the plugin writer not always being the best person to be responsible for providing all meta-data. However, I think it will be the best solution in most cases and it's always going to be easy to have a table of meta-data in the configuration tool that will override the plugin provided data so I'm not very concerned about this. Adding new fields to the plugin vTable every time someone comes up with some new useful meta-data seems very inconvenient. The most obvious way to provide this meta-data is to have an xml file paired with each plugin. That way new tags can easily be added as desired. I think that this is what we want in most cases but I'm still very interested in allowing plugins to be fully functional without any external file references. Imagine compiz running on a machine without a writable file-system and loading plugins remotely or plugins that dynamically create other plugins... My suggestion is that we remove the two description fields from the vTable and add a char *metadata field that contains meta information as xml data. A helper function that reads meta data for an option
Re: [compiz] re-work option initialization
Am Samstag, 31. März 2007 10:12 schrieb David Reveman: On Thu, 2007-03-29 at 17:23 +0200, Dennis Kasprzyk wrote: Am Donnerstag, 29. März 2007 11:02 schrieb David Reveman: Dennis Kasprzyk and I have been discussing some changes to how options are initialized. Problems with how options are currently initialized. 1. Helper functions are not used to initialize options, which means that if we make a change to the option structure, all option initialization code needs to be updated. Using helper functions will also reduces the amount of duplicate code. 2. No convenient way to get the initial value of an option once it's been modified. 3. An option can't be initialized without compiz running. 2 and 3 are of interest to configuration backends that like to be able to do offline readout of option information and some kind of standard default value. 3, might be hard to provide for all kind of plugins as some might rely on a unique plugin loader to be present so I'm not sure that I want to recommend a configuration backend to do this. However, it's easy to provide for plugins built as shared libraries and I don't want to prevent anyone from doing this if they wish to. Here's our current idea for how we can solve these issues: Add typedef Bool (*InitPlugin(Display|Screen)OptionProc) (CompOption *o, int index); or typedef Bool (*InitPlugin(Display|Screen)OptionsProc) (CompOption **o); and the number of display and screen options to the plugin vTable. I prefer the function prototype with the index as it's a bit more flexible. We can add a set of option initialization macros to compiz.h or helper functions to a library, which will make the initPluginOption function in each plugin minimal. Action options will be changed to contain a string or KeySym instead of the current key-code. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz Currently there are two types of configuration tools. Some with fixed functionality and some autogenerated. To improve the quality of the autogenerated tools I would like to make this proposal about additional values in the CompOption struct and the plugin vtable. Additions to the CompOption struct: char * group/char * subgroup : Ability to group sets of options and to give this sets a name. char *hints : A semicolon separated list of string that inform the configuration tool to handle this option in a special way. A string value could have a hint image or file to inform the configuration tool to open a file dialog when the user wants to set this option. We all could workout here a set of hints, that all configuration tools would understand. Additions to the plugin vTable: char* category: A plugin can define to belong to a category like effects or accessibility, so that a configuration tool can group plugins together. We could workout possible categories later here. All this values would be optional and could be exposed over the dbus plugin or any other configuration system. I've read the whole thread. To summarize, there's a desire to assign much more meta-data than the current short/long descriptions to plugins, which to me seems like a very valid request. Question is how we allow this in the best possible way. Mike made a good point about the plugin writer not always being the best person to be responsible for providing all meta-data. However, I think it will be the best solution in most cases and it's always going to be easy to have a table of meta-data in the configuration tool that will override the plugin provided data so I'm not very concerned about this. Adding new fields to the plugin vTable every time someone comes up with some new useful meta-data seems very inconvenient. The most obvious way to provide this meta-data is to have an xml file paired with each plugin. That way new tags can easily be added as desired. I think that this is what we want in most cases but I'm still very interested in allowing plugins to be fully functional without any external file references. Imagine compiz running on a machine without a writable file-system and loading plugins remotely or plugins that dynamically create other plugins... My suggestion is that we remove the two description fields from the vTable and add a char *metadata field that contains meta information as xml data. A helper function that reads meta data for an option from an xml file could easily be provided for those plugins that like to keep this in an external xml file. - David Great idea. Should we do the same for the options? Dennis ___ compiz mailing list compiz
Re: [compiz] re-work option initialization
Am Donnerstag, 29. März 2007 11:02 schrieb David Reveman: Dennis Kasprzyk and I have been discussing some changes to how options are initialized. Problems with how options are currently initialized. 1. Helper functions are not used to initialize options, which means that if we make a change to the option structure, all option initialization code needs to be updated. Using helper functions will also reduces the amount of duplicate code. 2. No convenient way to get the initial value of an option once it's been modified. 3. An option can't be initialized without compiz running. 2 and 3 are of interest to configuration backends that like to be able to do offline readout of option information and some kind of standard default value. 3, might be hard to provide for all kind of plugins as some might rely on a unique plugin loader to be present so I'm not sure that I want to recommend a configuration backend to do this. However, it's easy to provide for plugins built as shared libraries and I don't want to prevent anyone from doing this if they wish to. Here's our current idea for how we can solve these issues: Add typedef Bool (*InitPlugin(Display|Screen)OptionProc) (CompOption *o, intindex); or typedef Bool (*InitPlugin(Display|Screen)OptionsProc) (CompOption **o); and the number of display and screen options to the plugin vTable. I prefer the function prototype with the index as it's a bit more flexible. We can add a set of option initialization macros to compiz.h or helper functions to a library, which will make the initPluginOption function in each plugin minimal. Action options will be changed to contain a string or KeySym instead of the current key-code. - David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz Currently there are two types of configuration tools. Some with fixed functionality and some autogenerated. To improve the quality of the autogenerated tools I would like to make this proposal about additional values in the CompOption struct and the plugin vtable. Additions to the CompOption struct: char * group/char * subgroup : Ability to group sets of options and to give this sets a name. char *hints : A semicolon separated list of string that inform the configuration tool to handle this option in a special way. A string value could have a hint image or file to inform the configuration tool to open a file dialog when the user wants to set this option. We all could workout here a set of hints, that all configuration tools would understand. Additions to the plugin vTable: char* category: A plugin can define to belong to a category like effects or accessibility, so that a configuration tool can group plugins together. We could workout possible categories later here. All this values would be optional and could be exposed over the dbus plugin or any other configuration system. Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] compiz composited video and alpha only GLX pixmaps
Am Montag, 5. März 2007 12:12 schrieb David Reveman: I've added a simple plugin to compiz that provides a way to render video efficiently on a composited desktop. A video playback client basically copies video data to a pixmap and sets an X property on a client window that describes the image format of the data and where it should be rendered. The compiz video plugin will scale and perform necessary colorspace conversions when compositing the desktop. It provides very efficient playback of video on a composited desktop and it requires much less resources than e.g. XVideo as no intermediate buffer is required and hence also no accelerated offscreen rendering. RGB and YV12 image formats are currently supported but it's of course very easy to add support for additional formats. YV12 format requires GL_ARB_fragment_program and 8 bpp alpha only GLX pixmap support. The server doesn't provide alpha only pixmaps today. The attached patch adds an alternative PICT_a8 visual to composite and that is enough for xgl to support alpha only GLX pixmaps (not sure it will work with aiglx or nvidia's driver, I would guess not). Adding an alpha only X visual might be a bad idea. It doesn't cause any issues with the clients I've been running but I've seen that GDK thinks the server is broken and spits out some warnings when it finds a visual with masks set to 0. Might be a better idea to just add the fbconfig and no visual but the current GLX code in the server relies on every fbconfig having a matching X visual so it will need a bit more work and I'd like some feedback before I start doing anything like that. 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. - David I don't know if this is possible, but could xvideo be extended to support software generated xvideo adapters? If this would be possible compiz could add itself as video adapter and the video players would not need to be changed. Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Plugin Library Interface
Am Mittwoch, 7. März 2007 16:59 schrieb Mike Dransfield: Danny Baumann wrote: What are the major pros/cons of using this method over plain old libraries? They plug into the normal plugin infrastructure and don't add the need for plugin writers to mess around with dlopen(), dlsym() and such. Basically, they work like normal libraries and look like a plugin. A large advantage is that every plugin gets a notify whenever a library plugin is loaded or unloaded. The amount of code in the text library is very small and seems like it would do just as well as a normal c library. Other than being notified when it is added or removed I don't see how it is beneficial. Using a library would mean that the functionality could always be guaranteed. The idea behind this is, that no new dependencies are needed in a plugin, if you use this system. Currently text depends on cairo and pango, but each plugin that uses the library interface does not need to depend on it. If the text plugin is not available the text is simply not rendered. There could also be another text plugin that uses qt to render the text. I also think that your symbol lookup table could get really slow if there were more than 20 functions loaded, have you done any benchmarks on this? Do you have any other library plugins other than text? Or what do you plan for other types of library plugin? It seems like only text and group use this at the moment. And in Beryl, the text plugin is not only used by group, but also by switcher and scale. I could provide a patch which adds text display support (on hovering) to scale, but that patch would need the text plugin which is a bit problematic if scale is considered a core plugin and text isn't ;-) It would be very simple if it were just a library, there would be no need to port from and to compiz because the same library would work without modifications on both. It looks like the major advantage is that functions can be loaded and unloaded at runtime. The major disadvantages being slowness, possibility of crashes and incompatibility. I think we would all welcome libraries which make plugin developers lives easier, maybe you could write a library which has lots of compiz/beryl helper functions. I suspect something like that, combined with a patch which uses the functionality in some plugins would be very useful. Is the text plugin still integrated into the fileFromImage hooks or are you only using it as a library plugin now? The text plugin now only uses the library interface. ___ 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
Re: [compiz] Blur bugs and slowdown :(
Am Mittwoch, 7. März 2007 20:26 schrieb Bellegarde Cedric: Yes, you have multiple levels of blur here. The blurring behind the amarok window depends on the blurring behind the window below. We're not blurring windows here, we're blurring whatever is rendered behind the windows, which is a lot harder than just blurring a window or texture. - David Do you think there is a way to fix that? Beryl plugin do not do multiple levels of blur and all is faster when having multiple translucent windows. Another thing is blur effect in fade plugin. It make fade slow and ugly. Cedric ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz I will add an option to the blur plugin, where you can disable multi level blur. Dennis ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] BCOP: The Beryl/Compiz XML options parser
Adding new options to a plugin is a pain. There is a lot of code that has allways to be changed for that. This is the reason why I've created the Beryl/Compiz XML options parser (bcop). Bcop allows you easily to describe options in XML and will autogenerate the needed Beryl/Compiz C code for you. The only think that needs to be changed in a existing plugins is to include the xxx_options.h file. The autogenerated code appends the new options to the existing options, this gives the possibility to handle some special cases in the plugin directly. I have not found the time to write a README that describes the functionality, but there is a example.options file (bcop [--compiz] example.options will generate example_options.h and example_options.c). The most interesting parts are the automatic handling of restricted strings (type=enum) as enum and the handling of restricted string lists (type=selection) as masks. Reading the autogenerated code should not be that hard. The group,subgroup and hints XML keys are only used for beryl code generation. I have also added a new version of my generic plugins Makefile that now handles Beryl and Compiz, multiple source files and the bcop interface. You can checkout the code from Beryl svn with: svn co svn://svn.beryl-project.org/beryl/trunk/bcop/ The whole system is not well tested yet. I've created a bcop component in the beryl bug tracker at http://bugs.beryl-project.org please report bugs and problems there. Dennis onestone Kasprzyk ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Thumbnail plugin
On Wed, 2007-01-24 at 10:19 +0100, Stjepan Glavina wrote: Sounds good, lets add it. Follow the instructions here to get an fdo account: http://freedesktop.org/wiki/AccountRequests you can go ahead and add the plugin once you have an account. - David Thank you. Beryl has support for getting thumbnails of windows when they're unmapped. When a window is unmapped, the pixmap is saved. Look at the code: http://glug.grm.hia.no/beryl/trunk/beryl-core/src/window.c (search for 'thumbTexture' and 'thumbPixmap'). Do you have any plans to add support for this in Compiz core too? I don't know, showing a saved pixmap isn't good enough. You want live updating thumbnails even for minimized windows and we need input transformation support to do that properly. So I'd rather wait but it's your plugin so it's really up to you. Before you start sending patches to kde and gnome maintainers I suggest that we discuss the interface that will be provided by the thumbnail plugin. What does it currently look like? - David Leaving windows open because we want a live thumbnail of them, has the disadvantage that is wastes memory. Vista also only supports a non live pixmap for most of the applications. But If you want to have live thumbnails there are more possibilities to prevent input to a window. I know that input redirection would be the cleanest solution, but this can take some time until it's ready. One solution for that problem, would be to move the window behind the desktop window and not paint it, if no desktop window is available a Input prevention window could be created. The other solution would be to move the window outside of the visible area of the screen, and prevent movements on this window. I know that both of my proposals are clean solution but both could be realized now. Dennis Kasprzyk ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Thumbnail plugin
On Wed, 2007-01-24 at 17:25 +0100, Stjepan Glavina wrote: When hovering taskbar, gnome-panel/kicker change the property of the appropriate window (_NET_WM_SHOW_THUMBNAIL). Thumbnail plugin checks for PropertyNotify events and shows/hides the thumbnail. (I assume that you didn't want take this discussion off the list) This discussion should eventually be moved to the wm-spec-list but there's a few things I think we should try to decide here first. 1. Should one window only be allowed to show one thumbnail or should the property be a list of thumbnails? 2. How is the position and scale of the thumbnail encoded. Is it: data[0] = thumbnail window ID data[1] = x data[2] = y data[3] = width data[4] = height x, y being relative to the client window position. 3. The compositing manager might have to do some work before it can render the requested thumbnail(s) in a client window. The client wouldn't want the window which contains thumbnails to be visible until all thumbnails can be rendered properly. If the client sets the thumbnail property prior to mapping the window, it allows the compositing manager to delay any drawing of the client window until the requested thumbnails can be rendered. Some of this might need to be documented before it can be accepted as an addition to the EWMH spec. 4. What windows are valid in the thumbnail property? Any window in the _NET_CLIENT_LIST root window property? Or should there be a new _NET_THUMBNAIL_LIST property? Such a list means that the compositing manager doesn't have to provide thumbnails for all available windows, which makes sense for the current state where thumbnails for minimized windows can't be rendered. If someone can think of something else, please jump in. - David I also don't think that rendering the complete thumbnail window (what the current state of the thumbnail plugin is) should be the final solution. This should be done by the requesting application and the composite manager should render only the window thumbnail into it. So here is my idea: 1. We should think about a _NET_CM naming schema, because these are composite manager abilities and there may still be separated window and composite managers. 2. A window should have a _NET_CM_SUPPORTS (or _NET_CM_PROTOCOLS) list that contains all features supported by the composite manager for that window. I this case it would be _NET_CM_THUMBNAIL. This could be easily removed if a window gets minimized. This list could then be also used to inform a client about other features like opacity,brightness,saturation... 3. If a application wants that a thumbnail (or more) should be rendered into it's window, it simply sets the _NET_CM_THUMBNAIL atom with a list of the thumbnails. data[0] = thumbnail window ID data[1] = x data[2] = y data[3] = width data[4] = height data[5] = next thumbnail window ID ... x/y relative to the application window. Because the composite manager already renders the application window it should not be timing issue to render the thumbnails into it. If someone would like to create a switcher like application outside of the composite manager, setting of the thumbnail atom before mapping might be a disadvantage. We should also think of a system, how to allow that the opacity, brightness, and saturation (or any other supported feature) could be set only for the thumbnail. What do you think about it? Dennis Kasprzyk ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
