IRC Log Viewer » #firebreath » 2011-01-13

IRC Nick Time (GMT-7) Message
wolfmanfx 03:01 @taxilian book ordered :)
taxilian 09:01 morning all
wolfmanfx 09:01 hoi
taxilian 09:01 lol. he just wanted to see what it's like in here?
brb, switching to windows so I can try to track down the bugs NoAntzWk keeps reporting ;-)
just noticed dev isn't building on mac… will fix that first =]
hey kcsham. thanks for getting that started yesterday; sure appreciate it
kcsham 10:01 you're welcome. Firebreath surely helped a lot. Thank you!
taxilian 10:01 good! what are you using it for?
kcsham 10:01 speech recognition
taxilian 10:01 oh, yeah; we've talked before =] I remember now
kcsham 10:01 what are the significant items before 1.4 goes into beta?
taxilian 10:01 let's see.. there are a couple minor issues that need to be finished on logging
(this is a good question, I need to think this through)
hmm. that might be it; mainly I've just still been polishing up some new features
but I think I'm done with new features
and have moved on to polishing the documentation
which is also pretty much done
was hoping to have IE windowless support, but doesn't look like amackera will have time for that before 1.4, so likely that won't be there
it's probably about time to lock it down
kylehuff: I know your plugin isn't ready for "prime time" yet, but would you mind if we put it on the "examples" page anyway?
grr. wow, I'm really slipping. the commit I made last night broke the build on all platforms and I didn't even notice
FB_GitHubBot 10:01 FireBreath: master Richard Bateman * ae33931 (10 files in 4 dirs): Fixed mac/linux build errors - http://bit.ly/fIQsBf
taxilian 10:01 kcsham: tell you what; I'll make it a goal to put it in beta today
kcsham 10:01 awesome! let us know what we can help out as well.
taxilian 10:01 the #1 thing you can do to help is to use 1.4 and tell me if anything is broken (but give me another 20 minutes to finish fixing my oops from last night :-P)
kcsham 10:01 my next dev tasks on my project are (1) sign the plugin; (2) do a proper WiX installer
taxilian 10:01 I need to start digging through the git logs to build the changelog from 1.3
it's probably going to be rather large :-/
I need to do better at keeping that as I go instead of waiting for the release
cool. someone on the survey was suggesting that FireBreath have some sort of integration for signing plugins; would be cool, I think
I need to learn how to do it myself, though :-P
kcsham 10:01 i found that hard to figure out what are the new / breaking changes to non-C++ files. (e.g. Cmake files)
taxilian 10:01 yeah; I don't think there are any in 1.4, though
there is one thing that you'll possibly need to do if you're using multiple mimetypes, I think… trying to remember
did you find a cmake breaking change?
kcsham 10:01 no. but i generated a new dummy project and eyeballs the cmake files with the one i had when working with 1.3
something probably had to do with some common file changed for windows.
taxilian 10:01 yeah; the windows projectDef.cmake file changed
kcsham 10:01 I had to add to "CMAKE_SHARED_LINKER_FLAGS",
taxilian 10:01 it's not a required change unless you need a particular feature, though...
oh! I remember
kcsham 10:01 I now have to add a leading space to the argument i'm adding.
taxilian 10:01 it's a required change to use vs express
huh. weird
kcsham 10:01 im adding a /NODEFAULTLIB argument. Without the space, it concatenate with /machine:X86";"
taxilian 10:01 hmm. is that something that we need to fix, then?
kcsham 10:01 adding the space was a workaround. let me see what is actual source of issue.
taxilian 10:01 thanks
FB_GitHubBot 10:01 FireBreath: master Richard Bateman * aa4e4f5 (2 files in 1 dirs): Fixed build error on windows - http://bit.ly/fP06k2
taxilian 10:01 ok, 1.4 should be useable again :-|
FB_GitHubBot 10:01 FireBreath: firebreath-1.4 Richard Bateman * 855a916 (2 files in 1 dirs): Replaced for loop with more efficient lambda
FireBreath: firebreath-1.4 Richard Bateman * 7a9a96d (9 files in 3 dirs): Documentation improvements and fixes
FireBreath: firebreath-1.4 Richard Bateman * ee90d48 (1 files in 1 dirs): Documented scoped_zonelock
FireBreath: firebreath-1.4 Richard Bateman * 6ce473c (25 files in 10 dirs): Fixed tabs -> spaces issues to fix documentation issues
FireBreath: firebreath-1.4 Richard Bateman * 1069fdc (9 files in 3 dirs): Updated more class docs, fixed problems, etc
FireBreath: firebreath-1.4 Richard Bateman * ecf2022 (2 files in 1 dirs): Updated more class docs, fixed problems, etc
FireBreath: firebreath-1.4 Richard Bateman * 3c72b22 (9 files in 4 dirs): Updated more class docs, fixed problems, etc
FireBreath: firebreath-1.4 Richard Bateman * ae33931 (10 files in 4 dirs): Fixed mac/linux build errors
FireBreath: firebreath-1.4 Richard Bateman * aa4e4f5 (2 files in 1 dirs): Fixed build error on windows
FireBreath: firebreath-1.4 commits ee2319b...aa4e4f5 - http://bit.ly/ig0BO9
taxilian 10:01 jtojanen: I just fixed some of those errors myself; sorry :-/
jtojanen 10:01 be careful when pushing :)
taxilian 10:01 I'm not usually that sloppy, I promise
jtojanen: we're looking at locking down 1.4 beta 1 today; do you see a problem with that?
(I'll pull your changes in in a few minutes)
jtojanen 10:01 i haven't seen any big problems but of course we need more testing
taxilian 10:01 that's why it's a beta and not a RC
beta basically just means that all the new features we're allowing are there
the one thing that is left that I really wanted in there is windowless support on IE
but amackera hasn't had time to figure it out yet and I don't have anything that does drawing to test with it
jtojanen 10:01 what you mean?
i have
taxilian 10:01 amackera wrote in support for windowless plugins for npapi browsers on windows
but neither of us know enough about how things work on IE to make it work there
there might even need to be some tweaks, since ideally they should work the same, of course
amackera 10:01 Friggin' IE
taxilian 10:01 amackera: can you do a quick overview of how windowless works in firefox windows? jtojanen is an activex expert (unlike me) and might know how to do it off the top of his head
(yes, I am shameless… I will use all available resources as much as they allow me to to make FireBreath grow :-P)
amackera 10:01 sure
haha
Well windowless in NPAPI is pretty simple
jtojanen 10:01 how does windowsless differ ?
amackera 10:01 During plugin creation you just call NPN_SetValue with NPPVpluginWindowBool value false
taxilian 10:01 amackera: more the interface than the specifics, since that's not relevant to IE
https://github.com/firebreath/FireBreath/blob/master/src/PluginAuto/Win/PluginWindowlessWin.h
https://github.com/firebreath/FireBreath/blob/master/src/PluginAuto/Win/PluginWindowlessWin.cpp
kcsham 10:01 taxilian: the CMAKE_SHARED_LINKER_FLAG was my error. no worry.
taxilian 10:01 the core of it is that there is no HWND created; instead you get a DC
kcsham: happy to hear it =]
amackera 10:01 Assuming IE delivers the same objects in it's equivalent window deliver method
jtojanen 10:01 i will look to that
taxilian 10:01 jtojanen: so instead of drawing in your own window and getting your own WINPROC, you get the window messages from another function and you get a DC during a Draw event
if you need to draw, you have to call InvalidateWindow on the PluginWindowlessWin object and the browser will send you a draw event
jtojanen: if you could do that, that would be awesome. that's the one feature that I am not locking out when I make this beta :-P
amackera 10:01 That's in NPAPI, is it the same in IE?
taxilian 10:01 well, in IE it may not be exactly the same; hopefully we can find a way to unify it
amackera 10:01 right
taxilian 10:01 that may require us to modify the way that PluginWindowlessWin works, which is fine with me
amackera 10:01 Yeah, same
FB_GitHubBot 10:01 FireBreath: master Richard Bateman * 20b0aec (2 files in 2 dirs): Fixed log4cplus inclusion detection
FireBreath: master Richard Bateman * b007a6a (13 files in 6 dirs): Minor cleanups and fixes for ActiveX subsystem ...
FireBreath: master commits aa4e4f5...b007a6a - http://bit.ly/hJdgZr
taxilian 10:01 jtojanen: your changes are in master now
FB_GitHubBot 10:01 FireBreath: firebreath-1.4 Richard Bateman * 20b0aec (2 files in 2 dirs): Fixed log4cplus inclusion detection
FireBreath: firebreath-1.4 Richard Bateman * b007a6a (13 files in 6 dirs): Minor cleanups and fixes for ActiveX subsystem ...
FireBreath: firebreath-1.4 commits aa4e4f5...b007a6a - http://bit.ly/hJdgZr
taxilian 10:01 ok; I don't know of anything other than the IE windowless thing that needs to be in 1.4 that isn't, so I'm tentatively declaring this ready for beta; I will create the beta tag in about 5 hours, so please everyone look at things and test it and see if there is anything missing
once I do a beta I will stop developing master and firebreath-1.4 together and any changes that need to go in will be applied seperately to each branch
because new features will go into master, which will then be the 1.5 dev branch
and bugfixes will go in both
jtojanen 11:01 taxilian: ActiveX CComControlBase provides all the necessary functionality for windowless operation, e.g FireViewChange()
taxilian 11:01 I figured it probably did… I just don't know how to use it
can it be made to work with FireBreath's current PluginWindowlessWin implementation? or can we update it so they work the same way to FireBreath?
jtojanen 11:01 ActiveX checks during init if container can provide window or used one be created
pass the FBControl to PluginWindowslessWin
one way could be to define base class and inherit from that
that would be easier way
taxilian 11:01 can IE windowless mode be determined after Load is called?
jtojanen 11:01 yes
not before
taxilian 11:01 perfect
so what calls would need to be made back from PluginWindowlessWin to FBControl.h?
could we maybe abstract them so that it looks the same?
using boost callbacks?
brb
kylehuff 11:01 taxilian: yeah, that would be fine I guess. I don't have any objection.. I don't think it is a very good example, however - by way of form or function! I think I use less than 1/1000th of the functionality provided by Firebreath.. lol
but I do see the motivation.. (I read the emails on the list)
I could add it to the list this evening, *maybe* today.. but we'll see
taxilian 11:01 hehe
jtojanen 12:01 later
FuzzYspo0N 12:01 Hi
taxilian 12:01 howdy
FuzzYspo0N 12:01 I must say, firebreath is a great resource
taxilian 12:01 glad it's helpful to you =]
FuzzYspo0N 12:01 but the build dependancies made me want to suicide :p
taxilian 12:01 which build dependencies are those?
FuzzYspo0N 12:01 i did get it to work, though
taxilian 12:01 cmake? (that's the only build dependency)
FuzzYspo0N 12:01 Well, mostly the windows ones.
600MB iso for a few libraries and headers is a bit of a kick in the nuts
at least, here in my country
taxilian 12:01 well, if you use visual studio you don't have that dependency
a month ago you couldn't use express edition at all
FuzzYspo0N 12:01 Yea i am grateful
Just noting :)
taxilian 12:01 and 2 months to rewrite the entire ATL stuff to not require it is a bit of a kick in the nuts for us =]
yeah. sorry, nothing we can do about it
FuzzYspo0N 12:01 no worries
taxilian 12:01 where are you located?
FuzzYspo0N 12:01 I think its better than the other resources in terms of platform support and ease of use
South Africa
taxilian 12:01 I really wish I could package just the ATL stuff needed so you don't have to get the whole DDK, but Microsoft would sue me, and I don't have the funds for that
cool
FuzzYspo0N 12:01 Yea, i blame them for the DDK thing
I mean, packaging the device driver kit for a few libs for something standalone is just faggottry
But anyway, i was wondering about the OpenGL abstraction
if that had made any progress at all
or if there was a repo to poke around in?
taxilian 12:01 well, I'm just as glad they have the DDK; it's the only free way I know of that you can get ATL
there are some people who are kinda working on it, but I don't know the status
FuzzYspo0N 12:01 <warez>
jk
taxilian 12:01 or even if they really are working on it
feel free, just don't tell me about it =]
FuzzYspo0N 12:01 hmm, well i was just reading your blog post
(i think its yours)
http://colonelpanic.net/2010/11/firebreath-tips-drawing-on-windows/
taxilian 12:01 yes, that's me
FuzzYspo0N 12:01 I stumbled across the IRC link there
taxilian 12:01 there are a few people using OpenGL with FireBreath; it can certainly be done, though some platforms are harder than others
FuzzYspo0N 12:01 It seems super straightforward, but im guessing the users who are going for browser plugins aren't all that experienced maybe
taxilian 12:01 windows it's pretty easy, as I understand it
often true
FuzzYspo0N 12:01 Just code monkeys tasks with 'get that working'
And obviously i read the dev group, the mac side seems hairy
unless you totally cut some users
taxilian 12:01 yeah; mac drawing is a little crazy
I have hopes that someday someone will contribute an OpenGL abstraction; a few have said that they would
but I haven't yet seen anything
FuzzYspo0N 12:01 yea, its obviously a bit of a challenge
Well, now that i have found this and written my own npapi plugins i will make sure whatever openGL stuff i do , ill post in the mailing list
i would love to see some simple triangle example, but i have a monolith engine that im embedding
taxilian 12:01 cool. what would really be awesome is just to have some basic examples for now… something that works just on windows would be a great start
right
FuzzYspo0N 12:01 And maybe thats what happens, they get what they need done
and move on
taxilian 12:01 of course, examples of embedding such engines would be good too =]
FuzzYspo0N 12:01 heh :) Ill post whatever i come up with
I was more curious on the main loop thing
taxilian 12:01 yeah; I just need to convince people to post simple examples =]
main loop?
FuzzYspo0N 12:01 "You can create your own rendering / drawing loop and draw whenever you want."
So, lets say i just make a boost::thread for my application main loop
and do while(true) {}
it will obviously suck for the user
taxilian 12:01 well, yes… your thread will monopolize the process time
FuzzYspo0N 12:01 But the loop will run and not be bound by the window abstractions TIMER and such?
taxilian 12:01 right
you can do opengl or directx drawing from another thread
FuzzYspo0N 12:01 Basically, i want to get as many mspf as possible
taxilian 12:01 you just have to make sure you do all of the initialization and drawing on the same thread
FuzzYspo0N 12:01 right, thats what i was curious about
yea, cross contexts arent good
The engine is already threaded so thats no problem
taxilian 12:01 so what was the question, then?
FuzzYspo0N 12:01 well in my head "just spawn a thread of my engine = working, as long as i get the HWND from the plugin"
But, it felt too easy.
taxilian 12:01 well, there are some things to consider
FuzzYspo0N 12:01 I wanted to be sure i wasnt confused, and needed to bind windows timers and such
taxilian 12:01 you need to draw on WM_REFRESH
but you need to draw from the correct thread
FuzzYspo0N 12:01 "you must redraw" <- noted
taxilian 12:01 and you need to make sure you shut things down at the right time
on DetachedEvent
FuzzYspo0N 12:01 right
taxilian 12:01 but those are things that you should already figure out, if you're really familiar with rendering
so yeah, it's pretty simple
FuzzYspo0N 12:01 ok, cool. Ill be digging into this later today, what time zone did the irc wiki mention?
taxilian 12:01 MST
it's almost 1300 here
FuzzYspo0N 12:01 Ok, nice. Not a huge difference
that always gets me here in ZA
its almost 22:00 here
taxilian 12:01 so by "later today" you mean "tomorrow morning"?
FuzzYspo0N 12:01 haha, hmm. it could be. But i am nearly done with what i was doing, and after that i was gonna continue
taxilian 12:01 lol
ok
FuzzYspo0N 12:01 I managed to get it all built and working pretty quickly but the bandwidth here is really crap. So i had a nice break inbetween ^.^
taxilian 12:01 1.4 will be in beta this afternoon (my time), btw, so it's a great time to start using it if you're not
FuzzYspo0N 12:01 hmm, well, trunk was really weirldy broken (even things like commented out randomly)
So i was on 1.3.2 and someones atx fixes
Im going to install my VS pro instead of use express
taxilian 12:01 trunk is rarely broken, and never for more than the time it takes me to find things
FuzzYspo0N 12:01 But its a good time as i haven't really touched anything but docs and build pipeline
taxilian 12:01 there are things there right now that seem "commented out randomly", but they really aren't
if you haven't done anything, use fbgen again since that'll save you fixing the few breaking changes
FuzzYspo0N 12:01 hmm, ok well the most errors i saw on compile were to do with base class functions missing, making abstract declarations, and JSObject->Construct being not found (which was commented out it appeared)
cool
taxilian 12:01 was that 12 hours ago or so?
if so, that was my bad… I'm usually not that sloppy. it's fixed now
FuzzYspo0N 12:01 4:19 pm, so 5 hours ago
taxilian 12:01 yeah, that'd do it
FuzzYspo0N 12:01 But its fine, its trunk
taxilian 12:01 you missed my fix by about an hour =]
FuzzYspo0N 12:01 I wasn't like OMGFAIL:)
taxilian 12:01 lol. I was =]
I try to keep trunk stable
FuzzYspo0N 12:01 the stable worked as expected + theres activity and a dev on IRC = sold
Its easy to use, and has all the JSAPI i can wrap my head around
So, ill use 1.4 then later
Im excited that it works, though
as the one most (annoyingly) common request i get is if my engine can be embedded in a browser
taxilian 12:01 firebreath-1.4 branch on the tree should be stable from here out
FuzzYspo0N 12:01 neat
taxilian 12:01 I will hopefully have the changelog this afternoon
FuzzYspo0N 12:01 no rush from me, i'm happy to wait
im just hoping to get it done by friday if i can, as i have other stuff to finish
<3 tech
but i must finish games too
taxilian 12:01 cool
well, I'm headed home for a bit; be back in 30 min or so
FuzzYspo0N 12:01 see ya
taxilian 15:01 good grief… this changelog is long
FuzzYspo0N 15:01 heh i love that
taxilian 15:01 hehe
well, you can read it soon… when I finally finish it...
FuzzYspo0N 15:01 grr.
taxilian 15:01 hehe
FuzzYspo0N 15:01 heh i found an awesome bug just now, it was implemented using the // construct >.>
i had commented out the functioning lines.
(in my own code)
taxilian 15:01 lol
always a good plan :-P
FuzzYspo0N 15:01 its the 4am commit logs
Always check those first
taxilian 15:01 hehe
yep
that's why last nights trunk didn't build :-/
wasn't 4am, but I was tired...
FuzzYspo0N 15:01 hah, it happens all the time
haha. no ways.
2/3 bug reports so far = commented out lines
im going to add a commit hook that doesn't let it through if its after 1ma
1aM*
taxilian 15:01 think I'm done with the text… just adding the links
lol
taxilian 15:01 ok, everyone check it out: http://www.firebreath.org/display/documentation/Version+History#VersionHistory-1.4%28CurrentDevelopment%29
kylehuff 15:01 (fyi, I just did a pull from master and rebuild my plugin; no issues to report)
taxilian 15:01 awesome
I just pushed the beta 1 tag
kylehuff 15:01 well, other than the dependency regression you already know about.
taxilian 15:01 the X11 thing? I'm hoping to fix that next
kylehuff 15:01 yeah, the linking against GTK and it's host of crap even with the no gui flag
taxilian 15:01 I will fix that before the final release of 1.4
or even the release candidates =]
kylehuff 15:01 no worries, just being thorough in my reporting..
taxilian 15:01 is there an issue created for that?
if not, might not be a bad idea to make one =]
just to make sure I don't forget
kylehuff 15:01 I can't remember.. but I do remember having this exact conversation about there should be.. lol
taxilian 15:01 lol
FuzzYspo0N 15:01 ill test now
FB_GitHubBot 15:01 FireBreath: master Richard Bateman * b24856f (0 files in 0 dirs): Attempt to add a commit hash export-substitution for version - http://bit.ly/h2u9z6
FireBreath: master Richard Bateman * ce1bf5d (1 files in 1 dirs): Added export-substitution variables to version - http://bit.ly/eiz4ef
taxilian 16:01 As I just tweeted, #FireBreath 1.4 is now in Beta! Please test! http://bit.ly/hXpqX3 !
FuzzYspo0N 16:01 taxilian, Build: 11 succeeded, 0 failed, 1 up-to-date, 1 skipped
taxilian 16:01 excelent
FuzzYspo0N 16:01 testing in browser now
vs2008 express, too
taxilian 16:01 vs express should be much better supported in 1.4 than it was in 1.3
FuzzYspo0N 16:01 indeed it is
taxilian 16:01 if you install the ddk in a normal location it'll even set up the link and include dirs for you
FuzzYspo0N 16:01 yep, i removed mine to test that :)
cool, works in browser as expected
taxilian 16:01 excelent
this should be a great improvement
now I just have to actually document all of the improvements… :-P
and how to use them
logging should be useable now as well
btw, if anyone is on twitter please retweet @thefirebreath 's beta announcement
FuzzYspo0N 16:01 must follow first, sec
done
taxilian 16:01 thanks
btw, for all interested, FireBreath.org is up to averaging over 150 hits (over 100 unique visitors) per day. not bad. slow but sure growth
FuzzYspo0N 16:01 Thats cool. How old is the project btw?
taxilian 16:01 our 1.0 release was about a year ago
actually, 1.0 was in March, I guess… rc2 was in January
didn't really support Mac or Linux back then
FuzzYspo0N 16:01 cool. Well, all the builds work, it seems. Release, minsizeRel etc
taxilian 16:01 excelent
let me know how functionality goes =]
FuzzYspo0N 16:01 And was super easy, compared to earlier. Now to get some openGL going. I think ill probably start with a triangle
As i cant find one using this api, might as well make it on the way
taxilian 16:01 feel free to contribute an example =]
FuzzYspo0N 16:01 while the rest is easy, id rather do it 'correctly'
Never really used this api, so gotta make sure its propert
taxilian 16:01 know that feeling
FuzzYspo0N 16:01 hah, i guess its like ' ok where to start '
FuzzYspo0N 16:01 taxilian, im making notes along the way of things i thought 'it would be cooler if'. I can send them your way when im done, if you like.
(in terms of beginners, etc)
taxilian 17:01 sounds great
FuzzYspo0N 17:01 i wonder, once i rebuild, do i unregister and the reregister the dll?
or does the browser look at the exact location
loading the latest one
taxilian 17:01 unless the registration info has changed, shouldn't need to
under "Documentation"
FuzzYspo0N 17:01 got it, thanks
i take it the AW snap thing is a bad sign :P
taxilian 17:01 ?
oh, the twitter thing?
the URL wasn't working
FuzzYspo0N 17:01 in chrome, that a plugin has crashed dialog
taxilian 17:01 oh
yes
that's always fun
what did you do?
FuzzYspo0N 17:01 no idea. Was trying to get opengl context, Need a better place to put it i think.
The code
taxilian 17:01 attaching a debugger to be around when it crashes is a great idea =]
FuzzYspo0N 17:01 well, if chrome wont load it ;)
i can stare at the debugger all i want?
taxilian 17:01 yes it will
FuzzYspo0N 17:01 oh cool :)
taxilian 17:01 it just crashes before you see it
use the startup dialog flag (documented on the page)
FuzzYspo0N 17:01 ok, nice
yea thats awesome.
testing now, with a debugger
taxilian 17:01 kylehuff: incidently in regards to your comment earlier implying that you don't feel your firebreath code is good enough to show as an example… the whole nature of open source is that we don't wait for that before sharing, and thus all benefit from each other =]
FB_GitHubBot 17:01 FireBreath: master Richard Bateman * 95323a1 (2 files in 2 dirs): Fixed FB_GUI_DISABLED flag on linux (for real this time, I think) - http://bit.ly/f1i9Nt
taxilian 17:01 kylehuff: please test it out and let me know if it works for you =]
FB_GitHubBot 17:01 FireBreath: firebreath-1.4 Richard Bateman * 23e172f (2 files in 2 dirs): Fixed FB_GUI_DISABLED flag on linux (for real this time, I think) - http://bit.ly/f98ZIn
kylehuff 17:01 yeah, my comment wasn't really about that - I have it in a public repo and advertise that on a few different sites.. I was speaking more to the fact that it doesn't do much. it is just an API.. while it is works as intended, I just didn't see it as a good example for firebreath.
but hell yes I'm gonna test that.. I just told my boss to call me later so I can test this out.. lol
taxilian 17:01 lol
again, though: release early, release often
open source motto =]
FireBreath tries to do that, though this release cycle is definitely longer than it should be
however, it was neccesary
too many interrelated features
lol. jshanab: you need to set up a ZNC server :-P then you can use a single IRC nick and use it from everywhere
"Wow, look at how many people are in the room! oh, wait… it's all jshanab…" :-P
kylehuff 17:01 wait, I thought the open source motto was to complain obsessively about things you got for free, all the while screaming how you would have done it and simultaneously refusing to do anything about fixing it?
taxilian 17:01 no, that's the open source *users* motto
amackera 17:01 hahah
taxilian 17:01 I was talking about the project contributor's motto
kylehuff 17:01 ahh, gotcha.. I see the distinction there..
taxilian 17:01 though I have to admit that I have seen some of that here.. :-P
not from you guys, of course
kylehuff 17:01 well I won't pretend I always help when I can, I make sure not to complain about open source projects UNLESS it is the gnome project and they haven't even bothered to triage the bug+patch I submitted.... lol
taxilian 17:01 lol
kylehuff 17:01 sweet! it works!
taxilian 17:01 that's the one complaint that I have occasionally had… when an open source project makes it really hard to contribute
bugs me
I want to help! Let me!
kylehuff 17:01 `ldd myPlugin.so | wc -l` went from 51 to 10!
taxilian 17:01 not that it changes the size
or makes it work when it wouldn't have
but hey
kylehuff 17:01 no, in fact, the resulting binary is meaningless to me in that regard; I just no longer have to install gtk-dev to build it!
taxilian 17:01 hehe
kylehuff 17:01 I hope to automate the building on various platforms
*eventually
taxilian 17:01 hehe. I have hudson doing that already
on build.firebreath.org =]
FuzzYspo0N 17:01 damn, connection.
kylehuff 17:01 thanks taxilian; that takes one less cumbersome step out of preparing the build environment..
taxilian 17:01 still working on a few things with that, but I'm pretty sure they're fixable
FuzzYspo0N 17:01 taxilian, did you get my last message about the windowAttached
taxilian 17:01 nope
FuzzYspo0N 17:01 Is it meant to be called more than once?
kylehuff 17:01 so, might be a more generic question, but, do I have to have a separate binary for 64 and 32 bit systems?
taxilian 17:01 windowAttached will get called more than once if for some reason the window is given to us, then changed, then another given to us
amackera 17:01 FuzzYspo0N: That depends on the browser I think
taxilian 17:01 I've had a report that this happens on chrome on windows sometimes, but don't know why
amackera 17:01 kylehuff: Mac or Windows?
kylehuff 17:01 amackera: Both. (plus linux)
FuzzYspo0N 17:01 it does, yes
amackera 17:01 kylehuff: The answer is yes, but you can combine them into a "fat" binary
kylehuff: on mac os the tool is called "lipo" but i'm not sure of the other systems
FuzzYspo0N 17:01 taxilian, so i use onPluginReady right?
taxilian 17:01 FyzzYspoON: you could try troubleshooting that and see if you can figure out why
kylehuff 17:01 amackera: I see.. ok.. that would help with building, but not with delivery..
taxilian 17:01 onPluginReady makes no guarantees about the window
FuzzYspo0N 17:01 hrm
i saw the life cycle link.
taxilian 17:01 might be worth seeing if you can figure out what is happening in NpapiPluginWin with SetWindow
FuzzYspo0N 17:01 But, Not sure where i can put the init code.
kylehuff 17:01 amackera: do you know, does that increase the memory overhead? (the loading of a "fat" binary as opposed to one for the specific arch)
taxilian 17:01 attachedEvent is the normal recommended place
amackera 17:01 kylehuff: that depends on the technique of combining the binaries i think
taxilian 17:01 but not sure why it would be called twice;
FuzzYspo0N 17:01 maybe 3 times, sometimes
taxilian 17:01 kylehuff: AFAIK it shouldn't; it's common practice
weird
FuzzYspo0N 17:01 let me debug further up
amackera 17:01 FuzzYspo0N: I too have noticed the setwindow craziness
kylehuff 17:01 okay, thanks amackera. I was mostly looking to reduce the delivery overhead. I am packaging the plugin for each platform inside of an extension.. 3 platforms, at minimum 2 architectures - it's getting large...
FuzzYspo0N 17:01 attachObserver calls the callback? The logic there in naming sounds off to me?
sink->HandleEvent is called, when attaching
gah wait.
misreading like a moron
amackera 17:01 kylehuff: when you say delivery, do you mean the size of the binary?
FuzzYspo0N 17:01 amackera, trying to do opengl initialise it doesnt really like that much
amackera 17:01 FuzzYspo0N: you are talking to the master of opengl initization in a browser plugin
<-- this guy
FuzzYspo0N 17:01 orly :)
amackera 17:01 What do you need to know?
FuzzYspo0N 17:01 Im making a simple example, WHY DIDNT YOU? :P
kylehuff 17:01 amackera: yes, the overall size of the extension that will be used to deliver the plugins.. (also, reducing the number of times I have to compile the plugin would be a plus)
FuzzYspo0N 17:01 hmm i could easily embed v8 engine in a plugin i bet
that might be for lack of recompiling
amackera 17:01 FuzzYspo0N: nothing is simple with opengl initialization i'm afraid
FuzzYspo0N 17:01 amackera, well, getting the window handle seemed easy enough?
amackera, Im interesting to know the catches etc
amackera 17:01 You're in windows, yes?
Actually yes, if you're ok with your plugin drawing over other HTML content, it's pretty simple
FuzzYspo0N 17:01 yep
amackera 17:01 get the HWND, setup OGL, gogogo
FuzzYspo0N 17:01 hmm, well what makes the rest hard?
amackera 17:01 it's when you try to layer HTML content that it gets tricky
windowless mode doesn't give you a HWND
FuzzYspo0N 17:01 yea, i wont really be layer cos i have chromium embedded in my opengl view ^.^
then its like chrome inside chrome inside chrome = death
So, i think on top is ok for now
amackera 17:01 badass! :D
it's chrome all the way down :P
FuzzYspo0N 17:01 heh and v8 scripting engine, too
its a 2d game engine, trying to embed it
amackera 17:01 yo dawg, i heard you like browsers
FuzzYspo0N 17:01 lots of users want that, noobs
amackera 17:01 so i'm embedding a browser in your browser, so you can browse while you browse!
FuzzYspo0N 17:01 The interesting thing - the chromium supports plugins, so i can load my plugin inside a plugin instance
i wanna try that, first , a triangle.
The multiple call things is causing an AW SNAP.
because i need the 'last' created window, if i use logic, but i dont know how many
i guess i can hardcode the second time around, do init
but seems bad.
amackera 17:01 does onWindowAttached get called with the same HWND each time?
taxilian 17:01 remember that for each onWindowAttached you'll get an onWindowDetached before the next onWindowAttached
FuzzYspo0N 17:01 havent checked, ill see now
oh yea, taxilian, i should implement that too, might help.
amackera 17:01 in my plugin i just set up / tear down on each attach / detach
FuzzYspo0N 17:01 yea, i just figured it was abnormal
amackera 17:01 It certainly isn't ideal
taxilian 17:01 yeah
FuzzYspo0N 17:01 ill take a look
amackera 17:01 The long and short of it is that the browser giveth and the browser taketh away our HWNDs
taxilian 17:01 amackera: did you ever step through to see if it's a "legit" attach/detach? is the browser really clearing it?
amackera 17:01 it's been a while since i've looked at it, but i'm pretty sure it's not a legit attach / detach
like it's the same HWND each time
however
the dimensions of the window do change
FuzzYspo0N 17:01 thats intresting
second time round HWND is null?
taxilian 17:01 well, a HWND being null causes the detach
then it sends a non-null which causes the attachevent again
FuzzYspo0N 17:01 but attached is called
hmm, maybe dont attach a null HWND?
seems counter intuitive
taxilian 17:01 it calls attached and HWND is null?
it shouldn't
amackera 17:01 uh oh that's most definitely my fault
i changed that code for the windowless mode
taxilian 17:01 *sigh*. the beta is, what, 2 hours old? :-P
amackera 17:01 haha
kylehuff 17:01 lol
FuzzYspo0N 17:01 heh :)
HWND hW = win->getHWND();
amackera 17:01 How do i pull a remote branch with git?
FuzzYspo0N 17:01 First time = valid
second time = 0x000000
taxilian 17:01 amackera: git pull
are you trying to pull a specific one?
amackera 17:01 hehe nuts
taxilian 17:01 what are you trying to do specifically =]
amackera 17:01 yes, firebreath-1.4
or is master ok?
taxilian 17:01 git checkout -b firebreath-1.4 origin/firebreath-1.4
that will change you to the 1.4 branch
assuming that origin is the main github repo
FuzzYspo0N 17:01 hmm, but if i attach, make gl stuff, detach, remove gl stuff, should i still crash the plugin?
taxilian 17:01 well, if HWND is sometimes NULL that'll do it
if you remove gl sutff on detach it shouldn't be a problem
but sounds like there is a firebreath bug
FuzzYspo0N 17:01 fair enough.
taxilian 17:01 which must be my fault for not reviewing the code well enough, since I wouldn't dream of criticizing anyone who is working on a fix. (at least until after they finish)
FuzzYspo0N 17:01 hmm
whats weird though, is that the plugin with no code, is now showing the plugin crashed page.
i commented out all my changes
taxilian 17:01 did you restart chrome and rebuild?
did the build succeed?
FuzzYspo0N 17:01 yep, i dont leave it open (cos chrome hogs the dll)
so, i restart chrome each test
taxilian 17:01 hmm
well, sounds like *something* must be happening...
amackera 17:01 hold on
in SetWindow
taxilian 17:01 amackera: if you have other git questions, let me know
amackera 18:01 if the NPWindow* is null, then we should destroy our window
taxilian 18:01 AFAIK, yes
FuzzYspo0N 18:01 note - the HWND is null - not the window ptr
amackera 18:01 but if the NPWindow->window is null, should we also destroy our window?
taxilian 18:01 hmm. let me dig a bit
what actually happens? does one of the set calls just have a null HWND?
maybe we should just ignore that
amackera 18:01 that's what it looks like
ignore as in just return NPERR_NO_ERROR and continue as planned?
FuzzYspo0N 18:01 if the original hwnd is the same of course?
taxilian 18:01 well, it probably has dimention changes
but we usually just get those from the HWND anyway
FuzzYspo0N 18:01 i wonder if you can get race conditions then
like attach -> start engine in a thread -> drop engine
taxilian 18:01 well, it's all on the same thread
ahh, I see
hypothetically, yes; you need to be careful of that
FuzzYspo0N 18:01 cool, but thats just threading for you.
taxilian 18:01 yeah
amackera 18:01 what's the consensus on this null HWND thing?
FuzzYspo0N 18:01 hmm with default code
i still get the crash.
taxilian 18:01 amackera: I say we try that; if there is a NPWindow but HWND is NULL, let's just ignore the message
on windows, anyway
FuzzYspo0N 18:01 So, something else is also mesed up
taxilian 18:01 FuzzYspoON: unless it happens on FBTestPlugin I don't log it as a FB bug :-P
FuzzYspo0N 18:01 sure
well, im new to this workflow, so i dont know if im reloading all that i need to
i close chrome, i close all tabs etc, reopen the gen -> FBControl.htm
taxilian 18:01 should be
FuzzYspo0N 18:01 and the dll is obviously rebuilt
taxilian 18:01 when you say "default code", what are you referring to?
and where is it crashing?
FuzzYspo0N 18:01 its not crashing, chrome is saying it crashed
i get all my valid breakpoints etc, but as soon as i continue execution -> chrome shows the 'aw snap' page
but it was working, adding code made it crash, obviously bad code
but is there a cache somehow, thats not letting me update the plugin on the browser side.
taxilian 18:01 that means your plugin is crashing
use the startup dialog, attach a debugger, and find out why
FuzzYspo0N 18:01 yea....
its the default empty project
i reverted all code changes, etc.
rebuild the empty default dll
ill triple check
taxilian 18:01 well, it didn't crash before, right?
so something has changed
FuzzYspo0N 18:01 but its not "crashing", execution continues as normal
theres not debug break
taxilian 18:01 if it does the aw snap thing the plugin crashed
it's just that chrome runs them in another process
FuzzYspo0N 18:01 right - but the debugger would break?
if it "crashed"
taxilian 18:01 if you have it connected to the right place, it should
FuzzYspo0N 18:01 :) It doesnt
taxilian 18:01 you could send me the project, I guess
FuzzYspo0N 18:01 and im certain of the process attach, as it hits the breakpoints
taxilian 18:01 I can try it
FuzzYspo0N 18:01 hmm, well, im not sure if its just a dll cache on chrome or something
its literally the empty project
taxilian 18:01 shoudln't be
jshanab_ 18:01 I am arriving late to the party. is this a chrome only situation? it is easiest to debug on Firefox first.
taxilian 18:01 good point
try it on ff
jshanab_ 18:01 Get Firebug!m start firefox, attach to firefox in visual studio and set breakpoints, then drag test page in. This is how I do it
FuzzYspo0N 18:01 I shouldn't be getting the "Missing plugins" thing should i?
In FF
jshanab_ 18:01 In firebreath, installation in any browser does it in all of them
FuzzYspo0N 18:01 yep.
But, firefox cant find it :)
only chrome can, it seems
taxilian 18:01 there is a deeper problem, then
try registering it again?
FuzzYspo0N 18:01 i did
also, unregistered
etc
taxilian 18:01 zip up the project dir (not the build dir) and send it to me, then :-P
FuzzYspo0N 18:01 if i unregister, chrome says <need plugin>
heh, and i registered it, chrome automatically reloaded the page
and it was still aw snap
taxilian, i want to try again from scratch, making sure its not just a 3 am issue.
taxilian 18:01 not a bad idea
FuzzYspo0N 18:01 But its strange, i do know what to expect
But, its not doing that
hmmmm
thats so weird.
It wont let me delete the dll, either
its open in another program.
LIES
taxilian 18:01 lol
amackera: how're you doing on that fix? if I push something and make you merge will it throw you off too much? =]
jshanab_ 18:01 You should hear the ranting and raving today as one engineer where I work let windows update his desktop and windows 7 notebbok, Both are rather hosed now. If you figure out when windows lies, please let the rest of us know :-/
taxilian 18:01 lol
FuzzYspo0N 18:01 i jsut reran cmake, killed everything, 'starting clean'. Lets see
taxilian 18:01 often a good idea
FuzzYspo0N 18:01 shut down couchdb, check
lol
FB_GitHubBot 18:01 FireBreath: firebreath-1.4 Richard Bateman * c872bfe (8 files in 6 dirs): Finished fixing FB_GUI_DISABLED issue - http://bit.ly/h0PC2c
FuzzYspo0N 18:01 some things can just linger for now reason
jshanab_ 18:01 you aren't using VS2010 by any chance?
FuzzYspo0N 18:01 no, 2008 express
jshanab_ 18:01 ok, I have discovered a bunch of "issues" with debugging on VS2010 and some blogs claim it existed in 2008. the pdb database gets confused and I have had to shut down VS, delete the build directory, and rebuild everything. The symptom of this is when it flashes the brakpoints and just keeps going. Our project takes a while to build so this is really frustrating. It seems to be related to...
...not shutting down the debugger before exiting the program
taxilian 18:01 that's… convenient...
FB_GitHubBot 18:01 FireBreath: master Richard Bateman * 1102c89 (8 files in 6 dirs): Finished fixing FB_GUI_DISABLED issue - http://bit.ly/hIQIrh
FuzzYspo0N 18:01 yea, i was forced to use 2010 early when it was still pre RC
my god
every 2 minutes "the pdb cannot be updated"
NOOOOO. there goes 1 hour building.
every 1hr2min*
it was terrible, i havent gone back, i heard its better but me, no need
taxilian 18:01 I've been pretty happy with 2010
but I didn't use it in beta
as a general rule, I don't support beta products with FireBreath :-P
FuzzYspo0N 18:01 lol, its a good rule
we were actually doing a c# game, for windows phone 7
so the tools were super early and crap
like forcing uninstall of 2008
taxilian 18:01 lol
jshanab_ 18:01 The new 2010 is pretty good. but it is funny how MS gets the hard stuff and misses on the fundementals. over and over.
FuzzYspo0N 18:01 heh, no
same thing... strange.
amackera 18:01 taxilian: push away to your heart's content
taxilian: i won't get a chance to commit for another hour or so
taxilian 18:01 ok
I just did =]
I also assigned the issue to you
thanks for taking care of it
amackera 18:01 no problem :)
jshanab_ 18:01 ok, Tell me what you have. Maybe it will ring a bell. For example I had a problem that was killing any browser on load of plugin, it turned out that you CANNOT reliably use a dll and .lib built with 2008 on a project built with 2010!
taxilian 18:01 now that 1.4 is in beta, the policy is that you commit on one branch, then cherry-pick to the other (if applicable)
I can do that later, though, if it's a pain for you
fuzzy_ 18:01 hmm
so i found something interesting
taxilian 18:01 soudns interesting
I gotta go to a scout roundtable; I'll be back in a few hours
FuzzYspo0N 18:01 taxilian, i searched the registry, it appears that there was some key with some values referencing the 1.3 plugin
taxilian 18:01 huh
that's weird
be back later
kylehuff 18:01 taxilian_away: okay, I added my project to the "FireBreath Users" section; feel free to review/revise/redact as needed.
taxilian 20:01 kylehuff: awesome, thanks. I'll add it to the examples page as well, since it's open source
taxilian 20:01 interesting; just got a survey submission saying "Boost is a fat bloated non-standard beast, Not sure why you choose it as I haven't dug threw the firebreath code base. But once firebreath becomes more popular you WILL find that MOST users will find boost as a major issue. Standardize your code base!"
curious if any of you guys have encountered this attitude about boost?
kcsham 20:01 i can't imagine dealing with path without boost.
taxilian 20:01 honestly, I fought tooth and nail to avoid adding boost as a dependency to FireBreath… there just wasn't a good alternative
kcsham 20:01 i know in the embedded world, they stay out of boost.
taxilian 20:01 that's why we supply our own subset of boost with FireBreath is to keep from having an external dependency that's a pain to set up
why is that?
kcsham 20:01 code size; and remember they come from the world where they write their own OS.
taxilian 20:01 true; boost isn't any bigger than the STL, though, if you use it correctly
some things can actually end up being smaller since they are optimized at compile time
I can see why you'd avoid things like lambda
kcsham 20:01 it may have to ask them again.
i'm quite sure the thread part is probably not giving the level of control they need for real-time app.
taxilian 20:01 hmm. maybe on an embedded device… boost thread is actually pretty decent, from what I've seen. 'course, I'm not an expert on threading
just kinda interesting. He had a lot of comments… my response to him was very long =] most of his comments my response boiled down to "this is why we do that. Do you have a better suggestion?"
still, he's the second person to really rate the documentation poorly and the first to tell us why. The other guy didn't give us anything; just said that the docs are poor and left it at that. very helpful :-P
kcsham 21:01 are the comments public?
taxilian 21:01 no
if you'd like I can share some of them with you
I wont' give you his name, though
=]
I'll distill all of the comments into a public page eventually (minus names), but I'll wait a few more weeks
kcsham 21:01 np. i'll get the digested version from you later.
taxilian 21:01 much of it was criticism (justifiable) of documentation and poor organization on the website
kcsham 21:01 i'll post mine after i got through this phase of my project too. :)
taxilian 21:01 thanks =]
and feel free to be honest
I'm hard to offend =] I do find it puzzling when people criticize when they don't have a better suggestion, though
kcsham 21:01 at this point, the biggest obstacle seems to me is the vast numbers of technologies to overcome to become productive.
taxilian 21:01 such as?
kcsham 21:01 probably not core to firebreath, but firebreath glues them together and as such taking the blame.
Cmake, WiX,
taxilian 21:01 I can't argue either of those
I plan to write better docs for using CMake
wish someone else were able to do some of it, though; I'm getting spread too thin
kcsham 21:01 to get the simplest thing done end-to-end, would require substantial knowledge of them.
taxilian 21:01 true
wish there were anything I could do about it =]
but docs will help, I think
most things really aren't that hard in cmake
when you know what you're doing
kcsham 21:01 i'm not there yet. :)
taxilian 21:01 well, if you need help with something let me know
kcsham 21:01 especially the part to specify external library.
right now, i'm taking a short cut by piling platform specific stuff into a prebuilt folder.
like prebuilt/Win, prebuilt/X11
using the platform specific cmake file to add the path to them explicitly.
very un-cmake way.
taxilian 21:01 honestly, that's more or less how I'd do it
I might use find_library is all
linking to non-cmake projects is still not as smooth as it really should be
kcsham 21:01 exactly, we use an audio package and recognizer package. both are ancient and non-cmake.
taxilian 21:01 what platform?
kcsham 21:01 they're cross platform.
c code
taxilian 21:01 you could, of course, convert them to cmake; there are ways to link external projects using cmake, though
I haven't actually used them
I have the cmake book; I need to read through and learn how to do that better
kcsham 21:01 those would definitely come when we move to other platform. currently, we're building for Win only. a lot to clean up and make the build process a process.
taxilian 21:01 yeah
I have to admit, cmake can be a bit of a pain sometimes
wix you'd be stuck with anyway
but cmake really does save you a lot more hassle than you realize
also FireBreath as a library wouldn't be possible without it
s/library/framework
kcsham 21:01 i can see that.
anyway, that's it for the day. later.
Tonku 21:01 Aby body who knows how to add .xib file to the mac project...
taxilian 21:01 thanks for dropping in
you saw the full changelog, right?
Tonku: in FireBreath? I would assume you could just add it to the plugin project sources...
Tonku 21:01 oh..
taxilian 21:01 haven't actually tried it
I'd add something like *.xib in your Mac/projectDef.cmake
Tonku 21:01 I have added my mac .h and .m files into the mac folder, but dont know ehere can i add the .xib file..
taxilian 21:01 AFAIK you can put it anywhere in the project you want
the Mac folder would make sense, since it's mac specific
Tonku 21:01 will it apperar in the project, after I give ./prepmac.sh projects/ build/ ..?
taxilian 21:01 you may need to update the cmake project definition
do you understand the basics of how cmake works?
Tonku 21:01 I dont know really, I use it for the first time ..
taxilian 21:01 ok. hang on a sec;
Tonku 21:01 ok ..
taxilian 21:01 there are two files that define your project
the first is CMakeLists.txt
that's the one that is used on all platforms
Tonku 21:01 ok
taxilian 21:01 https://github.com/firebreath/FireBreath/blob/master/examples/FBTestPlugin/CMakeLists.txt
this is the FBTestPlugin (one of the examples) one
Tonku 21:01 ok
taxilian 21:01 if you look at line 15, you can see a simple file(GLOB command that searches for all the files that match the GLOB patterns given
and stores them in the ${GENERAL} variable
with me so far?
Tonku 21:01 pls wait lemt load the makelist file
taxilian 21:01 (btw, yours will be almost identical to start out with)
take your time
Tonku 21:01 yes ..I saw that section..
si I should add .xib to that list..?
taxilian 21:01 well, hang on
that's one option
Tonku 21:01 ok
taxilian 21:01 so you see at the bottom of the file, line 33, it combines the two lists ${GENERAL} and ${GENERATED} into ${SOURCES}
Tonku 21:01 I will try with that..
taxilian 21:01 hang on a sec; almost done
Tonku 21:01 yes
taxilian 21:01 go look at https://github.com/firebreath/FireBreath/blob/master/examples/FBTestPlugin/Mac/projectDef.cmake
this is the mac specific extension to CMakeLists.txt
so this only happens on Mac
you have a similar GLOB that puts files in PLATFORM
you could add it there as well
notice on line 23 it combines the old SOURCES list with PLATFORM
and then uses that in line 32 when it creates the actual plugin project
I would put it in the Mac/projectDef.cmake file, since that's mac specific
so if you wanted to put it in the Mac/ dir, you could add Mac/*.xib to the PLATFORM list
Tonku 22:01 so in this file file (GLOB PLATFORM RELATIVE ${CMAKE_CURRENT_SOURCE_DIR} Mac/*.cpp Mac/*.h Mac/*.cmake Mac/*.xib ) will do the job..?
taxilian 22:01 yep
Tonku 22:01 only that much..?
cool ...
taxilian 22:01 not hard, huh? you just need to know what is what
as long as the file ends up in the SOURCES list it'll go into the project
Tonku 22:01 wow..firebreath is super cool and you guys also..
:)
taxilian 22:01 well, yeah… ;-)
Feel free to fill out the survey on the website and let us know what you like / would like to see / what you think
Tonku 22:01 sure :)
taxilian 22:01 I have just updated the main FireBreath page; would be interested in feedback if anyone has any