IRC Log Viewer » #firebreath » 2013-04-17

IRC Nick Time (GMT-7) Message
reichi 07:04 taxilian: i came up with this now for the issue we've discussed yesterday
i looks fine to me
reichi 08:04 fine in terms of "it does what i expected it to do"
Aktau 08:04 I've seen two broad approaches for firing events from a plugin
Creating custom addEventListener/addRemoveListener and holding on to the NPObject's and whatnot
And the other one is just calling NPN_Evaluate or NPN_GetUrl
The second one seems way easier
And with some clever string manipulation allows easy creation of arrays and objects
Now I'm wondering, what are it's pro's/cons?
taxilian 09:04 Aktau: the second one is much slower
Aktau 09:04 NPN_GetUrl is slower than calling NPN_Invoke quite a bit of times to get the desired object tree taxilian ?
taxilian 10:04 NPN_GetUrl is *way* slower than NPN_Invoke. NPN_Evaluate I'm not as certain of, but what I would recommend is using the JSON.stringify (calling NPN_Invoke on it) to convert large structures to js
diorcety 10:04 hi
Is it normal the mix up between PLUGIN_NAME and FBSTRING_ProductName in firebreath-1.7
taxilian 10:04 the mix up?
diorcety 10:04 on osx
kylehuff 10:04 diorcety: on OSX?
not normal, but I can confirm.
diorcety 10:04 the path for the generated library is not the same that before
kylehuff 10:04 taxilian: when outputting the binary on build it is using FBSTRING_ProductName instead of PLUGIN_NAME, so until you rename the binary, your bundle will fail to load.
diorcety 10:04 can you give me the commit ?
kylehuff 10:04 I mentioned this about a month ago, but I wasn't certain if this was due to my invocation of the prep scripts being done way back in firebreath-1.2 or something way back.
what commit? I don't know what commit made the change. git blame could probably help you there. I never found the root issue, I have post-build rename my binary within the bundle.
taxilian 10:04 really? I haven't seen that somehow...
kylehuff 10:04 well, again, I'm not sure if it is due to my plugin config... but it happened I upgraded to 1.7 a while back. (could have even been 1.6,,,, it has been a while)
diorcety 10:04 i have double checked … i tried to make git diff firebreath-1.6 firebreath-1.7
not found stuff related to ProductName
taxilian 10:04 yeah, I can't think of anything that has changed
kylehuff 10:04 I didn't find it either diorcety; but I only did a cursory search. I was in the middle of a bunch of other crap
taxilian 10:04 at work I've been swamped doing web and (if you can believe it) front-end work, so I haven't had time to do plugin stuff in a bit
kylehuff 10:04 I'm going to be re-compiling on all platforms here in the next day or so. So I will revisit the issue (and determine if it is an issue, or a local config problem)
diorcety 10:04 PRODUCT_NAME in xcode project in fb-1.6 is PLUGIN_NAME in fb-1.7 is FBSTRING_Productname
taxilian 10:04 huh. well, if you can track it down I'll definitely accept a pull request. I won't have time to deal with it this week
what I don't understand is that if this is really keeping mac from building, why is it not happening to everyone?
kylehuff 10:04 Aktau: I wrote up a comparison that deals with the performance of returning data from a plugin to the browser; I don't know what you are trying to do, but maybe it will help you decide which way to go. (it may not be related to your question, I just caught on to the verbiage JSON.stingify and NPN_Invoke);
diorcety 10:04 no
i have made script based on generated plugin … so the script are broken
kylehuff 10:04 it builds fine for me, but in my environment I cannot load the plugin bundle.
Aktau 10:04 taxilian and kylehuff: that will serve awesomely, thanks
taxilian: that's sad to hear, I was excited by the extreme simplicity of the NPN_Evaluate solution
Don't particularly like the walls of code and memory releasing that the Invoke calls beget
taxilian 10:04 invoke if used right isn't really all that complicated
but look at kylehuff's link
npn_evaluate might be okay performance-wise; npn_geturl is horrible
and neither works well enough to use on IE
Aktau 10:04 Ah
That's my big advantage
And the reason I made a pure C npapi plugin
I do linux + recent chromium and firefox only
diorcety 10:04 i fix what i said: PLUGIN_NAME -> FBSTRING_PluginName (FB-1.6->FB-1.7)
Aktau 10:04 I'm also quite impressed by the npapi-vlc code
Except for their event handling
That's horrid
And really difficult to track
diorcety 10:04 it is the commit 6346cef7a1855b91b857be834bd84bbd564e0a4a
kylehuff 10:04 diorcety: out of curiosity does your plugin bundle load with the binary being named "differently"?
diorcety 10:04 kylehuff: i have'nt tried
103 set_target_properties(${PROJECT_NAME} PROPERTIES
in Mac.cmake
150 set_target_properties (${PROJNAME} PROPERTIES
151 OUTPUT_NAME ${FBSTRING_PluginFileName}
in Win.cmake
taxilian 10:04 hmm. yeah, those should probably be the same
diorcety 10:04 and nothing for X11
67 set_target_properties ("${PROJNAME}" PROPERTIES
taxilian 10:04 heh. those should really probably be made consistent
diorcety 10:04 :D
see you
diorcety 11:04 re
taxilian 11:04 he's back
diorcety 11:04 hum maybe use PluginFileName ... every where ... (without extension)
taxilian 11:04 that's kinda what I think too, I think
diorcety 11:04 string(REGEX REPLACE "\\.dll$" "" FBSTRING_PluginFileName "${FBSTRING_PluginFileName}")
in all case .dll is already removed?
taxilian 11:04 .dll *shouldn't* be in there, but maybe it is; I forget
but yeah, that might not be a bad idea
could be on older ones it had it
diorcety 11:04 set(FBSTRING_PluginFileName "np${PLUGIN_NAME}.dll")
in fbgen/src/PluginConfig.cmake
taxilian 12:04 hmm. awesome.
diorcety2 15:04 taxilian: is it normal the changes in templateInstaller for the commit ?
the GUIDS_INSTUPGR is changed at the line 3 but not at the line 5
taxilian 16:04 hmm. I'm not actually sure
good question
diorcety2 16:04 i will provide pull requests tomorrow
good night