API Reference

Jump to bottom
Tingkai Liu edited this page Nov 2, 2020 · 5 revisions

Session API

The concept of a session is meant to reflect the state of a widget:

  1. The kernel that the widget is connected to and the related information (Kernel id, Kernel Path, Kernel Name)
  2. The Processor that the widget is connected in the backend
  3. The CommTarget and CommId of the comm that the widget uses to communication with its kernel.

All information can be accessed by the built-in icon on each FBLwidget's toolbar:

Processor API

The concept of Processor is directly related to the backend servers in Crossbar, an in fact synonymous with the Servers described here.

In essence, the processor keeps track of the backend databases that a given widget is connected to. It is a string attribute that corresponds to an entry in the backend server settings schemas.

Related APIs

All the following APIs are specified in the base FBLWidget class which are then inherited by the children widgets (Neu3DWidget, NeuGFXWidget). New widget classes should put custom logic for when processor is changed inside the set processor(newProcessor: string) setter, and use processorChanged signal to monitor processor changes.

  1. FFBOProcessor.NO_PROCESSOR = "No Processor": a constant that indicates no processor connected.
  2. get processor(): string: a getter that returns the string name of the processor currently connected to.
  3. setProcessor(newProcessor: string, startUp=false): a function that sets the value of the processor
    1. Sets the hasClient and dirty states of the widget if either the newProcessor is FFBOProcessor.NO_PROCESSOR or is different from the current processor.
    2. In children classes (Neu3D), the startUp flag allows for a different behavior at the initialization stage of the widget.
  4. set processor(newProcessor: string): a setter that calls the setProcessor(newProcessor: string, startUp=false) API, with additional logic specified in the inherited child classes (like showing meshes associated with a given processor in Neu3D).
  5. processorChanged: a signal that emits the name of the new processor when changed.

Dirty State API

The dirty state of the widget reflects whether there is unsaved changes that is required to be manually saved to layout restorer for state-persistence. The dirty state of widget will set the dirty state of the entire JupyterLab application, which will prompt user to save the state of the widgets to the widget tracker for restoration is user leaves or refreshes the webpage. It will not prompt the user to save the widget state if the user closes the widget directly from within the JLab interface. See the related issue for more details.

Related API

The intended way of using the API is to call setDirty which will trigger an event dirty which can be used to handle changes in the dirty state.

  1. setDirt(state: boolean): void
    1. setDirty to true (dirty) is typically emitted by the widget when the state changes.
    2. setDirty for false (clean) is typically emitted by the extension when the state changes have been saved by the user to the layout restorer's stateDB.
  2. isDirty: boolean: a value to check if the state is dirty
  3. dirty: a signal that emits the dirty state when changed

Client API

In commit db9eeed, a new API that tracks the status of ClientConnection was introduced.

This API allows for the front-end to keep track of whether a client object is associated with the current front-end widget. The status of the client can be checked by the hasClient getter or set by the setHasClient() function call. A call to setHasClient would always emit a clientConnect signal that emits a boolean flag of whether the widget has client.

Additionally, to force a manual check, user can use the checkForClient() function which will communicated with the kernel to check for client.

The API has been used to change the Neu3DWidget's input search bar placeholder and disable the search bar when the client is not found.

Clone this wiki locally

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
API Reference
Jump to bottom

Tingkai Liu edited this page Nov 2, 2020
·
5 revisions
Session API
The concept of a session is meant to reflect the state of a widget:
  1. The kernel that the widget is connected to and the related information (Kernel id, Kernel Path, Kernel Name)
  2. The Processor that the widget is connected in the backend
  3. The CommTarget and CommId of the comm that the widget uses to communication with its kernel.
All information can be accessed by the built-in icon on each FBLwidget's toolbar:

Processor API
The concept of Processor is directly related to the backend servers in Crossbar, an in fact synonymous with the Servers described here.
In essence, the processor keeps track of the backend databases that a given widget is connected to. It is a string attribute that corresponds to an entry in the backend server settings schemas.
Related APIs
All the following APIs are specified in the base FBLWidget class which are then inherited by the children widgets (Neu3DWidget, NeuGFXWidget). New widget classes should put custom logic for when processor is changed inside the set processor(newProcessor: string) setter, and use processorChanged signal to monitor processor changes.
  1. FFBOProcessor.NO_PROCESSOR = "No Processor": a constant that indicates no processor connected.
  2. get processor(): string: a getter that returns the string name of the processor currently connected to.
  3. setProcessor(newProcessor: string, startUp=false): a function that sets the value of the processor

    1. Sets the hasClient and dirty states of the widget if either the newProcessor is FFBOProcessor.NO_PROCESSOR or is different from the current processor.
    2. In children classes (Neu3D), the startUp flag allows for a different behavior at the initialization stage of the widget.
  4. set processor(newProcessor: string): a setter that calls the setProcessor(newProcessor: string, startUp=false) API, with additional logic specified in the inherited child classes (like showing meshes associated with a given processor in Neu3D).
  5. processorChanged: a signal that emits the name of the new processor when changed.
Dirty State API
The dirty state of the widget reflects whether there is unsaved changes that is required to be manually saved to layout restorer for state-persistence. The dirty state of widget will set the dirty state of the entire JupyterLab application, which will prompt user to save the state of the widgets to the widget tracker for restoration is user leaves or refreshes the webpage. It will not prompt the user to save the widget state if the user closes the widget directly from within the JLab interface. See the related issue for more details.
Related API
The intended way of using the API is to call setDirty which will trigger an event dirty which can be used to handle changes in the dirty state.
  1. setDirt(state: boolean): void
    1. setDirty to true (dirty) is typically emitted by the widget when the state changes.
    2. setDirty for false (clean) is typically emitted by the extension when the state changes have been saved by the user to the layout restorer's stateDB.
  2. isDirty: boolean: a value to check if the state is dirty
  3. dirty: a signal that emits the dirty state when changed
Client API
In commit db9eeed, a new API that tracks the status of ClientConnection was introduced.
This API allows for the front-end to keep track of whether a client object is associated with the current front-end widget.
The status of the client can be checked by the hasClient getter or set by the setHasClient() function call.
A call to setHasClient would always emit a clientConnect signal that emits a boolean flag of whether the widget has client.
Additionally, to force a manual check, user can use the checkForClient() function which will communicated with the kernel to check for client.
The API has been used to change the Neu3DWidget's input search bar placeholder and disable the search bar when the client is not found.
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
API Reference
Jump to bottom

Tingkai Liu edited this page Nov 2, 2020
·
5 revisions
Session API
The concept of a session is meant to reflect the state of a widget:
  1. The kernel that the widget is connected to and the related information (Kernel id, Kernel Path, Kernel Name)
  2. The Processor that the widget is connected in the backend
  3. The CommTarget and CommId of the comm that the widget uses to communication with its kernel.
All information can be accessed by the built-in icon on each FBLwidget's toolbar:

Processor API
The concept of Processor is directly related to the backend servers in Crossbar, an in fact synonymous with the Servers described here.
In essence, the processor keeps track of the backend databases that a given widget is connected to. It is a string attribute that corresponds to an entry in the backend server settings schemas.
Related APIs
All the following APIs are specified in the base FBLWidget class which are then inherited by the children widgets (Neu3DWidget, NeuGFXWidget). New widget classes should put custom logic for when processor is changed inside the set processor(newProcessor: string) setter, and use processorChanged signal to monitor processor changes.
  1. FFBOProcessor.NO_PROCESSOR = "No Processor": a constant that indicates no processor connected.
  2. get processor(): string: a getter that returns the string name of the processor currently connected to.
  3. setProcessor(newProcessor: string, startUp=false): a function that sets the value of the processor

    1. Sets the hasClient and dirty states of the widget if either the newProcessor is FFBOProcessor.NO_PROCESSOR or is different from the current processor.
    2. In children classes (Neu3D), the startUp flag allows for a different behavior at the initialization stage of the widget.
  4. set processor(newProcessor: string): a setter that calls the setProcessor(newProcessor: string, startUp=false) API, with additional logic specified in the inherited child classes (like showing meshes associated with a given processor in Neu3D).
  5. processorChanged: a signal that emits the name of the new processor when changed.
Dirty State API
The dirty state of the widget reflects whether there is unsaved changes that is required to be manually saved to layout restorer for state-persistence. The dirty state of widget will set the dirty state of the entire JupyterLab application, which will prompt user to save the state of the widgets to the widget tracker for restoration is user leaves or refreshes the webpage. It will not prompt the user to save the widget state if the user closes the widget directly from within the JLab interface. See the related issue for more details.
Related API
The intended way of using the API is to call setDirty which will trigger an event dirty which can be used to handle changes in the dirty state.
  1. setDirt(state: boolean): void
    1. setDirty to true (dirty) is typically emitted by the widget when the state changes.
    2. setDirty for false (clean) is typically emitted by the extension when the state changes have been saved by the user to the layout restorer's stateDB.
  2. isDirty: boolean: a value to check if the state is dirty
  3. dirty: a signal that emits the dirty state when changed
Client API
In commit db9eeed, a new API that tracks the status of ClientConnection was introduced.
This API allows for the front-end to keep track of whether a client object is associated with the current front-end widget.
The status of the client can be checked by the hasClient getter or set by the setHasClient() function call.
A call to setHasClient would always emit a clientConnect signal that emits a boolean flag of whether the widget has client.
Additionally, to force a manual check, user can use the checkForClient() function which will communicated with the kernel to check for client.
The API has been used to change the Neu3DWidget's input search bar placeholder and disable the search bar when the client is not found.
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
API Reference
Jump to bottom

Tingkai Liu edited this page Nov 2, 2020
·
5 revisions
Session API
The concept of a session is meant to reflect the state of a widget:
  1. The kernel that the widget is connected to and the related information (Kernel id, Kernel Path, Kernel Name)
  2. The Processor that the widget is connected in the backend
  3. The CommTarget and CommId of the comm that the widget uses to communication with its kernel.
All information can be accessed by the built-in icon on each FBLwidget's toolbar:

Processor API
The concept of Processor is directly related to the backend servers in Crossbar, an in fact synonymous with the Servers described here.
In essence, the processor keeps track of the backend databases that a given widget is connected to. It is a string attribute that corresponds to an entry in the backend server settings schemas.
Related APIs
All the following APIs are specified in the base FBLWidget class which are then inherited by the children widgets (Neu3DWidget, NeuGFXWidget). New widget classes should put custom logic for when processor is changed inside the set processor(newProcessor: string) setter, and use processorChanged signal to monitor processor changes.
  1. FFBOProcessor.NO_PROCESSOR = "No Processor": a constant that indicates no processor connected.
  2. get processor(): string: a getter that returns the string name of the processor currently connected to.
  3. setProcessor(newProcessor: string, startUp=false): a function that sets the value of the processor

    1. Sets the hasClient and dirty states of the widget if either the newProcessor is FFBOProcessor.NO_PROCESSOR or is different from the current processor.
    2. In children classes (Neu3D), the startUp flag allows for a different behavior at the initialization stage of the widget.
  4. set processor(newProcessor: string): a setter that calls the setProcessor(newProcessor: string, startUp=false) API, with additional logic specified in the inherited child classes (like showing meshes associated with a given processor in Neu3D).
  5. processorChanged: a signal that emits the name of the new processor when changed.
Dirty State API
The dirty state of the widget reflects whether there is unsaved changes that is required to be manually saved to layout restorer for state-persistence. The dirty state of widget will set the dirty state of the entire JupyterLab application, which will prompt user to save the state of the widgets to the widget tracker for restoration is user leaves or refreshes the webpage. It will not prompt the user to save the widget state if the user closes the widget directly from within the JLab interface. See the related issue for more details.
Related API
The intended way of using the API is to call setDirty which will trigger an event dirty which can be used to handle changes in the dirty state.
  1. setDirt(state: boolean): void
    1. setDirty to true (dirty) is typically emitted by the widget when the state changes.
    2. setDirty for false (clean) is typically emitted by the extension when the state changes have been saved by the user to the layout restorer's stateDB.
  2. isDirty: boolean: a value to check if the state is dirty
  3. dirty: a signal that emits the dirty state when changed
Client API
In commit db9eeed, a new API that tracks the status of ClientConnection was introduced.
This API allows for the front-end to keep track of whether a client object is associated with the current front-end widget.
The status of the client can be checked by the hasClient getter or set by the setHasClient() function call.
A call to setHasClient would always emit a clientConnect signal that emits a boolean flag of whether the widget has client.
Additionally, to force a manual check, user can use the checkForClient() function which will communicated with the kernel to check for client.
The API has been used to change the Neu3DWidget's input search bar placeholder and disable the search bar when the client is not found.
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
API Reference
Jump to bottom

Tingkai Liu edited this page Nov 2, 2020
·
5 revisions
Session API
The concept of a session is meant to reflect the state of a widget:
  1. The kernel that the widget is connected to and the related information (Kernel id, Kernel Path, Kernel Name)
  2. The Processor that the widget is connected in the backend
  3. The CommTarget and CommId of the comm that the widget uses to communication with its kernel.
All information can be accessed by the built-in icon on each FBLwidget's toolbar:

Processor API
The concept of Processor is directly related to the backend servers in Crossbar, an in fact synonymous with the Servers described here.
In essence, the processor keeps track of the backend databases that a given widget is connected to. It is a string attribute that corresponds to an entry in the backend server settings schemas.
Related APIs
All the following APIs are specified in the base FBLWidget class which are then inherited by the children widgets (Neu3DWidget, NeuGFXWidget). New widget classes should put custom logic for when processor is changed inside the set processor(newProcessor: string) setter, and use processorChanged signal to monitor processor changes.
  1. FFBOProcessor.NO_PROCESSOR = "No Processor": a constant that indicates no processor connected.
  2. get processor(): string: a getter that returns the string name of the processor currently connected to.
  3. setProcessor(newProcessor: string, startUp=false): a function that sets the value of the processor

    1. Sets the hasClient and dirty states of the widget if either the newProcessor is FFBOProcessor.NO_PROCESSOR or is different from the current processor.
    2. In children classes (Neu3D), the startUp flag allows for a different behavior at the initialization stage of the widget.
  4. set processor(newProcessor: string): a setter that calls the setProcessor(newProcessor: string, startUp=false) API, with additional logic specified in the inherited child classes (like showing meshes associated with a given processor in Neu3D).
  5. processorChanged: a signal that emits the name of the new processor when changed.
Dirty State API
The dirty state of the widget reflects whether there is unsaved changes that is required to be manually saved to layout restorer for state-persistence. The dirty state of widget will set the dirty state of the entire JupyterLab application, which will prompt user to save the state of the widgets to the widget tracker for restoration is user leaves or refreshes the webpage. It will not prompt the user to save the widget state if the user closes the widget directly from within the JLab interface. See the related issue for more details.
Related API
The intended way of using the API is to call setDirty which will trigger an event dirty which can be used to handle changes in the dirty state.
  1. setDirt(state: boolean): void
    1. setDirty to true (dirty) is typically emitted by the widget when the state changes.
    2. setDirty for false (clean) is typically emitted by the extension when the state changes have been saved by the user to the layout restorer's stateDB.
  2. isDirty: boolean: a value to check if the state is dirty
  3. dirty: a signal that emits the dirty state when changed
Client API
In commit db9eeed, a new API that tracks the status of ClientConnection was introduced.
This API allows for the front-end to keep track of whether a client object is associated with the current front-end widget.
The status of the client can be checked by the hasClient getter or set by the setHasClient() function call.
A call to setHasClient would always emit a clientConnect signal that emits a boolean flag of whether the widget has client.
Additionally, to force a manual check, user can use the checkForClient() function which will communicated with the kernel to check for client.
The API has been used to change the Neu3DWidget's input search bar placeholder and disable the search bar when the client is not found.
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
API Reference
Jump to bottom

Tingkai Liu edited this page Nov 2, 2020
·
5 revisions
Session API
The concept of a session is meant to reflect the state of a widget:
  1. The kernel that the widget is connected to and the related information (Kernel id, Kernel Path, Kernel Name)
  2. The Processor that the widget is connected in the backend
  3. The CommTarget and CommId of the comm that the widget uses to communication with its kernel.
All information can be accessed by the built-in icon on each FBLwidget's toolbar:

Processor API
The concept of Processor is directly related to the backend servers in Crossbar, an in fact synonymous with the Servers described here.
In essence, the processor keeps track of the backend databases that a given widget is connected to. It is a string attribute that corresponds to an entry in the backend server settings schemas.
Related APIs
All the following APIs are specified in the base FBLWidget class which are then inherited by the children widgets (Neu3DWidget, NeuGFXWidget). New widget classes should put custom logic for when processor is changed inside the set processor(newProcessor: string) setter, and use processorChanged signal to monitor processor changes.
  1. FFBOProcessor.NO_PROCESSOR = "No Processor": a constant that indicates no processor connected.
  2. get processor(): string: a getter that returns the string name of the processor currently connected to.
  3. setProcessor(newProcessor: string, startUp=false): a function that sets the value of the processor

    1. Sets the hasClient and dirty states of the widget if either the newProcessor is FFBOProcessor.NO_PROCESSOR or is different from the current processor.
    2. In children classes (Neu3D), the startUp flag allows for a different behavior at the initialization stage of the widget.
  4. set processor(newProcessor: string): a setter that calls the setProcessor(newProcessor: string, startUp=false) API, with additional logic specified in the inherited child classes (like showing meshes associated with a given processor in Neu3D).
  5. processorChanged: a signal that emits the name of the new processor when changed.
Dirty State API
The dirty state of the widget reflects whether there is unsaved changes that is required to be manually saved to layout restorer for state-persistence. The dirty state of widget will set the dirty state of the entire JupyterLab application, which will prompt user to save the state of the widgets to the widget tracker for restoration is user leaves or refreshes the webpage. It will not prompt the user to save the widget state if the user closes the widget directly from within the JLab interface. See the related issue for more details.
Related API
The intended way of using the API is to call setDirty which will trigger an event dirty which can be used to handle changes in the dirty state.
  1. setDirt(state: boolean): void
    1. setDirty to true (dirty) is typically emitted by the widget when the state changes.
    2. setDirty for false (clean) is typically emitted by the extension when the state changes have been saved by the user to the layout restorer's stateDB.
  2. isDirty: boolean: a value to check if the state is dirty
  3. dirty: a signal that emits the dirty state when changed
Client API
In commit db9eeed, a new API that tracks the status of ClientConnection was introduced.
This API allows for the front-end to keep track of whether a client object is associated with the current front-end widget.
The status of the client can be checked by the hasClient getter or set by the setHasClient() function call.
A call to setHasClient would always emit a clientConnect signal that emits a boolean flag of whether the widget has client.
Additionally, to force a manual check, user can use the checkForClient() function which will communicated with the kernel to check for client.
The API has been used to change the Neu3DWidget's input search bar placeholder and disable the search bar when the client is not found.
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
API Reference
Jump to bottom

Tingkai Liu edited this page Nov 2, 2020
·
5 revisions
Session API
The concept of a session is meant to reflect the state of a widget:
  1. The kernel that the widget is connected to and the related information (Kernel id, Kernel Path, Kernel Name)
  2. The Processor that the widget is connected in the backend
  3. The CommTarget and CommId of the comm that the widget uses to communication with its kernel.
All information can be accessed by the built-in icon on each FBLwidget's toolbar:

Processor API
The concept of Processor is directly related to the backend servers in Crossbar, an in fact synonymous with the Servers described here.
In essence, the processor keeps track of the backend databases that a given widget is connected to. It is a string attribute that corresponds to an entry in the backend server settings schemas.
Related APIs
All the following APIs are specified in the base FBLWidget class which are then inherited by the children widgets (Neu3DWidget, NeuGFXWidget). New widget classes should put custom logic for when processor is changed inside the set processor(newProcessor: string) setter, and use processorChanged signal to monitor processor changes.
  1. FFBOProcessor.NO_PROCESSOR = "No Processor": a constant that indicates no processor connected.
  2. get processor(): string: a getter that returns the string name of the processor currently connected to.
  3. setProcessor(newProcessor: string, startUp=false): a function that sets the value of the processor

    1. Sets the hasClient and dirty states of the widget if either the newProcessor is FFBOProcessor.NO_PROCESSOR or is different from the current processor.
    2. In children classes (Neu3D), the startUp flag allows for a different behavior at the initialization stage of the widget.
  4. set processor(newProcessor: string): a setter that calls the setProcessor(newProcessor: string, startUp=false) API, with additional logic specified in the inherited child classes (like showing meshes associated with a given processor in Neu3D).
  5. processorChanged: a signal that emits the name of the new processor when changed.
Dirty State API
The dirty state of the widget reflects whether there is unsaved changes that is required to be manually saved to layout restorer for state-persistence. The dirty state of widget will set the dirty state of the entire JupyterLab application, which will prompt user to save the state of the widgets to the widget tracker for restoration is user leaves or refreshes the webpage. It will not prompt the user to save the widget state if the user closes the widget directly from within the JLab interface. See the related issue for more details.
Related API
The intended way of using the API is to call setDirty which will trigger an event dirty which can be used to handle changes in the dirty state.
  1. setDirt(state: boolean): void
    1. setDirty to true (dirty) is typically emitted by the widget when the state changes.
    2. setDirty for false (clean) is typically emitted by the extension when the state changes have been saved by the user to the layout restorer's stateDB.
  2. isDirty: boolean: a value to check if the state is dirty
  3. dirty: a signal that emits the dirty state when changed
Client API
In commit db9eeed, a new API that tracks the status of ClientConnection was introduced.
This API allows for the front-end to keep track of whether a client object is associated with the current front-end widget.
The status of the client can be checked by the hasClient getter or set by the setHasClient() function call.
A call to setHasClient would always emit a clientConnect signal that emits a boolean flag of whether the widget has client.
Additionally, to force a manual check, user can use the checkForClient() function which will communicated with the kernel to check for client.
The API has been used to change the Neu3DWidget's input search bar placeholder and disable the search bar when the client is not found.
Clone this wiki locally

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
API Reference
Jump to bottom

Tingkai Liu edited this page Nov 2, 2020
·
5 revisions
Session API
The concept of a session is meant to reflect the state of a widget:
  1. The kernel that the widget is connected to and the related information (Kernel id, Kernel Path, Kernel Name)
  2. The Processor that the widget is connected in the backend
  3. The CommTarget and CommId of the comm that the widget uses to communication with its kernel.
All information can be accessed by the built-in icon on each FBLwidget's toolbar:

Processor API
The concept of Processor is directly related to the backend servers in Crossbar, an in fact synonymous with the Servers described here.
In essence, the processor keeps track of the backend databases that a given widget is connected to. It is a string attribute that corresponds to an entry in the backend server settings schemas.
Related APIs
All the following APIs are specified in the base FBLWidget class which are then inherited by the children widgets (Neu3DWidget, NeuGFXWidget). New widget classes should put custom logic for when processor is changed inside the set processor(newProcessor: string) setter, and use processorChanged signal to monitor processor changes.
  1. FFBOProcessor.NO_PROCESSOR = "No Processor": a constant that indicates no processor connected.
  2. get processor(): string: a getter that returns the string name of the processor currently connected to.
  3. setProcessor(newProcessor: string, startUp=false): a function that sets the value of the processor

    1. Sets the hasClient and dirty states of the widget if either the newProcessor is FFBOProcessor.NO_PROCESSOR or is different from the current processor.
    2. In children classes (Neu3D), the startUp flag allows for a different behavior at the initialization stage of the widget.
  4. set processor(newProcessor: string): a setter that calls the setProcessor(newProcessor: string, startUp=false) API, with additional logic specified in the inherited child classes (like showing meshes associated with a given processor in Neu3D).
  5. processorChanged: a signal that emits the name of the new processor when changed.
Dirty State API
The dirty state of the widget reflects whether there is unsaved changes that is required to be manually saved to layout restorer for state-persistence. The dirty state of widget will set the dirty state of the entire JupyterLab application, which will prompt user to save the state of the widgets to the widget tracker for restoration is user leaves or refreshes the webpage. It will not prompt the user to save the widget state if the user closes the widget directly from within the JLab interface. See the related issue for more details.
Related API
The intended way of using the API is to call setDirty which will trigger an event dirty which can be used to handle changes in the dirty state.
  1. setDirt(state: boolean): void
    1. setDirty to true (dirty) is typically emitted by the widget when the state changes.
    2. setDirty for false (clean) is typically emitted by the extension when the state changes have been saved by the user to the layout restorer's stateDB.
  2. isDirty: boolean: a value to check if the state is dirty
  3. dirty: a signal that emits the dirty state when changed
Client API
In commit db9eeed, a new API that tracks the status of ClientConnection was introduced.
This API allows for the front-end to keep track of whether a client object is associated with the current front-end widget.
The status of the client can be checked by the hasClient getter or set by the setHasClient() function call.
A call to setHasClient would always emit a clientConnect signal that emits a boolean flag of whether the widget has client.
Additionally, to force a manual check, user can use the checkForClient() function which will communicated with the kernel to check for client.
The API has been used to change the Neu3DWidget's input search bar placeholder and disable the search bar when the client is not found.
Clone this wiki locally