Code: Select all
from pivy import coin
def test(event_callback):
event = event_callback.getEvent()
print(event.getState())
view = Gui.ActiveDocument.ActiveView
view.addEventCallbackPivy(coin.SoKeyboardEvent.getClassTypeId(), test)
Exactly this is the problem. To solve it I went from key "v" to key "i".The actual problem is that when a callback function is registered to the viewer it doesn't get these events as first and thus has no chance to handle them. And this makes it difficult because the macro coder cannot rely on an unreserved short cut to be still unreserved in the future.
That would be difficult. A better way is to change the priority queue so that a viewer with a callback function will get the events as very first and tells the system which events it handled. But I just don't know if this is (easily) doable.Maybe we can choose some keys which do not get used by the system and are reserved for 3rd-party /moduls? Currently I am using i, l, g.
It makes some sense but it won't resolve the main problem. As that problem is not resolvable anyway in a scenario where you have 100 workbenches and all would like to use sane shortcut combinations for commands. I was already thinking about this in the past:looo wrote:Maybe we can choose some keys which do not get used by the system and are reserved for 3rd-party /moduls? Currently I am using i, l, g.
keys are only used at a specific task, and only active within this specific workbench. I always thought there are some system-shortcut and some workbench specific. While the system-shortcuts are available in all workbenches, workbench-specific are disabled after changing the current workbench. Where is the problem?triplus wrote:It makes some sense but it won't resolve the main problem. As that problem is not resolvable anyway in a scenario where you have 100 workbenches and all would like to use sane shortcut combinations for commands. I was already thinking about this in the past:
As for the short story:looo wrote:Where is the problem?
It doesn't work like that.keys are only used at a specific task, and only active within this specific workbench. I always thought there are some system-shortcut and some workbench specific. While the system-shortcuts are available in all workbenches, workbench-specific are disabled after changing the current workbench.
It doesn't work like that.
Don't take the "i" !Sooner or later it will happen with the key i you now use instead.
I won't. Somebody else will or already has done that.looo wrote:Don't take the "i" !
Most of the commands you see on the toolbars should use ShortCuts or similar solution in the future yes. And each command on the toolbar should have sensible key combination set. If you look in the tooltips ATM a lot of commands don't have any keyboard shortcut set.So in your opinion shortcuts should be always available? And all keys should be assigned to shortcuts?
This is one aspect i need to think about more. But lets say i don't end up with the solution i am satisfied with. The end result will still be more keyboard combination made available for such use case compared to the current situation.I wonder if this would really makes sense. Maybe you can have a short look at my use case. This is a situation where a key is very useful (at least for me).
Doing this with a double key combination would double the work.
Currently all the keys do need to be assigned and still a lot of commands can't have sensible keyboard shortcut combination set. The end user needs to use only 2 workbenches (commands) (out of lets say possible 100) for the involved shortcuts to stop working.While I understand the reason why some of the keys may used by the system,(eg v) I don't like the idea to have every key assigned to a shortcut. I think this is really not necessary. And having 100 workbenches available at the same time is also not necessary.
When that happens the number of pre-set shortcuts for commands will hopefully start to grow exponentially!If your described system will get into master I would at least vote to disable all not useful shortcuts at a task. For example in the task I have posted, all other commands are disabled anyway, so also the key-press events referring to these commands should be disabled, and shouldn't be active.