|IRC Nick||Time (GMT-7)||Message|
|PauloMarcio||10:02||Hi, taxilian... it seems at FB::SimpleStreamHelper::SynchronousRequest [PluginCore/SimpleStreamHelper.cpp(109)] that the variable cb [PluginCore/SimpleStreamHelper.cpp(117)] should have been injected in req before AsyncRequest but were not
but req is const
|taxilian||10:02||feel free to submit a pull request
but are you on the latest version?
that sounds like something that I thought was fixed?
got it this week
that one must have slipped by
you can submit a jira ticket and I'll probably get to it eventually
but the best way to get it fixed is to just fix it, test it, and submit a pull request
|PauloMarcio||10:02||so do u think trunk has it done?|
|taxilian||10:02||no, 1.7 and trunk are at the same commit right now, I believe|
|PauloMarcio||10:02||ok, I'll do it
well, do you think should I remove const and inject cb in req or change every caller
|taxilian||10:02||Do it the same way that the AsyncRequest method does it
… which is to remove the const and inject cb, I believe
sorry, I have a splitting headache today and I just got back from traveling for 3 days. I don't mean to be so cranky =]
|PauloMarcio||10:02||no problem :)|
|jshanab_OSX||11:02||taxilian. good morning.|
|jshanab_OSX||11:02||I am writing my own opengl context abstraction. All libraries I found want to do event handling and things get all screwed up. If I can get it working nicely on windows,Mac and Linux, I would like to move it into FB. I was wondering if this is already being worked on and if not how it would be best integrated into FB.
The windows one is working and has restored operation!
|taxilian||11:02||cool =] yeah, I got your email
I'm still thinking on how best to do it
for now build it in however you need to
make a fork of the framework as needed
then I'll look at it with you and see how best to handle it
|jshanab_OSX||11:02||It is gonna take me a laeast a week to get working on the big 3, but I already got the mac part way working. I have teh added requirement of a tearoff/redock in my app so how to allow that is a bit... Interesting. I'll keep ya posted.
Right now it is a trip down memory lane, I haven't done the direct win32 in a while
|kevincondon||12:02||What is the best way to generate a FB Windows MSI installer that can be controlled by command line options to install as either per-user or global?|
|taxilian||13:02||kevincondon: I don't know|
|kevincondon||13:02||Are the plugin wxs file and FBControl.rgs the only places where FB decides what to do with the registry?|
and the rgs feeds the wxs
|kevincondon||13:02||Can you point me in the right direction for where that connection is?
I think I can figure out ways to conditionalize the installer's per-user/global choice in the wxs so that I can pass in properties via the msiexec command line. I'm definitely pretty far from figuring out what to do with FBControl.rgs though.
|taxilian||13:02||basically the rgs defines what happens when you call DllRegisterServer
when WiX is run it runs heat.exe on the dll which calls DllRegisterServer and that captures what it does
that's where the connection is
|kevincondon||13:02||So the DLL itself is built to be either per-user or global. That won't lend itself very well to install-time configuration. Other than building completely separate installers (run the prep script 2x with FB_ATLREG_MACHINEWIDE=1 in one of them), can you think of any other options? Even crazy ones?|
|jshanab_OSX||14:02||Don't we need CMAKE to generate a build config? like debug or release and you select at build time? or is this at user's install time|
|kevincondon||14:02||This is at the user's install time|
|jshanab_OSX||14:02||I think I saw that on wix's site. that means it all goes in the .wxs file.
I do not know if this SO is what you are talking about http://stackoverflow.com/questions/5411585/setting-allusers-in-wix-for-per-user-or-per-machin-installation-context
|kevincondon||14:02||That's definitely helpful for the wix part, thx. On the FB side, I understood @taxilian as saying that the generated DLL itself is built to be either per-user or global, since the registry keys are determined by analysis of the DllRegisterServer
So I would need a separate DLL for per-user and global, right?
|jshanab_OSX||14:02||That is beyond me I'm afraid. Everything I do is for all users. What is the use case for restricting to a user?|
|kevincondon||14:02||Per-user allows non-admin installation. Google Chrome installs that way, e.g. But we also have enterprise users who only push software to their users, thus the need also for global installs.
We currently have a single installer that takes command line args if you need to do a global install, otherwise it defaults to per-user. So the FB generated plugin install needs to fit into that mold.
|jshanab_OSX||14:02||Install without admin is a nice plus. I like that part. but now that windows 7 has the 2 admin rolls, it is not as much a diff. (being and admin user and running an app as admin are not the same as being logged in as "administrator" user)|
|taxilian||14:02||kevincondon: you wouldn't need a separate dll
but you might possibly need a separate msi
our plugin can be installed for either or both
sorry, for either
but it's a different msi for each
|kevincondon||14:02||Same DLL works either way -- that's awesome. I might be able to pass ALLUSERS=1 on the msiexec command line, then if I change the registry hive refs in the wxs and FBControl.rgs to HKMU, I may get what I want.
Tweaking FBControl.rgs seems a little problematic, but I'll give it more thought
I may be better off skipping msi and using our application's existing NSIS installer. I can copy the registry keys from the generated wxs and FBControl.rgs now that I know those are the only places I need to look for those keys.
And I'll have to be very careful about getting those keys put into our uninstall, too.
@taxilian I'm trying to take to heart your warnings about using msi, but I have a feeling that already having and existing application with an NSIS installer might make it worth braving a bit of registry handling.
|taxilian||14:02||I am sure you can do what you need with MSI, but I don't know how hard it will be
it's totally up to you
just don't expect me to fix it if it causes issues ;-)
|jshanab_OSX||14:02||I used cmake's cpack on the Mac version of my plugin and was quite impressed. I wonder how good the installer generator is for windows. MSI's are accepted by a browser,recognized and installed, I don't think NSIS is treated teh same|
|kevincondon||14:02||@taxilian Nope, I'm pretty sure my overlords won't accept me blaming you. I'm digging my own hole either way. You've been very helpfu.
BTW, FireBreath is one of the best done open source projects I've seen -- well documented, well supported. You can have a cross-platform, cross-browser skeleton built and deployable in just a few hours. That's priceless.
Especially after I spent a few days on my own to get a windows-only plugin that compiled and wouldn't load.
|jshanab_OSX||14:02||I agree!. I have gotten my plugin to display video on 3 operating systems and 4 browsers, If only the mobile market had something similar
PS That is why I donated to the cause. Well worth it, Gotta support this one!
|kevincondon||14:02||@jshanab_OSX Our existing NSIS installer is somewhat involved due to having wide matrix of use cases for installing our app. NSIS isn't going away for us, so I must either use NSIS to install the plugin DLL directly or I have to run the plugin's MSI from the NSIS installer.|
|jshanab_OSX||14:02||I use NSIS on the server side of my Video System. I found that cmake can generate them.|
|kevincondon||14:02||For Windows there's a lot to like about MSI, but there's not enough value to justify the work it would take to port our NSIS installer to MSI (or anything else) right now.|