IRC Log Viewer » #firebreath » 2010-10-19

IRC Nick Time (GMT-7) Message
taxilian 11:10 wow, quiet in here today
nitrogenycs 11:10 shhh, you'll wake them up
taxilian 11:10 lol
*sigh*. I slaved away all day yesterday to get the doxygen docs integrated properly, and now that it's done, nobody wants to ooh and ahh over it :-P
nitrogenycs 11:10 ahaha, I know that
taxilian 11:10 'course, if something like that is done properly, people don't realize that it's anything to ooh and ahh about
so that's probably an oblique compliment =]
taxilian 12:10 for any interested in better appreciating the genius (or the sheer ridiculousness, depending on how you look at it) of the documentation system on firebreath.org: http://colonelpanic.net/2010/10/integrating-doxygen-and-confluence/
elthariel 12:10 taxilian, oooooohh aaaaaaahh the doxygen doc
(what's the url :D)
taxilian 12:10 it's on firebreath.org
go to Documentation : Source Code Documentation
sorry, Source Documentation
elthariel 12:10 was a joke :)
taxilian 12:10 =]
sorry, I'm only half here today :-P
elthariel 12:10 me too
taxilian 12:10 thanks for oohing and ahhing apropriately =]
I have so far pretty much gotten no feedback at all on the class docs; not sure if that means that nobody has seen them, nobody cares, or that they are just so good nobody feels the need to comment
=]
NeilG 12:10 Hello!
taxilian 12:10 NeilG: that was fast =]
welcome
NeilG 12:10 It would have been faster, I haven't used IRC in years! :)
taxilian 12:10 lol
yeah, I hadn't much either
this channel has been surprisingly useful however
best kept secret, I guess; there are probably more people knowledgable about plugins in this chat room than are in communication almost anywhere else in the world, I'd bet
*possibly* excepting a few large companies that specialize in something plugin related
NeilG 12:10 It's a cool idea, I can see why it could be useful to have a chat room. We've just relied on forums instead!
So I can tell you that I've already found a possible solution
taxilian 12:10 I've thought about setting up a forum a few times, but so far the mailing list is pretty good
NeilG 12:10 From your email I think we've hit on the same solution
taxilian 12:10 and I just just only manage so many things at once
cool; tell me about it
NeilG 12:10 It looks like adding the MIME type to HKEY_CURRENT_USER\Software\Classes\MIME\Database\Content Type does the trick
taxilian 12:10 yes, but
the thing I'm not certain of
is how do you find out which mimetype was selected?
NeilG 12:10 It appears that IE can't parse multiple types separated by the '|' separator
taxilian 12:10 that is correct
that's very much a mozilla convention
NeilG 12:10 It gets passed in as a character array (if I understand your question?)
taxilian 12:10 really? where?
NeilG 12:10 Into NpapiPluginModule::NPP_New
taxilian 12:10 well, there, of course
but on IE
that is specific to NPAPI
never gets run on IE
NeilG 12:10 Oh, I see - I did misunderstand your question. :)
taxilian 12:10 let me clarify: I know exactly how to support multiple mimetypes on npapi; I haven't added support because I haven't clarified how to do it on activex yet
NeilG 12:10 I was going to ask the same of you, I'm not sure where the split between NPAPI and ActiveX is - so far I've done little more than scan the code and hack on it a little :)
amackera 12:10 taxilian: anything special i need to do to enable logging? I've added "add_firebreath_library(log4cplus)" to my ProjectConfig.cmake, but anything else I need to do?
taxilian 12:10 the split is very very clear in FireBreath
amackera: currently I think file logging is off by default
amackera: look in PluginCommon at log4cplus.cpp
amackera 12:10 ok
taxilian 12:10 Georg went over it and updated *a lot*, but I haven't had time to look at it yet
should be in dev
NeilG: everything in NpapiPlugin is npapi specific
everything in ActiveXPlugin is IE specific
everything else is generic
NeilG 12:10 Do you mean ActiveXBrowserHost?
I don't see ActiveXPlugin
taxilian 12:10 it's a project
it'll be prefixed
something like FBTP_ActiveXPlugin
ActiveXBrowserHost is in the ActiveXPlugin project
NeilG 12:10 Okay, with you
taxilian 12:10 so the main object we worry about in IE (or the root object, anyway) is FBControl.h
NeilG 12:10 Ah, that's very useful!
(to know)
taxilian 12:10 why thank you =]
I've tried to keep things fairly clean
so I can think of three ways this could work
NeilG 12:10 You definitely have, it's why I scanned through it and started hacking on it so quickly
taxilian 12:10 excelent. the newly added doxygen stuff should help even more with that
The first way is to add a CLSID for each mime type
and then set it up so that the CLSID gets passed into the contructor somehow
not sure how to do that or for sure if it is possible
I think it is, though
and if so, that would probably be idea
ideal
NeilG 12:10 Sure, I can see that
taxilian 12:10 the second way would be to add a CLSID for each mime type and have a templated version of FBControl that handles it
most likely possible, but if it is I would think option 1 would be as well
third way would be to try to get the mimetype from the DOM
I don't consider that to be a good solution because it seems like that is too late in the process to create the plugincore object
NeilG 12:10 Initially I was leaning more towards the third way because it seems the most similar to NPAPI but I hadn't considered the first two options before. I see your point though!
taxilian 12:10 I'm also not 100% certain that it is possible
and in addition, that adds an unneccesary requirement that we instantiate it specifically with a mimetype
instead of a CLSID
and there are some legitimate reasons why you would want to instantiate it with a CLSID sometimes
mostly for versioning
NeilG 12:10 Okay, that makes sense. I'm familiar with the NPAPI way of doing things, working with the ActiveX interface is definitely brand new to me (as of today!)
taxilian 12:10 trust me, it's a lot more painful
which is probably why I haven't gotten around to writing any blog posts about it like I did with NPAPI
when I really sat down and figured most of it out (some is still a little hazy), I did it in FireBreath
NeilG 12:10 It looks like it from the code! Although that could be observer bias because I'm familiar with NPAPI. :)
taxilian 12:10 and it's so much easier to use FireBreath for all of it that it isn't worth writing any of it by hand
even npapi
NeilG 12:10 Sure, it seems like it. I was looking at the interfaces I had to work with and it appears that everything is neatly contained in two classes for me to modify for each plugin instance. That's definitely respectable!
taxilian 12:10 that is the goal
I'm trying to figure out how this can be added while breaking as little backwards compatibility as possible
ideally with no breaking changes
seems like the "ideal" way to do this would be to do what you have done; pass the mime type into getPluginObject
that is a breaking change, though; if we do that, it *has* to go into 1.3. I don't want any more breaking changes after that
if it goes into 1.3, that pretty much means we have to figure it out this week
amackera, cygmatic: thoughts?
NeilG 12:10 Sure. I'm just looking through the code and reading documentation to see if there's any obvious way of getting the CLSID through the ActiveX interface
taxilian 12:10 let me see what I can do to help you get started
I have limited time today
if you open FireBreathWin.cpp
NeilG 13:10 Passing the MIME type through to _getPluginObject definitely made the most sense to me
Ok
taxilian 13:10 there is a DllGetClassObject function
that returns _AtlModule.DllGetClassObject(...
that's an ATL helper
NeilG 13:10 Yup
taxilian 13:10 it returns a class factory that is used to instantiate FBControl
somewhere in here is the place where it maps the CLSID to CFBControl
trying to remember where =]
NeilG 13:10 :)
taxilian 13:10 it's been awhile, since this part of the code pretty much doesn't change
one way would be to implement our own ClassFactory
that would probably do it
hmm. there is a guy working on writing an ATL-free version of this project; he could probably help a lot with this
too bad he's not here
NeilG 13:10 Damn. :)
taxilian 13:10 out of curiosity, where are you located?
NeilG 13:10 Out of MA, not too far north of Boston
taxilian 13:10 cool. I'm in UT
there are relatively few of us in the US in this room -=]
NeilG 13:10 Cool, my lead is from UT
I'm from the UK originally but I've been living in the US for about 2 years now
taxilian 13:10 how do you like it?
NeilG 13:10 I like it a lot. There are definitely some differences even in mentality but there isn't really a massive difference between the US and the UK
Mind you most of my experience is of New England so take it for what it's worth. :)
taxilian 13:10 I found basically the same thing when I lived for 2 years in Russia
NeilG 13:10 Probably the biggest difference - and probably true for you if you're in UT - is that Americans tend to think of distance in terms of time. So they don't mind driving an hour or 2 hours. But in the UK we definitely think of distance in terms of miles and a 60 mile drive is a pretty big thing!
taxilian 13:10 hehe. yeah, I did actually notice that
people always looked at me funny in Russia when I told them how far away something was from where I lived using time instead of distance
NeilG 13:10 Where in Russia did you go?
taxilian 13:10 Novosibirsk, Omsk, Irkutsk, Ulan-Ude, Krasnoyarsk, and Angarsk
NeilG 13:10 I've only been to St. Petersburg myself (but saw a lot through the train window on the way!)
taxilian 13:10 all within 50 hours of each other on the Railroad ;-)
NeilG 13:10 See? It blows my UK mind. :)
taxilian 13:10 hehe
here it is: FBControl.h line 262
NeilG 13:10 OBJECT_ENTRY_AUTO(__uuidof(FBControl), CFBControl)
?
taxilian 13:10 yep
that's what tells it to create a CFBControl for that UUID
NeilG 13:10 Right, I'm taking a look now
taxilian 13:10 https://gist.github.com/c8f2b6427995758272a3
that's what it is if you expand it out
NeilG 13:10 Here's a quick question for you - do you know how to debug with Internet Explorer?
taxilian 13:10 yep
NeilG 13:10 I have IE8, I open it and I see two iexplore.exe processes but attaching to either one doesn't seem to hit any breakpoints
taxilian 13:10 where are you loading the page from?
NeilG 13:10 On disk
taxilian 13:10 it will open another process for that
do you notice a yellow bar every time you load the plugin page for the first time?
NeilG 13:10 ...seriously?
Yes
taxilian 13:10 yeah
it has different security characteristics
what I normally do
is I wait for the yellow bar
and then I attach to all iexplore processes when it shows up
never had a problem with it that way
NeilG 13:10 Ah... that's a smart idea. I didn't realise that IE did that. I guess I can see why but... wow.
taxilian 13:10 good info here: http://firebreath.org/display/documentation/DebuggingPlugins
http://msdn.microsoft.com/en-us/library/ddfccbx7(v=VS.80).aspx
I think that'll let us make our own class factory
which in turn can create a CFBControl object and pass it the mimetype in question
we just need to create a map between the GUID and the mimetype
this is probably gunna take some CMake magic...
NeilG 13:10 Right - which I assume is something the fbgen.py script could do. Or would it take CMake?
taxilian 13:10 cmake
fbgen.py only runs once to create a skeleton projcet
cmake runs any time the project changes, if you're using it correctly
NeilG 13:10 Sure. I've used CMake before - and despite there being some things about it that annoy me it does do a good job
taxilian 13:10 yeah; it's probably the #1 criticism people have of this project, but that's because people really don't realize how much it hides for us
NeilG 13:10 It's a useful tool - I think it works better for this project because it doesn't try to do out-of-place builds (which I was)
taxilian 13:10 out-of-place?
NeilG 13:10 I can't remember the term they use but it's when you don't want any object files being in the directories with the source
taxilian 13:10 ahh
technically, we *are* doing that
NeilG 13:10 So you could, say, create an empty directory and run CMake -G "Unix MakeFiles" c:\path\to\source
taxilian 13:10 right
NeilG 13:10 And then I'd modify the CMakeFiles.txt and sometimes it would notice it would change... and sometimes it wouldn't
taxilian 13:10 the prep scripts basically do that
NeilG 13:10 It would always notice if I'd added or removed files but never did if I changed compiler directives
taxilian 13:10 huh
well, here is what I propose we do
create a Class Factory
use http://msdn.microsoft.com/en-us/library/ddfccbx7(v=VS.80).aspx
which means we need to implement http://msdn.microsoft.com/en-us/library/8bycx62d(v=VS.80).aspx
NeilG 13:10 Right
taxilian 13:10 then we need a good cmake-ish syntax for PluginConfig for defining multiple mimetypes
which should then get automagically made to work on both IE and firefox
which will probably require some less-than-pretty code generation with cmake, but what do you do?
if they only define one mimetype, we leave the function declaration as-is
NeilG 13:10 ...Cry? ;)
taxilian 13:10 yeah, sometimes :-P
NeilG 13:10 Sure, that all makes sense
taxilian 13:10 we create a #define that tells us it is a multiple-mimetype gig and use a couple of #ifdefs to determine which version of getPluginObject to use
maybe add a cmake check to throw out a deprecation warning
and life will be happy
oooh
useful docs
http://serious-code.net/moin.cgi/Scrap_2fComTutorial_2fAtlComponentHousingSupportWithObjectMap#head-985065f827996f487c488357dc7666c4cfbbe759
never expect that with ATL… nice when I find it
so.. what parts are you willing to do, and what do I need to do? =]
amackera 13:10 hm... seems like the logging modules are not accessible to the plugin?
like, i can't include the "logging.h" file
taxilian 13:10 amackera: you're on the latest dev?
where in the project? in your own?
amackera 14:10 yea
(to both questions)
NeilG 14:10 Hey, sorry for disappearing for a while
I was talking with my team about what needs to happen and how much time we have to get something implemented. :)
taxilian 14:10 NeilG: no problem. I'll get ot all of that… eventually. if you help, we'll get to it a lot faster =]
and you'll always be better off to be in sync with the trunk as much as possible
since things get fixed pretty fast when discovered
amackera: you may need to add PluginCommon to your include_directoriew
amackera 14:10 should that be done in PluginConfig.cmake?
taxilian 14:10 normally CMakeLists or projectDef would be the best place
but that should be added for all plugins
NeilG 14:10 Because we have such a tight schedule I'm going to go ahead and create 3 separate plugins for right now - it seems like it's the path of least resistance
However we'd definitely prefer to distribute just one DLL with our multiple plugin instances (if only to stop version mismatch nightmare scenarios!)
So I will definitely get around to this quickly - just not right away
taxilian 14:10 amackera: so cmake/projectConfig_main.cmake.in is really where it should go
NeilG: okay. I honestly think we could have this going today or tomorrow, but it's up to you
NeilG: also, to save time, I highly recommend you work on at least 1.2, probably 1.3 beta
I'm getting ready to put out 1.3 RC1 right now
the API shouldn't change much
NeilG 14:10 I'm using firebreath-dev-1.3-nightly-19
taxilian 14:10 ok; update to the RC when it comes out
shouldn't be any changes for you
amackera 14:10 taxilian: ok thanks
taxilian 14:10 no problem
let me know if you run into any problems
NeilG 14:10 For sure! I'll definitely do that. If that gets fixed today or tomorrow then we made a bad decision - the problem is we have two high-priority tasks to get done ASAP and I got pulled off one to work on the IE plugin
taxilian 14:10 without you I probably won't get it done today or tomorrow
I just don't have time by myself
and I have other things I need to work on
when you're ready to work on it, I'll help if we haven't gotten to it yet
NeilG 14:10 I have to try and get something working by the end of tomorrow - the worry is that we weren't sure this would work (or how much work is involved)
Okay, I'm definitely up for that
taxilian 14:10 good luck =]
NeilG 14:10 I really enjoy working on browser plugins, it's my kind of area. I will definitely get back to this - even if it's on my own time! :)
taxilian 14:10 this is your kind of chatroom, then =] don't be a stranger
NeilG 14:10 Thanks for all of your help - because I definitely think your idea is right. I think it's the best solution!
taxilian 14:10 and we always welcome suggestions
NeilG 14:10 I definitely won't be. FB and ColonelPanic were two fantastic resources because writing plugins seems to be a very undocumented arcane art!
taxilian 14:10 I'm glad it was helpful =] it means I haven't been wasting my time writing blog posts and frameworks ;-)
check out the new docs on the website and let me know what you think
NeilG 14:10 And yet we (my company) needed a plugin in order to get our games playable within web browsers - which has been well received in the serious games space
taxilian 14:10 cool =] Sleepless Software uses firebreath for games as well
NeilG 14:10 That's cool. I knew we couldn't be alone! I work for Muzzy Lane (http://www.muzzylane.com/)
The plugin is part of the Sandstone platform
taxilian 14:10 awesome. when you get things up, I'd love it if we could put a link on FireBreath's site; good advertisement for you, and it shows examples of what has been done with FireBreath
NeilG 14:10 Of course, we'll definitely do that. I'll email our web guy to remind him. :)
taxilian 14:10 sounds great =]
good grief; I'm putting together the changelog for 1.3
there are a ton of changes in there
amackera 14:10 lol
taxilian 14:10 good thing I decided to release it before finishing or it would be completely ridiculous
amackera 14:10 we're baking the windowless stuff for a bit, yes?
taxilian 14:10 amackera: yes; that'll be in 1.4
amackera 14:10 ok
NeilG 14:10 Okay, I have to disappear - but thank you SO much for your help. It's been really useful. I'll be back because I'd like to get supporting multiple MIME types working in IE! :)
taxilian 14:10 cool
cya
taxilian 14:10 amackera: do you have any thoughts on the multiple mimetype thing?
taxilian 14:10 check out the version history for 1.3.0 RC1: http://firebreath.org/display/documentation/Version+History
wow… forgot that InvalidatingCoreAnimation is new in 1.3
amackera 14:10 big release
taxilian 14:10 yeah
hadn't realized it had gotten that big
definitely time to release
amackera 14:10 as for the mimetype thing i wasn't really listening to the conversation
and consequently have no opinion hehe
aside: i totally have found a bug in windows XP home for TimerQueues
i think...
taxilian 14:10 What is a TimerQueue?
amackera 14:10 it's just a method of getting timers, without using SetTimer (and intercepting WM_TIMER msgs)
taxilian 14:10 huh
cygmatic 14:10 higher-res and more stable too
amackera 14:10 was using it with windowless plugins since there's no WM_TIMER message for them
cygmatic 14:10 and hi
amackera 14:10 hi :)
cygmatic: it seems to die for me on windows XP home
SP3
cygmatic 14:10 oh? that's news to me
taxilian 14:10 amackera: we can create a message window to use for windowless plugins
amackera 14:10 yeah that's the next step for me, i just want to make sure it's not something i'm doing
taxilian 14:10 ok, I hereby declare 1.3 features locked down
no more features go in
only bugfixes
the main repo is the 1.3 branch, dev is now 1.4
amackera 14:10 nice :D
i found this hotfix: http://support.microsoft.com/kb/951312
but i think it was included in SP3 so that might not be it
cygmatic 14:10 "To apply this hotfix, you must have Windows XP Service Pack 2 (SP2) or Windows XP Service Pack 3 (SP3) installed on the computer."
doesn't sound like it
amackera 15:10 hmm..
also, it might not be describing the problem i'm having
cygmatic 15:10 what problem are you actually having?
amackera 15:10 i have it in a mozilla crash report, let me just pull it up
http://crash-stats.mozilla.com/report/index/b0bdc6ff-843d-411e-8f77-c97102101019
any ideas?
cygmatic 15:10 hm, not all that informative :|
amackera 15:10 yeah
cygmatic 15:10 your dll is active on 2 threads though - intentionally?
amackera 15:10 yes
cygmatic 15:10 i have no idea about it from that, sorry
amackera 16:10 well it crashes even when i do nothing inside of the timer callback
and when i remove the timer callback it doesn't crash
my conclusion is that TimerQueues are busted in winXP
cygmatic 16:10 and if you sleep a bit inside the callback?
cygmatic 16:10 hm, leosamus problem with relative library paths seems to be a CMake one, $ORIGIN seems to work fine in a simple test-app
amackera 17:10 still dies
i slept for 500 milliseconds
cygmatic 17:10 that is strange, maybe you have some concurrency issues with the timers? maybe you delete a timer/queue prematurely?
amackera 17:10 hmm
actually that could be it...
no that's not it either
cygmatic 17:10 can you reproduce it in a minimal shareable test-app?
amackera 17:10 good idea, let me try
amackera 17:10 as an alternative, since i am creating an offscreen window to render openGL with, i could set up a timer with that HWND, right?
cygmatic 17:10 sure
or just create an invisible dummy window for timers
amackera 17:10 do you have any good docs for how to set up a winproc to intercept WM events? I'm totally lost with what i can find on the msdn
ahh i can register my own window class
and in that class struct i specify the winproc?
this must be in the FB source somewhere for windowed plugins
whoa
my mind is being blown
we already do this for windowed plugins?
awesome :D
cygmatic 17:10 yep, there is an example somewhere in FB ^^
amackera 17:10 kinda nasty, need to keep a static window map
cygmatic 18:10 taxilian: I know i'm picky, but why FB::wstring_to_lower(const std::wstring&) instead of FB::to_lower(const std::wstring&) and letting overload-resolution do its job?
cygmatic 18:10 hm, i guess we can't force doxygen to include documentation for functions that are not actually declared anywhere?
taxilian 18:10 cygmatic: we can rename wstring_to_lower
that's just the name it was in Facebook's stuff
on the undeclaired functions thing, I'm not sure what you mean
cygmatic 18:10 i tried to fake a nicer entry for make_method(), but it didn't show up in the docs
as there was no such function declared, i just made it up to look good
taxilian 18:10 cygmatic: the docs only update every night
so let me run the update and see if it changed anything
cygmatic 18:10 overloaded function also show up with an empty description
i generated it locally of course
before i mess up the confluence docs...
taxilian 18:10 ahh
you mean overloaded in a child class?
cygmatic 18:10 nah, just overloaded free template functions
taxilian 18:10 ahh
have you tried using @overload?
cygmatic 18:10 e.g. make_variant_list
taxilian 18:10 it just puts a "this is a convenience overload function" thing on it
cygmatic 18:10 that doesn't apply, they do different things
at least one of them
taxilian 18:10 you should be able to specify docs for each on e
cygmatic 19:10 well, i tried ;)
taxilian 19:10 heh. fair enough =]
there are definitely some things that I haven't been able to get to work as I would expect either
and oddly there are no error messages
amackera: any chance you could add docs to your mac PluginWindow objects?
cygmatic 19:10 i like doxygen in principle, but i sometimes feel like its one giant hack ^^
taxilian 19:10 hehe. yeah, it probably is
but it's still a lot less work than doing it all ourselves
and the way it is set up now, we can mix the two
the one thing I'm not really happy with is the naming of the pages
but since you can't have multiple pages with the same name (even under different parents) in Confluence, I don't know what to do about that
cygmatic 19:10 hm, the template part in the pages is rather hard to see: http://firebreath.org/display/documentation/namespace%20FB%20make_variant_list%20%283%29#ab670c112ba7d05db5529feb141889532
taxilian 19:10 I'll tweak it
I started to, but then got side tracked
cygmatic 19:10 ok, thanks
taxilian 19:10 try now
cygmatic 19:10 much more readable, but could be a bit bigger
taxilian 19:10 let me change it to monospace
that seems to look better
refresh?
cygmatic 19:10 i don't see a difference ^^
taxilian 19:10 did you shift-reload? the color is the same, but the font should be different
cygmatic 19:10 yep, at least it doesn't look different to me
taxilian 19:10 interesting
maybe that's a mac only font? didn't think so
how about now?
cygmatic 19:10 ah, yes
that looks different
(and i'm on osx too as mostly)
taxilian 19:10 weird
cygmatic 19:10 aha, the overload problem wasn't one - doxygen doesn't create detail pages if you only have @brief
taxilian 19:10 ahh! that explains it
hmm
if repeat_brief or whatever is turned on, does it?
seems like I turned it on, but maybe not
cygmatic 19:10 i can't find anything like that
taxilian 19:10 hmm. it's REPEAT_BRIEF
but it is on
cygmatic 19:10 what i also find confusing: there is a "structs and classes", but no "functions" and no "typedefs"
and i still don't get why "namespace DOM" is broken
taxilian 20:10 functions and typedefs go inside namespace DOM
what do you mean by broken?
oh, rihgt
right
yeah, I'm not sure why it does that either
sorry, they go in namespace FB
the functions and typedefs
http://firebreath.org/display/documentation/namespace+FB
cygmatic 20:10 yeah, just wondering why it has a global "classes and structs" but nothing similar for functions and typedefs
taxilian 20:10 it would make more sense if you look at the generated XML file
also understand that I could seperate classes and structs if I wanted
it's just a config option in the python script I wrote
I think ALWAYS_DETAILED_SEC may fix the issue with nothing being generated when there is only a @brief
cygmatic 20:10 ok, just wondering... if its not easy to do forget about it
taxilian 20:10 I can look; I could possibly extract the typedefs and functions out
my guess is that when we start adding groups I'll want to add some features to better support that as well
ok, fixed the problem where sometimes nothing gets generated when there is only a @brief
it will just use the @brief as the detailed description if there is no detailed description
cygmatic 20:10 cool
taxilian 20:10 cygmatic: so you'd like a "Global Functions" section and a "typedefs" section?
cygmatic 20:10 personally yes, but as i said, its not a must have :)
taxilian 20:10 give me a few minutes ;-)
actually; while I work on the code, could you create the wiki pages they should go under?
(next to Classes and Strucutres, Files, and Namespaces)
do you want something for enums as well?
and what about global variables?
cygmatic 20:10 rather constants or globals?
so you get all of these?
taxilian 20:10 hmm. good question; constants. not sure if those even find their way in
ahh, they do
but only in source code files
looks like inside a namespace I get "typedef", "function", "variable", and "enum"
cygmatic 20:10 hm, i added Functions and Typedefs for now
pointing to http://classdocs.firebreath.org/patched/functions.html and http://classdocs.firebreath.org/patched/typedefs.html
taxilian 20:10 ok; I'll leave the others in namesapce
hmm. I don't really have a source for functions and typedefs as a primary page
there is this: http://classdocs.firebreath.org/functions_type.html
for tyepdefs
but it's not quite complete
so I can put them under the page
but I don't have an auto generated page for listing them
cygmatic 20:10 doesn't really hurt :)
taxilian 20:10 yeah
just letting you know =] we can put a custom page there
cygmatic 20:10 ok, so no html-include there for the moment
taxilian 20:10 we could hypothetically create a xslt stylesheet to generate one at some point
and now to see if I coded it right...
taxilian 20:10 cygmatic: http://firebreath.org/display/documentation/typedef+FB+JSAPIPtr
http://firebreath.org/display/documentation/enum+FB+FBKeyCode
that is still in the namespace scope
this is a definite improvement; good idea
and very easy to link to everything: http://firebreath.org/display/documentation/JSAPIAuto
taxilian 21:10 cygmatic: just for you, I fixed namespace DOM
the main problem is that it should have been namespace FB::DOM
http://wiki.firebreath.org/display/documentation/namespace+FB+DOM
dries_staelens 22:10 Hi taxilian
I have a question about axutil.cpp
taxilian 22:10 dries_staelens: awesome. I have a question for you as well =]
was hoping to see you
dries_staelens 22:10 would it be ok to just remove the _MSC_VER macro condition?
taxilian 22:10 for what purpose?
dries_staelens 22:10 to remove the dependency on AtlSetPerUserRegistration()
taxilian 22:10 for what purpose?
dries_staelens 22:10 The else case of the macro is ATL-independent
I was working on removing ATL dependency, remember?
taxilian 22:10 right
it will become irrelevent when you do
what that does is redirects the .rgs registration code to HKCU instead of HKLM
the .rgs code is ATL dependent
dries_staelens 22:10 ok, i see
taxilian 22:10 so once there is an alternate way to register in some .rgs-like friendly way that doesn't require ATL, we will then no longer need axutil.cpp
until then, it needs to be in there because if you remove it it breaks WiX =]
dries_staelens 22:10 I've basically removed all ATL dependency except the registry stuff
taxilian 22:10 really? awesome!
is it in a clone somewhere where I can see it?
I would love to have that in 1.4, if possible
dries_staelens 22:10 so WiX requires the .rgs scripts?
taxilian 22:10 no
(sorry, needed to put my wife to bed =])
WiX has a tool called heat
that (if I understand how it works correctly) runs DllRegisterServer and captures all the registry operations that are perfromed
and writes an XML file that can then be used with a WiX installer to write a MSI that does the installation so that you don't have to self-register (which is considered bad practice in an installer)
the problem is that if we redirect the registry the way we do in axutil.cpp in VS2005, it breaks heat
so currently the WiX installer only works on VS2008 and later
however, whatever we come up with that is not ATL-dependent won't have to redirect the registry, so it should work on all compilers that can build firebreath
which will be awesome
dries_staelens 22:10 I'm asking our WiX guy
So it would be ok to do everything explicit in dllregisterserver?
I mean instead of reading an .rgs file or some other script, it's ok to put everything there hard coded
taxilian 23:10 well
we really need a way for users to customize it
I would prefer some sort of script :-/
dries_staelens 23:10 oh, i see
ok
taxilian 23:10 though I'm willing to consider alternatives to .rgs
I've been looking and I can't find anything pre-made for what we need :-/
I wonder how expensive a c++ json parser is
a format like json would be really easy to parse, is fairly easy to read, and could still be compiled as a resource
also could be well documented by us (whereas .rgs is definitely not well documented in easy to find places)
I dunno. what are your thoughts?
please note that I'm always open to counter arguments
dries_staelens 23:10 I'll look around and see what exists already
taxilian 23:10 any chance you could put what you have in a clone or something so I can look at it?
dries_staelens 23:10 I'll grab some lunch first, ttyl
taxilian 23:10 ok; I'll be in bed when you get back
something to consider; we're going to need to support creating FBControl with multiple CLSIDs, each for a different mimetype
I'm trying to decide the best way to do that with what we have, but if your stuff is closer then we can wait for that
dries_staelens 23:10 ok, i'll try to make a clone or something so you can look at it, i haven't figured out hg yet, so it'll take a while
taxilian 23:10 would you like the 30 second tutorial?
dries_staelens 23:10 yeah, i've read on the mailinglist about the multiple mime thing
i have turtoisehg
taxilian 23:10 go here: http://code.google.com/p/firebreath/source/clones create your clone. Check it out, move your changes into it, commit. remember that when you commit, it only commits locally. push your changes to the server
dries_staelens 23:10 my code might break stuff, so I'm not feeling comfortable putting that in there yet
or is it ok for you?
taxilian 23:10 that's why you create a clone
dries_staelens 23:10 oh wait, i get it
taxilian 23:10 it doesn't go into the main repo
but I can pull the changes — along with the history — in when they are fully baked
dries_staelens 23:10 great
I'll do that
taxilian 23:10 awesome. thanks for the update
where are you located?
dries_staelens 23:10 singapore
taxilian 23:10 figures. everyone that I want to talk to tends to be on a time zone where we're never both at work
keep me updated =] enjoy lunch