On my touchscreen computer, I get a warning when I use a simple Qt combobox (in PySide):
class MyComBox(QtGui.QWidget):
def __init__(self):
QtGui.QWidget.__init__(self)
comboxText=["Hi", "Bye", "Give me a warning"]
self.comBox=QtGui.QComboBox(self)
self.comBox.addItems(comboxText)
self.comBox.move(20,40)
self.setGeometry(100, 100, 200, 100)
self.show()
When I create an instance of the GUI, the GUI looks as I expect, but when I press on the dropdown menu, I get the following warning in my shell:
QAccessibleWidget::rect: This implementation does not support subelements! (ID 1 unknown for QWidget)
While it is somewhat innocuous, I'd like to make this go away as it is distracting when it pops up every time someone clicks on a combobox. Google has not yielded much on the topic, except the following related discussion:
http://www.daz3d.com/forums/viewthread/6773/
I am on Windows 7 and Python 2.7, running under Anaconda. Note I am only getting this error on my Dell touchscreen laptop, but not my work desktops (neither of which are touch screen). All are Windows 7, but the touchscreen laptop is a Dell Inspiron 15z "downgraded" from Windows 8.
Because of the lack of people clamoring with me about this problem, it is clear this seems fairly localized to me. Hence I have submitted this as a bug report at the Qt Project site (https://bugreports.qt-project.org/browse/PYSIDE-242). I will update here if I hear anything back.
The thread http://niftools.sourceforge.net/forum/viewtopic.php?f=24&t=2147 indicates that it is a problem with Qt accessibility support on some touch/tablets. Can you try disabling the Tablet PC Components (or, in Vista, Tablet PC Optional Components) from Control Panel -> Program Features -> Turn Windows Features On or Off, as mentioned in the last post there and check if it works.
Also, if you just want to suppress the the warning, since it is innocuous, you can install your own message handler using QtCore.qInstallMsgHandler()
And, this is more likely a Qt issue than a PySide one.
I had the same problem on windows8. Stopping the service TabletInputService seemed to fix it for me
Related
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)
I am trying to show a progress in the taskbar of the plasma desktop using the KDE Frameworks. In short, it want to do the same thing as dolphin, when it copies files:
I'm kinda stuck, because I don't even know where to get started. The only thing I found that could be useful is KStatusBarJobTracker, but I don't know how to use it. I could not find any tutorials or examples how to do this.
So, after digging around, and thanks to the help of #leinir, I was able to find out the following:
Since Plasma 5.6 KDE supports the Unitiy DBus Launcher-API, which can be used, for example, to show progress
I found a post on AskUbuntu that explains how to use the API with Qt
The real problem is: This only works, if you have a valid desktop file in one of the standard locations! You need to pass the file as parameter of the DBus message to make it work.
Based on this information, I figured out how to use it and created a GitHub repository, that supports cross platform taskbar progress, and uses this API for the linux implementation.
However, here is how to do it anyways. It should work for KDE Plasma and the Unity desktop, maybe more (haven't tried any others):
Create a .desktop file for your application. For test purpose, this can be a "dummy" file, that could look like this:
[Desktop Entry]
Type=Application
Version=1.1
Name=MyApp
Exec=<path_to>/MyApp
Copy that file to ~/.local/share/applications/ (or wherever user specific desktop files go on your system)
In your code, all you need to do is execute the following code, to update the taskbar state:
auto message = QDBusMessage::createSignal(QStringLiteral("/com/example/MyApp"),
QStringLiteral("com.canonical.Unity.LauncherEntry"),
QStringLiteral("Update"));
//you don't always have to specify all parameters, just the ones you want to update
QVariantMap properties;
properties.insert(QStringLiteral("progress-visible"), true);// enable the progress
properties.insert(QStringLiteral("progress"), 0.5);// set the progress value (from 0.0 to 1.0)
properties.insert(QStringLiteral("count-visible"), true);// display the "counter badge"
properties.insert(QStringLiteral("count"), 42);// set the counter value
message << QStringLiteral("application://myapp.desktop") //assuming you named the desktop file "myapp.desktop"
<< properties;
QDBusConnection::sessionBus().send(message);
Compile and run your application. You don't have to start it via the desktop file, at least I did not need to. If you want to be sure your application is "connected" to that desktop file, just set a custom icon for the file. Your application should show that icon in the taskbar.
And thats basically it. Note: The system remembers the last state when restarting the application. Thus, you should reset all those parameters once when starting the application.
Right, so as it turns out you are right, there is not currently a tutorial for this. This reviewboard request, however, shows how it was implemented in KDevelop, and it should be possible for you to work it out through that :) https://git.reviewboard.kde.org/r/127050/
ps: that there is no tutorial now might be a nice way for you to hop in and help out, by writing a small, self contained tutorial for it... something i'm sure would be very much welcomed :)
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 Qt program (using qt v5.0.2) contains a QWebView in which the user is supposed to login using their email address and a password.
Everything works fine on Windows (tried on w7 and server 2008) but on Mac (10.7.5) I have encountered an annoying issue.
When pressing alt-2 (key combination for #) nothing happens.
I have spent countless hours testing and trying to find any info on the net about it, but I really can't find anything about it.
Is there any workaround? Fix? Or is this even a known issue?
Edit:
As noted in comments below, my keyboard is European/Swedish.
It's a genuine Qt Bug. I reported it as https://bugreports.qt-project.org/browse/QTBUG-34981
Today we found the code responsible for it in
./qtwebkit/Source/WebKit/qt/WebCoreSupport/EditorClientQt.cpp
Around line 480 it says
#ifndef Q_WS_MAC
// We need to exclude checking for Alt because it is just a different Shift
if (!kevent->altKey())
#endif
shouldInsertText = true;
Apparently, Q_WS_MAC isn't defined on Mac Builds at this time - I think it's been deprecated in favor of Q_OS_MAC.S
Simply changing the statement to
shouldInsertText = true;
when compiling on Mac fixed the problem for us.