I have found that there are plenty of frameworks for browser plugins.
my first question:
which one of the following frameworks specified for plugins and which one is not specified for plugins:
FireBreath, OpenForge, Kango, BabelExt, Nixysa project, JUCE project, QtBrowserPlugin project .
my second question:
Is there another popular plugin's framework other than those mentioned?
my third question:
What is the main differences of these popular plugin's frameworks?
Indeed is there any comparison of these frameworks, the comparison could be in each of following terms:
usability (for a page as a NPAPI plug-in or for a browser as an
add-on extension),
simplicity (in developing),
speed (on execution),
extensibility (of developed add-on),
availability (in Windows 86x and 64x, Unix, Linux, mac and other
platforms and also mobile platforms specifically android, ios, ...),
flexibility (for new technologies),
reliability (in terms of security),
accessibility (open source or not),
portability (in Fire-fox, chrome, IE, Safari, Opera, ...),
applicability (in drawing, communicating, calling from external
server, threading, network accessing, etcetera),
stability (in changing the policies, for example in deprecating
NPAPI)
Also I have read Cross-Browser Extensions API? which I think it is about extension's framework (not plugin's framework)
I'll be honest -- this seems like something you should be able to answer with some google searching. I appreciate that you're at least trying to apply suggestions on how to better ask questions, though, so I'll respond on the few that I know something about.
FireBreath is a C++ framework for creating browser plugins, not extensions. It works as an NPAPI plugin for browsers supporting NPAPI plugins (previously this was all but IE, but Chrome dropped support for them this year and Firefox plans to at the end of 2016) or as an ActiveX control, giving it equivalent functionality to a browser plugin in Internet Explorer. FireBreath 2, which is working but poorly documented so far, changes the APIs from being synchronous between the browser and plugin to being asynchronous and adds an emulation layer to let them work with Google Chrome using Native Messaging. It's the most complete and up to date of the plugin frameworks, as far as I am aware. I am its primary author, so feel free to get your own confirmation of that.
Nixysa is a tool that takes definition files and outputs code for a NPAPI plugin. I haven't used it, so I can't tell you exactly what it's capabilities are. It hasn't been updated since 2012, when PPAPI support was added; this is unlikely to be useful, though, since PPAPI has changed significantly since then, and also since the only PPAPI plugins that can run without special command-line flags to chrome are ones specially blessed by the Chrome team.
JUCE is a GPL library with a commercial licence available which has some support for creating browser plugins. I have no idea as to how powerful it is these days; it seemed well written when I last looked at it, and takes a much more minimalistic approach than FireBreath does; FireBreath gives you a framework and tries to make everything Just Work, whereas JUCE seems (I could be wrong) to be more of a "provide the building blocks, but don't try to make everything look the same" type of thing.
QtBrowserPlugin is a defunct unmaintained project which at one time allowed creating browser plugins (probably just npapi, but not certain) with QT. Indications are that it probably doesn't work anymore.
I have no idea what the other projects are. If I were you, I'd try doing some research. Google is your friend.
Related
Everything that I have coded upto this point has been launched from Command Prompt or the IDE itself. I would like the ability to deploy an application such that launching it doesn't require a tutorial for novices. .exe, .apk, .app, ELF. Double-click and go.
I recall creating .exe files from Python as being restrictivly difficult. I was thinking C# and found .net/maui. It doesn't support linux, which I could maybe look past, but it also doesn't appear to support creating .exe files.
Java is more low level than I would like to deal with. Learning a new language that runs virtually could be the solution. I havn't done much investigating as this wouldn't be the ideal. (Edit: JVM requires an additional install, so that's not going to work.)
I don't have any experience with web developement, but it seems like a promising route none the less. It is not clear to me if I can create a local icon-launchable webpage that will run an application in your browser sans-server. Additionally, I am not sure how far my known languages will take me before I have to then learn CSS or whatever.
Thoughts?
Electron seems to be popular choice for cross-platform development in case you don't mind developing with JavaScript.
QT is another cross-platform framework that was around for a long time.
Specifically for .NET, there's MAUI (mobile-focused, no Linux), Avalonia UI, Eto Forms, AlterNET UI. The last one is desktop-only and still in beta.
I am trying to understand the general concept of wgpu and Dawn.
As I understand it, there are two main implementations of the WebGPU standard from Khronos: wgpu from Mozilla and Dawn from Google.
Do I understand correctly that:
-wgpu: is it a C/Rust library that can be compiled from into an executable file of the Operating System and into WebAssembly code for the browser ?
-Dawn: Can only create Web Assembly code for the browser.
And I also wanted to ask: can wgpu create WebAssembly code, does wgpu convert only its API code or C/C++ code too? I can't figure it out.
Basically, wgpu and dawn are the WebGPU spec implementations for Firefox and Chrome browsers respectively.
Currently, dawn is the most advanced implementation of the WebGPU spec, and will officially support WebGPU 1.0 in Chrome around May 2023.
A wgpu-based project compiled as a wasm target will be able to run on all WebGPU-enabled browsers.
More than that, the wgpu APIs is based on the WebGPU spec, but it can runs natively on Vulkan, Metal, Dx12, Dx11, and OpenGLES, and also provides additional features support for native applications.
For example, wgpu-in-app demonstrates how easy it is to integrate wgpu into iOS and/or Android app
From a user's perspective, an extension seems to be something that you go to the Chrome Web Store to get to extend the browser's functionality, whereas a plugin is something that you have to go to an external third party's website to get to extend the browser's functionality.
From a technical or implementation perspective, what is the difference between the two? I saw a similar question here (Is phplivex a extension or plugin?) but didn't get the answer I was looking for.
I am after the difference in the way an extension or plugin is developed and deployed (if any), and if there is any overlap between the two.
The words "extension" and "plugin" have lots of different (but related) meanings accross software products. These words are used interchangeably by many users (and developers). In browser extensions, they have a precise meaning, which is also visible through the UI. E.g. extensions (and apps) can be managed at chrome://extensions/, while plugins can be managed at chrome://plugins/ in Google Chrome.
In Chrome, Firefox, Opera and Safari, browser extensions refer to pieces of software that augment the browser using the browser extension APIs (see extension docs for Chrome, Firefox, Opera, Safari). Most of the modern browsers require extensions to be written using JavaScript. Extensions are usually platform-independent and run within a limited environment (Firefox is a notable exception to the latter). Extensions are usually deployed as a bunch of JavaScript files, other assets (HTML, CSS, media, ...) and configuration bundled in a browser-specific archive. Browser usually offer a seamless way to install the extension directly in the browser.
Plugins refer to NPAPI plugins, which are pre-compiled binaries that enhance the functionality of browsers via NPAPI. These plugins are invoked by inserting an <embed> or <object> tag in the document with a specific MIME-type. NPAPI plugins are OS-specific (though the source code can be platform independent) but not specific to a single browser. The capabilities of NPAPI are not constrained by the browser, so a bug in a browser plugin often have huge security implications (think of Java, Adobe Flash Player, Adobe PDF Reader). This is one of the reasons why NPAPI support is in the process of being completely dropped from Chrome. NPAPI plugins are usually installed outside the browser, e.g. via MSI installers on Windows.
As said in the introduction, "plugins" and "extensions" are used interchangeably. If you hear anyone talking about "(browser) plugins", odds are that they actually mean browser extensions.
We're developing an Eclipse-based RCP. Recently we've updated to Eclipse Juno and currently we focus on quality, which of course brought automated tests into focus, since the application is quite big and the testing effort delays releases.
We're already writing JUnit tests, but I'm more interested in UI tests. With older Eclipses this would not be a problem. There are plenty of good test frameworks around. Unfortunately with Juno everything changed due to the added ability to switch out the default SWT UI by Swing or JavaFX (at least this is what I've understood about the changes causing problems)
So most of the test tools don't work properly anymore. From past experiences it seems that:
SWTBot seems to get not much love lately and is very unstable (can't find elements in certain versions)
Window Tester seems quite good, but has a lot of problems identifying an element during the test run (especially with pop-ups such as content assist or tool tips)
Apparently Froglogics Squish supports Juno, but since a license costs about 2,5k Euro I have to pass
The same seems to be the case for QF-Test (too expensive).
This leaves Jubula (or GUIDancer, which is the commercial Jubula), which we've tried in the past, but which had similar problems as Window Tester and SWTBot (unstable in terms of changes to the Eclipse platform and difficulties to detect some elements)
I need to know, which tool to focus on / trust in. Does anybody have experience with one of the tools or is even currently testing a Juno RCP (or Juno itself for that matter)? Or does anybody know how Eclipse tests their own platform (if they even do it atm)?
Searching for information related to "test", "Juno" and "UI/GUI" only brings up the commercial products.
For me it is important, to find a tool, where I can use the developed test cased even in future releases, which means: A framework project, which has some support of the community to be able to adapt quickly. Also it is important to also find stuff like tool-tips, overlays or content assists/suggestions) - similar to a Selenium compared to basic HTMLUnit.
At this point I don't even care too much about integration, reporting or compliance to standards..
You can find a comprehensive table of GUI-Testing tools in the Eclipse Wiki:
http://wiki.eclipse.org/Automated_Testing#UI_tests
One important decision you have to make is, if you want to use your mouse to record/create tests (Jubula, QFTest, ...), if you want to be able to hand-write test-code (SWTBot, ...), or if you want to be able to do both (WindowTester Pro, ...).
Eclipse Juno is rather new, and I would expect problems with all of the listed tools, however the migration should not take that long since most of these tools mainly focus on testing SWT-widgets and Juno still uses SWT. So far I have not heard from any RCP Application seriously using JavaFX other than for technical demos, but I would be curious to see them!
The problem I think, is rather that testing Eclipse is hard and GUI-testing is especially hard.
You might want to have a look at this study which finds and explains the major problems:
http://swerl.tudelft.nl/twiki/pub/Main/TechnicalReports/TUD-SERG-2011-010.pdf
If you believe this study, JUnit-testing is usually preferable to GUI-testing. Well, with Juno you have the big advantage that Unit-testing Eclipse now is easier than it ever was because the framework switched from inheritance and singletons to dependency injection, which makes it far more testable.
I'd suggest you too look at Xored's Q7, which is used for GUI testing of some of Eclipse projects including Eclipse DLTK, Eclipse LDT, Eclipse Tigerstripe and the tool is just perfect : it let you develop dozens of UI tests per day per engineer, and do not have stability and incorrect-recording problems. It's designed specially and only to test Eclipse-based apps and obviously the best in the niche.
However it costs money, which can be a blocker for you (like squish), but they have a free Community version, which is enough for most of use-cases. As well as those Xored guys just introduced pay-per-testexecution pricing model -- the tools will be free and you have to pay as you go only per tests executed monthly (less than 5000 is free). More about new model is here eclipse-testing.com
I would like to be able to create FogBugz cases directly straight from the editor in NetBeans. Specifically, I would like to be able to look at a JUnit run in the IDE, examine the failures and create cases directly using the information that is right in front of me (rather than cutting and pasting into a web browser, etc).
I see that NetBeans 6.5.1 ships with Bugzilla available by default and JIRA connectivity in some sort of beta form. Is there an equivalent FogBugz issue tracker?
PS: I am aware of the new plugin architecture of FogBugz 7. However, I have a realistic appreciation of the time that I would be able to commit to creating my own plugin for either NetBeans and / or FogBugz and I suspect that I would be able to make just enough of a partial solution to make my life worse rather than better.
It appears you may need to write one yourself, as they have plugins for Eclipse and Visual Studio, but not Netbeans.
http://www.fogcreek.com/fogbugz/blog/post/Eclipse-Plugin-For-FogBugz.aspx
I am not aware of such plugin. You're right that it is not trivial effort to write full-featured connector, but getting basic one is not that hard ... especially if you're already familiar with NetBeans plugin architecture. If you decide to go for it, take a look at FogBugz API instead of new FogBugz plugins. FogBugz API is used to talk to remote FogBugz repositories.