This seems a known problem but I have not found a good workaround. I like the style of the
non-native QFileDialog, especially the feature that allows the user to input the path directly
which is very convenient since the user can easily copy/paste the folder/file name from other applications. However, it seems very slow when the dialog is first launched. The native option
is quite responsive but the problem is that it does not provide an input field so for the user to select a folder he/she has to walk into the directory, which can take many mouse clicks and is not fun. I am not sure if you have experienced similar problem or if I miss something.
BTW, my PyQt version is 4.4.3 and I am working on Windows XP.
Thanks,
Bing
Related
Some context
I've recently switched to ubuntu budgie (from unity), and I am really tired of the Plank/panel menu combo. I cannot find a setting that suits me, because depending on my screen setup, there's always something in the wrong place.
I am literally unable to show the menu on certain edges if I activate auto-hide, and if I don't activate it, it's not nice at all, to the point that I have removed the plank thing altogether. (Am I having strange bugs on this OS, or is it really messy?)
My idea
With great frustrations come new ideas. I thought again about one I had in the past. I would like to have a circle menu that pops around my mouse cursor when I press a given key combination (very much the kind of thing you would find in some games).
The main use case is to get "pined" application shortcuts easily when I need them, but perhaps other things would fit well with them (commands ...).
Questions
So my questions are:
Does such a thing already exist?
If it doesn't, is it difficult to realize? (How much time, complexity, ...)
What tools/libraries are needed for such a project? I know I'll find plenty of explanations on the gnome developer website but I could really use some more help.
Since you mention a buggy behaviour on Plank, depending on the screen configuration, I suspect you are suffering from this bug. In short: Plank's returned values for the space it needs are not always correct in multi monitor setup.
A neat option to replace at least part of the functionality is Ulauncher, by default called from a shortcut, but you could trigger it from anything that is capable of running its command.
Since Ulauncher's window simply identifies in the window list, you can easily write a script to move it to the current mouse position.
In case you'd need any help in that, just leave a comment.
Not sure if you are also referring to quick access of the window list, but for that you could use the Window Previews applet, or even the Workspace Overview applet, so life without Plank is possible.
I'm writing a WinRT game for Windows 8, in C#, using the excellent MonoGame. I've reached the part where the user has achieved a high score and needs to enter their name. This is causing me more pain than I'd anticipated so I thought I'd ask for help.
First of all, is there a simple "enter some text" function that I can call, similar to Guide.BeginShowKeyboardInput in Windows Phone 7, or the ancient InputBox command in VB? I'm using Windows.UI.Popups.MessageDialog for displaying simple dialog messages, but can't find any similar thing for requesting text from the user.
Failing that, is there a way I can easily use a little piece of XAML to present a textbox for the user to use?
If neither of these are possible, I guess I'll have to wire this all up myself... I then would plan to intercept keystrokes and display the required text on screen myself. As I don't have a physical tablet (just the simulator) I'm struggling to start with this. How can I:
Detect whether the device has a physical keyboard, so I know whether or not to display the on screen keyboard?
If there is no physical keyboard, how can I show and hide the on screen keyboard?
Some of these sound like they should be easy to answer, but I've yet to track down answers to any of them.
Many thanks!
Adam.
Hey there is such a way to do this in monogame. There is a new template that allows you to create a XAML + Game game which allows you to use the game class you a used to with the xaml bits as well. These links should get you started. The monogame team rocks.
There are the three game types listed there. You want XAML + Game there is a template for it now if you get the proper version of monogame.
https://github.com/mono/MonoGame/wiki/Windows-8-Project-Types
let me know if you need more help
This is not a cross platform solution but you could use a FlyOut and place the controls for data entry on the window. FlyOut guidelines are here and UI Controls for text input guidelines are here. I have also used MessageDialog in a MonoGame for asking the user simple questions (up to 3 options) or to get a Yes|No response. You can get details of that class here.
Ok. had enough of trying out lightboxes, overlays and dialog boxes plugins. The problem is that very few of them support nested (multiple) dialog open at the same time - a typical requirement in my opinion.
I'm looking for a recommendation for a simple plugin that:
supports callsbacks for the usual onShow/onLoad... events
supports nested instances i.e. the user open a dialog, clicks a button on it, another dialog opens up while keeping the first one open in the background. In other words, it should support the closure of each instance programatically
is NOT the jquery ui dialog plugin
This came about after the big disappointment with SimpleModal's inability to support multiple modal boxes open simultaneously!!!! #EricM, why would you do that to me? why???? ;)
I have narrowed it down to jqModal and the jquery tools overlay. The usage of the latter is weird. Maybe i'm tired but i just don't get it.
So before i dive into jqModal, does anyone have any recommendation based on personal experience that will achieve what I'm trying to do?
thanks
I'm working on a I/O verification tool based on Linux in a game project. It is written in C++, and,since using the same I/O module as our game, it's based on OIS 1.2. Thus, though all I need is to print users' inputs on the console, I still need to create a window for OIS.
So here comes my question: How can I create a mapped window while it is still invisible and processes keyboard events?
I can't unmapped the window in that it won't process any keyboard event anymore. I also can't find function for show/hide a window.(maybe I search through a wrong diretion...)
My little tool works fine now except there is a stupid top-level empty window which needs to be focused for processing keyboard events...
Any advise is welcomed.
Thanks!!!
After reading this post: Linux/X11 input library without creating a window,
I realized my problem was that I misunderstood the philosophy of X11. All I need to do is simply pass the root window handle to OIS, and set the x11_grabkeyboard flag as true. The only drawback is maybe I can hardly debug my program with gdb since the keyboard is grabbed...
Though my situation is solved, there is one thing left.
Every article I read said an InputOnly window won't be visible and is capable for handling input events, while my InputOnly window is absolutely visible after mapped...
Maybe it's my Linux, or again, a misunderstanding...
We've got some in-house applications built in MFC, with OpenGL drawing routines. They all use the same code to draw on the screen and either print the screen or save it to a JPEG file. Everything's been working fine in Windows XP, and I need to find a way to make them work on Vista.
In three of our applications, everything works. In the remaining one, I can get the window border, title bar, menus, and task bar, but the interior never shows up. As I said, these applications use the exact same code to write to the screen and capture the window image, and the only difference I see that looks like it might be relevant is that the problem application uses the MFC multiple document interface, while the ones that work use the single document interface.
Either the answer isn't on the net, or I'm worse at Googling than I thought. I asked on the MSDN forums, and the only practical suggestion I got was to use GDI+ rather than GDI, and that did nothing different. I have tried different things with every part of the code that captures and prints or save, given a pointer to the window, so apparently it's a matter of the window itself. I haven't rebuilt the offending application using SDI yet, and I really don't have any other ideas.
Has anybody seen anything like this?
What I've got is four applications. They use a lot of common code, and share the actual .h and .cpp files, so I know the drawing and screen capture code is identical.
There is a WindowtoDIB() routine that takes a *pWnd, and a source rectangle and destination size. It looks like very slightly adapted Microsoft code, and I've found other functions in this file on the Microsoft website. Of my four applications, three handle this just fine, but one doesn't. The most obvious difference is that the problem one is MDI.
It looks to me like the *pWnd is the problem. I'm not a MFC guru by a long shot, and it seems to me that the problem may be that we've got one window setup in the SDIs, and more than one in the MDI. I may be passing the wrong *pWnd to the function.
In the meantime, it has started working properly on the 64-bit Vista test machine, although it still doesn't work on the 32-bit Vista machine. I have no idea why. I haven't changed anything since the last tests, and I didn't think anybody else had. (On the 32-bit version, the Print Screen key works as expected, but it does not save the screen as a JPEG.)
Your question title mentions screen capture but your actual question doesn't. Please elaborate more clearly. Is the problem that you can do screen capture of three of your applications, but not the fourth one? You can use different screen capture software that can capture OpenGL/DirectX windows. Those surfaces are handled directly by the Window Manager and won't show up with a simple 'PrtScn'.
Switching to GDI+ won't solve it, nor will switching to SDI.
If it's the content of the CView that you want, then yes, that should be right one. If it's the content of the whole screen (at least the content, without the toolbar(s) and status bar), then you should pass it the CMainFrame (that's the default name which may have been changed, the one that is derived from CMDIFrameWnd).
Can you post the code of WindowToDIB()? I've just tried it and It Works For Me (TM), but without OpenGL code in the view. Try passing the following windows to your WindowToDIB() function:
CMainFrame* mainfrm = static_cast<CMainFrame*>(::AfxGetMainWnd());
- mainfrm
- mainfrm->MDIGetActive()
- mainfrm->MDIGetActive()->GetActiveView()
and see what you get.
The contents of each window are directX surfaces and are only assembled by the window manager in the graphics card. You'd not be able to capture this unless you switch off the new interface (DWM) or code specifically for screen capture from the DWM.
Wikipedia has a good description of the Desktop Window Manager (DWM)
Sorry, I still don't understand. You're trying to get the Print Screen key to work on all four applications? Or you're trying to get the WindowtoDIB() function to work, which takes a 'screenshot' (from within your own application) of the application itself, so that it can be saved as an image file?
Also, what do you mean with 'he Print Screen key works as expected, but it does not save the screen as a JPEG.'? Print Screen only copies to the clipboard, what happens when you paste in Paint?
If your WindowtoDIB() function only 'captures' the window you pass to it, then yes, your MDI child windows are not going to show up.
We eventually solved this by creating a different OpenGL context, and drawing everything to that. We gave up on the screen capture.