phosphorjs / phosphor Goto Github PK

Is there a project file and source code available for this example?

http://phosphorjs.github.io/examples/dockpanel/

I can look at the code in the browser, but the javascript is all stuffed into a bundle.js and isn't very digestible. I was hoping there is a starter project that generates this (is that typescript code in the source window?).

Thanks,
John

In Jupyterlab, the content of most plugins is scrollable (command palette, notebook, welcome page).

It would be nice to have a scrollspy feature in order to enable a top border or a shadow when the content is scrolled.

Cf jupyter.org screenshot below:

When clicking API on https://phosphorjs.github.io/, it leads to a 404 (for the gh-pages on this repo).

Looking at the gh-pages branch, it's rather empty:

Guessing the gh-pages just needs to be re-triggered?

keymap.spec.ts needs a once-over focusing on these points:

1. Only use the global keymap manager if absolutely necessary. Most all tests can get along with create a new KeymapManager instance, which will actually save on being diligent about disposing.
2. Ensure the test clauses are under the correct header. For example, some tests currently under findBinding() actually have nothing to do with that function.

I'm not convinced this base class should be disposable. There are some cases where preventing clearing the node is useful (cache pools), and not really any cases where it's truly required.

Migrated from https://github.com/phosphorjs/phosphor-ui/issues/1

• When a user changes the title label.
• When a user right clicks on the title node (with the client position)

When the user has not searched for something in the command palette, it currently returns a locale ordered list of results because all items are considered to have an equal score, but that heuristic might not be as good as using the initial order that palette items were added. In the case of the JupyterLab command palette, for example, the current order of items under the "Console" category is:

Controlling the order of items would allow us to put "New Python 3 console" first, which is more in line with what users might expect and more useful for discovery.

Thoughts?

cc: @blink1073 @jasongrout

When we move plugins here, migrated from https://github.com/phosphorjs/phosphide/issues/75

If possible, use getComputedStyle() to parse the CSS transition value instead of needing the TS and CSS files to be in sync:

/**
 * The tab transition duration.
 */
const TRANSITION_DURATION = 150;  // Keep in sync with CSS.

from ui/tabbar.ts

.p-TabBar.p-mod-horizontal.p-mod-dragging .p-TabBar-tab {
  left: 0;
  transition: left 150ms ease; /* keep in sync with JS */
}


.p-TabBar.p-mod-vertical.p-mod-dragging .p-TabBar-tab {
  top: 0;
  transition: top 150ms ease; /* keep in sync with JS */
}

from styles/base.css

Allow plugins to fail to activate with a warning. Instead of the current Promise.all() method of ensuring all plugins are loaded, allow individual plugins to fail to load, using the method demonstrated here.

This will allow us to gracefully handle the case of a plugin that depends on a token that is version incompatible with the token that is provided.

cf jupyterlab/jupyterlab#1011

Still not sure we have the right from a semantics perspective.

cf #50 about <a> tags

MenuBar, SplitPanel, StackedPanel have UI tests that rely on simulated events and are failing.

In addition:

A CommandPalette test fails in IE 11 on Windows 8. It may be related to simulate-event. It causes all subsequent tests that add a test command to also fail, but this is the only broken test in the CommanPalette suite and once it is fixed, the rest of the tests will work as well.

it('should trigger a command when its item is clicked', () => {
  let called = false;
  let options: ICommand = { execute: () => called = true };
  let command = commands.addCommand('test', options);
  let palette = new CommandPalette();
  let content = palette.contentNode;

  palette.addItem({ command: 'test' });
  sendMessage(palette, WidgetMessage.UpdateRequest);
  Widget.attach(palette, document.body);

  let node = content.querySelector('.p-CommandPalette-item');

  expect(node).to.be.ok();
  simulate(node, 'click');
  expect(called).to.be(true);

  palette.dispose();
  command.dispose();
});

TabBar has these errors:

FAILED TESTS:
TabBar
  #tabMoved
    x should be emitted when a tab is moved right by the user
      IE 11.0.0 (Windows 8.1 0.0.0)
    timeout of 2000ms exceeded. Ensure the done() callback is being called in this test.

    x should be emitted when a tab is moved left by the user
      IE 11.0.0 (Windows 8.1 0.0.0)
    timeout of 2000ms exceeded. Ensure the done() callback is being called in this test.

  #tabCloseRequested
    x should be emitted when a tab close icon is clicked
      IE 11.0.0 (Windows 8.1 0.0.0)
    Error: expected false to equal true
       at Assertion.prototype.assert (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:679:8)
       at Assertion.prototype.equal (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:793:6)
       at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:646:14)
       at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:21662:18)

  #tabDetachRequested
    x should be emitted when a tab is dragged beyond the detach threshold
      IE 11.0.0 (Windows 8.1 0.0.0)
    Error: expected false to equal true
       at Assertion.prototype.assert (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:679:8)
       at Assertion.prototype.equal (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:793:6)
       at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:646:14)
       at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:21706:18)

    x should be handled by calling `releaseMouse` and removing the tab
      IE 11.0.0 (Windows 8.1 0.0.0)
    Error: expected false to equal true
       at Assertion.prototype.assert (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:679:8)
       at Assertion.prototype.equal (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:793:6)
       at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:646:14)
       at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:21719:18)

    x should only be emitted once per drag cycle
      IE 11.0.0 (Windows 8.1 0.0.0)
    Error: expected 0 to equal 1
       at Assertion.prototype.assert (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:679:8)
       at Assertion.prototype.equal (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:793:6)
       at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:646:14)
       at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:21732:18)

    x should add the `p-mod-dragging` class to the tab and the bar
      IE 11.0.0 (Windows 8.1 0.0.0)
    Error: expected false to equal true
       at Assertion.prototype.assert (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:679:8)
       at Assertion.prototype.equal (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:793:6)
       at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:646:14)
       at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:21747:18)

  #handleEvent()
    click
      x should emit a tab close requested signal
        IE 11.0.0 (Windows 8.1 0.0.0)
      Error: expected false to equal true
         at Assertion.prototype.assert (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:679:8)
         at Assertion.prototype.equal (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:793:6)
         at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:646:14)
         at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:22082:22)

    mousedown
      x should add event listeners if the tabs are movable
        IE 11.0.0 (Windows 8.1 0.0.0)
      Error: expected -1 to not equal -1
         at Assertion.prototype.assert (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:679:8)
         at Assertion.prototype.equal (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:793:6)
         at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:646:14)
         at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:22128:22)

    mousemove
      x should do nothing if there is a drag in progress
        IE 11.0.0 (Windows 8.1 0.0.0)
      Error: expected 0 to equal 1
         at Assertion.prototype.assert (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:679:8)
         at Assertion.prototype.equal (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:793:6)
         at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:646:14)
         at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:22170:22)

      x should emit the detach requested signal if the threshold is exceeded
        IE 11.0.0 (Windows 8.1 0.0.0)
      Error: expected false to equal true
         at Assertion.prototype.assert (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:679:8)
         at Assertion.prototype.equal (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:793:6)
         at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:646:14)
         at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:22200:22)

      x should bail if the signal handler aborted the drag
        IE 11.0.0 (Windows 8.1 0.0.0)
      Error: expected false to equal true
         at Assertion.prototype.assert (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:679:8)
         at Assertion.prototype.equal (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:793:6)
         at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:646:14)
         at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:22212:22)

      x should update the positions of the tabs
        IE 11.0.0 (Windows 8.1 0.0.0)
      Error: expected false to equal true
         at Assertion.prototype.assert (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:679:8)
         at Assertion.prototype.equal (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:793:6)
         at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:646:14)
         at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:22224:22)

    mouseup
      x should emit the `tabMoved` signal
        IE 11.0.0 (Windows 8.1 0.0.0)
      timeout of 2000ms exceeded. Ensure the done() callback is being called in this test.

      x should move the tab to its final position
        IE 11.0.0 (Windows 8.1 0.0.0)
      timeout of 2000ms exceeded. Ensure the done() callback is being called in this test.

    keydown
      x should prevent default
        IE 11.0.0 (Windows 8.1 0.0.0)
      Error: expected false to equal true
         at Assertion.prototype.assert (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:679:8)
         at Assertion.prototype.equal (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:793:6)
         at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:646:14)
         at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:22269:22)

    contextmenu
      x should prevent default
        IE 11.0.0 (Windows 8.1 0.0.0)
      Error: expected false to equal true
         at Assertion.prototype.assert (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:679:8)
         at Assertion.prototype.equal (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:793:6)
         at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:646:14)
         at Anonymous function (Z:/Code/phosphorjs/phosphor/test/build/bundle.js:22284:22)

Over on the ipython repo we have been having a discussion about the technical details and performance of phosphor. This is an attempt to migrate that discussion to the phosphor repo. Here is the original discussion:

ipython/ipython#7997

Let's continue things here...

So i'm playing with boxlayout,

I figured the addStretch would add an elastic stretch. Though it seem to have a default value of 0, which make adding any other stretch with non default value completely collapse the default ones. It might be a design decision, in which case it's fine, and I can document it, or we might make the default 1 which make teh behavior a little less surprising.

The DockPanel should attach a document level focus event listener. When a child of the dock panel is focused, it will send a semantic-focus message to the widget, and a semantic-blur to the previous widget that had semantic focus, if applicable. It will also store a monotonically increasing semantic focus count as an attached property DockPanel.semanticFocusCount(widget: Widget): number.
The widget is in charge of applying applicable style to itself upon receiving the messages.

Plugins can install message hooks to these messages for the widgets that are being managed by the plugin. Each plugin would choose whether to emit a signal when the active widget of that type changed, the active widget itself, and a list of open widgets. This behavior could be collected into a helper class.

Example:
When a notebook receives an Execute Cell command, it would apply the command to the semantically focused widget if it is a notebook, or activate() the most recently focused notebook and apply the command to that notebook, if that is the desired behavior.

It would be useful for jupyter-js-widgets if phosphor has a Panel for the CSS flexbox implementing the logic for fit requests and resize events.

At the moment in jupyter-js-widgets, the base widgets have a layout attribute, which holds the following properties

• Sizes
  • height
  • width
  • max_height
  • max_width
  • min_height
  • min_width
• Display
  • visibility
  • display
  • overflow
• Box model
  • border
  • margin
  • padding
• Positioning
  • top
  • left
  • bottom
  • right
• Flexbox
  • order
  • flex_flow
  • align_items
  • flex
  • align_self
  • align_content
  • justify_content

When there is a shorthand property, this is always the one that is privileged.

The flexbox - based Box jupyter widget would probably have to trigger fit requests and/or resize events on changes of the properties of its layout attributes, or of the children list itself.

Besides, the base phosphor wrapper for DOMWidget views would trigger fit requests on change of its own layout attribute.

@ellisonbg and I were talking earlier about possibly using Phosphor to replace Backbone's View class. Would that currently be possible, and if so, how would I go about doing that?

Moving panels around in my browser appears to be more performance intensive than I would have expected. I can easily push chrome to 100% usage by dragging borders between panels around. Is this expected?

If a TabBar is disposed before a tab remove animation is complete, the animation will still fire, causing a potential null exception by accessing the DOM node of the disposed tab bar. The change was introduced here d71288c

Now that the code has settled down more, it would be nice to have the dist/ directory back so that we can check out phosphor and immediately start using it. Maybe after the shell branch has been merged.

I think vdom might use this in places. cf #137

they were test manually before merge, but need something formal

We thought it might be okay to expose accessors to a widget's geometry, as stored in the attached property on the widget. However, further conversation on gitter made us realize it was a bad idea. We document the conversation here so it's available for others.

S. Chris Colbert @sccolbert 11:12
@jasongrout as I'm writing this getGeometry function, I'm wondering if it's a good idea.
because abritrary changes could have changed the size of the widget in the interim
I think that's why I omitted it from the beginning: to force the user who needs to cache sizes, to think carefully about what and how they are doing that

Jason Grout @jasongrout 11:13
you mean without the resize events?

S. Chris Colbert @sccolbert 11:13
yes
the resize message is only sent when a call to setGeometry is different than the previous value

Jason Grout @jasongrout 11:13
right

S. Chris Colbert @sccolbert 11:13
all we know at that point is what we are setting the size to, not that the old values are still correct
what would you be using it for in this case?

Jason Grout @jasongrout 11:14
getting the leaflet size
but I'd expect that the geometry information would be a -1 if the size was unknown
Does the geometry reflect the unknown-ness of sizes?
In other words, if I'm in a container that is not absolutely sized, does the geometry reflect that I don't know my size, or does it calculate the size at a given time and cache that?

S. Chris Colbert @sccolbert 11:19
No, it does not calculate anything, ever.
which is why I don't expose a getter

Jason Grout @jasongrout 11:20
So what is the geometry in the case of a non-absolutely positioned layout?

S. Chris Colbert @sccolbert 11:20
when setting the size, we know the size. The only question is whether we should send a resize message when we do that. It's reasonable enough to check if anything is different from the previous call to setGeometry.
You're not supposed to call setGeometry on a non-absolutely positioned widget
it's not designed for that

Jason Grout @jasongrout 11:21
ah, okay, but you will get resize messages on those widgets anyway

S. Chris Colbert @sccolbert 11:21
Yes, and width/height will be -1

Jason Grout @jasongrout 11:21
I had thought the geometry was essentially a cache for the resize messages, but it's not!

S. Chris Colbert @sccolbert 11:21
i.e. the parent sends the child ResizeMessage.UnknownSize
nope, it only caches the previous values in order to check for a change
to determine whether to send a resize message

Jason Grout @jasongrout 11:22
I guess it's the other way around, actually. geometry sends resize messages, but other things send resize messages too, the unknown resize messages.

S. Chris Colbert @sccolbert 11:22
also, see prepareGeometry and resetGeometry for extra docs

Jason Grout @jasongrout 11:22
yes, I read those too.

S. Chris Colbert @sccolbert 11:24
I think I'm not going to add a getGeometry method. And instead encourage users to cache the sizes from the resize message. There's too many "gotchas" otherwise.

Jason Grout @jasongrout 11:24
Okay, key point here being that you might get a resize message for any number of reasons, and if you want to accurately understand your size, you need to keep track of those, computing dynamically when the resize message doesn't give you a size. In fact, if the resize message doesn't give you a size, you better compute it whenever you need it.
yep.
This should be an issue somewhere you can point people to

S. Chris Colbert @sccolbert 11:24
yep

Jason Grout @jasongrout 11:25
you better compute it whenever you need it.
or do your own invalidation, like the map does...

S. Chris Colbert @sccolbert 11:34
yep

as it says on the tin.

npm run test:ie
IE 11 / Windows 10

Seen in JLab:

These tests may be related to our simulate-event issues, but since the other tests on the KeyMap suite work, I'm posting them separately.

• 'should register partial and exact matches'
• 'should play back a partial match that was not completed'
• 'should propagate if partial binding selector does not match'
• 'should propagate if exact binding selector does not match'

@sccolbert just updated to the latest JupyterLab that is based on the latest stable phosphor. In JupyterLab the visual design of the dock panel is messed up, but that can be fixed on the Jlab side of things. For reference here is a screenshot:

We will update our style on the JupyterLab side to fix these things. The other big difference is the behavior of the drag areas in the dock panel. Those are summarized from (#155) here:

Summary of behavioral changes:

1. There is now a drop zone on top of the tab bars.
2. There is no more center drop zone on a widget.
3. You must hold shift while dragging to activate the border drop zones.
4. Clicking on a tab now activates the widget, even if the tab is already current.

I can see where 1 and 2 are coming from. The old center drag area wasn't completely obvious to new users - we saw this in users tests. But those results were not so dramatic that the new behavior is clearly better. The right way to test this is in a user test. I am willing for us to "try it out ourselves" for a bit, but I think we should treat this behavior change and provisional until we are convinced it is better.

I am guessing that 3 happened because the old border drop zones were interfering with the new tab drop zones. From an implementation perspective, I understand. But from the usability perspective, the new behavior is not discoverable without us telling users about the behavior. Even then, it is really subtle to figure out (when can you add the shift modifier for example). The old drag zones were nice because the users didn't have to be aware of the subtle nesting/border questions - they just moved things around to get the layout they wanted. Now they have be aware of the arbitrary (from their perspective) differences between nesting versus border drop zones.

I'm attempting to use Angular 2 with the Phosphor Docking Widgets. The idea is that the widget creates web content that is a custom tag, and that tag is then replaced (in the onUpdateRequest() call) by Angular 2 to populate the content. It seems to be working, in that my widget displays the HTML content that I expect. I think it has the potential to be a really cool architecture for providing a variety of "stand alone" apps within a common docking framework.

The problem is that I should be seeing scrollbars within the widget pane (since I have more content than would fit), and they aren't there. Instead, the content is simply cut off. Here is my Widget code below. Any ideas what I might be doing wrong? I see there is an onResize() method I could implement, but I'm not sure what to put inside it.

import { platformBrowserDynamic } from '@angular/platform-browser-dynamic';

import { Message }            from 'phosphor/lib/core/messaging';
import { Widget, WidgetFlag, ResizeMessage } from 'phosphor/lib/ui/widget';

import { AppInfoModule } from './app-info.module';

export class AppInfoWidget extends Widget {

  static createNode(): HTMLElement {
    var node = document.createElement('app-info');
    return node;
  }

  constructor() {
    super({ node: AppInfoWidget.createNode() });
    this.addClass('AppInfoWidget');
    this.title.label = "App Information";
    this.title.closable = true;
  }


  protected onAfterAttach(msg: Message): void {
    this.update();
  }

  protected onUpdateRequest(msg: Message): void {

    const platform = platformBrowserDynamic();
    platform.bootstrapModule(AppInfoModule);

  }
}

This is a list of things which need to be done before 1.0 release. Will add to list as I find things.

• Rename text -> label where relevant
• Rename tooltip -> caption where relevant
• Ensure docstring example import paths are correct
• Reasonably complete test suite
• Maximize support for dock panels
• Tear out window support for dock panels
• Flat widget hierarchy for dock panel (solves iframe issue and IE/Edge relayout issues)
• Allow a non-global instance of command registry and keymap manager to be used where relevant
• Tests for core/mimedata
• Tests for dom/dragdrop
• Audit import paths in doc string examples.
• Vector method conveniences: popAt, remove, removeAt
• Audit onActivateRequest implementation for each widget
• More specific node types on widgets and renderers
• Better return values for removeTab, removeItem, etc.
• TabPanel should activate the widget when its tab is clicked, even if its already the current widget.
• Application, DI, phosphide stuff
• Animated dock overlays
• Investigate using <a> tags inside things like tabs, command items, and sidebar buttons.
• Use this for sender type of ISignal objects.
• Update content renderers to use vdom.
• Audit BoxSizer usage to ensure that minSize >= maxSize at all usage points.
• Layout options should not be optional. The panel should provide the defaults.
• Should the split layout handle events for the split panel?
• Audit dispose methods on layouts (some may be missing).
• Audit everything for potential use of readonly.
• Add !important for CSS hidden rules where appropriate.

For example, dragging a cell into a notebook should allow the notebook content to scroll.

cf https://github.com/jupyter-incubator/dashboards/pull/204/files

migrated from https://github.com/phosphorjs/phosphor-dragdrop/pull/5

These two widget tests break in IE11 on Windows 8:

it('should send a `blur-request` message', () => {
  let widget = new LogWidget();
  expect(widget.messages).to.eql([]);
  widget.blur();
  expect(widget.messages).to.eql(['blur-request']);
});

it('should be invoked on a `blur-request', () => {
  let widget = new LogWidget();
  sendMessage(widget, WidgetMessage.BlurRequest);
  expect(widget.methods.indexOf('onBlurRequest')).to.not.be(-1);
});

More a question than an issue.

I looked at many options to (auto)build a pretty main page for phosphor, that would give a short intro,
and rebuild works on travis

JS-Based one are pretty much do everything yourself, especially template and design.

The more "out of the box" one, not enough out of the box is jekyll, which is ruby-based,
and I guess you will have something against it.

Thoughts ?

This test fails in IE 11 on Windows 8. It may be related to simulate-event. It causes all subsequent tests that add a test command to also fail, but this is the only broken test in the CommanPalette suite and once it is fixed, the rest of the tests will work as well.

it('should trigger a command when its item is clicked', () => {
  let called = false;
  let options: ICommand = { execute: () => called = true };
  let command = commands.addCommand('test', options);
  let palette = new CommandPalette();
  let content = palette.contentNode;

  palette.addItem({ command: 'test' });
  sendMessage(palette, WidgetMessage.UpdateRequest);
  Widget.attach(palette, document.body);

  let node = content.querySelector('.p-CommandPalette-item');

  expect(node).to.be.ok();
  simulate(node, 'click');
  expect(called).to.be(true);

  palette.dispose();
  command.dispose();
});

On Chrome, when the Menu keys is pressed and no element is focused, the contextmenu event is sent to the node which intersects position (0, 0) instead of the document like in other browsers. Often, the widget at (0, 0) will be a menu bar, which eats contextmenu events. This means the keyboard activation of the context menu does not work in Chrome. We need a workaround for this.

Why do we implement our own scrollIfNeeded (https://github.com/phosphorjs/phosphor/blob/master/src/dom/query.ts#L89) instead of using the browser's scrollIntoView (https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView)?

Alternatively, I think the scrollIfNeeded algorithm could be improved by following (maybe with a threshold?) the spec for scrollIntoView: https://drafts.csswg.org/cssom-view/#element-scrolling-members

We talked today about renaming Events to Messages.

This should be independent of the current addWidget api.

Panels can't be dragged in Chrome browsers using a touch screen. Observed with the DockPanel example on a Dell XPS laptop running Windows 10. With Firefox is works fine.

This is a TODO note

We have been talking about adding a context menu command registry similar to the keyboard shortcut registry that could be used to automatically build context menus for phosphor based apps. Here is the issue on JupyterLab that is blocked on this one:

jupyterlab/jupyterlab#577

This is a TODO note

Back in August in another thread I asked about the ability to click a button on a docked panel and have it become it's own window on the screen. A button should be provided to allow it to be easily snapped back in. I was told that feature is coming, probably pre-1.0. Is it getting close? It's a really important feature for us.

Thanks,
John

Looking at the code in https://github.com/phosphorjs/phosphor/blob/master/src/core/messaging.ts, if a Message hook modifies a message, and further processing occurs, the modifications are propagated. This behavior should be clarified in the docs. I see at least three ways to clarify this, depending on what you want to convey:

1. If a message hook modifies a message, the modifications are propagated to further hooks and the handler.
2. You should not modify the message (i.e., "don't do that!")
3. Change the code to create a (shallow?) copy of the message, and document that a (shallow?) copy is handed to the hook.

The computation of box sizes etc. should be precise and use doubles instead of ints.
E.g. for me in chrome the jupyterlab border of a notebook editor is 0.909091px which gets rounded to 0 by parseInt.

I couldn't get TypeDoc ^0.5.0 to build with TS 2, because it doesn't seem that TypeDoc accepts the full suite of tsconfig options (like which built-in libs to use). I also didn't spend a bunch of time on it, since docs have been broken for a while.

cc @blink1073

Are any examples available for using Phosphor widgets within the Angular 2 framework? Or better yet, are there plans to make Phosphor a true Angular 2 module?

Thanks,
John

In discussion in NYC this week, we saw a use case for a function on the Application that resolves a token if and when it is actually resolved. The use case is for a plugin that will use an interface if it is available, but does not explicitly require it to be available. An example is a main menu plugin may not be strictly required by the plugin, but we would like to add an entry to it if it is available. The signature may look like:

/**
 * Resolve a service of a given type if it becomes available.
 * 
 * @param token - The token for the service type of interest.
 *
 * @returns A promise which resolves to an instance of the requested
 *   service when it is registered.
 */  
weakResolveService<U>(token: Token<U>): Promise<U> {

}

While Qt uses the signal/slot names, in the JavaScript world the name callback is more common. We were going to rename slot to callback.