I would like to have i3-like keybinding modes in awesomeWM. What seems to be the easiest way to implement it?
In the default config, an array called globalkeys is set up and then "made active" via root.keys(globalkeys). From a quick look at the i3 documentation, I guess your desired behaviour is something like this: you just copy the definition of globalkeys and call it e.g. globalkeys2. Then you can change the key bindings in there and switch to this mode by calling root.keys(globalkeys2).
Related
I am familiar with bindings with curly braces, like {{variable}}, from Polymer 0.5.
However, in examples and code snippets for the release version of Polymer, I've begun to notice bindings with square brackets, such as [[variable]], as well.
Does {{variable}} mean something different now, or is it the same and [[variable]] is just an addition? What is the difference between binding to [[variable]] and {{variable}} in Polymer?
Just as you've noticed, there are now two different syntaxes for data-binding, which have different purposes:
{{variable}} indicates that you would like Polymer to automatically detect whether or not the binding should be one-way or two-way.
[[variable]] indicates that you want the binding to one-way only.
Why the change?
Polymer 1.x differs from older versions is that bindings are now one-way by default, much unlike 0.5, where they were always two-way.
In other words, if you write
<my-element some-property="{{myVariable}}"></my-element>
then by default, when
myVariable is changed, Polymer updates the binding, and thus updates my-element's someProperty.
someProperty is changed, Polymer does not update the binding to myVariable.
This is always the case unless you set notify:true on the property inside my-element:
Polymer({
is: 'my-element',
properties: {
someProperty: {
notify: true,
...
With notify: true, the binding is now two-way, so when
myVariable is changed, Polymer updates the binding to someProperty.
someProperty is changed, Polymer also updates the binding to myVariable.
This behaviour (when using notify: true) used to be default in 0.5; now you must ask for it explicitly.
When to use [[variable]]
There's no technical reason why you must use [[variable]], because Polymer will automatically detect whether bindings are one or two-way with {{variable}}. So why would you use it?
Let's say you're working in a large project, and you know that based on the way that data flows in a particular page/element, a certain property should never be changed by the element it is being bound to, for example in the case of an element which functionally serves a purpose as a label:
<display-data source-data="{{data}}"></display-data>
...
<data-editor source-data="{{data}}"></data-editor>
Everything looks good! The data property is bound to both the display-data element and data-editor elements, and will be automatically shared between them. (In this example, assume display-data's sole purpose is to preview the data that it is bound to.)
One day, you or someone else is editing display-data, and you forget about the situation in which it is being used in above. For an entirely different use-case, you or the other developer would like display-data to also format or otherwise modify the data it is given and push it back towards any other elements that may be bound to it. You/they edit display-data as such:
Add notify: true to sourceData, to allow two-way data-binding.
Add code into display-data which modifies the sourceData property.
This works great for all the pages that needed this functionality. But on the page mentioned before, this was not intended and ends up garbling the data that data-editor sees!
This problem would have been avoided had:
The dev team communicated better and had been more considerate of where elements are being used,
and/or [[data]] was used instead of {{data}} in the page/element in question.
With
<display-data source-data="[[data]]"></display-data>
...
<data-editor source-data="{{data}}"></data-editor>
data-editor can change data, but display-data will only ever be able to read data, and won't be able to change its value when it changes the value of its sourceData property, even when notify: true is set on sourceData.
Therefore, it could potentially be a good idea to:
Use [[variable]] whenever you need to bind to variable. This way, you enforce the direction through which data should flow in your element/page/application.
Use {{variable}} whenever you know that the binding must be two-way.
According to the documentation,
To make your code more easier to read, you may want to use the [[property]] form by default, and only use {{property}} for two-way bindings.
This being said, however, it ultimately comes down to a matter of choice. If you want to forego the use of [[variable]], no one is stopping you and you will not start any fires.
I have an observer to a value "App.selectedValue". I also have another Ember object that has a binding (App.someObj.appValueBinding) to App.selectedValue. However, when my observer is called, the binding of App.someObj is not updated.
This is illustrated in http://jsfiddle.net/Ur2Qj/8/
In the jsfiddle, you can see in the Chrome debugger or FireBug, that App.selectedValue and App.someObj.appValue have different values, even tho' the latter is bound to the former.
Seems like the binding should be updated when the observer is called. Is this expected behavior in Emberjs or is it a bug? Is there a work-around?
Thanks for looking at this!
Take a look at this: http://jsfiddle.net/ud3323/GUHCD/ (in JavaScript; I don't like CoffeeScript... sorry).
The two main things you've got wrong here is not using get() and set() properly and in your observer you need to set App.someController.content after the end of the current runloop (which means after all the other bindings have taken place). You do this by using Ember.run.next(). You could also use Ember.run.sync() there as well.
Oh and you need to use jQuery 1.7.1. Version 1.5.2 is not compatible with Ember.
I have a menu that has a structure like this:
Elements
A
B
C\
1\
a
b
2\
a
b
D
where Elements is displayed on the menubar anything with a \ has a sub-menu.
In this example I have two a's. I want to be able to distinguish which a was clicked buy getting a list like this for example ['a', '1', 'C', 'Elements'].
Does Qt have a function where I can look up the top menus, or a way of backtracking?
I don't want to have to write a connection for each QAction in the menu because that would be a lot of extra code and rather redundant I think.
Make use of the QMenu.triggered, QMenuBar.triggered, and QToolBar.actionTriggered signals.
These signals all pass a reference to the action that was triggered, thus avoiding the need to connect each action to an individual slot.
An alternative approach would be to create a subclass of QAction that allows a handler to be passed as an argument to its constructor. All the boiler-plate connection code could then be factored out into the __init__ method. This approach can be more flexible if there are a lot of actions that are re-used in several different menus and toolbars.
QSignalMapper might be what you are looking for.
I found another way of solving the problem, below, but I'm going with ekhumoro's answer because his was is cleaner I think.
backtrack = [str(event.text())]
previousWidget = event.associatedWidgets()[0]
while previousWidget.__class__.__name__ != 'QMenuBar':
backtrack.append(str(previousWidget.title()))
previousWidget = previousWidget.parent()
print backtrack
I tried to change like that(worked on the 'navigator' object)
page->mainFrame()->evaluateJavaScript(
"var navigator=new Object;"
"navigator.someProperty=...");
In that case, I would use the signal javaScriptWindowObjectCleared
That kicks in just before load, when the window has been cleared.
You probably want to validate the origin before doing anything, though.
That being said - and I am not too sure what you want to achieve - I wouldn't manipulate the javascript scope like that. Maintaining and deploying javascript is easier than doing the same for C++. So, I would instead just expose a simple C++ object to the javascript scope (via addToJavaScriptWindowObject), and then have the javascript code test this object and do what it has to do.
Either way, hope this helps.
how come that when I attach onchange by attribute and call it
onchange="validateDate(FPR_CURR_FROM);"
it works, but when I use a ASP .NET validator, and my attached function is called like :
function anonymous() {
ValidatorOnChange(event);
validateDate(FPR_CURR_FROM);
}
I get error: FPR_CURR_FROM is undefined.
First off: I know that using FPR_CURR_FROM to access element is BAD, and I should use getElementByID etc... And I will change it eventually. But as I bumped into that code, I'm curious what caused it - propably visibility of variables I guess.
I think it's a scoping issue, yes, it would take seeing more code and how anonymous is called, but that is what it looks like to me from what I see... One way around that is to attach the FPR_CURR_FROM variable to the window object, and access it via window.FPR_CURR_FROM...