IRC Log Viewer » #firebreath » 2013-01-08

IRC Nick Time (GMT-7) Message
CeeCee 06:01 Hi everyone, I have a general question about plugin capabilities, not necessarily FireBreath - was hoping someone with experience might be able to offer input
I was wondering if it's possible for a plugin to do screen capture outside of the browser window, for example, capture a screenshot of a user's desktop
Does anyone know if this is possible? It doesn't seem like it, would be great if someone could confirm
jshanab_ 06:01 I do not see why not. Anything you can do in c++. :-) but I'd have to try it. Different OS's impose different security restrictions, but generally they are based on process memory, file system and sockets. Video display is accessible for writing you should be able to read it?
Of course each Desktop Manager will have it's own way. Windows and Mac should be one way each, but it may be on linux you'll need to detect which Window Manager first. You have made me curious, things like logmein and joinme have both a plugin and desktop component
taxilian 09:01 good morning
reichi 09:01 good "morning" taxilian :)
schmoo2k 09:01 (taxilian - I am mid way replying to your reply<g>)
(but work keeps getting in the way)
taxilian 09:01 schmoo2k: heh. well, at least someone is interested. if you remain interested, maybe progress on the 2.x branch will even start being made sometime.. nobody else seems to care
schmoo2k 09:01 I thought silence was the new round of applause
Which makes me the heckler
taxilian 09:01 lol
nah, I appreciated your response
schmoo2k 09:01 I laughed at your comment "So I can't actually tell in some cases if you're agreeing with me about desirability of changes"
taxilian 09:01 =]
reichi 09:01 i'm sorry
I was on holidays
and now i'm completely under water :/
taxilian 09:01 hehe. I'm sure a lot of people are busy
reichi 09:01 in terms of stuff to be done
schmoo2k 09:01 IMO I think you do too much to protect your user (to the extreme that it sometimes gets in the way of seeing what is actually going on).
taxilian 09:01 you may be right about that sometimes; in large part that is what I'm trying to fix with the cmake changes
that and just make the cmake so that it's reasonable instead of bizarre
schmoo2k 09:01 Which is to say if you "do less it could make it easier for new adopters"
You can't make cmake be reasnoble
taxilian 09:01 lol
schmoo2k 09:01 Just roll with it
taxilian 10:01 yeah, but the current way that the firebreath cmake is doesn't actually make any sense anymore
originally it kinda did, but not entirely then either
schmoo2k 10:01 Programming cmake is like a genetic algorithm, every now and then you have to somthing random and see if its good or bad
taxilian 10:01 lol
I agree; cmake is a horrible, horrible system to use. it's almost as bad as any of the other options
schmoo2k 10:01 (well that my opinion) - BUT - if you are doing cross platform stuff (which I am) it is a beautiful thing.
(well maybe that is a bit strong).
taxilian 10:01 I'm not sure I buy "beautiful". just "less ugly than any other option"
schmoo2k 10:01 Lemme finish my reply
reichi 10:01 i am happy my target platform was only linux
so i could throw cmake away ;)
taxilian 10:01 heh
schmoo2k 10:01 As an aside, have you seen https://github.com/kripken/emscripten/wiki its very very kewl.
taxilian 10:01 schmoo2k: I'm reading your response. you have absolutely no idea how much is involved in PluginAuto =]
heh. I have seen emscrripten; I'm not sure how I feel about it
=]
schmoo2k 10:01 (you said that before about plugin auto, and I did merrily ignore it, lemme look closer)
taxilian 10:01 That said, one of the hopes with refactoring the PluginWindow stuff would be to make it so you don't need to do as much in PluginAuto that is "project specific" and maybe we could put more in the skeleton to make it more "library friendly"
but right now all of the configured files will kill us
schmoo2k 10:01 I think what I was saying is that those generated files should be compiled and linked directly into the users plugin project (by including the cpp files)
taxilian 10:01 some of that could be done
but not without cmake, for one thing
schmoo2k 10:01 And make no effort to create a pluginauto.lib at all
taxilian 10:01 at least not without restructuring
There is still too much in that project
if we can pair it down more it'd be better
but that will take work, time, and concentration that I don't really have right now =]
schmoo2k 10:01 What can be moved out into the FireBreath core should be and then see what is left
taxilian 10:01 great!
done
go look =]
schmoo2k 10:01 I will I will!
taxilian 10:01 because I already did that. The stuff that is "left" is stuff that for various reasons *couldn't* be pulled out
I think we can gradually rework some things to move more out, though
it's just going to take reworking
restructuring
in some cases entirely changing how something works
schmoo2k 10:01 Is this the main issue:
@@foreach (FBControl_GUID CUR_GUID)
In the IDL
taxilian 10:01 I wouldn't say the main issue, but that's definitely one of them
and it's not just in the IDL that that is necessary
schmoo2k 10:01 Are there similar issues in the Chrome world?
(npapi world)
taxilian 10:01 hmm. only to a much lesser extent that we could get around
that I can think of offhand
well, you do have the .rc file still
schmoo2k 10:01 (I would include the IDL in the source list specifically so I could see it in VS)
taxilian 10:01 I think it's in there somewhere, actually
it's supposed to be
schmoo2k 10:01 (I can see the tlb not the IDL tho)
taxilian 10:01 the axplugin_defs files are pretty critical/tricky to deal with in a "library" way as well
schmoo2k 11:01 You support more than one plugin within a single DLL?
taxilian 11:01 more than one mimetype, yes
schmoo2k 11:01 ok
jshanab 11:01 I love CMAKE. nothing else comes close. There, Now that I have gotten it off my chest, we can move on...:-)
schmoo2k 11:01 If you took cmake away I would be sad. But that is not the same as love.
taxilian 11:01 lol
I have a love/hate relationship with cmake
jshanab 11:01 I noticed that Adobe made an aggreement with Google to no longer support NPAPI on linux. While the windows future is unclear, they are pushing towards pepper as a standard. My question is Could this spell the end of Firefox and NPAPI and imply we need to consider PEPPER in FireBreath for the 2.0 line?
taxilian 11:01 it's conceivable that we will need to support PPAPI eventually
currently it doesn't make sense to spend any of my time on it, though, since I don't support linux
sad but true =]
jshanab 11:01 It is almost funny but the last update to flash for linux is absolutly awful.
taxilian 11:01 lol
jshanab 11:01 You dont? Oh NO Mr bill. the wiki is missleading! ;-) I got my plugin almost working on all 3 win,lin,osx
Seriously though, what exactly is meant by "I don't support linux"
taxilian 11:01 heh. I mean with my own plugin
my plugins don't support linux
firebreath more or less does
jshanab 11:01 Oh, Whew.
taxilian 11:01 sorry for the confusion ;-)
jshanab 11:01 I was looking at the cocos2d-x project and it is similar to Firebreath in archetecture. I could see a future where integrating Android and iPhone as targets into FireBreath (3.x???) would work. Instead of a browser with html and javascript, you have a generated app with XML and generated fbAPI calls from the controls.
taxilian 11:01 XML? seriously? *shudder*
;-)
I have given some real consideration to making an RPC module for JSAPI, though; it wouldn't be that hard to do something like that
would be particularly useful for IPC
jshanab 11:01 HTML is just XML with a schema. But the analogy with an xml described UI in a view with an activity to a browser with a canvas is close. So we would create a Firebreath Widget that can be built for each platform and then added to a control in a view.
just thinking out loud... Lunch calls BRB
schmoo2k 11:01 HTML can be malformed XML
kylehuff 12:01 being able to build a firebreath project with the Native Client SDK would take care of ChromeOS, and probably other mobile platforms in the future.
reichi 12:01 considering that wayland will make it's way in
i consider linux npapi to become even less attractive...
as it relies heavily on X11
(not to say completely)
jshanab 12:01 THe Native Client SDK is limited to what browsers? (I thought the cocoa api ported to c++ (well, c++ bindings) was pretty ingenous
taxilian 13:01 jshanab: native client is chrome only AFAIK
max_vodoo 15:01 hi
jshanab 15:01 good afternoon
max_vodoo 15:01 hi