On CamanJS there is an example of adding some effects and new layer:
Caman("#image", function () {
// We can call any filter before the layer
this.exposure(-10);
// Create the layer
this.newLayer(function () {
// Change the blending mode
this.setBlendingMode("multiply");
// Change the opacity of this layer
this.opacity(80);
// Now we can *either* fill this layer with a
// solid color...
this.fillColor('#6899ba');
// ... or we can copy the contents of the parent
// layer to this one.
this.copyParent();
// Now, we can call any filter function though the
// filter object.
this.filter.brightness(10);
this.filter.contrast(20);
});
// And we can call more filters after the layer
this.clip(10);
this.render();
});
It works ok. I've tried to add second layer by calling this code again with other parameters to image i've added layer before, but than the first layer dissapears.
On the website there are also examples how to add single effects. They are great, but they call only one filter at a time.
What i would like to acomplish is to, based on user settings, add for example one layer, two layers, or apply opacity and new layer.
And also i would like it to work every time on the base image, not the image effect from last filtering.
So, what is the proper way to change base image with multiple filters and layers according to user settings using CamanJS?
You probably figured this out by now, but you can call "this.revert(false)" after render to make sure you are editing the base image.
You can add multiple effects by calling all effects in the process and using if/then statements to determine user input. For example=
when button is clicked, x+=1
if (x%2===0){this.yourfilter();}
I'm just getting started though.
Related
What I need to get done
I want to make a simple controlled lexical plaintex editor - one which is controlled by a parent string field.
But I'm really struggling with getting my editor to simultaneously:
Be adopting parent state whenever it changes
Retain Selection after adopting parent state
Not automatically focus just because the external value changed (and got adopted)
Where I got so far
I tried a couple things, but this is the closest I got - Sandbox here:
export const useAdoptPlaintextValue = (value: string) => {
const [editor] = useLexicalComposerContext();
useEffect(() => {
editor.update(() => {
const initialSelection = $getSelection()?.clone() ?? null;
$getRoot().clear();
$getRoot().select(); // for some reason this is not even necessary
$getSelection()?.insertText(value);
$setSelection(initialSelection);
});
}, [value, editor]);
};
This approach works well when writing into the input itself, but the imperative adoption of value only works until the input was first selected. After it has already been selected (even when un-selected again), editor only adopts the value for one "render frame" and then immediately re-renders with the old value.
I'm clearly doing something wrong with selection, because:
removing setSelection(initialSelection) also removes this problem - but then selection doesn't get maintained between updates, which is also unacceptable.
I'm getting this error on every keystroke:
updateEditor: selection has been lost because the previously selected nodes have been removed and selection wasn't moved to another node. Ensure selection changes after removing/replacing a selected node.
... It seems to me that initialSelection retains a reference to nodes that are deleted by $getRoot().clear(), but I tried working my way around it and got nowhere.
I'll be glad for any advice/help about my code or towards my goal.
Thank you 🙏
Bit of background information on how Lexical works (feel free to skip to the next point)
Lexical utilizes EditorState as the source of truth for editor content changes and selection. When you do an editor.update, Lexical creates a brand new EditorState (a clone of the previous) and modifies it accordingly.
At a later point in time (synchronously or asynchronously), these changes are reflected to the DOM (unless they come from the DOM directly; then we update the EditorState immediately).
Lexical automatically recomputes selection when the DOM changes or nodes are manipulated. That's for a very good reason, selection is hard is to get right:
Selected node is removed but has siblings -> move to sibling
Selected node is removed but has no siblings -> find nearest parent
Text node content changes -> understand whether the current selection fits
DOM selection changes because of composition or beforeinput -> replicate selection
etc.
This selection recomputation is also initially done to the EditorState (unless it comes from the DOM directly) and later backed to the DOM.
Focus restoration
By default selection reconciliation will restore DOM selection to make sure it matches the source of truth: the EditorState. So wherever you move the selection (even if it's part of the automatic selection restore described above) will move the focus to the contenteditable.
There are 3 exceptions to this rule:
$setSelection(null); -> clears selection
readonly editor.setReadOnly -> you are not supposed to interact with a readonly editor
Collaboration editor.update(() => ..., {tag: 'collaboration'}) -> we created an exception for this
I would never recommend 1. for this purpose since the editor will lose track of the position.
The second makes sense when the editor is truly readonly.
The third can work for you as a temporary patch but ultimately you want a better solution than this.
Another temporary patch for your use case would be to store document.selection and restore it as soon as the Lexical contenteditable takes control.
That said, it seems like a reasonable use case to be able to skip DOM selection reconciliation at times programatically. I have created this proposal (https://github.com/facebook/lexical/pull/2134).
Side note on your error
Your selection is likely on the paragraph or some text node. When you clear the root, you destroy the element. In most cases, we attempt to restore the selection as listed above but selection restoration is limited to valid selections. In your case you are moving the selection to an unattached node (already removed as part of root.clear()).
I want to add a new functionality to my application: executing a action every time a specific column is changed inside of a specific modal. This column is changed in many places in the application via several methods (save(), saveAll(), updateAll(), saveField()).
My first approach was to use the beforeSave/afterSave callbacks to handle this for every change on Modal level. However, I noticed that these callbacks aren't being done with updateAll() and saveField().
Is there a easy way to track all changes made to a specific column for a specific modal, regardless of the method being used in modal?
You can create your own callback and use it with save all, as described here
I've found numerous posts regarding this, but I haven't been able to work out a solution, largely due to the fact that I don't have a very thorough understanding of OpenGL or GLKit.
I added the method described here to my project.
They specifically mention:
Important: You must call glReadPixels before calling
EAGLContext/-presentRenderbuffer: to get defined results unless you're
using a retained back buffer.
I tried unsuccessfully to set up a retained back buffer and given that doing so has 'adverse performance implications' I would rather avoid it.
The problem is, according to a comment in another post:
In GLKit, the GLKView will automatically present itself and discard unneeded renderbuffers at the end of each rendering cycle.
That being the case, how can I call the 'Snapshot' method at the appropriate time when using GLKit?
To date, in iOS 5 I get a weirdly yellow coloured version of the scene (as though there were no other colours) and in iOS 6 I get a pure white image (I imagine because I am using white as the clear colour).
Further, I have no idea what they (apple) are talking about in this comment:
// If your application only creates a single color renderbuffer which is already bound at this point,
// this call is redundant, but it is needed if you're dealing with multiple renderbuffers.
// Note, replace "_colorRenderbuffer" with the actual name of the renderbuffer object defined in your class.
glBindRenderbufferOES(GL_RENDERBUFFER_OES, _colorRenderbuffer);
so I have commented out the call in my app. If it matters my objects are using VBOs with position, texture coords and colour.
not sure that that is a good title ...
I can get code behind a button to:
TabBar.activeTab.setTitle("New Tab");
but I need to do something like:
TabBar.activeTab.items = { title: "New Tab"
};
so I can eventually automate several tab properties in a loop:
TabBar.activeTab.items = { [key]: [value]
};
Am I correct in thinking config and items can only be used on construct()? Is there a way of doing the above? tia.
It depends on the implementation of the component and config property in question whether it can simply be set or requires a method call to be applied.
You are correct that in ExtJs many config properties are interpreted at construction time. Some are interpreted at render time. Once an Ext.Component is rendered almost all properties require an explicit method call to be applied correctly.
In general, I recommend to always use a method call to change a property after construction time if available in order to not break the inner workings of the component. If you look at the implementation of Ext.panel.Panel#setTitle you can see that there is a lot of stuff going on under the hood, e.g. event firing, etc.
ExtJs 4 configuration
Ext 4 introduced an explicit 'config' mechanism that might serve your purpose. However, my understanding is that most ExtJs components are not (yet?) using it.
Check out '2. Configuration' in the ExtJs Class System Guide
Create objects from xtype/config literals
If you want to add new components to a container (e.g. tabs to a tab panel) it would be rather easy to accomplish.
Use Ext.ComponentManager#create (see [docs][2]) to create an actual component object/instance from your config literal.
Ext.container.Container#add actually calls this method internally, so you can simply pass config objects to the add method.
If you want to remove or add tabs to a panel, there is now way around calling the proper methods.
applyConfig()
Of course you could always implement your own applyConfig method that supports changing certain component configuration properties at runtime by 'translating' the config into the proper method calls.
I'm really new to the MVC pattern in Ext.
I have a tabpanel with multiple instances of the same component (let's call it product), each should call the server when it's opened, with an id parameter.
Right now, in order to create these tabs - I use this in the Product controller
Which creates a new instance of a view, but I feel like it's really incorrect.
createMainView: function (opts) {
return Ext.widget("productDisplay", opts);
}
I call it from my "main" controller, like this:
var tab = this.application.getController("Products")
.createMainView({ productId : id, closable: true })
tabs.add(tab);
tabs.setActiveTab(tab);
What's the correct way to properly use multiple instances of a view, each having an instance of one store and behavior (via the controller).
Can I use one named store for them (with a js file under app/store/product.js)?
Should I manually call load on the store from the controller (to pass the productId), or is there a nicer way?
It's kind of very broad and interesting question which require big and thorough explanation (which you can find btw on the Sencha.com in their guides and manuals). I would like highlight couple points so you have something to start with:
Stores are usually global objects. You don't keep two instances of one store in general. You can use filtering (local or remote) if you need to present information from the that store in several different views. The only time you would need to clone store is if you want to present different information from that store in 2+ different views at the same time.
Controllers are usually spawned by main application object. You don't have to do anything special - just list them in the controllers: [] property. And then spawed when application is launched (before their views are created and rendered). Keep that in mind.
If you have modal view - it's ok to create it manually and either re-use it or destroy and re-create later. You can add filtering and loading to controller which creates these views. And you can re-use same view/controller objects for different tabs if you want.
If your views are presenting one instance of an object (like one product is displayed on each tab) - don't attach stores to those views. Just pass them individual model (record).
I would recommend creating the stores that relate only to that view instance inside of the view's initComponent method.
Your controller's control handlers should be coded in a way that they can differentiate which view dispatched the event. This should not be too difficult because almost all view events contain a reference to the component which fired the event. You could then use the relative query selectors, e.g.: myEventFiringComponent.up('anotherComponent') or myEventFiringComponent.down('anotherComponent') to get a handle on a different component in the same view if you need to.
Please see this post for a full explanation.