IRC Log Viewer » #firebreath » 2013-02-07

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?
PauloMarcio 10:02 hum... 1.7
got it this week
taxilian 10:02 interesting
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.
taxilian 11:02 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
taxilian 11:02 cool
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?
taxilian 13:02 yes
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.
helpful.
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.