similar to: Some suggestions for extra metadata

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

The dependency checking currently provided is clearly not good enough. There's currently two issues with the plugins that exist in the compiz repository. plane plugin conflicts with cube and rotate plugin, zoom plugin should probably work with either cube or plane but currently only loads when cube plugin is used. Adding a { CompPluginRuleBefore, "cube" } to the plane plugin and a

Hi, I've been working a bit on the match interface of CCSM lately and I found that it would be really useful to have features for each match prefix the plugin (core/regex) supports. The feature name is built similar to the image feature names: "matchhandler:" + prefix. For example "matchhandler:title" supports the match prefix "title=". So I made a small patch

I was thinking about this more, and perhaps a more preferable solution would have some kind of OptionGroup parameter to constructors of cl options. This would of course be optional, with the default being a global one. Then, ParseCommandLineOptions() could instead take as an optional parameter an OptionGroup, and would then only work on cl options in that group. Would this approach be preferable?

Hello, I've noticed that X11 device windows (the ones that pop up when I plot something on Linux) aren't assigned any WM_NAME property until after they've been spawned. This causes problems for users of tiling window managers, who may wish to use the WM_NAME property to decide whether to float or tile the window. If I create a plot and then examine the window properties with xprop,

Hi, I have noticed a strange behavior: after the added one of the options "window_match" in scale and switcher plugins; these do not show some windows like gmplayer or amsn's windows This is the output of xprop $ xprop _NET_WINDOW_DECOR(INTEGER) = 20061011, 46149375, 4, 4, 27, 4, 4, 4, 27, 4, 9, 0, 36965, -11, -34, -68, 0, 582, 32767, 0, 0, 32869, 571, -34, -68, 0, 32767,

On Mar 4, 2009, at 12:15 AM, Alexei Svitkine wrote: > I was thinking about this more, and perhaps a more preferable solution > would have some kind of OptionGroup parameter to constructors of cl > options. This would of course be optional, with the default being a > global one. Hi Alexei, Sorry for the delay, I've been swamped lately and tend to process email in LIFO order :(

I don't have any opinions about this. Chris? Evan On Feb 17, 2009, at 8:00 PM, Alexei Svitkine wrote: > The motivation behind this patch is that tools that use LLVM as a > library and want to use its command line parsing facilities may not > want all the various options defined in the LLVM libraries to be > available - simply because they may not be relevant. > > This patch

Hi, This patch adds appropriate limits (1-100) to opacity_values in core options. Minimum is 1 to be consistent with the opacity changing action and because it doesn't make sense to have an invisible window that is still there. Regards, Erkin -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-opacity-limits.patch Type: text/x-patch Size: 1246 bytes

The motivation behind this patch is that tools that use LLVM as a library and want to use its command line parsing facilities may not want all the various options defined in the LLVM libraries to be available - simply because they may not be relevant. This patch adds an optional "Prefix" parameter to ParseCommandLineOptions(). If set, this will make inaccessible any options that do not

Hi Nick, There are already a lot of options that are being shared across various flavors. Adding a new option becomes a issue when that option need to available across all flavors. As the first step, I am thinking of consolidating the common options shared across all the Unix variant flavors in CommonOptions.td. The options that are shared between Darwin/GnuLD are :- a) -o b) -L c)

On Sep 18, 2013, at 12:18 PM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Hi Nick, > > There are already a lot of options that are being shared across various flavors. Adding a new option becomes a issue when that option need to available across all flavors. > > As the first step, I am thinking of consolidating the common options shared across all the Unix

I worte in my last mail that when I ue compiz git fullscreen videos are no longer ontop of the gnome-panel... that means that the gnome-panel is still visible while playing the video in fullscreen. The commit which I said may caused it has nothing to do with it compiz does not build if I revert it). again with older compiz and metacity it works fine. (now I am running 20070316). Anyone else wiith

After commit 102300, any obj-c software compiled with clang crashes at launch time with the following stack trace. Reverting this specific commit fix the issue. ------------------------------------------------------------------------------------------------ Date/Time: 2010-04-26 10:07:01.630 +0200 OS Version: Mac OS X 10.6.3 (10D573) Report Version: 6 Interval Since Last Report:

Hi, We are embedding our DSL language + LLVM in a modified WebKit based Safari on OSX. Starting with LLVM 3.3 (it was working with LLVM 3.1...) we see the following crash: Any idea? Thanks. Stéphane Letz ====================== Process: SafariForWebKitDevelopment [79228] Path: /Applications/Safari.app/Contents/MacOS/SafariForWebKitDevelopment Identifier:

I managed to build a reduced test case: ================== foo.m ================== #include <Foundation/Foundation.h> @interface BaseNode : NSObject <NSCoding, NSCopying> { } @end @implementation BaseNode @end int main(int argc, char **argv) { return 0; } ========================================== # clang -o foo -arch i386 -framework Foundation foo.m foo.m:8:1: warning:

xprop is a command line tool to display and/or set window and font properties of an X server. Alan Coopersmith (5): Add missing braces around else clause in Read_Quoted() Update README for gitlab migration Update configure.ac bug URL for gitlab migration Fix -Wsign-compare warning in dsimple.c xprop 1.2.4 pmav99 (1): Fix typo in xprop.man git tag: xprop-1.2.4

xprop is a command line tool to display and/or set window and font properties of an X server. Alan Coopersmith (5): configure: Drop AM_MAINTAINER_MODE autogen.sh: Honor NOCONFIGURE=1 Print which option was in error along with usage message Add -version option to print program version xprop 1.2.3 Eirik Byrkjeflot Anonsen (4): Free the thunks used by Show_Prop

xprop is a command line tool to display and/or set window and font properties of an X server. This release contains the following change to the way icons are displayed in the terminal when COLORTERM=truecolor in the environment variables: The vast majority of monospaced fonts are roughly half as wide as they are tall; to account for this when displaying icons, `xprop` draws each

Jason Nader (1): Add missing `-help` function Keith Packard (5): Make output with unknown width terminal the same as old code Free string list returned from XmbTextPropertyToTextList Correct icon buffer width computation for truecolor terminals Check return value from ioctl(TIOCGWINSZ) xprop 1.2.5 Pierre-Loup A. Griffais (5): Don't display icons if