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

IRC Nick Time (GMT-7) Message
adnan 05:10 Hello
firebreath plugin doesn't work with opera linux
my plugin works fine with chrome and firefox, but opera simply displays a message "Missing Plugin Click for info"
johannes 07:10 is there some "aoutplugins" to see whether opera recognized it at all?
adnan 07:10 Yes opera recognises the plugin, it is even showed in opera->pages.developer tools->plugins, it even intercepts the default action for mime-type, but doesnt work
adnan 08:10 even a simple plugin with just this code "window->alert("hello i am in PluginReady()" doesn't work in opera linux, plz help i don't wish to use NPAPI
adnan 08:10 opera linux plugin doesn't work especially with application/octet-stream
adnan 10:10 plugin only executing in chrome, not in firefox and opera
it is being detected however
taxilian 10:10 adnan: try running firefox or opera from the console; then you can see the console logs as they go by
you might spot something useful
and since a firebreath plugin is still an npapi plugin, you're going to have the same issues with a raw npapi plugin; you may as well figure out how to troubleshoot it in firebreath as try to rewrite it from scratch
adnan 10:10 actually plugins are working fine in all the three browsers
I am trying to invoke an external application in onPluginReady() function. I am simply using system() function. It works with chrome but not with opera or firefox, is there any alternative method of doing so
taxilian 11:10 adnan: I would assume there are other alternatives; popen comes to mind
that's really not a plugin question, though; it's a linux systems programming question
I'm no expert there
adnan 11:10 Thanks anyways, i need to google a bit
Harry78 11:10 hi taxilian, two good news:
1st: parameter problem is no more, it was a problem with the string passed in (there were german umlauts included, leading to binary data which could not be passed). I'll implement a base64 here before the parameters pass
2nd: the tax office doesn't need any more information (for the moment), hopefully they will never ask
taxilian 12:10 Harry78: if you use a wstring or utf8 encoding it should work fine even with unicode characters
awesome
Harry78 12:10 i'll have a look at a wstring implementation (project settings are very dependant, but they are generated). a foll-blown base64 would be really overhead
taxilian 12:10 FireBreath strings are all assumed to be utf8
Harry78 12:10 and that's possibly the problem: i'm reading in a textfile, containing strings from an external program. they may be cp1250 encoded, but surely not utf8. i'll ask in addition the external program originator if he can write utf8 text files
taxilian 12:10 alternately you can try to find a way to convert it yourself
Harry78 12:10 a libiconv call should do it, but then i have to manually add it to the project settings
(in windows, omg)
adnan 13:10 to add multiple mime-types do we have to add multiple set statements or separate mime-types using "|" in single set like "set(FBSTRING_MIMEType "application/zip|application/x-gzip")"
Elliott_D 14:10 I'd like to use a single header only boost library that's not included wwith firebreath. What's the best way to go about this? Should I just pull the files out of the boost download and include them in my project files? It seems overkill to switch to external boost.
taxilian 14:10 Elliott_D: which one is it?
Elliott_D 14:10 Boost CRC. It depends on a couple of ther headers.
*other
taxilian 14:10 fun. well, you could try just figuring out which headers it needs and copying them in; if you fork firebreath-boost you could use your own instead of the packaged firebreath one
Elliott_D 14:10 What would be the difference in forking it and using external boost via cmake?
taxilian 14:10 forking it keeps it as is, just you have to change which repo
external boost uses external boost
Elliott_D 14:10 fair enough
taxilian 14:10 your suggestion (pull them out of the boost download and include them) could be done with a fork, is what I'm saying
you'd have to do a little bit of git work yourself whenever you do a new checkout, but that's not that big of a deal
Elliott_D 14:10 Okay, that makes sense. Thanks.
taxilian 14:10 yw
dtiedy 16:10 looking for a way to always force a http get to hit the server and not pull from the cache. The cache=false parameter to FB::BrowserHost::createStream does not do the job
The issue is I'm retrieving a version.json file from a server and it is always pulling from the local cache with out checking with the server with the e tag and date