is it okay to use loadOverlay() in a restartless addon? - dom

Firefox addon. I'm porting an existing addon to a restartless one. I have a panel with a lot of UI elements (mostly boxes/description and images) in it, and it is very convenient for me to define the panel elements in an XUL overlay file. I will have lots of bloated js code if I don't.
The panel element (parent) itself is created in code dynamically, and then I use loadOverlay, wait for the 'merged' event and then append the panel element's children from the overlayed document. I also make sure that the elements are cleaned up upon a remove.
However, using overlays will most probably won't pass an AMO review. And some of the reasons I think are :
In most cases overlay elements will cause problems while removing (eg: toolbar buttons remembering their positions etc.)
There are problems with attaching js/css files in an overlay file.
loadOverlay is buggy (496320, 330458)
And here are my inferences :
loadOverlay() API itself is not deprecated - in fact it is 'not frozen and may change later' - which means possibly it will be use-able in future.
The bug that a second overlay load fails, is not applicable in my case, as I don't initialize without an overlay merge.
Using static overlay for preference windows etc. is perfectly acceptable as of now.
The panel in my case behaves a lot like a preference window (which is brought up on demand and cleaned up upon addon removal)
I don't have any js/css attached to the overlay, nor any event listeners for the elements. The overlay is only used to define boxes and description text - nothing more.
So considering these, is it acceptable to use overlays and loadOverlay() for a restartless addon ? If not, is there an alternative ?

About overlays, by checking source code of restartless addon that extend existing addon (like ehh), I see the overlay.xul is auto merged with the existing addon's. So it shouldn't be a problem to use overlay.

Related

Building Blocks not appearing after upgrade to Word 2013

I have a document-level (dotx) customization, with a custom ribbon, and one of the controls in that ribbon is this:
<gallery idMso="CustomGallery1" label="Building Blocks" size="large" />
The only other part that makes this work is the creation of entries under Custom1 in the Building Blocks Organizer. In Word 2010, this would show all the building blocks under the Custom1 category. In Word 2013, it shows the name of each building block briefly, and then all of them are removed and the list is empty:
The building blocks themselves all contain either a document property or document variable.
I have tried the following to resolve this but without success:
Ensured that they are still present by opening the template outside of Visual Studio; they are.
Upgraded the template to the 2013 dotx format.
Re-created the building blocks.
Re-created the entire dotx file, and then re-created the building blocks.
I also tried using other ribbon IDs, they are empty too (they do all have entries) but they display it differently:
There should be four entries there, they exist in my Normal.dotm. The last two controls there, for equations and content controls, do work, except the content control that is inserted displays similar behavior as the Autotext gallery:
I don't know what should be shown in this case but I doubt it's nothing.
Right now I'm assuming that this is just a broken feature in 2013 and will have to replace it with something else. Does anyone know anything to the contrary?
I don't think it is a broken feature, after some struggle, I did get to understand how to use it:
The gallery button in the "toolbar" of a newly added Building Block Gallery Content Control indeed seems empty at first, because it is set to list QuickParts. You have to change it in the properties of the control so that it lists the content of the AutoText Gallery instead (or any other Gallery of Building Blocks you'd like). To do so, either directly click on the Properties button in the Developper tab while the control is selected, or switch to Design Mode so that the Properties appears in the context menu (right-click on the control):
AutoText is "Insertion automatique" in French, the rest you can guess ;)
As far as I could find, it's just a broken feature. There's also a ridiculous memory leak the first time you do a Find and add fields during that find.

how to inspect gwt screen?

GWT screens are composed of a hierarchy of Widgets each implemented by various application classes. In order to maintain (add/change) these screens it is required to understand its structure, namely to discover which screen element is rendered by which Widget implementation.
Currently, I am trying to read the "suspected" class source while peeking at the DOM structure of the screen.
I am looking for a tool, or method, to aid with discovering which Widget class renders a specific screen element.
Such a tool would monitor the mouse position on screen and provide the class name of the hovered element (for example, in a tooltip).
Alternatively, I would be happy to find a programming method that allows adding a generic mouse event handler, most desirable to the RootPanel, further displaying the class name of currently hovered element.
Unfortunately AFAIK ,as of now there is no such tool for GWT( will be more happy if any ) .
As on browser side there is no such information available related to class files of java available since it compiled to javascript.
So , what's the fix??
Though very common and tradational.
1)Proper naming conventions
2)Proper package structure
3)Documentation etc ...
Check out the GWT-Instrumental project for an example of how this can be achieved. This is not a new project and may need to be updated to be properly useful in some cases, but seems to work with GWT 2.4 and GWT 2.5.1 projects just fine. The Inspector bookmarklet/instructions can be found at http://gwt-instrumental.googlecode.com/svn/latest/inspectorwidget/index.html.
This isn't doing exactly what you are describing, but could be modified fairly simply. What it does do is this:
When launched (or refreshed), look at every element on the page to see what widget might be references, and what css classes it has, what id it has, and what DOM events are sunk on it.
When expanded, renders a firebug-like tree of the DOM elements in the body, along with the details mentioned above
When the user hovers over a element in the tree, draws a yellow overlay on where that item is drawn on the page so you can find it.

GWT Editors for readonly and edit mode

GWT's Editor framework is really handy and it can not only be used for editing POJOs but also for read-only display.
However I am not entirely sure what the best practice is for doing inline edits.
Let's assume I have a PersonProxy and I have one Presenter-View pair for displaying and editing the PersonProxy. This Presenter-View should by default display the PersonProxy in read-only mode and if the user presses on a edit button it should allow the user to edit the PersonProxy object.
The solution I came up with was to create two Editors (PersonEditEditor and PersonDisplayEditor) that both added via UiBinder to the View. The PersonEditEditor contains
ValueBoxEditorDecorators and the PersonDisplayEditor contains normal Labels.
Initially I display the PersonDisplayEditor and hide PersonEditEditor.
In the View I create two RequestFactoryEditorDriver for each Editor and make it accessable from the Presenter via the View interface. I also define a setState() method in the View interface.
When the Presenter is displayed for the first time I call PersonDisplayDriver.display() and setState(DISPLAYING).
When the user clicks on the Edit button I call PersonEditDriver.edit() and setState(EDITING) from my Presenter.
setState(EDITING) will hide the PersonDisplayEditor and make the PersonEditEditor visible.
I am not sure if this is the best approach. If not what's the recommended approach for doing inline edits? What's the best way to do unit-testing on the Editors?
If you can afford developing 2 distinct views, then go with it, it gives you the most flexibility.
What we did in our app, where we couldn't afford the cost of developing and maintaining two views, was to bake the two states down into our editors, e.g. a custom component that can be either a label or a text box (in most cases, we simply set the text box to read-only and applied some styling to hide the box borders).
To detect which mode we're in, because we use RequestFactoryEditorDriver (like you do), we have our editors implement HasRequestContext: receiving a null value here means the driver's display() method was used, so we're in read-only mode. An alternative would be to use an EditorVisitor along with some HasReadOnly interface (which BTW is exactly what RequestFactoryEditorDriver does to pass the RequestContext down to HasRequestContext editors).
Yes,Presenter-View pair should be. But Here two ways to achieve this feature if you like to go with:
1) Integrate Edit/View code design in one ui.xml i.e.Edit code in EDitHorizonatlPanel and View code in ViewHorizontalPanel.The panel has different id. By using id, show/hide panel with display method. if getView().setState() ==Displaying then show ViewHorizontalPanel and if getView().setState()==Editing then show EditHorizontalPanel.
2) Instead of using labels, Use textboxes only. set Enable property is false when you need it in view mode otherwise true
You have created two Presenter/view but I think if Edit/View function has similar code so no need to rewrite similar code again and again for view purpose.
If a big project has so many Edit/View function and you will create such type of multiple View/Presenter than your project size become so huge unnecessary.
I think that whatever I have suggest that might be not good approach but a way should be find out which help to avoid code replication.

How to wait for DOM operation completion?

I have to maintain a part of an old Windows VB6 project (so, don't tell me to migrate-it to VB.NET). This program embeds the well known webbrowser control (IE) in which it loads local HTML files (containing different stats, but doesn't matter). Knowing we don't want any scroll bar in the web browser view (even if HTML page is longer than the webbrowser window, we just need to see what it's on top), we manage DOM on DocumentComplete event like this :
Private Sub wb_DocumentComplete(ByVal pDisp As Object, URL As Variant)
wb.Document.documentElement.Style.overflow = "hidden"
ProcessWithDStats
End Sub
All sounds right and the vertical scrollbar well disappear, but now, I need to add some stuff in the ProcessWithDStats sub (a big sub calling a lot of functions) which need to be sure the previous DOM operation is totally completed (I mean : scrollbar hidden and it's content re-justified accordingly to this new width w/o scrollbar).
So, how to do ?
At this time, ProcessWithDStats is executed before DOM management really finish to be rendered !
Until now, here are my attempts :
I've tried to add a scrollbar testing (comparing doc width and browser client area one) between the two lines, but it doesn't work : test is OK, but reflow of text (because of this change of width when scrollbar disappear) has not enough time for being applied before ProcessWithDStats is engaged.
I've tried to Sleep(), but it locks entire program (webbrowser rendering included)
Well is there a way to wait for real application of the given DOM management in this WebBrowser control ?
I mean something like :
Do
Doevents
Loop Until [DOM modification and rendering completed]
you need to do this... at the very least.
Do
Sleep 100
Doevents
Loop Until wb.Busy = False And wb.ReadyState = 4
On your version the .Busy may be called .IsBusy but are the same thing.
Also, there are additional things you should do if you want to truely know if a browser is done loading, read some of my previous answers if you want to know more, or need more accuracy than the above, but what i have included for you is for sure a much better solution than you currently have. Let me know if you need it to work on 100% of websites or just a select few, if a select few than this simple method may be enough.
Let me know hwo it goes anyway, cheers.

How to keep NPAPI plugins alive in ExtJS tabbed views

I'm trying to use a custom video player NPAPI plugin (view FireBreath) inside an tabbed ExtJS application. The plugin lives in one tab, and the others contain presentations of other non-video data.
When switching from tab to tab, the element that contains the plugin is destroyed, and all plugin state is lost. Is there any way to configure an ExtJS tabbed panel so that the html contained in it is not altered when switching to another tab (just hidden)? The alternative is to re-populate the plugin state when returning to the tab, but this would be associated with an unacceptable delay (mostly while waiting for video key frames).
Thanks,
O
I don't know about your ExtJS approach, if you can solve it on that side that would of course be preferrable.
However, if you can't, you can avoid the reinitialization by moving the stream handling to a helper application that is running in the background. The plugin would launch it as needed and receive the stream data from it after registering for it.
The helper would be told when to kill a stream and possibly kill it by itself after some timeout (to avoid session leaks in case of crashing plugins etc.).
I was about to consider a helper application as recommended above, or look into rewriting the plugin to be windowless. Both might be more robust solutions for other JS frameworks.
Fortunately, the solution ended up being simpler than this, at least for ExtJS. By default, ExtJS sets "display: none" on the tabbed view's div whenever it is undisplayed, which calls the plugin destructor. After doing a little more looking through their enormous API, ExtJS has a parameter hideMode as part of the Ext.panel.Panel base class:
'display' : The Component will be hidden using the display: none style.
'visibility' : The Component will be hidden using the visibility: hidden style.
'offsets' : The Component will be hidden by absolutely positioning it out of the visible area of the document. This is useful when a hidden Component must maintain measurable dimensions. Hiding using display results in a Component having zero dimensions.
Defaults to: "display"
Setting the parent Panel that contains the plugin to hideMode: 'offsets' fixed the problem perfectly.