Re: [compiz] place plugin
On Mon, 2007-05-21 at 22:06 +0200, Guillaume Seguin wrote: > 2007/5/21, David Reveman <[EMAIL PROTECTED]>: > > On Mon, 2007-05-21 at 20:35 +0200, Guillaume Seguin wrote: > > > 2007/5/21, David Reveman <[EMAIL PROTECTED]>: > > > > On Thu, 2007-05-17 at 14:06 +0200, dragoran wrote: > > > > > The place plugin has a bug: > > > > > when compiz is restarted or started to replace another wm it the > > > > > windows > > > > > are placed in weird positions ( titlebar behind the panel etc.) > > > > > > > > > > shouln't the place plugin loop over all open windows and place them > > > > > correctly when loaded? this should solve this issues. > > > > > any reason why this isn't done? have I missed something or is this > > > > > just > > > > > a bug? > > > > > > > > compiz should not place existing windows at startup. compiz doesn't > > > > > > Would it be possible to change that startup behaviour? Switching from > > > metacity to compiz is quite awful at the moment. And there are also > > > some minimize problems (windows that are mapped but are known as > > > minimized by X, so that you just can't do anything) > > > > Whatever bugs that exist should of course be fixed. If there's other > > things than bugs that is causing it to be awful, please explain more. > > > > -David > > > > The startup problems are the placement one (which was described above) > and the minimized windows problem : When switching from metacity to > kwin, minimized windows are mapped (I mean visible and updating) but > they are still in minimized state (wnck menus show "Unminimize > window", but triggering that doesn't help), so that all you can do > with them is close them (input is impossible, and you can't unminimize > them). I'll try to get some xprop feedback and screenshots next time > it happens. It's a bug in compiz. Minimized windows should always be mapped when the WM closes down. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] place plugin
On Mon, 2007-05-21 at 21:45 +0200, dragoran wrote: > David Reveman wrote: > > don't know what's causing it. > > > > > > It doesn't. I can't reproduce the misplacement issue on my system and I > try this: > start metacity open a maximized window > start compiz > titlebar is behind the top panel (need to press alt to move it back to > its original place, because its impossible to grab the titlebar for moving). That's a bug in the decoration plugin. It's not adjusting the position of windows properly when adding decorations to them. There were some issues before that made it a bit hard to fix this but I think it should be easy to fix in the current code. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Crash in blur.c (SIGSEGV)
On Sat, 2007-05-19 at 12:14 +0200, Artur Uszyński wrote: > Hello. > > System info: > OS: FC6 x86_64 > video: Nvidia GF 7900 GT, driver version 97.55 > compiz version: git > config backend used: ccp > > I can reproduce this crash every time on my system. When blur plugin is > active and I try to access any right-click menu, regular application menu or > drop-down list, compiz crashes. Backtrace produced by crashhandler plugin > shows crash in blur.c in function blurWindowResizeNotify, in the following > line: > > if (bw->state[BLUR_STATE_CLIENT].threshold || > > The values of bw seem to be wrong and IMO indicate classic problem with null > or uninitialized pointer (although I'm not a programmer): > > bw = (BlurWindow *) 0x0 > > Sometimes instead of 0x0 I get values like 0x40 or 0x33373b3338393932, which > don't seem to be right either. > > After restarting compiz and immediately accessing exactly the same object > (for example repeating right-click on desktop) crash does not happen, but > then accessing other similar object crashes compiz again. > > After commenting out the whole "if" statement mentioned above compiz no > longer crashes, but probably graphics glitches are introduced instead. > > There was a report including similar description sent on Wed Feb 21 04:34:20 > PST 2007: > > > > When I start blurdemo, that works too. The problem is that sometimes > > > changing the filter type crashes compiz. If I run it under a debugger > > > it starts working again. All the filter types work with blurdemo. > > "changing the filter type" might be a symptom of the same problem (accessing > drop-down list). This crash is likely caused by decoration and blur plugins calling wrapped functions from initWindow. I just pushed out some code that solves this by adding a new WindowAddNotify function that these plugins now hooks into. I'm pretty sure that this will fix your crash. Give the latest code a try and let me know. Thanks, -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] place plugin
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] place plugin
David Reveman wrote: > don't know what's causing it. > > > It doesn't. I can't reproduce the misplacement issue on my system and I try this: start metacity open a maximized window start compiz titlebar is behind the top panel (need to press alt to move it back to its original place, because its impossible to grab the titlebar for moving). ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] place plugin
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. > -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
Re: [compiz] place plugin
On Mon, 2007-05-21 at 20:35 +0200, Guillaume Seguin wrote: > 2007/5/21, David Reveman <[EMAIL PROTECTED]>: > > On Thu, 2007-05-17 at 14:06 +0200, dragoran wrote: > > > The place plugin has a bug: > > > when compiz is restarted or started to replace another wm it the windows > > > are placed in weird positions ( titlebar behind the panel etc.) > > > > > > shouln't the place plugin loop over all open windows and place them > > > correctly when loaded? this should solve this issues. > > > any reason why this isn't done? have I missed something or is this just > > > a bug? > > > > compiz should not place existing windows at startup. compiz doesn't > > Would it be possible to change that startup behaviour? Switching from > metacity to compiz is quite awful at the moment. And there are also > some minimize problems (windows that are mapped but are known as > minimized by X, so that you just can't do anything) Whatever bugs that exist should of course be fixed. If there's other things than bugs that is causing it to be awful, please explain more. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] place plugin
On Mon, 2007-05-21 at 20:34 +0200, dragoran wrote: > David Reveman wrote: > > On Thu, 2007-05-17 at 14:06 +0200, dragoran wrote: > > > >> The place plugin has a bug: > >> when compiz is restarted or started to replace another wm it the windows > >> are placed in weird positions ( titlebar behind the panel etc.) > >> > >> shouln't the place plugin loop over all open windows and place them > >> correctly when loaded? this should solve this issues. > >> any reason why this isn't done? have I missed something or is this just > >> a bug? > >> > > > > compiz should not place existing windows at startup. > but it seems that it does (they get moved to weird position if compiz is > started while some windows are open).. it should atleast leave them at > their old position. (metacity does not do this) It's a bug if they gets moved. > > compiz doesn't > > really try to avoid weird positions. the move plugin have some code that > > avoids moving windows to weird positions but that's only for when moving > > windows. > > > > A plugin that makes sure that windows are never placed at weird > > positions could be written for this purpose. > > > > > how would this fix the problem for windows gets misplaced at startup? It doesn't. I can't reproduce the misplacement issue on my system and I don't know what's causing it. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Maximized windows dissappear
David Reveman wrote: > On Sat, 2007-05-19 at 17:35 +0100, Mike Dransfield wrote: > >> David Reveman wrote: >> >>> On Sun, 2007-04-29 at 15:17 +0100, Mike Dransfield wrote: >>> >>> Jesper Andersen wrote: > Replying to my own email here: > > On Fri, 2007-04-27 at 09:05 +0200, Jesper Andersen wrote: > > > >> I am using the lastest git version of compiz and just run in to a new >> problem after switching to using the ini configuration plugin over the >> gconf-one. When I maximize a window and then try to move it to another >> viewport, the cube rotates but the maximized window disappears instead >> of moving along to the new viewport. The maximized window can be found >> using the scale plugin (only on show-all action). Further, if I then try >> to unmaximize the window, the window again disappears and I have to use >> scale's show-all action. Now, however the window appears in some random >> almost out of viewport location and I have to drag it back into >> position. >> >> I do not know whether it was my switch to the ini plugin that caused >> this annoying change in behavior. >> >> >> > I now tried with either gconf and ini (with the same settings) and > nothing changes. However I noticed the following: whenever I move a > window with some contents below the bottom edge of the screen to another > viewport, it is immediately displaced on the new viewport so that most > of the window's content is above the top edge of the screen. How much > seems related to how much was hidden below the bottom edge before the > move (this is only when moving a window to a new viewport by > Left/Right and similar, not for the usualy mouse-dragging of > windows and also not for windows that are beyond any other screen > edges). I have tried toggling the "Constrain y" option in the > move-plugin to no avail. I also tried changing the "detect outputs" in > the general options, also to no avail. > > I am not sure when this strange behavior was introduced and I am > wondering whether I am really the only one seeing this? > > > > No you are not. I can see both of these problems now and I have tracked the problem down to the moveWindowToViewportPosition function OR the w->output.top calculation. The exact line is this one if (m - w->output.top < w->screen->height - vHeight) In the case I just tested this variables had these values. m = 20 w->output.top =23 w->screen.height and vHeight are both 1050. This if statement returns true because -3 < 0 and it shifts the window down. Sorry, I am not sure how to best fix this one but it is a reproducible problem. I also see the offset problem as well and suspect its related to the same thing. >>> It should now be fixed. Thanks for tracking this down, Mike. >>> >>> >> I can still see a problem when moving windows across viewports >> when they are off the top of the screen. >> >> To reproduce, put window off the top of the screen and then use >> Right to move with it. The window gets put >> off the bottom of the screen. This is in a typical 4X1 arrangement >> with cube and rotate. >> > > How about now? > Yes, that seems to have got it, thanks. > -David > > ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Window specific actions and edge buttons
David Reveman wrote: > On Fri, 2007-05-18 at 15:14 +0100, Mike Dransfield wrote: > >> David Reveman wrote: >> >>> On Wed, 2007-05-16 at 11:51 +0100, Mike Dransfield wrote: >>> >>> David Reveman wrote: > On Tue, 2007-05-15 at 00:29 +0100, Mike Dransfield wrote: > > > >> There is a problem with some window specific actions like >> scale_group and rotate_with_window when they are activated >> by an edgebutton. >> >> The basic problem is that each of those actions use the window >> option provided to the action. When an edgebutton is used the >> window id sent is actually the id of the edge window, this means >> that actions which rely on this stop working. >> >> The obvious solution would be to change the affected functions >> to work on the active window rather that the one passed to the >> action. >> >> >> > Yes, I think that's what should be done. > > > OK - I did that for those two. I am just about to push out similar changes for close_window, minimize_window and maximize_window. If they reduce some functionality then please let me know and I will write it so that it checks for an edge and only uses activeWindow then. >>> This is likely not what you want when a button press triggered an action >>> and it removes the possibility to remotely trigger those actions for >>> specific windows. >>> >>> >> OK - I didn't think of that possibility. I'll change it back to >> the old way. >> >> I would like to keep the ability to do both without breaking >> either method. How about adding edge_window to the list of >> options which are sent? If the action was edge+button then it >> would be set to the id of the edge window. The window option >> could be set to active window in this case. >> > > Yes, that sounds pretty good. Maybe it's better to add a more general > event_window to the list instead. > OK - I have added that, reverted the other changes and amended core.xml.in to allow edges for a lot more core actions. I don't think that should cause any problems elsewhere. >>> For scale_group and such I think you want to only use the active window >>> if the provided window is an edge window or a maybe a window that isn't >>> managed. I don't see any reason why close_window, etc should be changed. >>> >>> >> I think it is a useful accessibility feature, there are lots of >> people who find it hard to click precisely on the decorator >> buttons. Pushing to the corner and clicking is easier because >> it does not require such fine motor skills. >> > > OK, I didn't get that this was the reason you wanted to change those > functions. Yes, it seems useful. Adding an event_window argument will > allow those functions to work with screen edges without modifying them. > > -David > > ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] place plugin
David Reveman wrote: > On Thu, 2007-05-17 at 14:06 +0200, dragoran wrote: > >> The place plugin has a bug: >> when compiz is restarted or started to replace another wm it the windows >> are placed in weird positions ( titlebar behind the panel etc.) >> >> shouln't the place plugin loop over all open windows and place them >> correctly when loaded? this should solve this issues. >> any reason why this isn't done? have I missed something or is this just >> a bug? >> > > compiz should not place existing windows at startup. but it seems that it does (they get moved to weird position if compiz is started while some windows are open).. it should atleast leave them at their old position. (metacity does not do this) > compiz doesn't > really try to avoid weird positions. the move plugin have some code that > avoids moving windows to weird positions but that's only for when moving > windows. > > A plugin that makes sure that windows are never placed at weird > positions could be written for this purpose. > > how would this fix the problem for windows gets misplaced at startup? ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] place plugin
On Thu, 2007-05-17 at 14:06 +0200, dragoran wrote: > The place plugin has a bug: > when compiz is restarted or started to replace another wm it the windows > are placed in weird positions ( titlebar behind the panel etc.) > > shouln't the place plugin loop over all open windows and place them > correctly when loaded? this should solve this issues. > any reason why this isn't done? have I missed something or is this just > a bug? compiz should not place existing windows at startup. compiz doesn't really try to avoid weird positions. the move plugin have some code that avoids moving windows to weird positions but that's only for when moving windows. A plugin that makes sure that windows are never placed at weird positions could be written for this purpose. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] kde-window-decorator crashes
On Tue, 2007-05-15 at 18:50 +0100, Diogo Ferreira wrote: > Silvan Calarco wrote: > > Hi, > > I've updated compiz to the 0.5.0 release and since my release 0.3.something > > I > > keep on seeing seldom crashes from kde-window-decorator when running it > > both > > on Xorg with AIGLX+nvidia card and Xorg+Xgl+ATI card. > > The crashes most often happen at desktop login and when loading certain > > applications (kmail, kaffeine, ...). > > The strange thing is that if I try to attach to kde-window-decorator with > > gdb > > it doesn't crash anymore! What might be the reason? > > If anybody can tell how I can make more debugging and give you more > > information. The distribution is openmamba. Could be related to this bug: http://bugs.freedesktop.org/show_bug.cgi?id=9526 I think someone reported that the workaround we have in libdecoration doesn't always work. I should probably go ahead and commit that fix to libXrender. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Maximized windows dissappear
On Sat, 2007-05-19 at 17:35 +0100, Mike Dransfield wrote: > David Reveman wrote: > > On Sun, 2007-04-29 at 15:17 +0100, Mike Dransfield wrote: > > > >> Jesper Andersen wrote: > >> > >>> Replying to my own email here: > >>> > >>> On Fri, 2007-04-27 at 09:05 +0200, Jesper Andersen wrote: > >>> > >>> > I am using the lastest git version of compiz and just run in to a new > problem after switching to using the ini configuration plugin over the > gconf-one. When I maximize a window and then try to move it to another > viewport, the cube rotates but the maximized window disappears instead > of moving along to the new viewport. The maximized window can be found > using the scale plugin (only on show-all action). Further, if I then try > to unmaximize the window, the window again disappears and I have to use > scale's show-all action. Now, however the window appears in some random > almost out of viewport location and I have to drag it back into > position. > > I do not know whether it was my switch to the ini plugin that caused > this annoying change in behavior. > > > >>> I now tried with either gconf and ini (with the same settings) and > >>> nothing changes. However I noticed the following: whenever I move a > >>> window with some contents below the bottom edge of the screen to another > >>> viewport, it is immediately displaced on the new viewport so that most > >>> of the window's content is above the top edge of the screen. How much > >>> seems related to how much was hidden below the bottom edge before the > >>> move (this is only when moving a window to a new viewport by > >>> Left/Right and similar, not for the usualy mouse-dragging of > >>> windows and also not for windows that are beyond any other screen > >>> edges). I have tried toggling the "Constrain y" option in the > >>> move-plugin to no avail. I also tried changing the "detect outputs" in > >>> the general options, also to no avail. > >>> > >>> I am not sure when this strange behavior was introduced and I am > >>> wondering whether I am really the only one seeing this? > >>> > >>> > >>> > >> No you are not. > >> > >> I can see both of these problems now and I have tracked the > >> problem down to the moveWindowToViewportPosition function > >> OR the w->output.top calculation. > >> > >> The exact line is this one > >> > >> if (m - w->output.top < w->screen->height - vHeight) > >> > >> In the case I just tested this variables had these values. > >> > >> m = 20 > >> w->output.top =23 > >> > >> w->screen.height and vHeight are both 1050. This if statement > >> returns true because -3 < 0 and it shifts the window down. > >> > >> Sorry, I am not sure how to best fix this one but it is a reproducible > >> problem. > >> > >> I also see the offset problem as well and suspect its related to the > >> same thing. > >> > > > > It should now be fixed. Thanks for tracking this down, Mike. > > > > I can still see a problem when moving windows across viewports > when they are off the top of the screen. > > To reproduce, put window off the top of the screen and then use > Right to move with it. The window gets put > off the bottom of the screen. This is in a typical 4X1 arrangement > with cube and rotate. How about now? -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] [PATCH] Descriptions for dbus when plugin not loaded
On Fri, 2007-05-18 at 15:17 +0100, Mike Dransfield wrote: > David Reveman wrote: > > On Tue, 2007-05-15 at 19:23 +0100, Mike Dransfield wrote: > > > >> Here is a quick patch for dbus to make it try to load the > >> metadata from a file if the plugin is not loaded. > >> > >> I have tested it and it works fine, but I wanted to check to > >> see if you had something else in mind. > >> > > > > Yes, I think we should load/initialize and read the metadata from > > plugins. Some minor changes need to be made to the plugin system before > > we're able to load and initialize a plugin without activating it but it > > should be easy to fix. > > > > I thought you might have something like that in mind, I shall > wait for that to be done. I looked at the code and you should be able to implement this without any changes to the plugin loading system. The dbus plugin will have to manually call p->vTable->getVersion, p->vTable->init and p->vTable->fini when retrieving metadata from an non-active plugin but that's fine. > > > BTW, I'm not very interested in just returning the descriptions. > > The GetPluginMetadata method should return an array of full meta data > > documents. This needs to be supported by the dbus plugin before we can > > remove plugin dependencies from the core. > > > > Once the above is done, I can look at modifying the getMetadata > function. I think it would be appropriate to change this function > to return a dictionary because its likely that it will be modified > and it will save breaking scripts. You can go ahead and add this right now. If you don't know exactly how to do the plugin loading and meta data reading then just leave that to me. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Window specific actions and edge buttons
On Fri, 2007-05-18 at 15:14 +0100, Mike Dransfield wrote: > David Reveman wrote: > > On Wed, 2007-05-16 at 11:51 +0100, Mike Dransfield wrote: > > > >> David Reveman wrote: > >> > >>> On Tue, 2007-05-15 at 00:29 +0100, Mike Dransfield wrote: > >>> > >>> > There is a problem with some window specific actions like > scale_group and rotate_with_window when they are activated > by an edgebutton. > > The basic problem is that each of those actions use the window > option provided to the action. When an edgebutton is used the > window id sent is actually the id of the edge window, this means > that actions which rely on this stop working. > > The obvious solution would be to change the affected functions > to work on the active window rather that the one passed to the > action. > > > >>> Yes, I think that's what should be done. > >>> > >>> > >> OK - I did that for those two. > >> > >> I am just about to push out similar changes for close_window, > >> minimize_window and maximize_window. If they reduce some > >> functionality then please let me know and I will write it so that > >> it checks for an edge and only uses activeWindow then. > >> > > > > This is likely not what you want when a button press triggered an action > > and it removes the possibility to remotely trigger those actions for > > specific windows. > > > > OK - I didn't think of that possibility. I'll change it back to > the old way. > > I would like to keep the ability to do both without breaking > either method. How about adding edge_window to the list of > options which are sent? If the action was edge+button then it > would be set to the id of the edge window. The window option > could be set to active window in this case. Yes, that sounds pretty good. Maybe it's better to add a more general event_window to the list instead. > > > For scale_group and such I think you want to only use the active window > > if the provided window is an edge window or a maybe a window that isn't > > managed. I don't see any reason why close_window, etc should be changed. > > > > I think it is a useful accessibility feature, there are lots of > people who find it hard to click precisely on the decorator > buttons. Pushing to the corner and clicking is easier because > it does not require such fine motor skills. OK, I didn't get that this was the reason you wanted to change those functions. Yes, it seems useful. Adding an event_window argument will allow those functions to work with screen edges without modifying them. -David ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] 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. > >> > >> > >> 0 > >> 1 > >> 0 > >> > > > > A more general plugin info struct should be better > > > > bob "[EMAIL PROTECTED]" > > alice "[EMAIL PROTECTED]" > > GPL > > 0.1.0-git > > http://www.example.com/plugin-info.html > > > > 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). > >> > >> largedesktop > > > > We should handle 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. > > >> > >> > >> title > >> xprop | grep ^WM_NAME | ... > > > > 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. > > >> > >> name > >>etc... > >> > >> > >> *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. > >> > >> > >> > >> > >> > > > > What about the subgroup tag that we already use in the opencomposite.org > > plugins? > > > > Foo > > > > ... > > > > > > ... > > > > > > > > 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. > >> > >> > >> > >> http://www.example.com/plugin-update.xml > > > > 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. > >> > >> http://www.example.com/plugin-info.html > >> > >> > >> > >> >> mime="text/html">http://www.example.com/plugin.html > >> >> mime="image/jpeg">http://www.example.com/plugin.jpg > >> >> mime="application/swf">http://www.example.com/plugin.swf > >> > > > > This should be on the plugin info page and not part of the metadata. > > This would allow config apps to display screenshots internally > without the user having to go to a separate website. > If you want screenshots then they should be a part of the plugin package. > > Regards > > Dennis > > > > > > > > ___ > > compiz mailing list > > compiz@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/compiz _
Re: [compiz] Some suggestions for extra metadata
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. >> >> >> 0 >> 1 >> 0 >> >> > A more general plugin info struct should be better > > bob "[EMAIL PROTECTED]" > alice "[EMAIL PROTECTED]" > GPL > 0.1.0-git > http://www.example.com/plugin-info.html > > Thats OK too, but the version should be split up or we end up with 1001 different versioning schemes and 1001 parsers for them. Info is basically metadata so we probably don't need the extra info tags at all. > >> *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). >> >> largedesktop >> >> > We should handle 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. >> >> >> title >> xprop | grep ^WM_NAME | ... >> > 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. >> >> name >>etc... >> >> >> *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. >> >> >> >> >> >> >> > What about the subgroup tag that we already use in the opencomposite.org > plugins? > > Foo > > ... > > > ... > > > > 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. > >> *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. >> >> >> >> http://www.example.com/plugin-update.xml >> > 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. >> >> http://www.example.com/plugin-info.html >> >> >> >> > mime="text/html">http://www.example.com/plugin.html >> > mime="image/jpeg">http://www.example.com/plugin.jpg >> > mime="application/swf">http://www.example.com/plugin.swf >> >> >> > This should be on the plugin info page and not part of the metadata. > This would allow config apps to display screenshots internally without the user having to go to a separate website. > Regards > Dennis > > > > ___ > 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] 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. > > > 0 > 1 > 0 > A more general plugin info struct should be better bob "[EMAIL PROTECTED]" alice "[EMAIL PROTECTED]" GPL 0.1.0-git http://www.example.com/plugin-info.html > > *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). > > largedesktop > We should handle 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. > > > title > xprop | grep ^WM_NAME | ... This is a big security risk. > > name >etc... > > > *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. > > > > > > What about the subgroup tag that we already use in the opencomposite.org plugins? Foo ... ... 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. > > > > http://www.example.com/plugin-update.xml Security risk again. Distributions don't like individual binary update systems. > > http://www.example.com/plugin-info.html > > > > mime="text/html">http://www.example.com/plugin.html > mime="image/jpeg">http://www.example.com/plugin.jpg > mime="application/swf">http://www.example.com/plugin.swf > > 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
[compiz] Some suggestions for extra metadata
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. 0 1 0 *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). largedesktop 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. title xprop | grep ^WM_NAME | ... name etc... *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. *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. http://www.example.com/plugin-update.xml http://www.example.com/plugin-info.html http://www.example.com/plugin.html http://www.example.com/plugin.jpg http://www.example.com/plugin.swf Regards Mike ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Allow core functions to be activated on hotcorners
Mike Dransfield wrote: > Sam Spilsbury wrote: > >> Recently there was a suggestion that the "Show Desktop" plugin could >> be activated on a hotcorner. I noticed that there is now a core >> interface for this - otherwise known as "Hide all windows and focus >> the desktop." This can be activated with Ctrl-Alt-D. However - it >> cannot be activated with a hotcorner - which could be useful for >> people who do not have a "Hide all windows and Show the desktop" on >> thier panel. I then noticed that none of these options could be >> activated with a hotcorner. >> >> Is it possible to activate core funtions with a hotcorner? >> >> > > The fix is simple, but it does not work with edge + edgebutton. > > I think its related to the same problems as with the other core > actions and edgebuttons. I would rather that problem is solved > first, then Ill add this if nobody else does. > > If you want to enable this functionality yourself then you can > modify metadata/core.xml.in and find the show_desktop option > then change the allowed line to this. > > > > Then make clean and make install > Second thoughts, this might be easier Download this patch here and apply it to your git checkout with this command. git am 0006-Allow-showdesktop-on-edge.patch http://www.anykeysoftware.co.uk/compiz/0006-Allow-showdesktop-on-edge.patch Further pulls will work without a problem. If you modified your source, then type git checkout -f to revert it. > >> ___ >> 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] Allow core functions to be activated on hotcorners
Sam Spilsbury wrote: > Recently there was a suggestion that the "Show Desktop" plugin could > be activated on a hotcorner. I noticed that there is now a core > interface for this - otherwise known as "Hide all windows and focus > the desktop." This can be activated with Ctrl-Alt-D. However - it > cannot be activated with a hotcorner - which could be useful for > people who do not have a "Hide all windows and Show the desktop" on > thier panel. I then noticed that none of these options could be > activated with a hotcorner. > > Is it possible to activate core funtions with a hotcorner? > The fix is simple, but it does not work with edge + edgebutton. I think its related to the same problems as with the other core actions and edgebuttons. I would rather that problem is solved first, then Ill add this if nobody else does. If you want to enable this functionality yourself then you can modify metadata/core.xml.in and find the show_desktop option then change the allowed line to this. Then make clean and make install > ___ > 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
