On 4/1/07, Mike Dransfield [EMAIL PROTECTED] wrote:
My plan is to push these changes out and then quickly work
another patch to make it all work properly again.
Are you OK with this?
Sounds good, I'll be glad to finally get it committed. :)
--
Travis Watkins
http://www.realistanew.com
On 3/27/07, David Reveman [EMAIL PROTECTED] wrote:
I told Mike Dransfield to have a look at your patches and include them
if they're OK. Let me know if you need feedback from me.
I keep updating and expecting them to be there. :) Mike didn't seem to
have any problems with them other than the
Travis Watkins wrote:
On 3/27/07, David Reveman [EMAIL PROTECTED] wrote:
I told Mike Dransfield to have a look at your patches and include them
if they're OK. Let me know if you need feedback from me.
I keep updating and expecting them to be there. :) Mike didn't seem to
have any problems
On 3/28/07, Mike Dransfield [EMAIL PROTECTED] wrote:
I haven't forgotten about the patches, the problem
with the warning seems to point to a deeper problem
where the plugins are not correctly unregistered.
Have you looked any further into these warnings and
stopping them?
As explained, it's
On Sun, 2007-03-04 at 02:19 -0600, Travis Watkins wrote:
On 3/1/07, Travis Watkins [EMAIL PROTECTED] wrote:
Remaining problems:
* need to figure out what to do with activate/deactivate
* core doesn't get any options registered
Updated the patch. It now registers/unregisters plugins
On 3/5/07, David Reveman [EMAIL PROTECTED] wrote:
I haven't looked at it yet. I will soon. If all the functionality that
the current dbus plugin provides works OK, then I don't see any reason
for holding back on this one.
Should I add mikedee's changes? They change the interface for
activate.
Travis Watkins wrote:
We to advertise the dictionary method with introspection but still
support the old method. Not sure if you can do it with the same
activate message though.
It should be easy enough, just a case of checking the type of the
first iterator and handling either string or
On 3/1/07, Travis Watkins [EMAIL PROTECTED] wrote:
Remaining problems:
* need to figure out what to do with activate/deactivate
* core doesn't get any options registered
Updated the patch. It now registers/unregisters plugins on load/unload
by wrapping initPluginForDisplay and friends. I
On 2/27/07, Mike Dransfield [EMAIL PROTECTED] wrote:
I have had a quick look and I think its possible to have a
variant number of key value pairs with something like this
as the signature.
a(sv)
Which is probably the same as something like this (but will
probably not marshall as well)
a{sv}
On 2/27/07, Travis Watkins [EMAIL PROTECTED] wrote:
Alright, I'll redo it as an addition to the current dbus plugin and
send in a patch. It might not be until tomorrow though.
Alright, here is my patch. A couple issues:
* It doesn't seem to register any options for core,
Travis Watkins wrote:
The real problem is actions (ie activate/terminate)
because they can take a variable number of arguments
so would need to register somehow.
Perhaps it can take an array?
It would need to be a dictionary because they are named
parameters and they contain different
On 2/27/07, David Reveman [EMAIL PROTECTED] wrote:
Incremental changes are always appreciated when possible. Having a
history of all changes is always good. You can do that locally or we can
get things into head in its current state and you can work on it there.
Whatever you prefer. If the
Travis Watkins wrote:
From the specification:
A DICT_ENTRY works exactly like a struct, but rather than parentheses
it uses curly braces, and it has more restrictions. The restrictions
are: it occurs only as an array element type; it has exactly two
single complete types inside the curly
On Mon, 2007-02-26 at 14:36 -0600, Travis Watkins wrote:
I've started work on a rewrite of sorts for the dbus plugin that
changes how it listens/responds to messages to make it possible to
generate introspection data. The main changes are registering every
plugin, screen, option, etc with
On 2/26/07, David Reveman [EMAIL PROTECTED] wrote:
Awesome, I've been hoping that someone would interested in doing this.
The new dbus-python requires it so if I want to write python apps that
use it this is needed. :)
I'm all for changing the API. If you like to get your current changes in
Travis Watkins wrote:
The real solution is to change the API to make it
introspection-friendly. Rather than make these changes and submit them
I thought it was be a good idea to ask what people thought a good
solution would be. The API would ideally have every method take/return
the same number
On 2/26/07, Mike Dransfield [EMAIL PROTECTED] wrote:
I thought that we were ok for most options because
each method is attached to a different object.
You should be able to read each option to tell what
datatype it is when generating the XML, or am I
misunderstanding it?
You're right, I forgot
17 matches
Mail list logo
