IRC Log Viewer » #firebreath » 2012-10-04

IRC Nick Time (GMT-7) Message
Guest39982 07:10 hi! I had no luck by adding the boost "process" library to firebreath by adding "add_boost_library(process)" to the cmake file. is there any way to add it?
guest9823 09:10 (got my browser window closed). in commit 2f0f8ba of firebreath, the comment states "Add boost::process to the included boost". Is there a way to use it right now?
taxilian 09:10 guest9823: I don't remember for sure, but I think boost process is a header only library
guest9823 09:10 that's exactly what is written in so there is no need to add it via the project's cmake file via "add_boost_library(process)"?
taxilian 09:10 correct
guest9823 09:10 thx for the hint, i'll manually copy the header files to the boost 3rd party installation in fb1.6
taxilian 09:10 why?
just use 1.7
JuanDaugherty 10:10 is the installer just an appendage or a central part of FB? In particular might it or does it scan the host to determine what browsers are present (or have any other operative FB logic)?
taxilian 10:10 it's just a convenience thing
and there is no need to scan the host to see what browsers are present; it just installs so that all that might be will work
mainly it is strongly recommended that you install plugins using an MSI and that gives you a simple way to do so
it is also strongly recommended that you don't use a self-reg dll
rather that you don't selfreg the dll in the install
JuanDaugherty 10:10 self reg?
as opposed to with some user interaction?
taxilian 10:10 self reg means calling DllRegisterServer on the dll; it's bascially what regsvr32 does
great for testing, less of a good idea for production install
JuanDaugherty 10:10 ah. You know I wonder sometimes if I need to regsvr after every link
taxilian 10:10 no
JuanDaugherty 10:10 I don't believe my app does/did that, but I thought the Wix installer did
taxilian 10:10 all it does is add some registry keys; once the keys are in place, you only need to rerun it if you move the dll
JuanDaugherty 10:10 thx
taxilian 10:10 when you create the wix installer it uses heat.exe to run dllregisterserver and captures the output and generates a .wxs file to do what it does
JuanDaugherty 10:10 so it self-regs?
taxilian 10:10 but the nature of a MSI installer is instead of running a string of commands, it describes what changes should be made; that way the changes are recorded and will be uninstalled correctly
with a self reg it's just running a program to install, another to uninstall; there is a lot more that could go wrong
JuanDaugherty 10:10 right. I'm thinking ATM a third party package to scan for the present browsers may be needed
taxilian 10:10 so by not doing a self reg you have exact control over what is happening rather than trusting that FireBreath didn't make a mistake and not uninstall it correctly, which could (and has in the past) cause some really weird, confusing, and extremely difficult to debug issues with uninstall or upgrade
why is that?
JuanDaugherty 10:10 how else would you get a list?
taxilian 10:10 why do you need one?
what is the problem you want to solve?
JuanDaugherty 10:10 from which the user can select which they want a plugin installed for or not
taxilian 10:10 why would you need to do that? you install it for activex, you insatll it for npapi
JuanDaugherty 10:10 and Chrome, FF, and IE are supported on Windows
taxilian 10:10 ie is activex
chrome and ff are npapi
thus they are covered
no need to install specifically for one of the browsers
even opera, though last I checked it has to be a per-machine installer for opera to see it
JuanDaugherty 10:10 now that my base plugin is mostly working turning to these other issues
at least in FF
it seems 12 is the version of FF it want's to run on WIndows XP
JuanDaugherty 11:10 vs2012 has a very different look and feel from earlier, using the xpress on 64
taxilian 11:10 huh
JuanDaugherty 11:10 as installed anyway, same core app but looks more like a web page although they call it desktop VS
JuanDaugherty 11:10 a vs2k5 solution appeared to convert without issue, but haven't gotten function synced with 32
JuanDaugherty 12:10 i wonder at what point a general browser will default to 64bit on 64bit OS? Does Safari now?
JuanDaugherty 13:10 looks like everything will work with prep2012x64 with the free product, but you have to get the nightly cmake
taxilian 13:10 JuanDaughtery: no, no browsers in windows are currently 64 bit by default
JuanDaugherty 13:10 about time
FWIU more than 30% of windows installs now are 64bit OS
tortexy 15:10 after going fullscreen... any idea how to prevent the upcoming popup of the browser informing to press f11 ?
taxilian 15:10 that would be a browser issue, not a plugin thing
probably not possible, but if so it'd either be a hack using API calls or an extension thing
Scott_ 15:10 question about hello world?
taxilian 15:10 okay
Guest81343 15:10 Just compiled it w/ debug symbols and the binary was 3MB
taxilian 15:10 okay
Guest81343 15:10 Is it always that big?
taxilian 15:10 with debug symbols? yes
Guest81343 15:10 yeah
concerned this very nice framework is too heavy
hoping there is a way to get something like hello world MUCH smaller
taxilian 15:10 are you planning to deploy with debug symbols?
Guest81343 15:10 no
I just something quick
taxilian 15:10 then why are you basing your decision on what the size is when compiled in debug mode?
Guest81343 15:10 Cause I came to the FAQ
taxilian 15:10 generally I recommend that people release the optimized, release version
Guest81343 15:10 saw this
and thought I'd just ask
I'd think final size is a known issue
taxilian 15:10 which after compressed tends to be about 300-500K for the installer if ti's a really simple plugin
yes, you could make it smaller wtihout FireBreath
you'd do 10x more work and be much more likely to run into issues
but you coudl do it
Guest81343 15:10 No, I want to use firebreath
just want to make sure I can get 'close' before I spend more time on it
I'll recompile w/o debug and play around on my own
what I needed to know
taxilian 16:10 our plugin installer is about 800K; it has a lot of other stuff added to it
remember you'll usually deploy compressed as well
Guest81343 16:10 cool thanks, the readme.txt should mention something high level, just kicking the tires like I did was "whoa...." moment
and why I came here
taxilian 16:10 feel free to update it ;-)
tortexy 16:10 Thanks!
JuanDaugherty 20:10 prep2012x64 appears to generate idl for 86, breaking the build there
JuanDaugherty 20:10 (xpress, could be specific to it, atlib x86 vs x64 is brk, idl files show target arch = x86)
taxilian 20:10 … Juan why would the idl be different between x86 and 64?
JuanDaugherty 20:10 shouldn't it have target arch x86_64 x64 whatever?
taxilian 20:10 not as far as I know...
the .idl file should just define the interface; it's compiled with midl to c/c++ code
and that should compile for either
JuanDaugherty 21:10 well it's an express env, so you may wish to not support. I don't have the problem with the prep2005x64 I made and which produced the current working 64bit plugin but hit snags updating it to the 32 function level
i.e. the current level of my end plugin code
so was gonna see if vs2012 would work and except for that it appears it would, and I may clear that
funny thing is there a dramatic change in compile times if you do or don't have _WIN64 defined when the build type is x64
i.e. faster if you do