I asked a similar question here: Embedded - GPIO Key does not register but I am tying to take a step back and focus on just one part of that question.
My board has 3 gpio-keys already built in: power, volume up, and volume down. When calling cat /sys/kernel/debug/gpio they show up under GPIOs 256-319, platform/c2f0000.gpio, tegra-gpio-aon: as expected. When in my dts file I create a new gpio-key node, no matter what is in the node, the buttons no longer show up in /sys/kernel/degub/gpio but are lsited in /proc/device-tree/gpio-keys.
If I call my node something different the buttons do not disappear, even if the new node is gpio-key compatible. I should be able to add properties to a node by inheriting from a base dtsi. Why does my additions to the gpio-key seem to disable the other keys?
Related
In the Squeak System Browser, I see that there are many class categories related to Etoys:
But how do I access Etoys from Squeak? How do I get something like the screenshot shown below?
(Source of Etoys screenshot: https://commons.wikimedia.org/wiki/File:Squeak_screenshot.png)
There are also Squeak versions set up specifically for Etoys, e.g.:
https://squeak.js.org/etoys/#fullscreen
I think there is easier way than Leandro is proposing.
Just run the Workspace from the menu where you type:
Project enterNewWithInitialBalloons
Select it with mouse and run it - Do it (alt+d). Application should start. I'm unfamiliar with the application. To me it looks similar to the picture you show.
Edit: how did I find it?
I searched through the source code. I have to agree that this is not straight forward.
First I tried to find anything that has to do with Etoys project/class. I tried to find anything that would indicate that you can start it.
This way I found Etoys-Experimental package with class EToysLauncher. The word launcher to me sounded like it could be launched. I looked at the class of the EToysLauncher where I found instance creating protocol where you can find these methods (remember we are still at the experimental package!):
#buildGallery
#buildPanel
#openGallery
#openPanel
If you go through these e.g. EToysLauncher openPanel you will get a message doesNotUnderstand: #latestProjectVersionsFromFileEntries. I then started to investigate the Walkback. I tried to check what is the issue here. I got this message because of the last line ^ Project latestProjectVersionsFromFileEntries: entries.
I went to the Project>>latestProjectVersionsFromFileEntries: to check what it is actually doing. In meantime I have inspected the values from the entries variable in the debugger. In the entries I could find an OrderedCollection but nothing what would satisfy #('*.pr' '*.pr.gz' '*.project') from the method. So I thought to myself, that perphaps the Project itself could satisfy it.
I went to the Project class and protocol Etoys-Squeakland-instance creation where I found two methods #enterNew and #enterNewWithInitialBalloons.
The #enterNew gives doesNotUnderstand: #newMorphicOn: so I skipped that one and tried the #enterNewWithInitialBalloons, which worked and since it is in the protocol Etoys-Squeakland-instance creation I came to the conclusion it has create Etoys-Squeakland new instance.
Edit: Show shared flaps?
Yes, you can activate the flaps also via Show shared flaps.
There is, however, quite a difference between running the Project enterNewWithInitialBalloons and Showing the shared flaps via Preferences.
If you start the Etoys via the Project enterNewWithInitialBalloons you will start completely new project (your currently opened windows will be hidden). To see your previous windows you need to either Porojects/Enter Project and switch to the HomeProject or you have to close the newly opened project via Projects/Close This Project.
The source that shows it is:
enterNewWithInitialBalloons
| newP |
newP := MorphicProject new.
newP world addMorph: (DoCommandOnceMorph new extent: 1#1; actionBlock: [SugarNavigatorBar putUpInitialBalloonHelp]; yourself).
newP enter.
This creates new MorphicProject and to this project it adds new Morph.
On the other hand, if you start it with Preferences/Show shared flaps the flaps will be just added to your current environment without creating a new project.
The source that shows it is: Preferences class >>sharedFlapsSettingChanged
sharedFlapsSettingChanged
"The current value of the showSharedFlaps flag has changed; now react"
self showSharedFlaps "viz. the new setting"
ifFalse:
[Flaps globalFlapTabsIfAny do:
[:aFlapTab | Flaps removeFlapTab: aFlapTab keepInList: true]]
ifTrue:
[Smalltalk isMorphic ifTrue:
[self currentWorld addGlobalFlaps]]
The self currentWorld addGlobalFlaps adds the flaps to the currentWorld. The PasteUpMorph>>addGlobalFlaps creates new PasteUpMorph and adds it.
You can also notice the difference also in the menu bar title Untitled vs. HomeProject.
Question
How to use these private functions on other windows? It would be nice to have this knowledge back in the wild. I am specifically trying to get CGSOrderWindow and CGSSetWindowLevel to work.
I was trying in the direction of:
temporarily register as the dock and then register the dock as the dock again immediately afterwards
or
code injection into the Dock process per this comment:
Also, the author of the above project seems determined to make all core functionality available as a framework. It seems to be implemented as code injection into the Dock process.
Reason I know this is possible
I have been doing work on trying to setLevel on window of another app, and focus window of another app if focused. I am posting this again with the info I learned because from my searching online, I know this was done in the past, its just the knowledge is not publicly out there anymore. The sourceforge pages are no longer there. So I was wondering if you could help me make this information public again.
This is the topic I read that gave me this information - http://cocoadev.com/HowtoControlOtherAppsWindows
Here you see comments like:
You cannot control an another app's windows from a user-level process, unfortunately.
SlavaKarpenko
You can, Slava, you just need to register as the Dock. It might be possible to temporarily register as the dock and then register the dock as the dock again immediately afterwards, not sure. I think the call you'd be wanting to investigate as CoreDockRegisterDockOwner in HIServices.framework.
FinlayDobbie
You could also use APE or similar to do control the windows, or (as mentioned above) register as the Dock (look for the private APIs with Universal Connection in their name). Has anyone found a polite way of getting the Dock to give up its universal connection? The only way I can find is to force quit the Dock and grab the universal connection when it's not looking (which prevents the dock reloading).
SamTaylor
There's an open source project up on sourceforge.net that looks much more like the window managers I've used on Unix boxes than Space.app (or Space.dock): http://wsmanager.sourceforge.net/
SteveCook
Verifying things work
This is what I learned, from the sources at bottom of this post, we see all these functions work with CGWindowIds, so how do I get that, this is how:
Get all windows with CGWindowListCopyWindowInfo. Then access each element from that array with CFArrayGetValueAtIndex and then get the CGWindowId with objectForKey:, kCGWindowNumber, and then integerValue.
Now if I try to focus or set level of a window that is OWNED by the app running the code, it works fantastic. For instance:
MY_TARGET_CGWINDOW_ID = 179;
rez_CGError = CGSOrderWindow(_CGSDefaultConnection, MY_TARGET_CGWINDOW_ID, kCGSOrderAbove, 0);
Will focus it, rez_CGError is 0. Even if the window is minimized, it is unminimized, without animation, and shown.
Now however, if I try this on a window of a different app we get some errors:
MY_TARGET_CGWINDOW_ID_of_other_app = 40;
rez_CGError = CGSOrderWindow(_CGSDefaultConnection, MY_TARGET_CGWINDOW_ID_of_other_app, kCGSOrderAbove, 0);
This fails and rez_CGError is 1000, which I suspect means "cid (CGSConnection) used does not have permission to modify target window". The same happens if I first do [app activateWithOptions: (NSApplicationActivateIgnoringOtherApps | NSApplicationActivateAllWindows)] before making the call above.
So I first get the cid of that owning window like this:
var rez_CGError = CGSGetWindowOwner(_CGSDefaultConnection, MY_TARGET_CGWINDOW_ID_of_other_app, &ownerCid);
This works good and I get ownerCid is set to a value. Then I do the focus command with this new connection:
rez_CGError = CGSOrderWindow(ownerCid, MY_TARGET_CGWINDOW_ID_of_other_app, kCGSOrderAbove, 0);
However this gives rez_CGError of 268435459, which I suspect means "current app does not have permission to use this ConnectionId (cid)". (Same happens if I call activateWithOptions first.
My Sources for the Private Functions
Here is the sources for some private functions I found - https://code.google.com/p/undocumented-goodness/source/browse/trunk/CoreGraphics/CGSPrivate.h
This one source here contains a function that is not in the above link - CGSGetConnectionIDForPSN - i test it and it exists - from - https://github.com/mnutt/libqxt/blob/767498816dfa1742a6f3aee787281745afec11b8/src/gui/qxtwindowsystem_mac.h#L80
I have made a custom virtual keyboard widget for my kiosk application, and now comes the time when I want it to produce fake keyboard events and feed them to an QLineEdit of choice.
I do the following:
// target is the QWidget to receive the events
// k is the Qt::Key (keycode) I want to send (Testing with an 'A')
Qt::Key k=Qt::Key_A;
if(0!=target){
//According to docs this will be freed once posted
QKeyEvent * press=new QKeyEvent(QKeyEvent::KeyPress, (int )k,0);
QKeyEvent * release=new QKeyEvent(QKeyEvent::KeyRelease, (int )k,0);
//Give the target focus just to be sure it is available for input
target->setFocus();
//Post the events (queue up and let the target consume them when the eventloop gets around to the target)
QCoreApplication::postEvent ( target, press) ;
QCoreApplication::postEvent ( target, release) ;
}
I see the target widget receive focus, but there are no letters typed into the input field like I would expect. What am I doing wrong? Which assumptions are wrong?
PS: I know that this could be solved by using existing virtual keyboards or at least using the platform interface as is done in this post. In our approach we have decided to build the kayboard into the application to obtain full control over the UX and keyboard design.
Thanks!
Since no-one stepped up, I will try to provide some closure.
It turns out that Qt5 comes with a library of testing facilities called testlib. It has all sorts of goodies to facilitate easy creation, management and running of unit tests for Qt application. Among these facilities there is a set of functions for sending fake events such as fake typing of text, mouse clicks etc. It is quite comprehensive and covers many use-cases. Since this is used internally by Qt developers to test Qt itself it is also production proven code.
I simply copied what I needed from there.
I have made like an "Asteroid" copy, that works pretty well! I made it with different modules (enemies, controls and background). Now I have also made like a starting screen, where the player can choose to play the game, view highscores etc.
The problem is that I have no clue how to implement this into a storyboard.. I might have misunderstood the use of modules.
I am starting in a Scene1, which is the intro+buttons to start the game. Next, I want to move to scene2(when player presses start button), and that seems to be no problem, and scene 1 gets purged. But when I die, I want to move to scene1 again. Problem is that some listeners dont get removed, and the game crashes shortly after scene switch.
I guess the main problem is that in my scene2, I have put in require("background"), enemies and controls in my enterscene, which I dont know how to remove when it should be purged.
Ive entered all of the modules and put them in the same group that gets purged on exitscene, but not everything gets removed.
How do you think I would fix this the easiest way? I am very new to Corona and still in a early learning stage.
Display objects, like display.newImageRect()'s and display.newText() that are created in the createScene() function and added to the "group" display group will be automatically removed when the scene is purged.
Any timers, transitions, or audio.plays that have onComplete handlers, as well as network requests and any event handler that attaches to the Runtime must be removed by hand. If you're various object you are creating are doing any of these things, their remove functions should undo these actions so that removing them will clean them up.
I find it best if I'm adding runtime handlers, timers, etc. to do it in enterScene() and make sure I undo them in exitScene(). Then if its something that is done in createScene() it should be cleaned up in destoryScene().
modules are kind deprecated to start.
Second, putting stuff in other files and calling them with "require" is supposed to be used to call libraries, not code that will run. "require" is not a dofile, or a eval, it will run once, and only once (when the first "require" of the file is made).
If you still want to put things in other files, like loading your background, you need to do a "background.lua" file that has a "background.load()" function and a "background.unload()" function, and call them in appropriate places.
I am aware of the ability using an EdgeShapeTransformer to change the look of edges:
vv.getRenderContext().setEdgeShapeTransformer(new EdgeShape.Line()); // for example
However I am looking for how to change the way the line looks while dragging from one node to another to create an edge interactively. By default the 'hovering' edge which is not yet linked to another node is a large curved line. See the example here for what I mean.
CubicCurveEdgeEffects is where it is done. There is an EdgeEffects interface that can be implemented to do other things instead. It is used by the SimpleEdgeSupport class via the EditingGraphMousePlugin.
(Credit to Tom Nelson, offline communication.)