I'm porting a C-language kiosk application to a x86 machine, running Ubuntu 16.
I'm using the EFL GUI framework (version 1.20.7) - it is new to me.
The GUI is quite simple: a few screens, with background images, some buttons, labels and text-entries on each. relevant screen is raised, to be visible, according to application-logic. I did that.
My question: should there be a root-parent-window (container) for all sub-windows? At least in my simple design?
I went through many example programs, but all very specific, none with a bigger GUI.
Another thing that puzzled me was that widgets were created via the root-window, even if they were inserted/located in a child-container (taken from the EFL docs, test_button.c):
win = elm_win_util_standard_add("buttons", "Buttons");
bx = elm_box_add(win);
bt = elm_button_add(win);
elm_box_pack_end(bx, bt);
Thanks.
Every widget requires a parent, which at the top level is probably a window. It's recommended that this be a logical parent so examples where that is not the case are probably misleading.
If you would like to see a larger application with many windows then maybe you should check out the EFL IDE which is written using the EFL graphical libraries.
Related
I'm reading the documentation for menus in Firemonkey desktop applications. It explains that there are two completely different menu components, one is to be used for Windows (TMenuBar) and the other is to be used for OS-X (TMainMenu).
Further, it also explains that a TMenuBar does not display on OS-X (nonstandard for OS-X), and that a TMainMenu is placed in the non-client area of the Windows form (nonstandard for Windows)
It's my understanding that Firemonkey is supposed to be one code-base for multiple platforms, but it appears they want me to separate the two. I can understand the menus work differently across both platforms, but it seems like an unnecessary pain to implement two different main menus (and conditionally show/hide them depending on the platform). I have no intention of using the special capabilities of menus specific to either platform. Not to mention the TMenuBar is completely ugly.
Since the TMainMenu also shows on Windows, but yet also claims it's "nonstandard for Windows", can I assume that the TMainMenu is sufficient for both? Or do I really need to implement a separate TMenuBar just for Windows? What are the implications if I don't separate them?
I saw this video, but It's for Delphi XE2, and I can't find such an option in the Delphi XE8 TMenuBar control. And again, the TMenuBar is very ugly and doesn't work like typical menus, like the TMainMenu does. I'm confused why they would advise to use this TMenuBar at all.
The help page linked to is wrong if being 'FireMonkey-native' (so to speak) is not a concern (for what I mean by that, see below). TMainMenu is not 'non-standard' on Windows - it wraps the Windows native menu bar API like the VCL equivalent. TMenuBar, in contrast, is completely custom.
That said, in general the fashion has been to use custom menu bars on Windows since Office 97 did so way back nearly twenty years ago, however the original menu bar API is still fully supported and used by (e.g.) Notepad in Windows 10. Further, writing a decent custom menu so that it fakes a real one properly - as well proving the additional functionalty that led to not using a real one in the first place - takes a fair bit of effort and detailed API knowledge. Unfortunately it might be doubted whether the FMX offering enjoyed this, which isn't to say it won't get better in the future.
One caveat - one reason to use TMenuBar might be if you are using FMX's custom styling options, and want your menu bars to fully participate.
I create my programs on Ubuntu 12.04 and compile them on Windows (when necessary).
Recently I noticed that my Lazarus projects look different on Ubuntu and Windows. The problem is on Windows XP, 7 and 8. I'm not sure if Vista looks the same.
For example, group boxes containing radio buttons look shrunk in height, thus hiding parts of the components.
Now I have to edit this forms on Windows before compiling for those platforms. What's worse is that when I bring these project back to Ubuntu, the forms looks unnecessarily stretched out (in height).
Is there a solution to this?
Thanks!
It is easily to check if the controls themselves have the same height(just query their left and top properties and dump it in a memo or log for verification)
If that is ok, it is probably the font. Default fonts are subject to themes, and sometimes readability/disability settings.
Consistent cross-platform look is not a trivial task and does not come at no-cost.
Read http://wiki.freepascal.org/Autosize_/_Layout, especially the part that can scale controls on your form depending on the font size that the end user has configured in the Control Panels
Read few chapters from Google: "windows dpi aware applications"
Editres is a pretty powerful program for displaying and even modifying properties of widgets within an application window. I believe it interfaces with the X resources. However, very few programs actually understand its protocol (for instance, Firefox does not). Is there a similar program or perhaps a command line tool for displaying widget hierarchy in any given window? A program like xprop will work on any window in the X Window System, but it (as far as I know) only retrieves information about an entire window and not the widget tree within it.
For context, I am working with the GNOME desktop environment on Red Hat Enterprise Linux.
Many modern widget toolkits don't use X windows for each widget, but instead manage the widgets manually as part of the library. As such, there's no protocol to intercept like you can with traditional X programs. These toolkits do expose widget tree information in other ways, though. GTK 2 had https://live.gnome.org/Accerciser, which appears to work with GTK 3.
Can anyone provide some insight on how to "duplicate" an iTunes style window in Windows? Specifically I am looking for the following features:
1) rounded window
2) top and bottom toolbars
3) rounded text fields
I'm currently attempting a bit of cross-platform development with Real Studio and while I've discovered the mechanism by which to perform the rounded windows in OS X (declare method call to HIWindowSetContentBorderThickness or SetContentBorderThickness), I cannot find in the MSDN how to do similar things in Windows. Obviously Apple accomplished it in actually writing iTunes for Windows. Perhaps they wrote custom controls from the ground up.
SIDENOTE: I found this article from a few years back that briefly discusses it (http://discuss.joelonsoftware.com/default.asp?joel.3.454369.12), but this is pretty much all I could find.
Even if I can't duplicate it exactly, some direction on which Windows libraries might contain the functionality I need to do it "manually" would be nice. Any further assistance would be greatly appreciated.
There's no API for doing Apple-style rounded corners, but there are lower-level APIs for creating windows (both frame windows and controls) of any shape you want.
I don't use RealStudio, but I believe it allows you to access both .NET and native Win32 APIs, so:
If you're using .NET Windows.Forms, read Shaped Windows Forms and Controls in Visual Studio .NET. It's written for VB7, but should be easy to translate to your favorite language.
If you're using the raw Win32 API, there are at least two ways to do this. The simplest, but most limited, is to call the SetWindowRgn API, which sets the shape of your window to anything you can create as an HRGN. But that probably won't cut it for you. You don't want jagged edges; you want smooth curves, with alpha-blended borders, and maybe shadows. (At least that's what Apple does.) The Layered Windows API is the way to do this. It allows arbitrary shapes (even changing on the fly, if you use UpdateLayeredWindow—although you don't need that feature to emulate iTunes), alpha transparency, and complicated hit testing. Since the original article is very out of date, and doesn't cover all of the functionality, also see Layered Windows for the current documentation, which has links to the references.
there is a third party controls that do what you want. It works on Mac & Windows.
http://www.madebyfiga.com/fgsourcelist/
works well.
sb
I want to build a desktop app where the size of both the window and the content is resized automaticly according to the resolution of the monitor. I know it can be done easily with the docking features of .NET Forms, but my customer insists on going with Linux so I can't use it.
I tried Flex & Air, but the content is not resized automaticaly when I put the app in fullscreen or in another resolution (the app goes full screen but I still have tiny buttons). Now, I am looking at Qt and Gtk...
Is there a GUI framework that can do that? I don't care about the programming language.
Also, since the app will go in a bar it would be nice to be able to customize easily the skin. (like in Flex, WPF, etc.)
Regards,
Pascal
An excellent place to start is understanding how the Screen class works: MSDN Even though that is .Net, it will give you an idea of how the screen size, dpi, etc. can be obtained. In addition that information should translate to the Mono platform. Since your client is insisting on Linux, you should look at MonoDevelop and then possibly the GTK# framework. My understanding is that GTK# is not a very friendly (that is pretty) development system (yet).
See:
MonoDevelop
GTK#