Hi Vijay, It sounds like reading up on NPAPI and how Windows applications paint is in order :)
Here are some documents: Here's the high level link about NPAPI on the Mozilla docs, links to samples etc: https://developer.mozilla.org/en/Plugins This is the reference for NPAPI: https://developer.mozilla.org/en/Gecko_Plugin_API_Reference Here's the MSDN page on GDI, which shows how to paint into bitmaps etc: http://msdn.microsoft.com/en-us/library/dd145203(VS.85).aspx I'll fill in a few answers below. On Fri, Mar 6, 2009 at 2:03 PM, eager_learner <[email protected]>wrote: > > Thanks John and Marshall. I have much work done in the lines of what > Marshall has suggested except that I did this in the plugin_list.cc as > opposed to plugin_list_win.cc. I got all my clues from the default > plugin. I am able to get the stream for the content-type as desired. I > just dont know what is available in terms of UI for me to display. > > At the end of my followup questions are things I have done [GOTO ABC > at the end of my questions] > > Q1. SetWindow entry point function similar to NPP_SetWindow gets > passed a parameter of type NPWindow > //static NPError SetWindow_metalink(NPP instance, NPWindow > *window) > a) How can this be used to display anything for the plugin? see the npapi documentation. depending on whether it's windowed/windoweless, you'll either have to run a message loop for the HWND, or you'll be called with an HDC (on windows) to paint. > > b) window->window is of type void* and is expected to be a > window handle. Can this be platform agnostic(Win32/Linux...)? Are no > > there Chrome API wrappers that abstract details of Windowing and > rendering? I would assume that this is part of Webkit. I have no clue > about this. Pointers to docs and smaple code highly appreciated. > > Q2. Regarding the archtecture document > > http://sites.google.com/a/chromium.org/dev/developers/design-documents/plugin-architecture,there > is > i. a browser process > ii. a rendering tab process and > iii. a plugin process > > Assuming that the Entrypoint functions are running in the plugin > process (??? correct me), how will the plugin process communicate with > the rendering process to > display what it needs to? you don't need to worry about any of this, it's all handled transparently. you just need to implement the NPAPI entry points. > The WebKit is shown to be part of the > rendering process. Does the plugin writer need to be aware of the IPC > mechanism defined in chrome > and if so where could I find that. > > Q3. What I would like to do is have a dynamically generated HTML page > with a table of items based on the stream that I get in NPP_Write > function. Can I summon the renderer via the NPWindow argument? Any no. but you can script the renderer. see NPObject in the NPAPI documentation. > > Example code for this? > > Q4. A general question I have on browser plugins is whether the screen > blitz is platform independent (Win32, Linux etc). no > Is there any > conditionally compiled code that plugin developers generally have for > display. This question is rephrasing Q1.b. > > Q5. Since I am working on the metalink plugin ["PoC"] as an internal > plugin, I will need the plugin-process to spawn threads > (chomeThread??) to download each piece concurrantly. Is there a > document explaining to developers API like ChromeThread etc? the documentation for the chrome classes is mostly in the headers. > > > Below is the summary of where I have reached. > > ABC: > //in plugin_list.cc in PluginList::PluginList() I added the following > #if defined (OS_WIN ) > #if defined (METALINK) > const PluginVersionInfo metalink_plugin = { > FilePath(kDefaultPluginLibraryName), > L"Metalink Plug-in", > L"Provides the starting point for Metalink > plugin to be > registered and called appropriately", > L"1", > L"application/metalink+xml", > L"metalink", > L"Something", > { > metalink_plugin::NP_GetEntryPoints, > metalink_plugin::NP_Initialize, > metalink_plugin::NP_Shutdown > } > }; > internal_plugins_.push_back(metalink_plugin); > #endif > #endif > > My Entrypoints for NPAPI are also defined > NPError API_CALL NP_GetEntryPoints(NPPluginFuncs* > funcs) > { > #if 0 > int * p = 0; > *p = 22; // my assert > #endif > funcs->version = 1; > funcs->size = sizeof(*funcs); > funcs->newp = newp_metalink; //NPP_New; > funcs->destroy = destroyp_metalink ; > //NPP_Destroy; > funcs->setwindow = SetWindow_metalink; > //NPP_SetWindow; > funcs->newstream = NewStream_metalink; > //NPP_NewStream; > funcs->destroystream = DestroyStream_metalink; // > NPP_DestroyStream; > funcs->writeready = WriteReady_metalink; > //NPP_WriteReady; > funcs->write = Write_metalink; //NPP_Write; > funcs->asfile = NULL; > funcs->print = NULL; > funcs->event = HandleEvent_metalink; > //NPP_HandleEvent; > funcs->urlnotify = URLNotify_metalink; > //NPP_URLNotify; > funcs->getvalue = NULL; > funcs->setvalue = NULL; > return NPERR_NO_ERROR; > } > > > > I am able to get the stream based on my content type and as of now I > write logs to a separate file. Below is the snippet > -------------------BEGIN LOG--------------- > newp_metalink >>> //NPP_NEW > SetWindow_metalink >>> //NPP_SetWindow > In SetWindow_metalink : Window is not NULL > In SetWindow_metalink : Window->window is not NULL > NewStream_metalink >>>//NPP_NewStream; > WriteReady_metalink >>>//NPP_WriteReady > Write_metalink >>>//NPP_Write > WriteReady_metalink >>>//NPP_WriteReady > Write_metalink >>>//NPP_Write > Got all the data. > DestroyStream_metalink >>>//NPP_DestroyStream > xmllen = [2675] > SetWindow_metalink >>> //NPP_SetWindow > In SetWindow_metalink : Window is not NULL > In SetWindow_metalink : Window->window is NULL > destroyp_metalink >>>//NPP_Destroy; > m has been reinterpreted appropriately. > In Destructor of metalink_session. > ----------------------------------------------- > > > Sincerely > Vijay > > > On Mar 6, 6:46 am, Marshall Greenblatt <[email protected]> wrote: > > Hi Vijay, > > > > Once you have your code linking with chromium, you have two options for > > registering your internal NPAPI plugin. > > > > 1. Add an entry to the builtin_plugins array in > > webkit/glue/plugins/plugin_list_win.cc PluginList::PlatformInit(). > > > > 2. Use the following approach that can be called from anywhere once > chromium > > has been initialized. > > > > A. Include the appropriate header. > > > > #include "webkit/glue/plugins/plugin_list.h" > > > > B. Create an instance of NPAPI::PluginVersionInfo populated with your > plugin > > information and NP function pointers. > > > > NPAPI::PluginVersionInfo info; > > > > info.path = FilePath(L"my_dummy_path"); > > info.product_name = L"My Product Name"; > > info.file_description = L"My Product Description"; > > info.file_version = L"1, 0, 0, 1"; > > > > info.mime_types = L"application/x-my-plugin"; > > info.file_extensions = L"*"; > > info.type_descriptions = L""; > > > > info.entry_points.np_getentrypoints = my_np_getentrypoints; > > info.entry_points.np_initialize = my_np_initialize; > > info.entry_points.np_shutdown = my_np_shutdown; > > > > C. Register the plugin information with the system. > > > > NPAPI::PluginList::RegisterInternalPlugin(info); > > NPAPI::PluginList::Singleton()->LoadPlugin(FilePath(info.path)); > > > > Finally, to the load plugin in an HTML page you use an embed tag like the > > following: > > > > <embed type="application/x-my-plugin" width=600 height=40> > > > > I recommend looking at the chromium embedded framework for a simple NPAPI > > plugin example and plugin development environment. > > > > http://code.google.com/p/chromiumembedded > > > > Regards, > > Marshall > > > > On Thu, Mar 5, 2009 at 11:59 PM, eager_learner < > [email protected] > > > > > > > > > wrote: > > > > > Hello Plugin Gurus > > > > > The following link is very well written and I hope it still holds good > > > > >http://sites.google.com/a/chromium.org/dev/developers/design-document. > .. > > > > > I have some followup questions on plugin development (internal) > > > > > 1. Based on the plugin architecture design document, can you point me > > > to an existing plugin (flash, shockwave, activeX) code file names? The > > > source Navigator project that I have created does not show any > > > inheritance of WebPplugin > > > > > 2. Again the debugging process seems a little difficult if new > > > processes are spawned (one for the browser, one for the renderer and > > > one for the plugin). How can we attach Visual Studio to the plugin? > > > > > 3. Do plugin writers need to know anything about the class > > > PluginInstance? It seems to create the WebPlugin or atleast gets > > > passed it and has a reference to it. > > > > > Simply put, what needs to be done by plugin developers to develop an > > > internal plugin? Does the NPAPI need to know about the PluginInstance? > > > > > Perhaps there is a clearer document that explains this. > > > > > Thanks > > > Vijay- Hide quoted text - > > > > - Show quoted text - > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
