I have a few windows on my linux machine using the xfce4 desktop enviorment.
I wish to have a grid-like view where i can see only the part of each window im intrested in.
An example for the general vision:
see a script running without the window borders on terminal across the header
see work status of F#H client out of the advenced client view in the middle left
see only the turrents status list of qBittorrent at middle right
have another terminal at footer (again without header/borders)
My best way to describe it shortly is to generate a view from selective parts of windows.
Added a picture for illustration
Is there any way of doing such thing in a practical way? Am i missing out on a great software?
There are several tiling helpers for Xfce.
Perhaps try xpytile , which is a tiling add-on for Xfce. It offers
automatic tiling, manual tiling and can simulaneously resize side-by-side windows (like AeroSnap for MS-Windows).
Related
I'm going through a bunch of PDFs viewing and then renaming.
I want to open each PDF at 100% zoom when I double-click it from nautilus. Currently it opens at 59%. I have to resize the window every time.
The application seems to call itself "Document Viewer". As far as I can tell, this is an unhelpful indirect name for evince. But I am not sure, because GNOME as a whole is trying to be "clever" about everything.
I've tried "Save Current Settings as Default", but that doesn't have the desired effect.
I've also tried gsettings set org.gnome.Evince.Default zoom 1.0 based on eg https://askubuntu.com/questions/606838/configure-evince-to-open-maximized-with-100-zoom-level . The gesttings command did not produce an error. But nor did it change evince's behaviour.
I'm open to a generic X11 solution, and reserving an area of the screen for this. I'm also open to a solution involving evince, or how nautilus launches it, or a different graphical shell or PDF viewer. Preferably applications available with debian 10.
Ideally I'd like a graphical shell which can give 100% previews and inline renames with F2. This would give a quick workflow for view-renaming whole folders of scanned papers one after the other.
I'd also be interested in socio-cultural explanations of the confluence of factors that resulted in such a severe and basic failure: opening a PDF from the graphical file browser does not result in a readable rendering, and requires the user to resize the window.
Screen is 3840x2160.
"Save Current Settings as Default" works for me on F33. I didn't change any of the other Gnome settings. I use a couple of different monitors with different resolutions and it doesn't give me any issues. I don't know if Debian handles Evince differently; I haven't used Debian for ages. Not a lot of help, sorry.
I want to implement a simple specialized window manager for presentations (not user-controllable) that supports only the following operations:
Moving and resizing of windows
Switching desktops
Starting applications not on current desktop (in background) without disrupting current image.
I don't need any user input, button/titles, ...
What existing window manager should I use as example? There are many little "hello world" window managers, but they usually does not support desktop switching.
You don't need to reimplement the wheel.
openbox will do everything you mention and more besides.
Simply edit the rc.xml to disable the root menu, and re-launch.
Openbox also allows per app setting so that certain applications can open on a particular desktop by default, or with a particular size, or open hidden.
It also supports wildcards in the window selection, so that settings can apply to all windows.
devilspie2 is a window matching utility that can perform actions whenever a window opens.
It is highly hackable and the code is available on github. It will match windows by name/class/etc when they open, and perform actions on them. (including matching all windows and moving them to a different desktop. It will work with most window managers.
Based on the original devilspie which does not have Lua scripting, but is configured using s-exprs instead.
xdotool will also allow you to perform complex actions on windows without hacking any code. It will even fake user input (mouse/kbd) if you need it.
There are a few window managers written in Python that could be good starting points. Qtile and whimsy both describe themselves as hackable.
I'm currently getting my feet wet with Win CE 5.0 to update some code on an existing platform. We're interested in deploying a custom shell/home screen/application launcher as well and I had a couple questions:
1) We're running the standard CE shell and I'm assuming it can be customized because the source code is made available with Platform Builder. I was wondering how "painful" it would be to completely replace it with something like a status bar at the top of the screen (think iPhone). I was thinking task switching could then be handled by shortcut keys exclusively. I have my doubts about this.
2) If it can't be removed, can the taskbar be resized and moved to the top of the screen? We're basically trying to find a way to reserve the first 20 or so pixel rows at the top of the screen for our own status bar and prevent maximized application windows from drawing over top of it.
Thanks very much for the help.
-ksudeadeye
I was happy and angry when I found the solution because it's more easy than I expect.
For 2) reserve space you need to do this:
RECT rc;
SetRect(&rc, 0, 25, GetSystemMetrics(SM_CXSCREEN),GetSystemMetrics(SM_CYSCREEN));
SystemParametersInfoW(SPI_SETWORKAREA, 0, (void*) &rc, SPIF_SENDCHANGE);
With this code you reserve 25 pixels in the top of the screen.
:D
If you have doubts maybe this can help you or this.
Good luck.
To hide the task bar is a simple registry change:
; Hide the windows tasbar by default.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shell\AutoHide]
""=dword:1
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shell\OnTop]
""=dword:0
As far as customizing, your own, that is a little more work, and not something I've attempted.
I have some experience with modifying the taskbar in CE 5.0. It is not an easy task, but the results can really add that personal touch to the device. I was tasked with adding a user mode second taskbar with a password dialog and a second type of shell notification to add icons to the user bar.
In the end, it is just standard Windows CE programming - the taskbar, notification tray, start button, etc. are just like any other windows in the CE environment.
You should start exploring here:
C:\WINCE500\PUBLIC\SHELL\OAK\HPC\EXPLORER\TASKBAR\taskbar.cpp
Be careful, clone your code, and be prepared for lots of debug cycles. This is more than 5000 lines of serious spaghetti code.
I am working on old Motif-based application for Linux. I want to be able to programmatically change the active window of our application. I can redirect the input by using XSetInputFocus() function and the keyboard input start to go there, but XReconfigureWMWindow() and XRaiseWindow() functions just don't work.
I've read that Window Managers try to stop this behaviour, so tried to disable configure redirection, but this doesn't work either. Any ideas how to make one of my own windows on top of the window stack?
There is a tiny program called wmctrl available (at least in Debian/Ubuntu it is in standard distribution) which is able to perform many operations on windows and desktops, and handles plenty of window managers. I'd suggest testing whether it works in your environment, and if so, peeking at its sources.
You may find the answer to this is dependent on the Window Manager the user is using, or even what settings they've given to the Window Manager. I like to set my Window Managers to do "focus follows mouse", which means you can't send the focus to a window that I haven't put my mouse on, unless you also warp the mouse there (is that function called XWarpMouse?).
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.