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.
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.
In some WMs it is possible to choose theme which affects how windows are displayed, e.g. how a background of a button is coloured.
If I draw a window using bare Xlib calls, what should I do to conform to these theme-affected settings? I.e. am I supposed to write specific code for every possible WM? How is it resolved in general?
There are several theme types and they sometimes play together, but they should not be confused.
Window manager/border themes describe the decorations of each window, not the content
UI toolkit themes/widget themes describe how buttons, text fields etc. are drawn within a window
Icon themes describe which icons are used, covering application icons as well as file icons, action icons, toolbar icons etc.
Color themes define a palette of colors to be used within the framework of the other themes
Pointer themes define a set of mouse pointer icons
Some desktop environments bundle all these themes in "desktop" themes, or at least provide a frontend to choose all of them. Yet, these themes are independent from the desktop environment and also from each other. It is possible to set them using configuration files.
If you want your application to fit with the user's preferences, first of all you should adhere to the Icon theme. The Pointer theme is taken care of by the X server, as long as you only use stock mouse icons and don't upload your own to the X server.
The second obvious thing would be the Color theme, but unfortunately there is no standard for color themes, both Gtk+ and Qt frameworks provide this functionality in an independent fashion (and desktop theme configurators understand and manipulate both to provide consistency). You could do some magic to find out whether the user prefers Gtk+ colors or Qt colors (e.g., is running Gnome or KDE) and then extract the colors somewhat from there.
The hardest thing however is to provide a look and feel of your UI elements that is true to the UI toolkit theme(s) the user has chosen. First you would again have to decide between Gtk+ and Qt (other toolkits that are themeable exist as well, but are typically not themed by the user, or niche players like Enlightenment). Then you would have to re-implement the same functionality. Interestingly, many themes come with their own theme engine in Gtk+, and it is possible to let the theme engine do the work for you. An approach that was picked-up by several parties already. Examples:
Java Swing supports mimicing Gtk+ applications by implementing the Gtk+ themeing API and letting the Gtk+ theme engines do the work, works with some inconsistencies.
Firefox and other Mozilla Apps using XUL also do this, but there are always annoying differences, starting with the default font size.
Qt itself has a compatibility Gtk+ theme, that basically does the same; this one works pretty well.
My suggestion is to not reinvent the wheel, instead use Qt (or Gtk+ if you prefer) for GUI elements that go beyond basic drawing operations. Note that from my experience, even primitive drawing is typically better done with Qt than with Xlib.
The user gets the look&feel she expects (not only the look), the interface is rich and stable, and you save considerable time writing all this stuff.
I was looking at Evernote and Producteev for Windows and noticed they used similar GUI toolkits. What tookit(s) are they using? Here's some links., Producteev. (Check the Windows Screenshots) and Evernote.
I am the programmer for the Windows desktop application for Producteev. We didn't use any toolkits for the GUI. All of the UI code was written from scratch based on designs from our in-house artist. We drew a little bit of influence from Evernote (particularly in the toolbar area) to give a familiar look to the application, so that's why there's some similarities.
The application itself is written in C#, and I use GDI+ to make all the drawing calls. There are about a dozen custom-written controls, including buttons (some of which bring down menus), glowing text boxes, list boxes (for tasks). There's also another collection of them to replace for all of the default Windows controls in order to force anti-aliased text rasterizing.
Through experience I have found that the native windows forms/components don’t like to be changed. I know using Delphi or Visual Studio you are given native windows components to populate a form or window with and then you attach code on events that these components may do (onClick for example).
However, how do all of these programs like Word or google’s Chrome browser alter the standard windows’ window? I thought it was somehow protected?
Chrome seems to have tabs actually on the window’s frame?
I know you can also get toolkits like Swing and QT that have their own controls/components to populate a form. How do these work? (How does the operating system/computer know what a non-native button should act like? For example; Chrome's back and forward buttons, they're not native components?).
I can understand how OpenGL/DirectX window would work because you’re telling the computer exactly what to draw with polygons/quads.
I hope this question is clear!
Windows does not protect GUI elements. Windows and controls can be subclassed to handle various drawing operations in a custom way. For example, windows may override and reimplement the handling of the WM_NCPAINT message to draw a custom titlebar and frame:
http://msdn.microsoft.com/en-us/library/dd145212(VS.85).aspx
Some Windows controls have an "owner-draw" mode. If you use this, you get to draw the control (or at least vital parts of the control), while Windows takes care of responding to user input in the standard way.
Swing ant QT draw their own widgets at a low level using basic primitives, but they also have theme engines which can mimic the native controls.
Qt moved to native controls a while back. As for how swing does it, it gets a basic window from the OS. Then much like Opengl\Directx it does all of the drawing with in that window. As for where to position things that is what the layout managers do. Each manager has a layout style horizontal, vertical, grid, components it has to draw and a section of window it is expected to fill. From there it does some pretty easy math to allocate its space to its controls.
There's no magic: non native controls are simply drawn on a blank window. Or, instead of being drawn they may be represented as one of several bitmaps based on state (ie: a button may be represented as a .png for the normal state, another .png for the pressed state, etc)
I'm from a Windows programming background when writing tools, but have been programming using Carbon and Cocoa for the past year. I have introduced myself to Mac by, I admit it, hiding from UI programming. I've been basically wapping my OpenGL code in a view, then staying in my comfort zone using my platform agnostic OpenGL C++ code as usual.
However, now I want to start porting one of my more sophisticated applications to Mac OS.
Typically I use the standard Visual Studio dockable MDI approach, which is excellent, but very Windows-like. From using a Mac primarily now for a while, I don't tend to see this sort of method used for Mac UIs. Even Xcode doesn't support the idea of drag and drop/dockable views, unfortunately. I see docked views with splitter panels, but that's about it.
The closest thing I've seen to the Visual Studio approach is Photoshop CS4, which is pretty nice.
So what is the general consensus on this? Is there are more Mac-like way of achieving the same thing that I haven't seen? If not, I'm happy to write a window manager in Cocoa myself, so that I can finally delve in an learn what looks like an excellent API.
Note, I don't want to use QT or any other cross-platform libraries. The whole point is that I want to make a Mac app look like a Mac app, leave the Windows app looking like a Windows app. I always find the cross-platform libraries tend to lose this effect, and when I see a native Mac UI, with fancy Cocoa transitions and animations, I always smile. It's also a good excuse for me to learn Cocoa.
That being said, if there is an Open Source Cocoa library to do this, I'd love to know about it! I'd love to see how someone else achieves this, and would help smooth the Cocoa learning curve.
Cheers,
Shane
UPDATE: I forgot to mention a critical point. I support plugins, which can have their own UI to display various plugin specific information. I don't know which plugins will be loaded and I don't know where their UI will live, if I don't support docking. I'd love to hear people's thoughts on this, specifically: How do I support a plugin view architecture, if the UI can't change? Where do I put the plugin views?
Coming from a Windows background, you feel the need to have docking windows, but is it really essential to the app? Apple's philosophy (in my opinion) is that the designer knows better than the user how things should look and work. For example, iTunes is a pretty sophisticated app, but it doesn't let you change the UI around, change the skin, etc., because Apple wants to keep it consistent. They offer the full view, the mini player, and a handful of different viewing options, but they don't let you pull the source list off into a separate window, or dock it in other positions. They think it should be on the left, so there it stays...
You said you "want to make a Mac app look like a Mac app", and as you pointed out, Mac apps don't tend to have docking windows. Therefore, implementing your own docking windows is probably a step in the wrong direction ;)
+1 to Ken's answer.
From a user perspective unless its integral to the app like it is in Adobe CS or Eclipse i want everything as concise as possible and all the different options and displays out of my way so i can focus on the document.
I think you will find with mac users that those who have the "user skill" to make use of rearranging panels will in most cases opt for hot key bindings instead, and those who dont have that level of "skill" youre just going to confuse.
I would recommend keeping it as simple as possible.
One thing that's common among many Mac apps is the ability to hide all the chrome and focus on your content. That's the point behind the "tic tac" toolbar control in the top right corner of many windows. A serious weakness of many docking UIs is that they expect you to have the window take up most of the screen, because the docked panels can obscure content. Even if docked panels are collapsable, the space left by them is often just wasted and filled with white space. So, if you build a docking panel into your interface, you should expect it to be visible most of the time. For example, iTunes' source list is clearly designed to be visible all the time, but you can double-click a playlist to open it in a new window.
To get used to the range of Mac controls, I'd suggest you try doing some serious work with some apps that don't have a cross-platform UI; for example, the iWork apps, Interface Builder or Preview. Take note of where controls appear and why—in toolbars, in bottom bars, in inspectors, in source lists/sidebars, in panels such as IB's Library or the Font and Color panels, in contextual HUDs. Don't forget the menu bar either. Get an idea of the feel of controls—their responsiveness, modality, sizing, grouping and consistency. Try to develop some taste—not everything is perfect; just try iCal if you want to have something to make fun of.
Note that there's no "one size fits all" for controls, which can be an issue with docking UIs. It's important to think about workflow: how commonly used the control would be, whether you can replace it with direct manipulation, whether a visible indication of its state is necessary, whether it's operable from the keyboard and mouse where appropriate, and so forth. Figure out how the control's placement and behavior lets the user work more efficiently.
As a simple example of example of a good versus bad control placement and behavior in otherwise-decent applications, compare image masking in OmniGraffle and Keynote. In OmniGraffle, this uses the Image inspector where you have to first click on an unlabeled button ("Natural size") in order to enable the appropriate controls, then adjust size and position away in a low-fidelity fashion with an image thumbnail or by typing percentages into fields. Trying to resize the frame directly behaves in a bizarre and counterintuitive fashion.
In Keynote, masking starts with a sensibly named menu item or toolbar item, uses a HUD which pops up the instant you click on a masked image and allows for direct manipulation including a sensible display of the extent of the image you're masking. While you're dragging a masked image around, it even follows the guides. Advanced users can ignore the HUD entirely, just double-clicking the image to toggle mask editing and using the handles for sizing. It should be easy to see, with a few caveats (e.g. the state of "Edit Mask" mode should be visible in the HUD rather than just from the image; the outer border of the image you're masking should be more effectively used) Keynote is substantially better at this, in part because it doesn't use an inspector.
That said, if you do have a huge number of options and the standard tabbed inspector layout doesn't work for you, check out the Omni Group's OmniInspector framework. Try to use it for good, and hopefully you'll figure out how to obsess over UI as much as you do over graphics now :-)
(running in slow motion, reaching out in panic) Nnnnnoooooooo!!!!!
:-) Seriously, as I mentioned in reply to Ken's excellent answer, trying to force a "Windowsism" on an OS X UI is definitely a bad idea. In my opinion, the biggest problem with Windows UI is third-party developers inventing new and inconsistent ways of presenting UI, rather than being consistent and following established conventions. To a Mac user, that's the sign of a terrible application. It's that way for a reason.
I encourage you to rethink your UI app's implementation from the ground up with the Mac OS in mind. If you've done your job well, the architecture and model (sans platform-specific implementation) should clearly translate to any platform.
In terms of UI, you've been using a Mac for a year, so you should have a pretty good idea of "the norm". If you have doubts, it's best to post a question specifically detailing what you need to present and your thoughts on how you might do it (or asking how if you have no idea).
Just don't whack your app with the ugly stick by forcing it to behave as if it were running in Windows when it's clearly not. That's the kiss of death for an app to Mac users.