I can get the list of available printer fonts by calling Delphi's TPrinter methods which I believe in turn calls Windows GDI (such as CreateFontA() ?). I do this in WINE running in Debian. I do not know why, but luckily this list contains true type font names, which I need most but are not shown by command xlsfonts. I am not sure if this is relevant to the technology under the hood, but package CUPS is installed.
This successful experience makes me to think that WINE must in turn call some Linux API (X, xfs, ...?) and then provide my program the results I want.
Now I would like to get the same list directly from Linux in C or C++. Which way should I take in order to achieve this goal? What API documentations should I study?
WINE font inspires me a lot, but I decide to stop researching the solution for my own question as the technology required to retrieve printer fonts in X window seems to be not trivial. I choose to use the font list given by Delphi's TPrinter running in WINE instead.
I close this question.
Related
I have two monitors, each connected to a different GPU. Both GPUs are in a single machine, and I want to run a single application. I have two independent views, and I would like to render each one using a GPU/Monitor set. I can create multiple surfaces and devices, but I want to ensure I associate each surface with the GPU its monitor is plugged into, otherwise I suspect I'll suffer performance issues as the frame buffers need to be copied back and forth between cards.
I'm using fullscreen surfaces, and I was thinking this was something vkGetPhysicalDeviceSurfaceSupportKHR would tell me. However, both VkSurfaceKHR appear to be valid targets for each VkPhysicalDevice so I guess this is something the OS and GPU Driver can handle, but is there any hint about which surface is optimal to associate with a device?
From what I can tell the extension VK_KHR_display is one way of doing this, but it's not available on my Windows 10 machine or Nvidia GPU. It seems to be intended for embedded platforms only. However it lets you list attached displays for each device which is pretty much what I'm looking for: https://vulkan.lunarg.com/doc/view/1.0.30.0/linux/vkspec.chunked/ch29s03.html
This quote from the docs makes me belive this may not be supported on Windows:
Issues
1) Does Win32 need a way to query for compatibility between a particular physical device and a specific screen? Compatibility between a physical device and a window generally only depends on what screen the window is on. However, there is not an obvious way to identify a screen without already having a window on the screen.
RESOLVED: No. While it may be useful, there is not a clear way to do this on Win32. However, a method was added to query support for presenting to the windows desktop as a whole.
However, I'm still interested in hearing if there's a work around to achieve a similar effect.
Finally figured out a work around for this:
Direct X actually supports this through use of the IDXGIAdapter::EnumOutputs function. This lets you list the monitors connected to each GPU. Then using these two extensions you can remap this information to Vulkan:
VK_KHR_external_memory_capabilities
VK_KHR_get_physical_device_properties2
You can use these to get the deviceLUID from VkPhysicalDeviceIDPropertiesKHR.
This can then be compared with the Luid from this structure in Direct X DXGI_ADAPTER_DESC
You can also use glfwGetWin32Window to get the HWND of the monitor. This lets you associate a vulkan surface with a direct x monitor.
You now have all the information you need to accociate vulkan surfaces with the devices they're actually connected to.
At least in my application, setting this up correctly results in a significant difference in performance.
This would all be way simpler (and cross platform) if Windows would just support the VK_KHR_display and VK_KHR_display_swapchain extensions as Linux does.
There are two extensions that are useful for such things: the one mentioned by You, VK_KHR_display and the second called VK_KHR_display_swapchain which allows You to create a swapchain directly on a device’s display without any underlying window system.
But these extensions are rarely supported on Windows. In core Vulkan API there is no way to achieve what You want. And I'm afraid You need to use OS-specific functions (You need to rely on the WinAPI functions in this situation).
[EDIT]
Did You saw this question? How can you get the display adapter used for a particular monitor in Windows? If not, maybe it will help You start with Your research.
As you already discovered, on Win32 you need to use the OS windowing system to pick the display you want to use, using the Window API. It can be straight forward.
BUT if you intend to make simple and agnostic OS code, check GLFW project. It has high level functions to handle windows on all major OSs.
Check :
GLFW monitor Guide
GLFW Vulkan integration
GLFW on its own words:
GLFW is a free, Open Source, multi-platform library for OpenGL, OpenGL ES and Vulkan application development. It provides a simple, platform-independent API for creating windows, contexts and surfaces, reading input, handling events, etc.
I'm doing research about a schoolproject. The project is to develop a program that can change the colors of the screen (of the OS aswell of all programs that run on it). The endproduct is supposed to be a single program that is able to change the colors by input (i.e. increasing the presentness of a primary color, for instance add 10% RED), and is an experimental approach to manipulating color blindness. I've already done the theoretical biological research, now I'm looking into the practical deployment of such an application.
I have not set on a single programming language, as I do not know which ones would be the best for, let's say, the windows 7 environment. (which language features the easiest/fastest function calls, for example)
Some examples of function calls I intend to program:
GetColorValues (return data about the current colors the pixels of the screen are displaying)
ProcessColorValues (A simple modification of all respective colors returned by the function above)
SetColorValues (Return the modified colors back to their respective places on the screen)
I would prefer being able to intercept the data whilst it is being pipelined to the screen, in order to keep the processing smooth.
Technically now, I don't really know where to start. I don't even know if I'm supposed to look into the OS, or the drivers of the graphics card.
I was hoping someone could guide me and tell me what I should look for, or where I could find these.
Thanks for reading.
Arnaud
The Windows Monitor Configuration Functions could be a starting point - for example the SetMonitorRedGreenOrBlueGain function to boost specific colors. You should be able to call these functions from C# or VB.Net using PInvoke
I need to write a small application in C/C++ to implement a panel task bar like thing to display information along the top of a desktop window (specifically an xorg desktop on a Linux system). I need to avoid bloat and steep learning curves for the GUI programming.
My research is pointing me at GTK+/GTKmm or FLTK. It looks like FLTK is probably the simpler to get to grips with and the most likely to provide a small clean package with minimal dependencies. So I've based my research on FLTK so far.
I've been doing some reading and am struggling to find out how to write a basic program that will create a narrow undecorated window that covers the width of a monitor in such a way that maximising other applications would not obscure it. The FLTK tutorials I have found so far (including the FLTK documentation) only implement standard windows with borders that can be moved around the screen.
I'd like to start by writing a simple program in FLTK (or GTK+/GTKmm) that creates a 20 pixel deep bar across the with of the screen containing a "hello world" message. The bar's area would be reserved outside the area that other programs can access so that maximising another application would not hide the "hello world" message. I think this has something to do with a WM_STRUT_PARTIAL property but I can't find information about this in FLTK.
Doing this is partially to understand how to write a simple GUI program and partially to solve a specific need that I have.
I'm looking for any help/guidance to put me in the right direction to get started. Many thanks.
starfry, it is not a trivial task I believe. The problem is that your desktop (say GNOME2/Metacity) reserved that space, and paints its panel in the area where you want your bar. -
If you really want your tray-bar applet to be based on FLTK, the you would have to "embed" it in a (GNOME) applet. It was long ago when I did similar thing with SDL application, but I am afraid I forgot how to do it. The first thing that comes to my mind is to use somehow get the XID from the GNOME applet and somehow pass it to the FLTK part of it, and then let FLTK do the rest...
Sure, you may use another desktop, like KDE, or i3 or IceWM, they ALL have their own ways of dealing with the tray bar (there is no standard for it!) so, pardon my "French" - it is going to be a PITA to support all environments...
If I was on GNOME, i would write the applet entirely using GNOME/GTK. Forget FLTK in that case. That is my recommendation. If you target KDE, then do it using KDE/QT libraries (Plasma widget would be what to look for).
However, if you still want to use FLTK, start with the fltk::draw_into() function (it is probably called fl_draw_into() in FLTK 1.x), fltk::xid() and related functions.
I am developing an iOS application that comes pre-loaded with CoreData content.
I am trying to create an importer app for the Mac OS X command-line which uses the same xcdatamodel and imports the initial data that I can ship with the actual app.
So far, so good.
One of the fields in the model, however, is a transformable in which I want to store a Bezier path. Unfortunately, Mac OS X uses NSBezierPath while iOS uses UIBezierPath to store bezier paths.
Is there any way of using the binary UIBezierPath class (and its header file) from the iOS Simulator platform in my OS X project?
I don’t want to convert my project to run in the simulator because I want to be able to run it from the command-line and pass arguments.
There should be a way to make this work, shouldn’t there? Because the simulator platform is compiled for the Mac’s architecture and no GUI components are ever used.
I am also looking for other (creative?) ways to solve this problem… A custom NSValueTransformer, perhaps, or a reverse-engineering of UIBezierPath’s NSCoding adaptation?
Maybe I am just too narrow-minded, too focused on what will essentially turn out to be a futile attempt. Please feel free to point this out in your answer if you think it’s the case…
The library CKBezierPath emulates the NSBezierPath for iOS. Not tested, but give it a try. ;-)
Ken Ferry (Apple engineer from the Cocoa frameworks team):
The keyed archive container format is
interchangeable, however whether a
particular archive is interchangeable
depends on what's in it. Obviously if
a class is only present on one of iOS
and Mac OS X, that's a problem. For
arbitrary individual classes present
on both OSes, it's difficult to say
anything too concretely. People may
have taken advantage of the new OS to
drop some aspects of compatibility.
If your keyed archive contains
exclusively Foundation classes, it's
our intent that they should be as
interchangeable between iOS and Mac OS
X as between versions of Mac OS X. I
don't think we have specific tests to
make sure it works, though, so, well,
if it doesn't for something, file a
bug.
NSBezierPath is AppKit though, so you have to fall back to reverse engeneering. It might not be too difficult because UIBezierPath and NSBezierPath probably both depend on CGPath, but that's only a guess.
PyQt experts: I developed the GUI in Windows and used setGeometry to position the widgets. When I tried to run the same code in Linux it looks cluttered.
And added to that in Windows the font size of 8 seems good. But in Linux, especially in Ubuntu, it doesn't appear well since the font size is 10 by default. Some among the differences are the border of the group box doesn't appear in Linux while it is visible in Windows..
Is there a way that I can make the same code to get the same look and feel in Windows and Linux irrespective of the font and size changes and other differences?
In future if I port my application to Mac will the same code work there too? Or should I have to maintain the separate code for each by checking with platform.system() equal to "windows" or "linux"?
The answer is simple: don't use setGeometry directly (to position your widgets).
Consider the following: what if the user wants to resize your application window?
Compose the user interface (you could do this from Designer or from code) within QSplitters (if you want a resize handle between two components) and/or within QVBoxLayouts / QHBoxLayouts (note that these can be nested).
This will make your UI components behave consistently.
I agree with #ChristopheD. Using setGeometry is bad. It's like designing a webpage with fixed pixel geometry and then wondering why it looks bad on another device.
Qt has a lot of wonderful layout code. Let it do it's job.
Qt by default will paint a widget according to instructions contained in the QStyle. You can test how badly you break your layout in different styles easily enough... run your program with different style options. Like so:
program.py -style motif
Also try -style platinum or -style windows. Even different versions of Windows will probably break your layout.
If you really want to see how bad pixel-based layouts are, try running your program with the -reverse parameter... that's how your program will look to someone running it who speaks a Right-To-Left language, like Hebrew or Farsi.
The problem that you have with widgets not drawing where you want them to can be solved by creating custom painting code for your widget. See the PyQt QPainter docs or better yet, the original Qt QPainter docs..
While I hope my answer is useful, it probably means your program needs to be partially rewritten. In the long term, however, it means that you'll have code that is portable between styles and operating systems, and will even work translated (assuming you care about that).