|IRC Nick||Time (GMT-7)||Message|
|Wavey||03:07||Did any of you ever tried to run a firebreath plugin built on windows 7 (platform toolset v100) on windows 8?|
|taxilian||09:07||good morning all. I'm back in the office|
|michaelfig||10:07||Hi, I'm trying to implement a plugin with three different JS objects. At first, I had them registered in one plugin with different mimetypes, but that made IE get quite crashy when they were all used on the same page in different OBJECT tags. My new solution is to define a new JS root object, which registers the other three objects as properties. Is this supported, and has anybody else done it? I'm seeing "Error: Error cal
@taxilian: Good morning. Sorry for calling you "Robert" instead of "Richard" in my github pull request. :/ I'd be interested to know if you could use any of my changes. :)
|taxilian||10:07||lol. no worries. hang on, let me look at it again
michaelfig you can definitely expose multiple JSAPI objects from a single plugin instance
but I don't know of any reason that using multiple mimetypes should make it "crashy"
|michaelfig||10:07||It worked like a charm under other browsers, but my IE7 machine just didn't behave well... it apparently didn't do much checking to see that it didn't need to reinstall the plugin three times whenever it changed, and other stuff like that.|
|taxilian||10:07||okay; looking at these changes, the main reason I'm not going to accept this one is that there is far too much inside a single pull request; I need pull requests to be a single feature or fix (or a small group of completely related ones).
can you explain what you mean by https://github.com/michaelfig/FireBreath/commit/3cf54fabc6e7e61550cc373f21c30d6b9968f65f ?
|michaelfig||10:07||I like the design of a root object with three properties much better.|
|taxilian||10:07||it's cleaner, if you're just doing js tie-ins|
|michaelfig||10:07||The commit is because in log4cplus, it fails to compile unless you define _WIN32_WINNT. I think it's good practice in general to define this macro up front for all win32 projects, but if you leave it undefined, I think it should still compile.
What do you mean by js tie-ins?
|taxilian||10:07||the general policy is to modify external libraries as little as possible, so that updating them will be easier
|michaelfig||10:07||I have the convenient situation of one of the three doing drawing, and the other two just as "tie-ins".|
|taxilian||10:07||then yeah, I'd just use a single object tag
so how does threads.cxx normally work in other projects w/out that defined, then?
|michaelfig||10:07||Beats me. I'm using vc 2005, if that makes a difference.|
|taxilian||10:07||is LOG4CPLUS_USE_WIN32_THREADS normally defined?|
|taxilian||10:07||hmm. I guess it's possible that it doesn't compile by default in 2005
I would probably prefer you used cmake to add a define globally rather than modify the log4cplus files directly, though
|michaelfig||10:07||I agree, now understanding your 3rdparty library policies.|
|taxilian||10:07||https://github.com/michaelfig/FireBreath/commit/6e14acede570e5a02e8bec4d7f791ca847e9b06d I'm happy to accept, but would definitely prefer to have in its own pull request; I know it's a tad bit more of a pain, but if you just create a new branch (off of firebreath's master) and then cherry-pick it in it shouldn't take too long
https://github.com/michaelfig/FireBreath/commit/7370f9e93fb24feaa9add4358b65ae716a284005 I need more information about what you're trying to solve
in particular, setting the extension on mac to .dylib is incorrect
|taxilian||10:07||I'm not sure where SUFFIX is used, though|
|michaelfig||10:07||In naming the file that's used in the call to chrome.cmake and xpi related stuff.|
|taxilian||10:07||I see. yeah, mac plugins are not dylibs
so the purpose of the commit is to make the XPI generation work better?
|taxilian||10:07||rather, to make it work on non-windows platforms
|taxilian||10:07||I can only surmise, then, that you haven't tested it on mac =]|
|michaelfig||10:07||Yes, that's my third platform: first X11, then Win, then (with almost no experience) Mac.
Still trying to make the beast compile under Mac.
|tonikitoo||14:07||$ FireBreath/prepmac.sh . build-release -D CMAKE_BUILD_TYPE=Release
is that the proper way to pass "release" to the prep build
I get something like this in console:
Manually-specified variables were not used by the project:
|taxilian||15:07||tonikitoo you don't need to pass cmake_build_type except on linux
just set xcode to release mode