IRC Log Viewer » #firebreath » 2011-08-17

IRC Nick Time (GMT-7) Message
dodo_ 08:08 anyone know how to make browsers reload the plugins once a new plugin is installed?
dodo_ 08:08 does any one know if calling navigator.plugins.refresh(false); on every page load is good / bad practice? performance issues? etc..
taxilian 11:08 FireBreathBot: tell dodo_ navigator.plugins.refresh(false) is standard practice; see fb_installer.js in the firebreath codebase
FireBreathBot 11:08 taxilian: I'll pass that on when dodo_ is around.
taxilian 11:08 FireBreathBot: tell dodo navigator.plugins.refresh(false) is standard practice; see fb_installer.js in the firebreath codebase
FireBreathBot 11:08 taxilian: I'll pass that on when dodo is around.
Apologet 11:08 Hello
taxilian 11:08 hello
dmg10 11:08 Visual studio and intellisense is sooo slow.
taxilian 11:08 heh. yes, yes they can be
you can turn off intellisense if you want
dmg10 11:08 i'm going to go mad, i'm not used to this. I'm using Visual Studio express... where do I turn it off? Google said I can rename a file feacp.dll. is there an easier way?
taxilian 11:08 hmm. I know how to do it in vs pro, but not sure if it's the same in vs express
dmg10 11:08 U're not for higher are you?
taxilian 11:08 you mean for hire?
as in, do I do subcontracting work?
dmg10 11:08 oops, yeah
taxilian 11:08 sometimes; depends on the scope of the project you need and how busy I am
and of course how much you're willing to pay =]
dmg10 11:08 hehe, of course. Well, if you remember it's for adding a shared webbrowser to a plugin. It's potentially an important piece of this startup I'm creating.. but there may be other ways of doing it too (slopier). It's a shoe string budget but at some point it's probably worth outsourcing, and freeing up my time to work on the server.
taxilian 11:08 ahh, I remember seeing you talk about that, but you were gone when I got back
oh, wait; then you came back
and we talked
it's coming back now :-P
so could you clarify why it is that you have to have only a single web browser instance? what problem are you actually trying to solve?
dmg10 11:08 I've had to read up about COM, NPAPI, windows gdi, visual studio tuning, boost shared pointers and just refamiliarize myself with C++
It's not that I can't get there... but is it worth it? :)
taxilian 11:08 lol. believe me, I know what you mean; I think I have 5 or 6 different books on COM, and I still don't feel like I really understand all of it
dmg10 11:08 one sec.
The problem is as follows: I'm trying to create a toolbar where the entire toolbar is a browser. The content for the toolbar is downloaded from our servers.
taxilian 12:08 and you know you can't create browser toolbars using an NPAPI plugin, right?
dmg10 12:08 The content includes advertising... and it's important on browsers like Chrome and IE that content is not being pulled and advertisers charged when the toolbar is offscreen.
Yes, I know that.... but
In chrome there is no way to officially create a toolbar
So you need to inject it per page.
That's how Aljazeera's news bar and stock ticker add-ons work
taxilian 12:08 *shudder*. that sounds potentially… problematic. in short, the idea scares me to death
dmg10 12:08 I know... I didn't make up the rules :(
On IE.... no injecting required.
but each toolbar is part of the process that the tab belongs to
So similar problem.
taxilian 12:08 err, that's a ver different problem, actually
NPAPI plugins are always created as part of the same process
so they can share memory
dmg10 12:08 yes
taxilian 12:08 if IE toolbars are each in a different process, you'll have a heck of a time trying to share that
dmg10 12:08 If they embed the same ActiveX control, then the control would be synced.... even if the toolbars were separate... isn't that correct?
taxilian 12:08 most likely, yes
fair point
dmg10 12:08 That's why I said IE and chrome are similar.
Firefox is easy, you just embed the Gheko browser... no npapi plugin required.
Safari looks the same, but haven't tested if they let you embed the browser in the plugin.... it looks that way though, given the NY Times toolbar.
taxilian 12:08 now why is it that they absolutely have to be shared?
wouldn't each having its own copy work?
dmg10 12:08 Advertisers would be overcharged... no1. But on chrome, it means that each tab would require downloading a new webpage.... It would be much more spritely if it was only downloaded in the plugin and (almost) immediately appeared when a new tab was opened.
taxilian 12:08 hmm.
any luck finding a way to scrap HWNDs?
dmg10 12:08 I agree the Chrome solution is ugly...
Haha... I'm nowhere near at that point. I'm still struggling just using the WebView that is there :)
Managed to instantiate it, but loadUri() isn't working for me. I'm obviously doing something wrong
taxilian 12:08 well, it's still a very new library; completely undocuments
and only used in one project
dmg10 12:08 Oh... it could be me... I'm tripping up on all sorts of things. Love your vid docs by the way.
taxilian 12:08 glad you've found them useful
which ones have been the most helpful?
(and why? I'm debating doing some more)
dmg10 12:08 I think in general the ones where you are doing stuff, is more useful than your youtube vids explaining NPAPI.
taxilian 12:08 yeah; the npapi ones are more to help people understand how the framework works
so your vote would be more coding demonstrations, huh? =]
dmg10 12:08 Well, for someone in my position... of course I'm biased.
Can't wait to get back to Eclipse and GWT
taxilian 12:08 lol
dmg10 12:08 What tools did you use to produce them just by the way?
taxilian 12:08 the first ones I used Jing; I'm now using camtasia thanks to a generous donation of a license
dmg10 12:08 Oh right, I saw they were hosted on Jing... so it's a recording solution too I guess.
taxilian 12:08 it's limited to only recording 5 minutes at a time, which makes things a bit challenging
but it also helps force you to keep things short, so that can be nice =]
dmg10 12:08 Well, have a think about it, I don't mind plowing ahead for a while and see how far I get. I'm learning and relearning at the very least.
Obviously you either have some time or you don't. And you have your price.
taxilian 12:08 yep. I am looking at the possibility of setting up a company to do firebreath work; porting plugins, development, testing, the works. it's at least a month or two away, though; we'll see
I need to have some people besides just me, though
dmg10 12:08 ooh, that sounds interesting. Would that be a full time thing then?
taxilian 12:08 no, but if there were enough work we might end up with someone that would be full time and I would work with them to make sure things were done right, etc
dmg10 12:08 Yeah. I can see you're very thorough. Very sensible abstractions... in just the right places.
taxilian 12:08 I'm glad you approve =] I've tried to make it so; I have some improvements in mind, there is the possiblity of a 2.0 version in the next 6 months
dodo_ 13:08 does any one know if calling navigator.plugins.refresh(false); on every page load is good / bad practice? performance issues? etc..
FireBreathBot 13:08 dodo_: 17:32Z <taxilian> tell dodo_ navigator.plugins.refresh(false) is standard practice; see fb_installer.js in the firebreath codebase
dodo_ 13:08 @taxilian: when i install my plugin using MSI or any other exe installer and the broswer is already open, how do i get the browser to load the plugin?
taxilian 13:08
nirvdrum 13:08 Whoa. When did we get a forum?
taxilian 13:08 lol
umm… 4 or 5 months ago?
I don't remember
nirvdrum 13:08 I feel like I knew this once before.
taxilian 13:08 April 2, looks like
nirvdrum 13:08 Dunno.
taxilian 13:08 you dropped off the face of the planet for awhile
nirvdrum 14:08 It's been crazy. I try to help out with email moderation.
taxilian 14:08 hehe. oh, I'm not complaining (much ;-)). It's good to have old faces around, but I know how things go. I'll take whatever help I can get, whenever I can get it
dodo_ 14:08 where do i find the ActiveX GUID id for my plugin? does this change when i recompile or run prep command?
taxilian 14:08 no, it's in PluginConfig.cmake
it's the FBControl_GUID
dodo_ 14:08 thanks
taxilian 14:08 yw
dmg10 15:08 taxilian: So precompiled headers aren't used? I see includes in some places.. but in the project settings that I checked, most of them are off. Is this a cmake thing?
taxilian 15:08 precompiled headers are used, but not in the standard visual studio way
and yes, it's kinda a cmake thing
cmake doesn't directly support precompiled headers
dmg10 15:08 ok, so visual studio (intellisense) won't get faster by turning it on
taxilian 15:08 ? it would be faster if you turn it off
but you need to turn indexing off, not just intellisense
dmg10 15:08 I don't know what I'm talking about.
But I read this:
which seemed to indicate that correct use of them speed up both build and intellisense times
taxilian 15:08 ahh. well, unfortunately there is not currently (that I know of) a way to turn on regular PCH with visual studio
and I misunderstood your question
dmg10 15:08 oh the joys of cmake
taxilian 15:08 hehe. well, like I tell everyone else; if you can find a good replacement, I'll consider it =]
dmg10 15:08 i think the most fustrating thing about it is that commands populate variables that you just have to know about. Wish it had been written in python or something.
or rather just predictably :)
taxilian 15:08 heh. it's pretty predictable, actually, you just have to know the rules
there are really only a few native cmake commands that do that
the really confusing ones are all cmake addons
dmg10 15:08 I also don't really have a sense of orderings... and impacts. I put the add_firebreath_library() in PluginConfig.cmake, at the bottom because I saw it in one of the examples.
but I don't really have a sense that that's the right place for it.
taxilian 15:08 that's not cmake; that's FireBreath
and it is actually the right place for it
that's on the list of things I'll probably change when/if I do a 2.0
dmg10 15:08 fair enough. I'm sure it's all my ignorance.
taxilian 15:08 not so much your ignorance as that FireBreath's cmake stuff is not adequately documented
so please feel free to ask questions when you have them
dmg10 15:08 Also I added the ATL includes to the WebView cmake.
taxilian 15:08 and feel even free-er (it's a word, I promise :-P) to put my answers on the wiki somewhere
dmg10 15:08
When I worked for corporates I would answer emails on the wiki and send them a link. They didn't like that.
taxilian 15:08 lol
dmg11 15:08 The problem is that what you wrote on it isn't highlighted.
taxilian 15:08 hehe. yeah; I get emails when the wiki is updated, so it's easy for me to see what changed =]
dmg11 15:08 So they wouldn't easily identify what you wrote and prefered the email. Tried to think up a webservice that would allow me to send highlighted content on pages(without caching) from a link... but it was quite hard... gave up
But confluence just sends a copy of the page... no?
taxilian 16:08 yes
with the part highlighted that changed
a diff, basically
but you have to be subscribed
dmg11 16:08 oh... that must be new
taxilian 16:08 don't think so
but I could be wrong
it's not easy to figure out how to do =]
dmg11 16:08
I wrote the same kind of thing for wikipedia
never kept it up to date though
Woohoo... I got WebView working... yeah... it's obvious in retrospect that I had to pass through the onWindowAttach/Detach calls (sheepish).
taxilian 16:08 lol
not neccesarily
what isn't obvious is what is getting you this time
though it's even less obvious on windows
what you really want to do is in the onWindowAttached event create the WebView object and then add it as an observer to the window
!find AttachObserver
FireBreathBot 16:08 Found 2 possible matches. Displaying 2
/^void PluginEventSource::AttachObserver( PluginEventSinkPtr sink )$/ (f) found in src/PluginCore/PluginEventSource.cpp:
/^void PluginEventSource::AttachObserver(FB::PluginEventSink *sink)$/ (f) found in src/PluginCore/PluginEventSource.cpp:
dmg11 16:08 And there you go spoiling my fun ;)
taxilian 16:08 hehe
so here is how it works, and this isn't documented either
PluginEventSource is a subject; PluginEventSink is an observer
PluginCore extends PluginEventSink
and PluginWindow extends PluginEventSource
… so ...
the reason that PluginCore gets the AttachedEvent from the PluginWindow is that it is attached as an observer
if you attach the WebView to the PluginWindow (it is also a PluginEventSink) then it will get that and all other events
this is a really nice way to abstract your view from your model or controller, if you want to think of it that way, because your controller (the plugin class) can simply make calls on the view (WebView) to tell it what should happen and the WebView will take care of all of the drawing
because it will get events directly from the PluginWindow
on Windows this isn't a real big deal, but on Mac it has to translate all of the mouse and keyboard events; with this architecture we just tell the WebView to handle all of those events from the PluginWindow and PluginCore doesn't have to worry about any of it
(ironically, this has been the way this is all set up since the very beginning; I just have never documented it)
dmg11 16:08 digesting
taxilian 16:08 =]
if you are familiar with the Subject : Observer design pattern this will make more sense
dmg11 16:08 Is that like pub/sub
taxilian 16:08 yes
I think it's basically the same pattern, just a different name
or at least the same in function
dmg11 16:08 yeah, just need to map it mentally onto classes before I can ask silly questions
taxilian 16:08 !findfile PluginEventSource.h
FireBreathBot 16:08 Found 1 matching file(s) in the master branch. First 1 are:
taxilian 16:08 !findfile PluginEventSink
FireBreathBot 16:08 Found 1 matching file(s) in the master branch. First 1 are:
taxilian 16:08 if you're interested in looking at the source, the base classes are there
dmg11 16:08 They're in my Visual Studio project too, in the PluginCore :)
easier to look at there
taxilian 16:08 hehe
dmg11 16:08 It's not like it's a packaged dll.... I have been exploring the projects cmake created
"packaged dll".... you can tell I live in java land :)
taxilian 16:08 lol
dmg10 16:08 Ok, so you're saying it's not necessary to forward individual events. (onWindowAttached/detached). Instead I have the WebView set up as a direct observer of the PluginWindow. But to do that I derive WebView (or edit the source) and set up an EventMap in that class directly.
taxilian 16:08 no no no
I'm saying that WebView is *already* set up to do that
you just have to add it as an observer
so in the AttachedEvent handler in your plugin class, something like win->AttachObserver(m_webview);
dmg10 16:08 oh ok... but I got the concept regardless... (except that I forgot it's already set up)
taxilian 16:08 and it will then fire the attachedevent for you
and then in detachedevent you'll want to remove the observer
dmg10 16:08 got it, got it.
I remember seeing event maps in MFC. It's like deja vu.
taxilian 16:08 hehe. this is loosely based on that
you could actually do the code yourself if you wanted; the macros are pretty simple
dmg10 16:08 discovering an api is like looking though a misted window of your car while the demist is on.
taxilian 16:08 and since these aren't well documented… well, it starts out mistier than usual
dmg10 16:08 but that's strange then isn't it
given that I only passed through the onWindowAttached arguments.
wouldn't expect it to be functioning because it wouldn't be subscribed to the window.
taxilian 17:08 the windows one doesn't actually need anything other than the attachedEvent
it's on Mac that it needs more
and it might need more sometime in the future
just doesn't now
dmg10 17:08 ok, so the window param that was passed thru in attachEvent is all the COM object actually needs
and doesn't need the events.
taxilian 17:08 yeah
for now
dmg10 17:08 So the essay was really about future proofing my code ;)
taxilian 17:08 no
it was about understanding how the event model works
and about understanding how this is set up to work
and why
dmg10 17:08 respect
taxilian 17:08 the primary effect at the moment is to future proof your code =]
dmg10 17:08 :)
taxilian 17:08 also now that it's in the logs, people can maybe find it
and perhaps eventually someone like kylehuff will get bored and throw it on the wiki
(he does that sometimes)
dmg10 17:08 For a small project, you got better documentation than Google
taxilian 17:08 heh. it's not terrible; there are just lots of things that aren't there. Most people who have problems don't use the search feature of the wiki
dmg10 17:08 I think the wiki is great for tutorials. And the vids are great. But like that pub/sub explanation might be better in the code.
taxilian 17:08 yeah; mainly the reason this hasn't been documented yet is that it's not actually neccesary to know what is happening. it's just convenient
dmg10 17:08 Well thank you for taking the time now to help me out all the same
taxilian 17:08 np
dmg10 17:08 If you attachObserver(webview instance) in the Plugin::AttachEvent handler, then how do you know that the WebView::AttachEvent handler will be called? Won't the event get lost? Just my ignorance, but doesn't this happen when the PluginWindow becomes available? or is an AttachEvent specifically when created when AttachObserver() is called?
taxilian 17:08 actually, it happens when the observer is attached; it fires an attachedevent on any observer after it attaches
and a detachedevent right before it detaches
dmg10 17:08 oh ok
I was thinking that the event was more os/browser centric. Coming from some wrapped Window object.
taxilian 17:08 the event itself is not, though it is called in response to a os/browser event
because the PluginWindow object is created in response to the browser giving us a window
and then as soon as we have it, we attach it
dmg10 17:08 ok, I think I remember you talking about this in the plugin life cycle.
Late at night here in South Africa. Thanks for the help. Later.
taxilian 17:08 good luck
Skype 17:08 taxilian: Raised for getLastError implementation as discussed
FireBreathBot 17:08 FIREBREATH-117: Summary: Improved Exception Reporting In JavaScript
FIREBREATH-117: Assigned To: richard
FIREBREATH-117: Priority: Minor, Status: Open,
taxilian 17:08 skype: yeah, I saw it; I just haven't had time to do much on improvements recently
I think that will change early next month
Skype 17:08 Wondering should have raised that as a bug instead?
taxilian 17:08 no; it would just have been changed by me to an improvement =]
I have a hard time calling it critical
though if you want to fix it yourself I'll help you figure out what tod o
Skype 17:08 The FB::WinMessageWindow is awesome, an optional parameter in the constructor ie FB::WinMessageWindow(bool createAsTopLevel = false|true) would be nice, what you think?