I am currently programming my first shiny application and I am having some difficulty with some of the more subtle user interface features. I am using the tcltk library to import a number of simple dialog boxes for the user to select local directories and files (the application is only going to be run locally so I will not be using shiny's fileInput commands). This also has the advantage of not being OS specific like the choose.dir command (see R Windows OS choose.dir() File chooser won't open at working directory for more discussion on that).
However, when I'm working in Windows (I'm testing on Windows 10 although I do most of the development work in Linux), I'm finding that calls to tkchooseDirectory only opens up the dialog box behind the shiny application, if I'm running a shiny application, or behind the RStudio IDE if I'm just calling it from the console there. This doesn't seem to be a new problem: http://r.789695.n4.nabble.com/tkchooseDirectory-opens-dialog-below-browser-window-td4729500.html but I haven't seen any solutions yet.
For my development work with the RStudio console then this is a minor nuisance but, given that the shiny application will be eventually be delivered to the client (a state agency), I would really rather not aggravate them with dialog boxes being hidden by the application.
Thank you for any help that you can provide!
[edit 1] Further information: it appears that when calling tkchooseDirectory from the RStudio console, only the first call to tkchooseDirectory results in a dialog box being displayed behind the application. Subsequent calls place the dialog box to the top of the display as expected. Also, this behaviour does not happen in the R for Windows GUI and seems to be something perculiar to RStudio and its associated products.
[edit 2] It appears that others have experienced similar problems with other tcltk library dialog boxes too: MessageBox in R
[edit 3] The easiest minimal example to see this is by running:
library(tcltk2)
tkchooseDirectory()
in the RStudio console on a Windows 10 system.
So, I don't think there's a direct solution to this unfortunately ...
One option is to raise a toplevel window and then the directory dialog on top of it (you have to run everything at once here, otherwise the root is in the background again).
library(tcltk2)
root = tktoplevel("width" = 1, "height" = 1)
tkraise(root)
tkchooseDirectory("-parent", root)
Another option would be to use gWidgets.
dir_ <- gWidgets::gfile(type = "selectdir")
I found it best to pause using Sys.sleep briefly prior to opening the dialog:
root = tktoplevel("width" = 1, "height" = 1)
tkraise(root)
Sys.sleep(1) #pause just a little for dailogs
selectedDir <-
tclvalue(tkchooseDirectory(
initialdir=getwd(),
title="Select directory"))
tkdestroy(root)
Related
I often code functions in the following way by creating a basic function, entering debug mode, and then writing the function in debugmode. E.g.,
myfun <- function(x) print(x)
debugonce(myfun)
myfun("test")
The benefits of this is that I can get real time feedback on whether my code is working with the arguments passed to it.
However RStudio appears to have recently changed it's behaviour to make this more difficult. I recently upgraded to 2021.09.0 Build 351.
Previously, it would open the Source Editor when you call this command.
But if you closed this screen, you could return to your code, edit the code, evaluate code, and so on without the viewer re-appering.
However, now it seems to reappear every time you evaluate your code.
For instance, if I close the viewer, go back to my main script, and evaluate x, the Viewer opens back up.
This is super annoying for someone used to editing and evaluating code while in debugmode using the source script file.
Is there any way of entirely disabling the Source Editor view in Rstudio? Or alternatively, is there a way of being able to edit and evaluate code without the Source Editor constantly re-appearing in Rstudio (like how it used to work)?
My current fix is to downgrade to Version 1.3.1093, where you could edit and evaluate code without the Viewer constantly re-appearing. But it would be a shame to miss out on future upgrades.
This issue was principally a bug that has now been fixed.
At time of posting, downloading a daily build fixes the issue, but eventually this fix will be incorporated into beta and standard builds.
https://github.com/rstudio/rstudio/issues/9943
While trying to add D&D support to a gnome-shell-extension that I'm writing I ran into a bit of trouble. I can create drop targets to any open window, but that's all I've managed to pull off.
I can't differentiate between the windows. I tried to use global.get_stage().get_actor_at_pos(Clutter.PickMode.ALL, x, y).get_parent().get_parent().get_meta_window().get_wm_class(), but half the time it gives me the wrong window and every now and again it just returns null. Also I'm not sure how to drop the information into the target.
All I'm trying to do is drop a file URI into a browser window or the file into a file manager.
Is it even possible in gnome-shell-extensions and how would I pull it off? Any advice would be welcome!
Here is the current available shell code about DND between windows: https://github.com/GNOME/gnome-shell/blob/master/js/ui/xdndHandler.js You can do practically nothing with it.
In Mutter, there are more than one procedure to handled a drag and drop in a window, because there are one implementation for X11-windows and another implementation for Wayland-windows.
To be honest, i don't know if there are a way on Wayland and how will be.
I can tell you that in gnome-shell (Mutter to be specific) there are not a fully implementation of this ability on X11. Most you can know, it's if a drag and drop occurs from a window to the shell and the position of the dragged actor, but the shell dosen't provide any api to create an internal drag and drop from the shell to a particular window.
The shell drag and drop that you can fully used, it's only an internal (just the shell) drag and drop from and to the shell (only for clutter actors) and not an external one between different windows.
In X11, the drag and drop process occurs between windows only. One window provide the dragged object and the information that it's associate to that object. The another window (could be the same) will accept the drop of the object, taking on account the information that the first window provide.
As there are not way in the shell to be possible setting the requiered information to the target-window and like your GUI is inside a big top window (The window that represent the shell global stage: https://github.com/GNOME/mutter/blob/6c18bae83cd27a7397a1ed0c1c0c81b282f1b44e/src/compositor/meta-dnd.c#L152) and like you don't have access to this big internal window, finally you can not do anything to interact directly with other windows.
Here (https://github.com/swayfreeda/blender-2.77a/tree/5969d704f44952ea8cbecba2ba4150fb4a48e6de/extern/xdnd) you can find a fully implementation of drag and drop on X11, you will need to modify the code to be adapted to the Mutter workflow and then add this code to Mutter. After that you will have support, but you will need to create the corresponding procedured to then invoked the functionalities, provide information and recive usefull events from the shell to the window, to be possible finally control it in gjs, but it will be only for X11, not for Wayland. I suppose you will need to do something similar if you want support on Wayland.
Good loock.
I am trying to configure Console2 to use the R terminal.
I created a new tab named "R" and under the shell directory I linked it to:
...\R\R-3.1.3\bin\x64\R.exe. Console 2 just hangs for a few seconds and then reappears in the corner of my desktop with the window completely resized as small as it will go. You cannot resize it in this state - it just jumps back. The only option is to quit.
If I instead link to ...\R\R-3.1.3\bin\R.exe it works fine except that if I alt-tab to another window and then return to the terminal I am unable to type anything in R tab for Console2 or delete previously typed characters. It's completely unusable and I have to restart.
Is this a bug or am I doing something wrong?
This is something I've been experiencing myself and it seems to be a bug - it happens with most other shells I used under Console2. The only solution that worked for me was to use a modified version of Console2 called ConsoleZ, which is found under: https://github.com/cbucher/console - it has many other useful options and it's more actively developed. Hope it helps.
This seems a rather silly question: but I can't find (for more than an hour) now a button to "reset" all standard windows.. I accidentally closed quite a lot of them during a crash. (Especially the "command window" and the signals-in-region during simulation seem to be gone permanently).
From "ModelSim User’s Manual, v10.1d", appendix F:
Most user GUI preferences are stored as Tcl variables in the .modelsim file on Unix/Linux
platforms or the Registry on Windows platforms.
You may consider to look into .modelsim, and possibly delete it, together with .modelsim.bak. The motivation for this suggestion is that .modelsim contains setup details for the layout of panes. .modelsim will (should!) be regenerated next time you open modelsim.
At the menu bar (main window), click on layout and then choose reset. Most of the windows will be reset.
My scenario here is the following: I am using a pyqt widget to display a solid color fullscreen on a second display and observe this display with a camera that is continuously capturing images. I do some processing with the images and this is the data I am interested in. This works great when used interactively with ipython and matplotlib using the qt4agg backend like so
% ipython -pylab
# ... import PatternDisplay, starting camera
pd = PatternDisplay(); pd.show(); pd.showColor(r=255,g=255,b=255)
imshow(cam.current_image)
I need a similar behavior now in a console script though: it should display the PatternDisplay widget, capture an image, than change the color on the PatternDisplay and take a new image and so on.
The problem is now that the PatternDisplay is never updated/redrawn in my script, likely because PyQt never gets a chance to run it's event queue. I had no luck trying to move the linear worker part of my script into a QThread because I cannot communicate with the PatternDisplay Widget from another Thread any longer. I tried to replicate the implementation of ipython/matplotlib, but I didn't fully understand it, it is quite complicated - it avoids running the QApplication main loop via monkey patching and somehow moves QT into it's own thread. It then checks periodically using a QTimer if a new command was entered by the user.
Isn't there an easy way to achieve what I want to do? I am gladly providing more information if needed. Thanks for any help!
What you need is easier than IPython's job - IPython makes the Qt application and the command line interactive at the same time.
I think the way to do it in Qt is to use a timer which fires at regular intervals, and connect the signal to the 'slot' representing your function that gets the new image and puts it in the widget. So you're pulling it in from the event loop, rather than trying to push it.
I've not used Qt much, so I can't give specifics, but the more I think about it, the more I think that's the right way to do it.
I solved the same problem (i.e. interactive ipython console in terminal, and GUI thread running independently) in the following way with ipython 0.10 (code here)
1. Construct QApplication object, but don't enter its event loop explicitly
2. Run the embedded IPython instance
3. Run the UI code you need by instantiating your window and calling show() on it (like here with the yade.qt.Controller(), which I aliased to F12. (I did not find a way how to ask the embedded shell to run a command at the start of the session, as if the user had typed it)
(You can also show() your window first, then run the embedded ipython. It will provide event loop for Qt.)
(BTW I also tried running Qt4 from a background thread (using both python threads module, and Qt4.QThreads), but it refuses to run in such way stubbornly. Don't bother going that way.)
The disadvantage is that UI will be blocked while ipython is busy. I hope to finding something better for 0.11, which should have much better threading facilities (I asked on ipython-users about how to unblock the UI).
HTH, v.