The More General Question
I am wondering if there is a standard way that operating systems / desktop managers use to expose the user's preference regarding the placement of the window frame controls (Close, Maximize/Miniaturize, Minimize).
For platforms like Windows and MacOS, it's "pretty" safe to assume that the users wants their window controls on the right and left respectively to match the rest of the windows in the GUI. But the key word here is "assume'. I hate to assume things when I code.
Furthermore, what about all the different Linux distributions and flavors?
I think this information could be useful to application developers in the same way that it's useful to know the user's preferences regarding dark or light themes.
My More Specific Question
Now, what I'm building currently is an Electron application that could really benefit from a custom title bar (a.k.a. a frameless window). And I do understand that my problem is caused by the fact that I want to bypass the window frame abstraction that is normally offered by the operating systems, but I'd really like to be able to position my custom controls in my title bar without having to guess.
But anyway, since I use Electron, I do have access to native features using NodeJS, but I'd also be curious to know if browsers have or are planning to implement a way for the CSS or JavaScript running in the browser to determine the intended placement of the window controls, again, similarly to prefers-color-scheme?
Related
I'm aware of the existence of DDS files which allow programming of display graphics on the as/400, but is there another way?
Specifically, what I want to do is manipulate the terminal buffer directly to be able to display anything else than just text.
For example, the terminal looks like that:
Let's say, in memory, there would be a two dimensional char array: text[20][80] for the text menu and lower than that, there would be a pixel buffer array of size [200][800].
Is there a way to access either of those arrays directly?
I would like to be able to create a displayable menu entirely in C without the need of a display file and also display other kind of graphics (images) directly in the pixel buffer.
Is there a way to access either of those arrays directly?
That's easy enough, though a "display file" that has no formatted fields will still be needed. The 'file' will be the connection between the program and the physical device (or the emulator). You can define a single large area that contains whatever "text" you want your program to put into it. This can even include display field attributes that delimit input areas.
For the most control, the DDS USRDFN keyword is appropriate. But for simple stuff like lists of menu items, almost any large text field can be output to.
Outputting simple text is easy. For detailed stuff like USRDFN formatting, detailed understanding of the 5250 protocol is needed.
One kind of alternative would be to use User Interface Manager (UIM) APIs to update a PANEL's "text area" (:TEXT) via its USREXIT= application program. The UIM handles everything as far as any "display file" definition and actual I/O goes. The UIM can be thought of as a HTML interface for 5250 and uses a very similar markup language to define PANELs.
Another alternative is the Dynamic Screen Manager (DSM) APIs. These give much finer control than the UIM or DDS methods (though DDS USRDFN gets very close). But as with USRDFN, actual device control will require 5250 protocol knowledge.
...and also display other kind of graphics (images) directly in the
pixel buffer.
There is no "pixel buffer" for 5250 nor even 'pixels'. It's a character-based protocol, like telnet. If you're going for images or 'pixels', you're into browser interfaces, or perhaps Java and NAWT, or X-windows, etc.
Now, granted that with TCP/IP and sockets, you can do essentially anything that you're able to program. Whatever you can figure out how to do, including downloading/installing 3rd-party code libraries, you can do -- within the network restrictions surrounding your server. But it is in fact a server, so GUI kinds of apps generally shouldn't run on it. That's the same as for almost all types of servers. Code the GUI on the client system rather than the server. But you can do it if you really want to.
I'm not sure why you'd want to do this...
Now-a-days, it'd be much easier to simply generate your output as HTML and serve it up via the integrated apache web server.
But if you really want to do graphics via 5250, it can be done...theoretically at least. In 20+ years on the platform, I've never seen it.
But way back when (1994?), IBM added support for Graphical Data Display Manager (GDDM) and Presentation Graphics APIs into OS/400. "GDDM is a means of
displaying, printing, or plotting pictures. Presentation Graphics routines are a
means of displaying, printing, or plotting business charts."
The support is still in the OS. However, client side support is NOT available in IBM i Access for Windows or the most recently released client, IBM Access Client Solutions (ACS). It appears that the standalone IBM Personal Communications product may support GDDM.
For complete control of the character buffer, take a look at the Dynamic Screen Manager (DSM) APIs. The DSM APIs are "a set of screen I/O interfaces that provide a dynamic way to create and manage screens for the Integrated Language Environment® (ILE) high-level languages. Because the DSM interfaces are bindable, they are accessible to ILE programs only."
There is a way to do it in ILE C/C++. This was very fun to investigate since I haven't tried it myself.
The only documentation on it (page 183+) I could find is from 5.1, but you are able to cross reference the functions used to this 7.3 manual (possibly page vii/7) to see if they're still used the same.
Hope this helped!
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 want to code sth. that basically works like TiVo. Switch it on, you only see the menu or an output, so no underlying OS or anything else is directly visible to the user.
So I want to use Linux as base. Can you suggest a good base distribution?
Can I code a frontend without having a window-manager up and running?
If yes, is that possible with java-gnome or what language/gui-framework combination would you suggest?
If no, what's the minimal window manager that can handle fancy menus, etc?
What does it take to create video-overlays over a HD-stream? Are there some libraries I should take a look at?
Thanks
Yes. If you only have one window you don't need a window manager. Using X you can start some application and set it's position and size from the commandline (making it fullscreen). You might want to take a look at xinit if this is what you want. This is likely the easiest why to get something working. But another option is skip X and use DirectFB. If you want to display several windows, on the other hand, you need some sort of window manager to manage them.
As long as you run X there is no problem using java-gnome as framework if that's what you are confortable with. I guess you didn't mean to run the stock gnome applications, but code everything visible to the user yourself.
This very much depends on what you mean with fancy menus. If you mean transparancy and such you need a composite manager (if you don't just render everything yourself inside your application window). I'm not sure about this but I think you can run a composite manager independent from a window manager if you find that suitable. Again, this is if you run X. Using DirectFB transparency and such are done in a more simple way.
If you intend to write your own media player you should take a look at GStreamer. It can stream, decode and display video and also add video-overlays (among other things) and is extremly easy to use.
Minimalistic tiling window manages like Awesome, Ratpoison or XMonad may be useful as a base, otherwise you'll have to manage focus and window sizing yourself. It is normally fairly easy to make these invisible to the user.
Absolutely.
I wouldn't count on Gnome itself working without a window manager. Other than that... language doesn't matter.
Window managers only do window management. Menus and the like are the job of the widget toolkit. Anyways, Metacity.
... This one I have no clue about.
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).
I'm currently designing my first ever GUI for Windows. I'm using MFC and Visual Studio 2008. The monitor I have been designing my program on has 1680x1050 native resolution. If I compile and send my program to one of my coworkers to run on their computer (generally a laptop running at 1024x768), my program will not fit on their screen.
I have been trying to read up on how to design an MFC application so that it will run on all resolutions, but I keep finding misleading information. Everywhere I look it seems that DLUs are supposed to resize your application for you, and that the only time you should run into problems is when you have an actual bitmap whose resolution you need to worry about. But if this is the case, why will my program no longer fit on my screen when I set my monitor to a lower resolution? Instead of my program "shrinking" to take up the same amount of screen real estate that it uses at 1680x1050, it gets huge and grainy.
The "obvious" solution here is to set my resolution to 1024x768 and redesign my program to fit on the screen. Except that I've already squished everything on my dialogs as much as possible to try and get my program to fit on screen running at 1024x768. My dialog fonts are set to Microsoft Sans Serif 8 but still appear huge (much larger than 8 points) when running at 1024x768.
I know there HAS to be a way to make my program keep the same scaling... right? Or is this the wrong way to approach the problem? What is the correct/standard way to go about designing an MFC program so that it can run on many resolutions, say 800x600 and up?
I assume your application GUI is dialog based (the main window is a dialog)?
In that case you have a problem, because, as you discovered, MFC has no support for resizing a dialog correctly. Your options are:
Redesign your GUI to use a SDI or MDI GUI.
Use a dialog resize extension. There are many available, for some very good suggestions see this question. Another options are this one and this one.
Don't use MFC. wxWidgets has much better support for dialog resizing.
MFC is only a thin wrapper over the Windows API. They both make an assumption which is hardly ever true: if you have a higher resolution screen, you'll adjust the DPI or font size in Windows to get larger characters. Most of the time, a larger screen size means a larger physical monitor, or a laptop where you want to squeeze as much information into a small screen as possible; people value more information over greater detail. Thus the assumption fails.
If you can't squeeze your entire UI into the smallest size screen you need to support, you'll have to find another way to make it smaller. Without knowing anything about your UI, I might suggest using tabs to group the controls into pages.
I've had good luck making my windows resizable, so that people with larger screens can see more information at once. You need to do this the hard way, responding to the WM_SIZE message to the window and deciding which controls should be made larger and which ones should just move.
There is no automatic way to resize the content of your dialogs when resolution changes. So, you need to set some boundaries.
Option 1.
If you are developing your app for customers, pick one minimum resolution (like 1024x7678), redesign you dialogs so that everything fits. Maybe break up some into several, or use tab strip control.
Option 2.
Create separate dialog forms for each resolution you'd like to support, but use the same class to handle it. At runtime detect resolution and use the appropriate form.
Option 3.
Write your own resizing functionality, so that user could adjust the size of your dialogs to his liking.