|IRC Nick||Time (GMT-7)||Message|
|MattF||09:03||Hi, what's the best way to store parameters/config that a plugin needs to access?
the info I need to store is a COM port name
|linearray||09:03||a config file?
|FireBreathBot||09:03||Found 2 possible matches. Displaying 2
/^string FB::System::getAppDataPath(const string& appName)$/ (f) found in src/PluginCore/Win/SystemHelpersWin.cpp: http://goo.gl/CNjOS
/^std::string FB::System::getAppDataPath(const std::string& appName)$/ (f) found in src/PluginCore/X11/SystemHelpersX11.cpp: http://goo.gl/N0f5C
|FireBreathBot||09:03||Could not find any tags matching SystemHelpers.cpp|
whatever, you can use this: https://github.com/firebreath/FireBreath/blob/master/src/PluginCore/SystemHelpers.h
|MattF||09:03||the plugin I have needs to communicate with a device attached to the local PC so needs to know which COM port to send data to
is there a way to set some parameters when installing a plugin and have those parameters stored in the relevant app data path?
|linearray||09:03||depending on your needs you can pass the parameter from the website to the plugin
you can ask for the COM port when the plugin loads for the first time
you can also hack it into the installer, sure
I've not used the installer yet though
|MattF||09:03||passing the COM port name to the plugin may be easier as they can just be retrieved based on logged in user and as you say passed as a parameter to the plugin|
|nirvdrum||09:03||Yay. The latest Chrome update seems to have broken my plugin again. I guess it's time for me to grab the latest Firebreath again.|
|nirvdrum||09:03||No offense. I just prefer when I don't need to touch it :-P
Usually it turns out I'm accessing memory someplace I shouldn't be.
|nirvdrum||09:03||With any luck, Firebreath will now prevent me from doing that :-)
At least, that's what happened during my last upgrade. All of a sudden I had a compilation error that I didn't have previously. Fixing that fixed my Chrome problem.
So, thanks for adding such aggressive checking in there.
|nirvdrum||09:03||I'm glad I set up Firebreath as a submodule. It makes doing this a lot easier.|
|nirvdrum||09:03||I think I'm on 1.6.0 RC2 still.
Or something between RC2 and 1.6.0 final.
|nirvdrum||10:03||Looks like I need to regenerate my project.|
|nirvdrum||10:03||NpapiPluginModule::Default no longer exists.|
|nirvdrum||10:03||Which means that generated file changed.|
|taxilian||10:03||you don't need to regen
just remove np_winmain.cpp and dllmain.cpp
those are no longer needed
it'll pull in the entrypoints from PluginCore
|taxilian||10:03||look at fbgen/src to compare|
|nirvdrum||10:03||Is there anything else that would have changed? I usually find it easier to just regen to be safe.|
|taxilian||10:03||fbgen is pretty simple really
I dont' think so; that changed (removing those files) a long time ago, so I hadn't even considered that people who still had them would be affected by the other change
that should be the only breaking change from 1.5.0
|nirvdrum||10:03||Heh. I must've just carried those through for a while then.
I haven't touched this one project in 5 months, but it was basically 1.6.0. It just started off on a much earlier version.
|taxilian||10:03||you should be fine, just remove those files|
|nirvdrum||10:03||I'll give that a shot, thanks.
And it's just now occurred to me how long I've been using Firebreath for. Time sure does fly by.
|taxilian||10:03||hehe. yeah, I know. FireBreath is pretty stable these days
when you started it was much less so
|nirvdrum||10:03||Well, thanks for sticking with the project. I'm not sure I would have the patience to do so :-P
I was ready to strangle people when getting straight NPAPI going.
|taxilian||10:03||hehe. there are days… =]|
|nirvdrum||10:03||Have you looked at PPAPI at all?|
|taxilian||10:03||a little bit; the main thing that keeps me from spending much time with it is that nobody but Chrome will every support it
I do think it'd be interesting to see if FireBreath could be made to build for it, though
|nirvdrum||10:03||I'm guessing Mozilla will cave at some point.|
|taxilian||10:03||I doubt it|
|nirvdrum||10:03||They added SPDY. I think they're giving in on the h.264 thing.|
|taxilian||10:03||they are really really strongly against revising NPAPI. they want to get rid of NPAPI entirely and not have plugins anymore
yeah, but there is a lot more pressure for that than there is for PPAPI
|nirvdrum||10:03||It'll be the only way to get flash on Linux. I don't think Adobe would risk that on Windows, but they could on Mac.
|taxilian||10:03||well, we'll see|
|nirvdrum||10:03||That sounds foreboding.|
all we can do is wait and see what they decide to do
|ch||14:03||is there a complete example for a pluginLoaded js event?
preferably without race conditions :-)
|ch||17:03||(found something that apparently works)|