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

IRC Nick Time (GMT-7) Message
j-b 03:09 Good morning
j-b 04:09 I have a lot of difficulties to compile a FB project:
I had to use the system boost, because the version in submodule does not compile on gcc 4.7, on Linux
reichi 04:09 this looks like a coding error to me
i guess you'll have to wait for taxillian, he may have an idea
he usually drops in in about 4-5h
dougma 05:09 j-b: perhaps if we could see FBVLC.cpp?
j-b 05:09 reichi: I can wait forever, to be honest :)
we are moving our old VLC plugins to fb
reichi 05:09 wait
j-b 05:09 dougma:
reichi 05:09 the vlc guy?
j-b 05:09 reichi: yes, me
reichi 05:09 cool
j-b 05:09 now, I do not know if I need to run or not :)
reichi 05:09 i am i fan of vlc
(and just a firebreath user)
ok well i assume you do know how to code ;)
j-b 05:09 reichi: well, we have 2 implementations of plugins, one for ActiveX and one for NPAPI.
reichi 05:09 yeah i'm using them ;)
j-b 05:09 reichi: and someone did a fbvlc
and they are crap
reichi 05:09 since it broke on what
j-b 05:09 so, I am trying to see if I can improve fbvlc and fb to suit our needs
the guy who did fbvlc did only for Windows, and this is not ok for us.
We need Xcompilation and we need to get rid of ATL
reichi 05:09 sure not :)
what's your boost version?
j-b 05:09 But, at least, the code is short.
reichi: arch version, so I guess latest
reichi 05:09 ah
j-b 05:09 and the code can be very wrong
I just started to look at FB this morning
reichi 05:09 it always can
j-b 05:09 But I like it.
reichi 05:09 so do i
it does all the nasty stuff one usually doesn't want to have to care about
j-b 05:09 well, this is not our issue, since the nasty stuff is done :)
the issue is more to be able to easily extend
reichi 05:09 j-b: is that exactly the source you're trying to compile?
j-b 05:09 and synchronize NPAPI and ActiveX
reichi 05:09 let me give it a shot...
j-b 05:09 I am using firebreath-1.6 from git
and I am using local boost, because the 3rd party version does not compile with gcc 4.7
reichi 05:09 hmm
boost has recently been updated to 1.5 for firebreath
but possibly only for the 1.7 branch
j-b 05:09 and now I feel stupid
reichi 05:09 1.7 has not been released yet
at least i think it has
i remeber taxillian doing something like that
(he's the maintainer)
there is a 1.5.0 branch for boost
and firebreath master is actually submoduling that
so does 1.7 (seemingly)
so maybe you want to try building it with 1.7
j-b 05:09 doing it right now with trunk
j-b 06:09 well, trunk boost version compiles fine, indeed
but still the fbvlc compile error
reichi 06:09 boost related compiler errors are totally awful imo :/
j-b 06:09 indeed
reichi 06:09 /home/jb/VideoLAN/dev/firebreath/projects/fbvlc/FBVLCAPI.h:514:77: required from here
(just had to look at it long enough)
but i don't get the issue :/
j-b 06:09 me neither
dougma 06:09
looks smelly
smells ok.
j-b 06:09 I worked-around it
dougma 06:09 oh good. :)
reichi 06:09 j-b: bit commeting the code? ;)
j-b 06:09 yes
I need to have a correct base
even if I need to use my axe
j-b 07:09 [100%] Built target FBVLC
reichi 07:09 :)
i don't like the constructor code being defined in the header, to be honest
i actually had to grep to find that code
j-b 07:09 I don't like 99% of this code
reichi 07:09 ok
so it's not only me ;)
but yeah
it's a good start
j-b 07:09 exactly
reichi 07:09 to get a feeling of what fb can do, and what it can't
j-b 07:09 what I don't get is if I can do a WindowLess and a WindowFull plugin with the same code
and what I don't get is what is gtk here for
reichi 07:09 i guess that's something you should talk about with taxillian
j-b 07:09 and I don't get why the .so is soo big
reichi 07:09 yeah
that's annoying :/
my plugin is like 2 Megs
für 4k loc
(own code)
sorry. for
j-b 07:09 boost?
reichi 07:09 (I tend to mixin the german word for "for" which is für)
at least boost eats up all your memory at compile time
you should have a look at that
it's incredible how much ram it takes
j-b 07:09 well, is it worth it ?
reichi 07:09 i think so
i think the point is, that boost is very popular nowadays
and can be assumed to be pretty well tested
j-b 07:09 I don't care about boost, I care about FB
reichi 07:09 firebreath is worth it
j-b 07:09 can I do Windowless on X11 ?
reichi 07:09 hmm no
on of both doesn't work
i'm not totally sure which one
j-b 07:09 seems to work on Windows
reichi 07:09 well, the x11 support is probably the least-sophisticated one
only SetWindow on X11
so no windowless, i guess
GdkNativeWindow browserWindow;
maybe that's the answer to your gtk-question
j-b 07:09 same on Mac?
reichi 07:09 hmm dunno ;)
I'm using a "custom-platform" implementation
on an embedded linux based system
JuanDaugherty 09:09 I get this thing on odd occasion during testing/dev where a dialog box comes up in chinese. Anybody seen that, know why it is?
taxilian 09:09 j-b: from your compile error it looks like you're using a parameter that is FBVLCVideoAPI* or & somewhere; neither should ever be used, you should be using the boost shared ptr
JuanDaugherty: that is a totally new one on me =]
j-b 09:09 taxilian: sorry, I fixe the compile errors
taxilian 09:09 okay
let me know if you run into any other issues
j-b 09:09 taxilian: I will run into other issues, but I am RTFM today
taxilian 09:09 I should be around most of the working day
(I'm in GMT-0600)
j-b 09:09 I'm in GMT+0100
taxilian 09:09 so X11 windowless; FireBreath doesn't support it currently, but that's because I don't know how
X11 drawing is my weakest area; it could be added relatively easily (I would think), I just don't know how it works
if you know how the NPAPI stuff needs to work, I can help you extend FireBreath to do what you need
and you can absolutely have a plugin that works both windowed and windowless
j-b 09:09 what I need is to just pass the video data to a buffer for the browser to display it. I don't even need x11
not sure that this makes sense :)
reichi 09:09 npapi says you need x11 ;)
taxilian 09:09 I only know of one NPAPI feature that would do that without X11 and I don't know if anyone has implemented asyncdrawing yet
reichi 09:09 npapi for linux is specified using x11
taxilian 09:09 if so it's very new
j-b 09:09 and for MacOS?
taxilian 09:09 heh. FireBreath has great support for drawing on Mac OS, but it's a little bit of a tricky question. If I were you I'd use CoreGraphics, probably the easiest
and I can give you code that will draw a pixel buffer for windows and mac os
is this intended to become the new "official" vlc plugin?
j-b 09:09 yes
I think the current code work with and without windowless on win32
taxilian: you do not think it is a good idea?
taxilian 09:09 then if you'd like I'll do some code reviews with you and help you make sure it's clean -- it'd be a fantastic sample plugin for helping people understand FireBreath
I think it's a wonderful idea
j-b 09:09 taxilian: well, the current fbvlc code is:
- crap
- 1 tenth of the code size
- same features on activex and npapi
- exactly the complete api of the classic plugin
- has windowless on windows
It has a few issues:
- Linux, Mac
taxilian 09:09 well, just let me know what questions you have and I'll help as I can. linux support will be the hardest, simply because I don't know how to draw well on linux
j-b 09:09 - ATL is not GPL compatible
linux, I can do
taxilian 09:09 excellent
hmm; I hadn't considered the implications of ATL and GPL; I wonder if that makes FireBreath's LGPL license invalid
j-b 09:09 mac and windows windowless are the more important
taxilian 09:09 ATL is a header-only library
j-b 09:09 taxilian: it does not make it invalid
taxilian 09:09 so it's technically open source
j-b 09:09 but VLC is GPL
taxilian: last time I checked there were 7 classes that are easy to reimplement
taxilian 09:09 for atl?
j-b 09:09 yes
so, this is not my biggest issue
taxilian 09:09 it might actually be more than 7
j-b 09:09 ok
taxilian 09:09 and you also have to worry about the self registration; that uses ATL for importing registry stuff
I've actually wanted to remove the ATL dependency for a long time, but haven't had the time or motivation
it is doable, but I wouldn't say it's a trivial task
what do you see as the biggest issue?
j-b 09:09 size of the plugin
and Mac integration
for windowless
and cleaning the code done by the russian guy
taxilian 09:09 Mac integration won't be a problem, drawing-wise
j-b 09:09 even with windowless?
taxilian 09:09 Mac CoreGraphics is as windowless as it gets
I'm not 100% sure if all browsers support true windowless (transparency) with coregraphics, but if there are any that don't they don't support true windowless with anything else either
so if you use CoreGraphics you're there
reichi 09:09 j-b: i would honestly consider rewriting it ;)
taxilian 09:09 Mac doesn't really have a windowed mode, actually
are we talking about RSATom's code?
j-b 09:09 and if I use OpenGL
reichi 09:09 taxilian: yes ;)
j-b 09:09 yes
and if I use OpenGL?
taxilian 09:09 OpenGL you won't be able to use windowless mode on windows; at least not without using an offscreen buffer
on Mac you'll have to use CoreAnimation and some browsers won't support transparency so it will be like windowed mode on windows
alternately you could use an offscreen buffer and blit to CoreGraphics, same as you'd have to do for windowless on windows
j-b 10:09 yes
VLC has a video output named vmem
as in video output to memory
that provides raw data
taxilian 10:09 if you have the raw data, why would you need opengl?
j-b 10:09 for the windowed mode
sorry, I was not clear
taxilian 10:09 but still; why do you need opengl if you have raw data?
j-b 10:09 for direct rendering
in not-windowless mode
taxilian 10:09 for that matter, why not just use windowless mode? (incidentally, just looked at FBVLC and as far as I can tell it only supports windowless mode on windows)
j-b 10:09 of course, RSAtom only works on windows
taxilian 10:09 is opengl more direct than drawing using GDI to a hWND?
j-b 10:09 windowless is slow
it had a memcpy and a chroma-conversion
taxilian 10:09 not as slow as people seem to think these days; older computers may still have an issue with it, I suppose
fair enough
j-b 10:09 chroma-conversion can be very expensive
especially in I422 and and 10bits
taxilian 10:09 that makes sense
j-b 10:09 while in OpenGL shaders, it is fast
taxilian 10:09 honestly to me that just means it's an even better sample plugin ;-)
j-b 10:09 lol
of course
taxilian 10:09 I will help as I can; I'm pretty swamped for time, but let me know what questions you have
j-b 10:09 I just started today, to make it build on linux, with cmake and stuff. I was RTFM ing while doing a git bisect on another project
taxilian 10:09 hehe. sounds… fun… =]
j-b 10:09 bisecting ffmpeg is not fun
reichi 10:09 lol
j-b 10:09 especially with the fork
taxilian 10:09 1.7 is pretty much production ready, incidentally; I would have released it already but I'm trying to find time to pull in some pull requests
reichi 10:09 i can't remember any bisect that has ever been fun to me ;)
j-b 10:09 with a linear project, bisecting is easy and fun
taxilian 10:09 and that's why I love git rebase…. -P
'course, that only works well enough sometimes… but still
reichi 10:09 i have autosetuprebase
and i would prefer it being the default
taxilian 10:09 someone from Cambridge just sent me a feeler email asking if I'd be interested in a job that would mean relocating to the UK
that would have to be one heck of a high paying job to be even close to worthwhile...
reichi 10:09 didn't you just move into a new home?
taxilian 10:09 3 months ago, yep
and having my parents near by as emergency babysitters / support is probably worth at least 50K anyway
reichi 10:09 haha
JuanDaugherty 10:09 the stream handling mechanisms aren't hooked up to the browser in the way in which one might take the name "DefaultBrowserStreamHandler" I take it.
taxilian 10:09 huh. so I've never seen autosetuprebase before
that's kinda cool
I may just switch that on
reichi 10:09 it well set all new gits to rebase for you
JuanDaugherty 10:09 i.e say to npn/npp NewStream
reichi 10:09 my biggest discovery ever was "git grep"
i didin't know about that for ages
taxilian 10:09 JuanDaugherty I don't fully understand your question; "take the name"?
JuanDaugherty 10:09 *take the name to imply
also meant of course the core fb i/f to/abstraction of the browser
taxilian 10:09 still not following, I'm afraid
JuanDaugherty 10:09 in the std scenario I'm dealing with
my plugin is invoked by the user loading a file with its associated mime type
so the browser already has the stream ready I presume
taxilian 10:09 ahh; there is a pull request that adds that functionality
I just have been so swamped the last month I haven't had time to accept it
JuanDaugherty 10:09 in old npapi code this would be fielded by newstream, I assume there ...
taxilian 10:09 (review it so I can accept it)
JuanDaugherty 10:09 don't understand "pull request that adds that functionality". Are you saying it's a future feature? If so conceptually what do I have to do with Mathias's existing stuff to make this happen?
taxilian 10:09 do you understand how a pull request works on github?
JuanDaugherty 10:09 yes
i think so, have a github account (Ren Ren Juan)
taxilian 10:09 okay; so someone submitted a pull request; the pull request contains patches that add the functionality to support a browser-created stream
I dont' want to pull it in until I can review it and make sure it's solid and that the API is something we can live with (because I hate changing APIs and breaking backwards compatibility)
so I haven't done so yet
but perhaps I will today; my boss tells me today is as good a day as any to take some time to catch up on FB stuff
JuanDaugherty 10:09 your boss
and you don't mean Ms. taxilian I take it
taxilian 10:09 no, I mean my employer
though this project certainly owes a lot to the fact that my wife is an amazing and patient woman who lets me work on it in my "spare time" =]
but I use FireBreath at work, so it is in the best interests of the company for me to maintain it; we've just been working on getting a release out recently and I haven't had time
FireBreathBot 10:09 Commit d2d86af on master by Jason Frey: "Added support prepping on Visual Studio 2012 (Visual Studio ..."
Commit 213375c on master by Richard Bateman: "Merge pull request #87 from ManageIQ/add_vs2012_support
JuanDaugherty 10:09 just a little surprised as yesterday you suggested using this
taxilian 10:09 I didn't realize you needed to use the browser-created streams
though you just needed NPP_GetUrl, etc
JuanDaugherty 10:09 do need them but that's ancillary function
reichi 10:09 you could thest the pull-request for taxillian ;)
taxilian 10:09 hehe. I'm actually doing it now
reichi 10:09 :D
JuanDaugherty 10:09 so it actually is PRAWBWBR
taxilian 10:09 … but will be… ?
JuanDaugherty 10:09 reviewed
taxilian 10:09 ahh
well, yes
I review everything; there are some in here who have push access to the trunk, but I still review everything
I also welcome people to review anything I push
I find more problems are caught early that way =]
JuanDaugherty 10:09 so a pull at github automatically implies a commit authority? I wouldn't have thought that.
taxilian 10:09 no; a pull request is for when you don't have commit authority
those with *push* access have commit authority
JuanDaugherty 10:09 I take it its' unsolicited npp new stream
reichi 10:09 JuanDaugherty: you basically fork the project
taxilian 10:09 correct
reichi 10:09 commit a change to your fork
and than ask the author of the original git "please pull my changest abcd"
taxilian 10:09 Juan: I'll add your fix for allowing to turn off PCH while I'm doing things today
reichi 10:09 you can actually do that via the github webinterface now
taxilian 10:09 yeah; it's pretty nice. some things I can review, see that it's fine, and just do it there
JuanDaugherty 10:09 reichi, right I know, that's the ethos/basic MO of github, the rationale for git
this is what I would call de rigeur "serious plugin" function for fw like fb
taxilian 10:09 it actually comes up pretty rarely
but it definitely needs to be pulled in
I am working on it as we speek
JuanDaugherty 10:09 appears I have no choice but to use the NPN function NewStream
taxilian 10:09 … or you could wait for a few hours and I'll have it working for you
JuanDaugherty 10:09 oh, that quick
taxilian 10:09 it's written, I just need to test it
and decide if I want to change the API
JuanDaugherty 10:09 well I can test it for you
taxilian 10:09 I will hold you to that =]\
reichi 10:09 ah, i see you have merged some the the umerged changes in 1.6 to 1.7 some time ago
taxilian 10:09 give me… an hour?
and then I should be well into it
I just need to finish a fix on our product codebase and push and I'll be on firebreath stuff; already merged it in
JuanDaugherty 10:09 np, if you were addressing me
taxilian 10:09 I was
JuanDaugherty 10:09 that it comes up rarely supports my characterization
taxilian 10:09 hehe. I have worked on quite a few "serious plugins"
most of them don't need that feature
only plugins of a certain type do; many of those are not serious, actually
it's just the function of the plugin that influences it, not the seriousness of it
hmm. one thing to note, Juan, is that I don't think that ActiveX support for this has been added
JuanDaugherty 10:09 sorry. I shouldn't have said that, I have a huge impulse control problem
taxilian 10:09 I dont' know how to detect an unsolicited stream from activex because I don't know how (if at all) activex supports that
if you can provide some insight I could add that at the same time
j-b I'm guessing you'll need that functionality as well for vlc
JuanDaugherty 10:09 and yesterday I was very tired so the 2 synergized. I can work with the np leg alone/first.
taxilian 10:09 okay; it's just that today I'm working on this, and I'm happy to add the activex side as well (in fact I'd prefer to) I just dont' know how it works
j-b 10:09 taxilian: that functionality being?
taxilian 10:09 the ability to specify a src in the object/embed tag and have it automatically create a stream
j-b 10:09 hm,, yes
JuanDaugherty 10:09 i'll look at my legacy code. As I said I'm not specializing in nor an expert in plugins but I presume that IE adopt a good portion of the np protocol
taxilian 10:09 I know how it works on NPAPI and I'm merging in a pull request
I don't know how it works on ActiveX
JuanDaugherty 10:09 are you thinking AX distinct from IE?
taxilian 10:09 no
JuanDaugherty 10:09 so that if my presumption is correct, doing np will cover IE
taxilian 10:09 no
npapi is not supported by IE
IE uses ActiveX
JuanDaugherty 10:09 AX apparently has an event system that signals data ready
taxilian 10:09 can you tell which interface that is?
JuanDaugherty 10:09 an OnDataAvailable method is invoked analogous to NewStream
taxilian 10:09 alternately if you can tell me which interfaces the root AX control implements I can probably figure it out
hmm; is your legacy ax control an MFC control?
JuanDaugherty 10:09 it's an ocx
taxilian 10:09 that doesn't tell me anything. Well, you've given me somethign to look for. I'll get the stuff I have working first, then dig into that
reichi 10:09 taxilian: mmh, NPAsyncSurface seems totally platform indepent, right?
except the HANDLE for windows
j-b 11:09 m
JuanDaugherty 11:09 it is mfc
reichi 11:09 the struct looks very platform independent to me
stride and raw bitmap data
JuanDaugherty 11:09 stride?
taxilian 11:09 reichi: I think so, yes
reichi 11:09 mmh
that thing may solve my issue...
i guess i'll have a look at it
JuanDaugherty 11:09 iBindStatusCallback is the i/f
taxilian 11:09 need to figure out if any of the current platforms even support it
reichi 11:09 JuanDaugherty: stride tells you how "long" one scanline is
JuanDaugherty 11:09 well they do but maybe deprecated
reichi 11:09 for upside-down images it would be negative e.g.
taxilian 11:09 NPAsyncSurface is not deprecated by anyone; it's too new for most browsers to have implemented it
reichi 11:09 hmm
my problem is i would've to implement that into qtwebkit first
JuanDaugherty 11:09 sorry I meant iBindStatusCallback, it's still in use
dunno about ie specific
taxilian 11:09 fair enough; that gives me some things to play with
JuanDaugherty 11:09 *IE
taxilian 11:09 I really don't like this interface; it's too confusing / complicated
requires too much background knowledge that will be hard to document
trying to decide how to improve it
JuanDaugherty 11:09 you mean netscape or ms?
taxilian 11:09 sorry, I mean the one in the pull request for an unsolicited stream
JuanDaugherty 11:09 ah
well in fb, ur the boss :)
and as principal doer, your likes/dislikes are actionable
taxilian 11:09 hehe. I could stand to have a few more people taking active interest in helping make these decisions, though :-/
JuanDaugherty 11:09 principal but not sole. That's my anti-pattern.
taxilian 11:09 =]
JuanDaugherty 11:09 so in your case politic handling is called for
taxilian 11:09 so in this case, the question is between efficiency of process and cpu usage vs efficiency of programming
I can either ask the plugin object to handle the stream and expect it to create the stream object for me
in which case I have to send all sorts of parameters that it will then be passing to another function to create the stream
JuanDaugherty 11:09 for my use I'm good with a concise description of what needs to be done and the pull request + mathias stuff as inputs
taxilian 11:09 or I can create the stream and pass a single object with all of the information and ask the plugin to decide if it wants to accept it or not
I like the latter idea better because it's a clean API; it's slightly less efficient because it does create an object that then may just be discarded
JuanDaugherty 11:09 efficicency of programming should always trump in a first case
taxilian 11:09 thoughts? j-b as well, if you wouldn't mind providing some input
that's kinda my perspective as well; premature optimization should be avoided, and it's not like an unsolicited stream is created often enough that a few processor cycles are going to be a problem
JuanDaugherty 11:09 I said it is mfc, but I just associate that with that AFX macro stuff and the win32 generally
taxilian 11:09 there is actually a really big difference between mfc AX controls and ATL ones
taxilian 11:09 so has been implemented in mozilla since FF 13 aparently
but I don't think anyone else has accepted it
reichi 11:09 i've just read the specs
unfortunatley is isn't what i suspected it to be
taxilian 11:09 what were you hoping for?
reichi 11:09 to be x11 independent
but it's just an extension of what's already there
taxilian 11:09 hmm
reichi 11:09 i totally misinterpreted it ;)
taxilian 11:09 actually should be what you describe
reichi 11:09 well
you can't create a window ;)
taxilian 11:09 but you can draw to the plugin window
reichi 11:09 if i understand correctly it's just a way to get direct access to surfaces physical memory
(or virtual)
i still have one major problem
i don't have x11
and i'll never have
and npapi was totally not specified for that case
(which you basically have on all embedded devices)
the worst thing
i don't even want to draw
i just need the window-size
taxilian 11:09 browser window size or plugin canvas size?
reichi 11:09 plugin canvas
so i can (sync) clear it
i'm using it on a set-top-box
so we do have video
i just need to clear the area of where plugin resides
so video becomes visible
(and resize/-position the video)
taxilian 11:09 ahh
you should be able to get that from the NPWindow
regardless of your drawing mode
reichi 11:09 without x11
you have nothing :(
you can't catch an x11 event without x11, right?
taxilian 11:09 it isn't an X11 event
the size is part of the NPWindow
reichi 11:09 well
taxilian 11:09 just need to figure out what type of model it supports
reichi 11:09 maybe i just never got the correct spot to catch the size ;)
taxilian 11:09 might have to add a new PluginWindow type
reichi 11:09 oh, i already have that ;)
i have a complete own "platform set of classes"
taxilian 11:09 SetWindow should give you the size
reichi 11:09 no window object...
the basic problem is the browser-side backend
not firebreath
i guess i'll have to implement a new platform-implmentation into qtwebkit
taxilian 11:09 when you say no window object
no NPWindow*?
or no window object inside the npwindow?
reichi 11:09 well basically
on the qtwebkit side
we only have dummy methods
(ifdefs around everything unsign X11 in any way)
so my issue is a lot less about FB than about the actual browser
I'm sure firebreath would do fine
if it would get any drawing events/SetWindow Calls with proper values
unfortunatley all my tries for "simple solution" lead to a dead-end for some reasons
taxilian 11:09 are you sure you have the right npapi headers for qtwebkit?
either way the NPWindow* should have a size
it's part of NPAPI, not a platform specific thing
reichi 11:09 well
qt's npapi implementation is very x11 centric
but i think i'll try to write a very very basic implementation myself
taxilian 11:09 that shouldn't matter
reichi 11:09 which just calls SetWindow/raises a draw event with the size and position
taxilian 11:09 because the size in the NPWindow is not platform specific
the NPAPI spec says that when the window size changes a SetWindow should be called with the new size
reichi 11:09 well
you may have pointed at what i've been blind about....
taxilian 11:09 if anyone needs a 128GB ssd, tha'ts about the best price I've seen
reichi 11:09 damn
sadly i live in germany
taxilian 11:09 hehe
reichi 11:09 so customs would eat the good price...
taxilian: ich think it's just one method call to much ifdefd...
(that's what it's called in qt)
JuanDaugherty 12:09 sadly? Wish i did.
reichi 12:09 no
don't get it wrong
i'm pretty happy here
but prices are way better in the us ;)
especially for electronics
JuanDaugherty 12:09 Sind Sie Deutsche?
reichi 12:09 Deutsche"r" ;)
JuanDaugherty 12:09 oder auslander in deutschland
reichi 12:09 at least as long as you're not talking to a woman :)
JuanDaugherty 12:09 :)
reichi 12:09 I'm an original bavarian
JuanDaugherty 12:09 ouch
reichi 12:09 (Oktoberfest started this weekend, btw)
JuanDaugherty 12:09 "Juan Daugherty" after all
reichi 12:09 your 2nd name is pretty common, isn't it?
JuanDaugherty 12:09 relatively yes, with variants
there's actually another in Guatemala apparently
taxilian 12:09 okay, JuanDaugherty. You win
PCH will be off by default
with a compiler flag to turn them on
that way we can still use them on a build server, etc to speed up compilation
but I just turned them off (and spent an hour fixing crap) and now things are working much better
JuanDaugherty 12:09 VS 11 is VS2012, is that right?
taxilian 12:09 I think so
JuanDaugherty 12:09 i didn't have a problem with pch when i went back to vs 8. But that's the right thing to do for pch on general principles. I'll want to have it on most of the time.
taxilian 13:09 this is taking longer than I expected; I'm needing to do a bit more of a refactor than planned. I still plan to have it done today, though
JuanDaugherty 13:09 take you time, in no rush here
this isn't the only job I'm working
taxilian 16:09 wow. this is really an all day project
when I'm done there will be an entirely new (and far better thought out) method for using browserstreams
and the old method will be deprecated
I hope I can finish it today
change one line, means I have to change more, leads to more, leads to more....
reichi 16:09 :D
don't you know
"give me a moment"
NEVER works
taxilian 16:09 I just don't like fixing things partway
then I have to fix them again later
JuanDaugherty 16:09 maybe better to just concentrate on a minimal UnsolicitedDefaultBrowserStream ?
reichi 16:09 i like your point of view taxilian :)
taxilian 16:09 wouldn't work
anyway, I'm well over halfway done
actually closer to done than not
the whole BrowserStreams API is terrible
it's confusing and nobody can figure it out
it's far too difficult to do simple things
so I'm fixing it
or at least improving it
I'll leave the old APIs for backwards compatibility, of course
JuanDaugherty 16:09 for all covered fb browsers?
taxilian 16:09 correct
though I still will need to finish teh unsolicited stream support for IE
not yet sure how that works
first things first
JuanDaugherty 16:09 if need have any question like the earlier ones on the AX leg lemme know
taxilian 16:09 I probably will
JuanDaugherty 16:09 s/if need/if you/
taxilian 16:09 but maybe not today; normally I'd keep at this 'til it's done, but my wife has plans this evening and I need to watch the kids
JuanDaugherty 16:09 if the part that deals with the lack of solicitation is done, I can apply it to what I have, pick up the production level when your done
taxilian 16:09 fair enough
JuanDaugherty 16:09 i.e what pulled from github last week as current
taxilian 16:09 basically I've created an object called BrowserStreamRequest
JuanDaugherty 16:09 *what I
taxilian 16:09 in the new case FB creates one and gives it to the plugin to either accept or ignore
but to follow to the natural conclusion, in other cases the developer creates one and passes it to the browser to create
that's what I'm working with
it'll be a nice API when I'm done
JuanDaugherty 16:09 SFAIK, the lack of solicitation only concerns one case
the plugin invocation for a file/stream unknown to it
taxilian 16:09 yeah; however, handling that case well is what I'm concerned with
JuanDaugherty 16:09 as a result of it being the mime type handler for that
taxilian 16:09 ahh, and thanks for reminding me; need to pass along the mimetype of the request
actually there are two cases; that is one
the other is when you have a src attribute in your object/embed tag
JuanDaugherty 16:09 so this will be somekina stream object member of browser host in those cases?
taxilian 16:09 no; it'll actually be a method on PluginCore that you'll override
you'll be given a BrowserStreamRequest object to look at
that will tell you things like the mimetype, etc
and you can assign a callback function or an event sink
JuanDaugherty 16:09 well if you can give me that mechanism today or tomorrow I can use it with the existing stream facilities in just the np leg and give you some feedback
j-b 16:09 cd
sorry :)
taxilian 16:09 lol
you are now in your home directory
j-b 16:09 I hate screen + putty + slow connexion
taxilian 16:09 hehe
JuanDaugherty 16:09 6
3 maybe, no personal content
taxilian 16:09 Juan: I will have it ready tomorrow, if not today
at least for testing
JuanDaugherty 16:09 vg
the app does some solicited streams so I can work with that and the windowing stuff which doesn't I think require any changes to fb
taxilian 16:09 sounds right
JuanDaugherty 17:09 \me *mrs. taxilian
taxilian 17:09 well, I'm done for today. I'll finish it up tomorrow