IRC Log Viewer » #firebreath » 2011-03-12

IRC Nick Time (GMT-7) Message
tony_ 07:03 I want to redraw the plugin 5 times a second..How to schedule a time and where can I handle the timer callback, and Invalidate the control/..?
Its mac plugin using core graphics
nitrogenycs 12:03 hey
JSAPI::HasProperty is called when you do obj['blabla'] or obj.blbla right?
Now, when is JSAPI::HasMethod called?
if HasProperty() is called with a name like "myMethod" should it return the method or not?
I guess no?
taxilian 12:03 nitrogenycs: sorry, I'm back
nitrogenycs 12:03 taxilian: no problem
taxilian 12:03 so that's a tricky question
it always calls HasProperty
to see if it is a property or not
in FireBreath, as of 1.4, HasProperty will return true for methods most of hte time as well
and then it returns a JSAPI method object
which is a jsapi object which you can call ->Invoke("", <args>)
nitrogenycs 12:03 ok
taxilian 12:03 that's not really required, though; it just makes it so you can do something like:
nitrogenycs 12:03 So will Invoke ever be called with something else than ""?
taxilian 12:03 var a = plugin.myMethod
well, it could be
but by default usually isn't
nitrogenycs 12:03 okay
taxilian 12:03 I think there is a flag you can set to disable methodobjects
not sure, 'cause the guy who wrote all this stuff is a slacker who doesn't document things well
nitrogenycs 12:03 lol
is it enough to implement only the pure virtuals for a custom JSAPI?
e.g. are things like the event automatically mapped to the GetProperty/GetMethod things?
taxilian 12:03 hang on, let me open the class def for JSAPI
honestly I really should pull some things out of JSAPI because they don't always apply
the event stuff in particular
and make JSAPI more of an interface than it is
ignore all the zone stuff
ignore all the event stuff
nitrogenycs 12:03 ok, currently trying to implement it for c# and python, we have the wrappers already written and they compile :)
taxilian 12:03 okay
nitrogenycs 12:03 ok, I ignored events
and only had zone for the constructor
taxilian 12:03 other than those, most of the methods that aren't pure virtual are just specializations of methods that are
i.e. allow wstring instead of string
nitrogenycs 12:03 yes
I used only the pure virtuals
ok, now last question about the method objects
taxilian 12:03 HasMethodObject, etc, is just if you want to support those
it's optional
nitrogenycs 12:03 method object is so you could do the var a= plugin.myMethod; a(1,2,3); stuff right?
taxilian 12:03 right
nitrogenycs 12:03 if I don't implement methodobject I can only do plugin.myMethod(1,2,3)
taxilian 12:03 right
nitrogenycs 12:03 ok cool
then I'll implement those as well
taxilian 12:03 I'd start without
and then add them
I'm not totally sure I did it in as clean of a way as it should be
but look at JSAPIAuto for an example of how it works
nitrogenycs 12:03 ok
taxilian 12:03 I think it ends up sometimes getting it from GetProperty instead of GetMethodObject, but I don't remember for sure
nitrogenycs 12:03 okay
I'll write some test code to check
property deletion is triggered by SetProperty(name, undefined)?
taxilian 12:03 currently, actually, I don't think it's implemented
nitrogenycs 12:03 ok
taxilian 12:03 feel free to implement it
and send me a patch
nitrogenycs 12:03 :) ok
i'll first get this going, then I'll refine
taxilian 12:03 would actually be pretty easy
nitrogenycs 15:03 does anybody know if I can easily include the plaform sdk with cmake?
taxilian 15:03 yes
I know
there may be others who know as well
most likely are
Deaod 16:03 anyone got some time on their hands?
taxilian 16:03 not really, but whats up?
Deaod 16:03 well, i started writing a plugin
taxilian 16:03 btw, nitrogenycs, did you want to know how to find the platform sdk?
Deaod 16:03 now i wanted to use curllib to download something from a server
compiled, but regsvr wont install it.
taxilian 16:03 Deaod: you're probably missing a dll
the libcurl you used probably was a dynamic link
if you want to use a static one, you could use the firebreath lib
Deaod 16:03 says it could find the specified module
if thats of any help.
taxilian 16:03 right
you are missing a dll
Deaod 16:03 mkay
taxilian 16:03 probably something like curl.dll or libcurl.dll
it needs to be in the same dir as the plugin .dll file
Deaod 16:03 moving those into the system32 folder should do, i thought
taxilian 16:03 well, yes… as long as you don't ever plan to worry about needing to install this, that should work fine
but if it's in system32 then regsvr32 should work
Deaod 16:03 mmmmh
that explains it then
taxilian 16:03 or if it's in the same dir
Deaod: depends.exe (Dependency Walker) is a good tool for tracking down things like that
though it does always find ieshims.dll and sometimes one other as being missing when they aren't
nitrogenycs 16:03 taxilian: I chose the easy way for now and did something like "${PROGRAMFILES_DIR}/Microsoft SDKs/Windows/v7.0/Include"
taxilian 16:03 no no no no no no no no no no no no no
don't do that
it is fragile
it will break
and there is a much easier way
go look at cmake/Win.cmake
specifically look for how I find signtool
nitrogenycs 16:03 hmm, interesting
that's also how it's done in scons
except it has it builtin :)
taxilian 16:03 really? pity that google's team hasn't figured that out yet
omaha requires you to set an environment variable
nitrogenycs 16:03 :)
taxilian 16:03 I'm not real impressed with scons, but that may just be because the projects that I have seen use it seem to use it really really poorly
nitrogenycs 16:03 scons has some complex stuff in there to find the pathes for all visual studio sdks and platform sdks
from express to professional, from 2005 to 2010, x86, x64, ia64 etc
taxilian 16:03 really? the cmake stuff isn't all that complex, and it'll find all of that
it's at the beginning of the file
of Win.cmake
just find it in the registry
nitrogenycs 16:03 yes, I found WINSDK_DIR
taxilian 16:03 we should probably make that into a nice useable cmake module and submit it to the project
but I have too much else to do
nitrogenycs 16:03 just for reference, this is the scons stuff for the sdk:
it's basically the same with a few fallbacks
ok, I'll use WINSDK_DIR
thanks for the pointer, that cmake file is nice to have :)
taxilian 16:03 I don't remember if I put that variable in a scope that you can use it or not
but you can definitely copy it
like I said, we should probably make it into a proper cmake module (maybe steal some ideas from the scons detection) and have it there by default on win
and submit it to the cmake project
nitrogenycs 16:03 yes, I need to copy it
cool, works like a charm
taxilian 16:03 yep =]
the day I discovered cmake can read the registry like that was a good day
be back in a bit
nitrogenycs 16:03 hmm, but it gets the wrong one
there's one in c:\program files and one in c:\program files (x86)
by default the code gets the one in c:\program files
while the headers I need are in program files (x86)
I guess cmake would have to read the wow64 registry or something
taxilian 16:03 nitrogenycs: I would look in the registry and see if you can find a different path
nitrogenycs 17:03 yeah, I am using the \\v7.0A registry key for now
nitrogenycs 18:03 taxilian: I see evaluateJavascript does not return anything
taxilian: because of IHTMLWindow2::execScript
taxilian: maybe one could get the "eval" function via code and then invoke this one with the script string?
taxilian 18:03 possibly
of course, that begs of question of whether or not it would still retain the permissions of a plugin? I don't know
I've thought about it a few times, but my personal opinion is that you should avoid calling that function wherever possible anyway
nitrogenycs 18:03 yes, I can see why
For the wrapper it seems useful, because otherwise you can't get javascript results without javascript pushing it in explicitly
one way to circumvent this and the current code would be to do
_eval_callback = plugin.evalResultCallback; on the js side
and the do evaluateJavascript("_eval_callback(eval(1+1))");
thereby talking js into calling back to ourselves :)
taxilian 18:03 yeah
but that seems like too much of a hack to make standard
nitrogenycs 18:03
taxilian 18:03 not quite following what they're doing..
nitrogenycs 18:03 basically they just get a pointer to the IDispatch
taxilian 18:03 right… but which idispatch?
nitrogenycs 18:03 of a DoSomething method
and then they invoke it and return the result
taxilian 18:03 right; we do that all the time
that's easy
nitrogenycs 18:03 now we could change DoSomething to "eval" and it would work
taxilian 18:03 well, maybe
eval is a property of the window object
so we should be able to get it from there
in fact, you can do that with FireBreath already
pretty easily
I just don't know what the permissions that it executes as is
nitrogenycs 18:03 ahhhhhhhhhhh
I can call getDOMWindow()
taxilian 18:03 yes
nitrogenycs 18:03 then call getJSObject() on it
taxilian 18:03 right
I haven't actually tried it
but it will definitely work on FF, and most likely will work on IE
that's how we do the onload callback, and it works on both
nitrogenycs 18:03 :) coolies
taxilian 18:03 but IE is sometimes a little inconsistent
nitrogenycs 18:03 yes, I think the scope of eval can be different
taxilian 18:03 it shouldn't be, but it might be
you'd have to try ti
try it
nitrogenycs 18:03 ys, I will