My issue is KiCad related however it applies to other programs as well.
In KiCad under the schematics editor if you right click, move the mouse and then left-click the cursor will be placed back where you first right-clicked.
According to some answers (see launchpad below) this is not a bug it's a feature, so the developers are reluctant to make it an optional feature. There is a similar feature concerning warping the mouse when zooming in, which is optional.
My question is therefore if it is possible to block certain programs from moving the mouse cursor? i.e.
$ kicad --mousewarp=0
I have seen several requests for this on forums and as bug requests on launchpad:
https://forum.kicad.info/t/mouse-jumping-feature-removal/7077
https://bugs.launchpad.net/kicad/+bug/816739
Also a video on the issue at youtube:
https://www.youtube.com/watch?v=VtpipzDhyBY
An interesting observation is that if you select OpenGL in the pcb editor, the mouse does not warp, but there is no such alternative in the schematic editor.
Short answer: No.
The application sets the mouse cursor based on its needs. While this is annoying in the case you mention, it can be useful in others.
Long answer: Yes, but you may need to create your own input driver and ignore the XWarpPointer() calls.
Related
So I am testing Arch Linux because I was considering switching. I am running Arch on the latest version of VirtualBox. After I set up the xmonad tiling window manager and rebooted, only the wallpaper popped up. There was no dock, no icons, and no mouse. After reading the manual 2 times over, nothing helped. If anyone knows how to get xmonad to work, that would be great.
Thanks!
I have been using XMonad on Arch for nearly an year now, so I guess I am eligible to answer this.
As per my understanding, you have installed xmonad, xmonad-contrib and xmobar from the Arch official repos. Now, the first thing that you should do is make a configuration file, both for XMonad itself, and XMobar, which is its status bar. Your xmonad configuration goes in ~/.config/xmonad/xmonad.hs (default) or ~/.xmonad/xmonad.hs. XMobar config goes in ~/.config/xmobar/xmobarrc0.hs. If you are using a login manager, xmonad will start as usual, else just use ~/.xinitrc with exec xmonad command for starting xmonad.
Now, as you mentioned, wallpaper is being displayed for you, which might be due to nitrogen or feh or anything similar that is autostarting and setting up your wallpaper. Else, everything you want, you have to set it up yourself in the xmonad config file. The wallpaper also doesn't start by itself if you have a clean install. XMonad just gives a black screen with a black cross for the mouse pointer.
Dock: There isn't any dock on xmonad. If you want a status bar, you can use xmobar or polybar or anything else. I use xmobar with clickable objects, which acts like a dock. Configure it as you want.
Icons: Window managers have a keyboard-driven workflow. You can define workspaces which are clickable, and have your mouse do the switching. But you won't have icons on your Desktop with your files. For that, use any Desktop Environment. You can use xmonad with KDE, Xfce, etc. too, if you want that specific workflow.
Mouse: Well, you should have a cross for a pointer, even if you do not setup anything. If that isn't working, then there is some issue with the drivers that were loaded. But, for a proper arrow-shaped pointer, you can set it up in the xmonad config itself.
Now, you might wonder how you will launch applications if there is nothing to click. For that, you have dmenu, rofi and many other prompts which you can setup. For me, the super key launches rofi in a nice, centered window with application names and icons and fuzzy searching enabled. Configure to your heart's content. A window manager showcases your creativity.
Hope I could give the helping-hand to know what is possible. If you want some ready-made configurations, look for DistroTube's dotfiles.
I am answering because I do not have enough reputation to make a comment. Sorry :|
Xmonad is a tiling window manager and that is all it is. It really doesn't have the concept of desktop icons. Nor does any tiling window manager. A tiling window manager is just all about managing your windows. For status and dock, you usually pair a different program (Xmobar, Polybar etc).
But hold on, if there are no icons, how do I access the applications? Well that's one point about it. Tiling window managers' key selling point is the extensive usage of "Keyboard Shortcuts" People use tiling window manager mostly for the benefits of usage with keyboard.
It takes time to get used to, but has its benefits. If it feels strange and uncomfortable, maybe tiling WMs are not what you want.
Also, this question doesn't belong in here. SO is only for programming related questions. You have other Stack exchange sites for these (SuperUser, Unix/Linux, AskUbuntu, etc)
Reading the book "The Spec UI framework". Trying to implement the part described in chapter "Taking over the entire screen".
After executing the code suggested in the book:
WindowExample new openWorldWithSpec
it seems to be impossible to return to previous state. Tried to delete the new WorldMorph in the inspector. Also tried with halos, as the book suggests but those buttons that are available in the halo menu don't allow it to be closed.
Is it an intended behaviour for this (to be executed to prepare an end-user environment and disable programming UI) or am I missing something?
Working in Pharo 5.0, Mac OS X version.
That is indeed intended behaviour, as part of making applications that do not allow access to the development environment anymore. But you can take a look at the code for PharoLauncher to see how you can enable a developer mode
You can actually get back to normal by:
Alt-Ctrl-Clicking on the Morph (macOS combo may be different, this is for Windows).
Clicking on the little wrench and ask for inspect.
In the evaluation pane, do:
self delete
World menu is available again.
Open a browser.
Done.
If one disables halos in settings, this is a tad harder.
I'm using Dymola but I expect OpenModelica might very well be the same (or at least similar).
For a given component model sometimes it makes more sense to have lots of parameters shown on one "tab" of the parameter GUI. This can lead to an excessively long GUI which, for many reasons including for psychological reasons in relation to how humans process information, is not a appropriate solution.
To solve this I would like to add a vertical scroll bar on the parameter GUI. I believe I saw it once though I cannot recall exactly where.
For illustrative purposes look to the right side of your web browser window. That gray bar that goes up and down is the scrollbar :). I know, obvious but you never know.
I assume I need to put some command in an annotation somewhere though where and what command I am not sure. For example, I found some reference to a verticalScrollBarPolicy but alas, I can not find any documentation on this.
Anyone know how to do this?
EDIT #1:
Dymola (and Adrian indicated OpenModelica as well) will automatically create the scroll bar when the GUI gets larger than the screen. Unfortunately (at least in Dymola) there is little margin so if you GUI is a fraction smaller than the window the "OK" button will be covered by the ribbon on the bottom of the screen and the GUI will be needed to made slightly larger to make the scroll bar appear automatically. This is a reason why a manual option for a scrollbar would come in handy.
I think additional "tabs" might help?
As far as I know in OpenModelica we have a scroll bar for that dialog windows if the window would expand out of the screen.
As of this posting my understanding based on feedback on this forum, my own experience, and from additional discussions with others there is no current manual control of the GUI (i.e., size, scrollbars, etc.).
Your best bet if you come across issues (e.g., you have a super small 2nd monitor) is to use lots of tabs and keep descriptions very short (which is probably appropriate for most applications anyways).
This is a Dymola and OpenModelica issue not a modelica issue as it is not contained in the modelica specification (as I understand it).
If this changes and I find out about it I'll remove or update this post.
We have a hardware device, with an LCD display. It supports an USB interface to connect keyboard and mose. Using these keyboard and mouse, we can navigate to varios menu items and edit entries.
We have couple of test cases written to verify that mouse click and keyboard input events are working when pressed respective key.
My task is to automate these test cases.
I donot have any control to the hardware device, as I can not access the o/s kernel or any application running there. There is one way to verify what is currently displayed on the UI. So I have to use that and verify whether the mouse/keyboard has performed the appropriate events.
As I have gone through couple of previous posts, it seems like that one of the way to achieve this is through virual HID device driver rather than actual keyboard and mosue. But I am not sure how to achieve it.
Please do help me for it. I am fine with any programming language.
I am more interested to simulate the mouse and keyboard events.
You probably don't need to write your own driver. AutoHotKey does pretty much anything you can think of, and the scripting language is quite easy to learn.
You can get it here:
http://www.autohotkey.com/
Since you're using linux, here's a similar project that will run on linux:
http://sikuli.org/
If you aren't familiar with Cinch, its an application on Mac App Store that allows you to resize ANY window to half/full screen size if you drag the window to the edge of the screen. Exactly like the functionality in windows 7.
Now my question is, how is it done? I have looked all over cocoa apis looking for notifications/delegate methods for whenever a window is being dragged (ALL windows, not just windows owned by the app from which code is running from) but can't find it. Looked in Core Graphics API...Quartz Display Services....but can't find it.
Any help will be greatly appreciated as I have been looking for the past week....Thanks!
Edit: Resize the window is easy since it can be done through applescript bridge..
Are you developer behind i-Snap or some other Mac App Store clone of Cinch?
I'm the developer behind Cinch, and while I try to maintain an "abundance mentality" which basically says "There's enough out there for everyone", I've been upset by the Mac App Store lowering the barrier for entry to this market which has produced a number of half-backed competitors.
I would be thrilled to see some real innovation around the work I have done, and not just clones looking to make a quick buck.
Anyway, you want to look at the Accessibility APIs. It's a Carbon C API. This is probably your best reference: http://developer.apple.com/library/mac/#samplecode/UIElementInspector/Introduction/Intro.html%23//apple_ref/doc/uid/DTS10000728
I've not used the Cinch app, but if I were to do this I'd expect to be using cocoa events. (Also see here) Specifically the mouse handling events, combined with where the mouse is currently on-screen. They probably set a variable when a window is grabbed and then track the mouse pointer until it hits an edge or until they release the mouse button.
Events are very powerful and provide very low level access to what is happening, but can also be very complex. Good luck!
I'm not sure. Maybe the developers combine apple script and carbon events. You can create carbon events to know when the mouse has been clicked or dragged