IRC Log Viewer » #firebreath » 2015-03-20

IRC Nick Time (GMT-7) Message
kylehuff 07:03 I can finally register plugins built with VS2013 CE... I don't know what fixed it exactly, but I uninstalled VS2010 that was still hanging around.
taxilian 07:03 kylehuff: very interesting
that makes absolutely no sense to me at all :-P
that makes absolutely no sense to me at all :-P
you're up early
taxilian 07:03 kylehuff: so on the plugin scan thing I think what I'd love to see is just a function that returns a std::vector<WindowsPlugin>, where WindowsPlugin is a struct that contains a vector<string> of mimetypes, the plugin name, and a few other details. It should scan first HKCU and then HKLM
so you can put the function in a separate function at the bottom of the file for now; I may abstract it more later
heh. just found your pull request, didn't see it earlier
kylehuff 08:03 taxilian: yeah, I didn't mention the pull request here, as I had some touch-up to do this morning. the use of stringstream felt dirty to me, and while the alternative works, I'm not sure it is much better.
taxilian 08:03 how hard would it be to do a refactor to have it output as I described above?
how hard / do you have time?
kylehuff 08:03 shouldn't be hard. in addition to the fields you mentioned for the struct, I assume the path is also needed in there?
I should have time, other than baby sitting, I've got nothing going on today
taxilian 08:03 yes, definitely need the path =]
kylehuff 08:03 so, the same structure will be needed on all 3 platforms, right? what do you think about making it more generic, like "PluginInfo" struct, or the like, then the platform specific parts will just have their own method of collecting that information
taxilian 08:03 probably not a bad thought
way to think like a framework dev =]
kylehuff 08:03 haha... now if I only knew what a "struct" was... j/k =c )
taxilian 08:03 lol
kylehuff 08:03 do you see any issues with casting a char array to LPWSTR? i.e. (LPWSTR) lpData - I know little about windows wstring/wchar, other than they exist.
taxilian 08:03 yep
do not do that =]
do not do that =]
wstr is a 16 bit char format
if you look in the PluginLoader file there is already an example of how to convert string to wstring
if you look in firebreath in utf8_utils.cpp there are examples for both directions
it used to be kinda painful and we had to include an external lib to do it, but now c++11 supports it
it used to be kinda painful and we had to include an external lib to do it, but now c++11 supports it
kylehuff 08:03 ah, okay. I'll check it out.
taxilian 08:03 and in fact prefer using std::string and std::wstring wherever possible over using raw strings
kylehuff 08:03 does this look right for converting a LPTSTR to a string?
taxilian 08:03 looks reasonable. you know that you have to allocate the string for that to go in, right?
for RegEnumValue to write to, I mean
probably easiest to start out by defining a wchar_t buf[32767] and then use that for each string
just reuse for each call, I mean
kylehuff 08:03 yep, needs to be allocated.
gotta run to the market, I'll be out for 20m or so.
taxilian 08:03 'sfine
I'll be around most of the day, but I'll be working with a coworker on getting the FireWyrmJS stuff started
htaiwan 09:03 Hi everyone
kylehuff 09:03 microsofts documentation makes no sense to me. for this function, they say a particular parameter is a type of LPTSTR, but the compiler expects LPWSTR, and in their own examples they are using TCHAR...
taxilian 09:03 well, it helps if you know that those three things are, in this case, the same thing =]
LPTSTR = Long Pointer Type String (pointer to the type we are using for a string, which means TCHAR*)
what TCHAR is depends on whether or not UNICODE is defined
htaiwan: hello, we're not really ignoring you, just thinking about other things =]
kylehuff: So in this case, TCHAR is actually wchar_t
LPWSTR is specifically wchar_t*
so in this case they are actually all the same
kylehuff 09:03 mind blown... lol
kylehuff 11:03 taxilian: I've changed it to return a std::vector<PluginInfo>, where plugin info is a struct that has string name, description, path, vendor and std::vector<std::string> mime_types. but I'm thinking about the linux version. To get any about the plugin in linux, we will have to open it, so it makes sense to check if it is FireWyrm compatible at that step (while it is already loaded), so does it make sense to do that for Windows plugins as
taxilian 13:03 yes, it definitely does
yes, it definitely does
hmm; we could add a registry key to indicate that it's firebreath
hmm; we could add a registry key to indicate that it's firebreath
a "cheat"
kylehuff 13:03 okay, hmm.. the reg key might be less resource intensive, as that wouldn't require loading plugins, but we still have to do it on OSX and Linux (for each plugin found)
taxilian 15:03 well, OSX it could be in the plist
kylehuff 15:03 true
so, looking at the method "NP_GetMIMEDescription", it looks like it only returns a single mime type; do linux plugins not support multiple mimetypes?
taxilian 16:03 it returns a single string, with multiple mimetypes separated by ; I believe
kylehuff 16:03 ah, okay, no problem then.
kylehuff 16:03 okay, I just pushed up the proposed changes that return a struct... actually, it returns a PluginList, which is a std::vector template, and each item is a struct of PluginInfo. it is my first attempt at a template (and vector list of structs, for that matter), so it might actually suck. =c )
*pushed to the pull request
taxilian 16:03 lol. no worries, I'll take a look and see if I have suggestions
kylehuff 16:03 okay, I'll start on the Linux/OSX versions in the meantime.
taxilian 16:03 kylehuff: I may have some specific feedback later, but I don't see anything glaring wrong with it. I'm slightly unsure how I feel about extending std::vector, but I don't actually have a specific reason why that wouldn't be a good idea, it's more that I never considered it =]
I might change find_mime to findByMimetype and have it return an iterator
btw, one really nice thing with "auto" is instead of doing for(PluginList<PluginInfo*>::iterator it = this->begin(); it != this->end(); ++it) { you could do for(auto it = begin(); it != end(); ++it) {
as you're currently doing it you could even do a for (auto plugin : *this) to iterate (I think), but if I change to return an iterator then that won't work anymore =]
all in all, looks perfect. thanks! This saves me a lot of time
kylehuff 16:03 yeah, thats my fault, I was testing the code separate from firebreath using g++ on mingw, I forgot to move that one back to auto. I'll fix that, the name and see about returning an iter
taxilian 16:03 no problem, I just accepted the pull request
feel free to commit directly to the refactor branch for now
feel free to commit directly to the refactor branch for now
I can fix that; it's minor
kylehuff 16:03 okay, I'll leave it alone then. if you find anything wonky, I'd love to hear about it, I spent most the time reading about templates, which I still don't have a good grasp on
taxilian 16:03 I'm also going to change it to hold the PluginInfo object itself rather than a pointer to it. With c++11 it should be able to optimize out the inefficiencies with rvalue moving
actually, one more piece of feedback (and another thing you'll likely facepalm on)
the way you've written PluginList<T> it's not actually useful unless T is PluginInfo
so you may as well just do class PluginList : public std::vector<PluginInfo>
and this leaks memory because nothing is freeing any of those PluginInfo objects you allocated
but I'm sure those are things you'd have figured out if you actually were using it =]
LOL. so it turns out FireBreath doesn't actually register its mimetypes in the registry under MozillaPlugins....
but I can fix that
kylehuff 17:03 so, you are saying PluginList<PluginInfo*> to PluginList<PluginInfo> with "rather than a pointer to it"?
so, you are saying PluginList<PluginInfo*> to PluginList<PluginInfo> with "rather than a pointer to it"?
regarding how I wrote PluginList<T>, I wanted magic. I thought that is what templates are for? =c )
lol, you are right. in my test program I was dumping all the plugins and their mimetypes to cout, I didn't even notice that all FireBreath plugins were conspicuously absent...