IRC Log Viewer » #firebreath » 2013-09-30

IRC Nick Time (GMT-7) Message
Marl 02:09 Did anyone experience this while compiling an FB plugin? http://computer-programming-forum.com/77-vc-atl/4ba6e3f6e815f4df.htm
My problem is that I need the CWinThread in the plugin.. But when I add afxwin.h, the compiler will say: WINDOWS.H already included. MFC apps must not #include <windows.h>
taxilian 08:09 good morning all
kylehuff 08:09 good morning
this whole dropping of NPAPI absolutely sucks! I don't know what I'm going to do about chrome...
taxilian 08:09 yeah, I'm with you there
what have you tried?
kylehuff 08:09 I attempted to use the dlopen feature of NaCl to open my library, which all worked, except it is still brutally sandboxed, and fork, exec and pipes are all inop.
for Firefox, it won't be too difficult. I spent most of yesterday converting my library into a standalone dll/so with shims to expose the C++ methods to js-ctypes. that is going okay, but I can't link against boost::thread for some reason...
taxilian 08:09 you should give native messaging a try
kylehuff 08:09 that is going to be my next approach... however my understanding is that will require a system installed package which would mean installing something in addition to the extension. I was hoping to avoid that.
taxilian 08:09 I do believe that is correct
but you could install the extension with the same installer
the user will just have to accept it
kylehuff 08:09 yeah. but now I've got to delve into desktop installers... *facepalm* and keeping the application updated... ugh.. /whining
taxilian 08:09 hehe
so after a lot of looking around, I think we're just going to try to get out of the browser. We're going to try to trigger "open" by opening a connection to a SSL websocket… which won't actually be SSL, and it'll just close the connection
but it will see that as a "hey, time to open!"
which means we'll have to run a resident program to make it work, which I'm not excited about
kylehuff 08:09 this is for chrome?
taxilian 09:09 for all
onfire 09:09 hello
we would like to use our imaging sdk, which prints images on to a given windows handle, to use a dynamically created "div" container to print the images to.
the javascript creates div elements by itself, and we want the plugin object, which is a windowless plugin btw, to get the div element to print an image to.
how can we pass a window handle which is associated to the div element in the html, to the plugin object.
taxilian 09:09 you cna't
you can't
you could put the plugin object in said div at 100% x 100%
which would let you draw in the same position as the div
but you can't get the window handle of individual html components
onfire 09:09 thanks a lot, for the quick reply.
taxilian 09:09 note that Chrome tells us they are dropping NPAPI support sometime next year
onfire 09:09 so, are they going for an alternative way to handle plugins?
taxilian 09:09 in their opinion or ours?
onfire 09:09 both ? :)
taxilian 09:09 well, here is the announcement: http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html
so they can speak for themselves
as for me, there are no alternatives that I've found so far that do an even semi-reasonable job of replacing what I use plugins for
kylehuff 09:09 taxilian: regarding the wiki page about post-NPAPI world [http://www.firebreath.org/x/kQCt] -- the part under js-ctypes that reads - "Uncertain if you can include your own DLLs or not. If not, it may not work at all." - yes, you can. and those dll/so libraries can be located either on the system, or provided by the extension bundle.
taxilian 09:09 though for some people there are
kylehuff: there is a reason it's a wiki, please update with whatever relevant info you can =]
kylehuff 09:09 I am logging in now, I just wanted to clarify that here.
taxilian 09:09 cool
and thanks
kylehuff 09:09 that also eliminates the the 4th con from that section
taxilian 09:09 always a good thing
kylehuff 09:09 would you consider the fact that the life-cycle of the library instance is per method execution as a con? (with js-ctypes) i.e., deconstructor is called after execution of a method
taxilian 09:09 hmm; yeah, that could be a con
it's at least something to know
kylehuff 09:09 I'll add it. thanks.
"Limited functionality, no way to handle large chunks of data," -- I'm not sure I understand this one. I am able to return very large strings of JSON formatted data without incident. (rather quickly, actually) -- or is that in reference to something else?
taxilian 09:09 should be changed to "large chunks of binary data"
kylehuff 09:09 okay, yeah, that makes sense. I don't think it supports binary return at all, now that I think about it. I'll have to check on that. I know you can define new types, even structs as return types.
taxilian 09:09 and I guess "no way" is deceptive; I'm sure base64 encoding would work
kylehuff 09:09 yes, since I believe the return type for base64 would still be ctypes.char or ctypes.char.ptr
taxilian 09:09 seems a bit inefficient, though
kylehuff 09:09 yeah, I'm going to do some playing around with it later today to see if I can find better ways to return data. I've also got to figure out the threading. (callbacks must be executed by the main/initial thread. you could use a webWorker for long-running methods)
I'll have to write up an abstraction library - maybe a jsm module. I'll document what I figure out, since demonstrated examples of js-ctypes are few and far between, and the docs are pretty vague in many cases.
John_______ 10:09 hi
anyone?
taxilian 10:09 John_______ ask a question first, then stick around long enough for someone to answer
we aren't always here, and someone is more likely to respond to a question than just to a "is anyone here"
John_______ 10:09 thx
can i use plugin to do something like injecting a snippet of javascript into page?
kylehuff 10:09 John_______: that seems overkill for an NPAPI plugin. why wouldn't you use an extension for that?
John_______ 10:09 i just don't understand very well about plugin. do you mean extension can do that a lot easier?
kylehuff 10:09 John_______: yes. An "extension" or "add-on" is typically Javascript, and it can be used to interact, manipulate, alter the DOM. A "plugin" is a binary component (usually C/C++) for doing tasks that cannot be done in Javascript
which browser(s) are you targeting John_______?
John_______ 10:09 i expect most major browsers
do you mean plugin is more powerful than extension?
kylehuff 10:09 yes, but significantly more complicated, and also not supported by some browsers (and those that do are dropping support)
taxilian 10:09 John_______: http://npapi.com/extensions
you need to understand the difference
kylehuff 10:09 also, if you are looking to make an extension that supports multiple browsers, I would suggest using an extension framework, such as crossrider or kango - unless you are intimately familiar with the intricacies of extension development for multiple browers.
john________ 10:09 to kylehuff: seems extension is the choice. do you work on an open source extension framework? or do you know one?
taxilian 10:09 .. he did just suggest a couple...
john________ 10:09 ?
taxilian 10:09 he said "I would suggest using an extension framework, such as crossrider or kango"
those are the two most popular extension frameworks that I know of
I don't have any experience with them, however