Re: [compiz] Plugin Dependencies
You shouldn't keep a small db of known plugins. The dbus plugin should be able to give you the dependencies of any plugin so you can sort them properly and generate proper error messages if some plugin can't possibly be loaded due to some conflicts. I haven't being following compiz development for a while now, so i'm not sure whether this has been changed or not. But wouldn't reading the dependency options via dbus require the plugin to be activated first, making this method rather pointless, as you need to know the options before activation? Or has a semi-activated plugin state been implemented now? Also I found many of the dependency options within the plugins to be incomplete. For example the cube plugin i think (I don't have access to a compiz install right now) requires to be loaded before switcher and scale. When in reality for it to work it needs to be loaded after gconf and dbus, before rotate and with rotate as a dependency. I don't see any good reason to why we would want the dependency order resolved by the core. We can add an utility function and put it in core or better in some shared library which can be used to solve dependencies at the plugin or application level. What do you think? That plugins can be stacked differently, is a feature. It might not be incredibly useful right now but I think it will be later on so I'd like to keep it. Yes a shared library would be very useful, maybe just a few functions thats can be accessed through compiz.h? Or maybe there could even be a new plugin to handle automatic activation/dependancies? (Maybe this plugin could also be used to determine which settings backend to use, now there is an ini settings plugin, but that is a seperate issue..) Thanks Ben, On 2/26/07, David Reveman <[EMAIL PROTECTED]> wrote: On Thu, 2007-02-22 at 15:46 +, Ben Reeves wrote: > I'm continuing to work on compiz-settings now. The most common > complaintat the moment is the way it activates plugins, a lot will > fail to activate due to being loaded in the wrong order. At the moment > It has a small db of known plugins and has load_before and load_after > for each one, however if a plugin is unknown it will be loaded last > and will fail to activate. You shouldn't keep a small db of known plugins. The dbus plugin should be able to give you the dependencies of any plugin so you can sort them properly and generate proper error messages if some plugin can't possibly be loaded due to some conflicts. > > I think it would be much better if every plugin carries it's own > load_before, load_after and depends_on options and the core then > decides in what order to activate the plugins. This would make writing > a settings manager much easier, make it easier to start compiz and > save duplicated effort so that each settings manager doesn't have to > do it's own form of dependency generation. To activate a plugin the > settings manager could simply send a dbus signal activate "cube" and > the core would return whether it has activate any dependencies e.g. > activated "rotate" and if plugin activation was successful or not. > > What do you think? I don't see any good reason to why we would want the dependency order resolved by the core. We can add an utility function and put it in core or better in some shared library which can be used to solve dependencies at the plugin or application level. What do you think? That plugins can be stacked differently, is a feature. It might not be incredibly useful right now but I think it will be later on so I'd like to keep it. - David -- Thank you Ben Reeves ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] Plugin Dependencies
I'm continuing to work on compiz-settings now. The most common complaintat the moment is the way it activates plugins, a lot will fail to activate due to being loaded in the wrong order. At the moment It has a small db of known plugins and has load_before and load_after for each one, however if a plugin is unknown it will be loaded last and will fail to activate. I think it would be much better if every plugin carries it's own load_before, load_after and depends_on options and the core then decides in what order to activate the plugins. This would make writing a settings manager much easier, make it easier to start compiz and save duplicated effort so that each settings manager doesn't have to do it's own form of dependency generation. To activate a plugin the settings manager could simply send a dbus signal activate "cube" and the core would return whether it has activate any dependencies e.g. activated "rotate" and if plugin activation was successful or not. What do you think? -- Thank you Ben Reeves ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Time to Vote for a Logo
I've extended the pole by another day On 1/4/07, Jeffrey Laramie <[EMAIL PROTECTED]> wrote: On Thursday 04 January 2007 10:19, Jeffrey Laramie wrote: > On Thursday 04 January 2007 10:11, Matthias Hopf wrote: > > On Dec 21, 06 20:39:43 -0500, Jeffrey Laramie wrote: > > > Our discussion and editing period has come to and end and it's time to > > > vote! You can find the poll here: > > > http://forum.go-compiz.org/viewtopic.php?t=286 > > > > Warning: mysql_connect() [function.mysql-connect]: Host > > 'gatorade.dreamhost.com' is blocked because of many connection errors; > > unblock with 'mysqladmin flush-hosts' in > > /home/.mansel/compizweb/forum.go-compiz.org/db/mysql4.php on line 48 > > Yes, the forum has been down more than a day now. Once we get that > straightened out I will start a new poll. The forum is back up and you may resume voting. Rather than start over we'll just add another day to the end of the poll. It will now end on January 6th at midnight GMT. After the forum stops accepting votes simply add your vote to end of the thread and we'll manually count it at the end. We're on the honor system here, so please no double voting. _______ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz -- Thank you Ben Reeves ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] Sane value for Number of Desktops?
Would it be possible that the max restriction for the number_of_desktops option could be set to a sane value. At the moment it's set to a maximum of ~32,000. Realistically whose going to want 32,000 workspaces! It makes the option really hard to set in compiz-settings because slider increments are too big. I think it woulb be more sensible to set it to max 100 (probably less). -- Thanks Ben Reeves ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] Re: [PATCH] Dbus improvements (was Include option type in gconf schema)
Whats the status of these patches, are they going to be included in git? I would really think these improvements would be useful Thanks, Ben On 11/24/06, Mike Dransfield <[EMAIL PROTECTED]> wrote: > Great, I've been hoping that someone would implement functionality for > retrieving all the option meta data through the dbus plugin. Let me know > when this is ready to go into head and I'll have a look at it. > > I think the attached patch is much better than the previous one I have made the methods return complex datatypes and I have split the function into type specific rest functions. This will hopefully make it much easier for strictly typed languages. I have also added some changes to send notifications as signals, this serves as a simple way for the actions to return information, doing it any other way would mean some nasty hacks to the core. The downside is that script writers will have to deal with asynchronous programming. I will have a look at adding some functions to get information on windows and screens and then I will have a look at introspection. I have attached the patches in the git format specified, hopefully they will be acceptable. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Include option type in gconf schema
David, is there any chance that the gconf (or dbus) changes will be introduced into the git? because i would really like to get my configurator released, and i can't do it until the option type is available.I have separated all the gconf code in the program into separate wrapper functions so when the dbus changes get into the head then I should be easily be able to switch the backend to use dbus instead. I think tho there is one option missing with dbus, is there anyway to get a list of plugins available? Thanks,BenOn 11/15/06, Ben Reeves <[EMAIL PROTECTED] > wrote:David, is there any chance that the gconf (or dbus) changes will be introduced into the git? because i would really like to get my configurator released, and i can't do it until the option type is available. I have separated all the gconf code in the program into separate wrapper functions so when the dbus changes get into the head then I should be easily be able to switch the backend to use dbus instead. I think tho there is one option missing with dbus, is there anyway to get a list of plugins available? Thanks,BenOn 11/14/06, David Reveman < [EMAIL PROTECTED]> wrote: On Mon, 2006-11-13 at 05:57 +, Mike Dransfield wrote:> Ben Reeves wrote:> > I am writing a configuration front end for the compiz gconf plugin at> > the moment, but it's proving harder than it should be because gconf > > does not record what type of compiz option the key is. For example,> > say i want a color picker for each color option the only way I can> > tell with gconf if it is color is if it has a # at the beginning, but > > there could be string option which also have a # at the beginning so> > is not reliable.> >> > My proposal is that the short_description of each gconf key should> > contain the option type >> I think the solution for this is to wait until the dbus bindings> support getting information about settings. I have been working> on this and have a rough solution which I have attached. >> Putting the type into the option description, or a seperate file seems> like it would cause a lot of problems. The short description is translated> so that would cause bugs, it is also not straight forward for developers. >> The dbus patches are roughly my idea for how information about> options can be got via dbus. I wrote them so there is one getMetadata> function which returns all the information about the option. Your > application should cache this information as often as possible.>> I think that the method should return a dictionary rather multiple> return values. I couldn't find how to create a dictionary so I stopped. > If anyone knows how to do this (or even if I can just return multiple> return values) I would like to know.Great, I've been hoping that someone would implement functionality forretrieving all the option meta data through the dbus plugin. Let me know when this is ready to go into head and I'll have a look at it.-David-- Thank youBen Reeves -- Thank youBen Reeves ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Include option type in gconf schema
If it can't be stored in the schema, what if it was stored in a seperate key. e.g. each key has another key with the same name %key_name%_option_type (or something along those lines).e.g./apps/compiz/general/allscreens/options/close_window_key should also have another key /apps/compiz/general/allscreens/options/close_window_key_option_type = "CompOptionTypeAction"/apps/compiz/plugins/cube/screen0/options/skydome_gradient_end_color /apps/compiz/plugins/cube/screen0/options/skydome_gradient_end_color_option_type = "CompOptionTypeColor" I would prefer not to use dbus because if anyone turns the plugin off (or it fails) then the user will not be able to change the configuration to change it back. However if dbus is the only option, mike could you possibly give me an example of how I would retrieve the key type using your code. Thanks On 11/13/06, Mike Dransfield <[EMAIL PROTECTED]> wrote: Ben Reeves wrote:> I am writing a configuration front end for the compiz gconf plugin at> the moment, but it's proving harder than it should be because gconf> does not record what type of compiz option the key is. For example, > say i want a color picker for each color option the only way I can> tell with gconf if it is color is if it has a # at the beginning, but> there could be string option which also have a # at the beginning so > is not reliable.>> My proposal is that the short_description of each gconf key should> contain the option typeI think the solution for this is to wait until the dbus bindingssupport getting information about settings. I have been working on this and have a rough solution which I have attached.Putting the type into the option description, or a seperate file seemslike it would cause a lot of problems. The short description is translated so that would cause bugs, it is also not straight forward for developers.The dbus patches are roughly my idea for how information aboutoptions can be got via dbus. I wrote them so there is one getMetadata function which returns all the information about the option. Yourapplication should cache this information as often as possible.I think that the method should return a dictionary rather multiplereturn values. I couldn't find how to create a dictionary so I stopped. If anyone knows how to do this (or even if I can just return multiplereturn values) I would like to know.Mike ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] Include option type in gconf schema
I am writing a configuration front end for the compiz gconf plugin at the moment, but it's proving harder than it should be because gconf does not record what type of compiz option the key is. For example, say i want a color picker for each color option the only way I can tell with gconf if it is color is if it has a # at the beginning, but there could be string option which also have a # at the beginning so is not reliable. My proposal is that the short_description of each gconf key should contain the option type e.g./apps/compiz/general/allscreens/options/close_window_key short description should be something like "compiz_key_modifier" /apps/compiz/plugins/cube/screen0/options/skydome_gradient_end_color should contain something like "compiz_color"Hope thats clear-- Thank youBen Reeves ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
[compiz] Compiz Community
Hi,I am new to this mailing list as well, I just wanted to say that I have setup a new compiz community forum on http://www.compiz.biz (http://209.152.181.53/ ). This is by no means the "official" one, it's just that nothing much seemed to be happening on compiz.net or compiz.org so I set it up. Maybe when the domain issues are sorted out the forum can be transfered. thanks - Show quoted text -On 11/8/06, Jeffrey Laramie wrote: Hello,I'm new to compiz and to this list but I'd like to contribute. I couldn't finda more appropriate place to ask a few questions about the compiz project(which is actually my first question).1. Since the apparent compiz/beryl fork I don't see a compiz "community" site. Is there one?2. Is compiz going to continue to be developed, and if so, is there a road mapfor future development/migration?3. There was some discussion on the beryl site over the last few days and it appears that Guillaume has agreed to stop redirecting the compiz sites toberyl. Is he also releasing the ownership of the compiz.net and compiz.org domains? Is anyone following up on that? Are there plans to launch a newcompiz site?I'm afraid my coding skills are too weak to help compiz development, but Icould help with documentation, web page maintenance, and other less technical tasks. Let me know if I can help.Jeff___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
