search

andlabs / libui

Simple and portable (but not inflexible) GUI library in C that uses the native GUI technologies of each platform it supports.
Other
10.72k stars 614 forks source link

Request: toolbar/headerbar component #76

Open jblindsay opened 8 years ago

jblindsay commented 8 years ago

It's entirely possible that I overlooked this, but I haven't seen a toolbar component. It would be wonderful if such a component could be added. As a bonus, it would be great if toolbars could be horizontal and vertical, but I'm not sure if this is supported on all platforms.

The developers are to be congratulated on the remarkable amount that you've achieved with this project thus far. It is an exciting time for desktop application developers. Thank you.

andlabs commented 8 years ago

The problem with toolbars is that OS X has a radically different paradigm to how toolbars should work than Windows and Unix do. On OS X, toolbars don't merely provide icons for accessing menu items; they provide access to commonly used groups of features and controls related to editing the current document, etc. No New File/Open File/Save File/etc. This is reflected in the API: each window can only have one toolbar, at the top of the window. So I'm not sure how to reconcile these differences.

jblindsay commented 8 years ago

Thanks for the explanation. If applications can't have toolbars, is it possible to have shortcut keys for menu items?

pcwalton commented 8 years ago

One alternative might be to expose an NSToolbar-like interface and to map it to the Ribbon framework on Windows (uiribbon.dll). On modern versions of Windows (Windows 8+? maybe 7 too) this is preinstalled in the System32 directory. Ribbons are more similar to how toolbars work on Mac OS X, in that they're grouped, one-per-window, etc. They're also what Microsoft has been moving to in lieu of toolbars for new apps, so they match the underlying OS.

On the other hand, maybe this is a bit of a stretch, and it's not clear what to do on Linux.

andlabs commented 8 years ago

The problem isn't the technology used, it's the user experience that you get out of it. I can certainly imitate OS X toolbars with traditional toolbars on Windows and GTK+ (and possibly ribbons and headerbars too), but what will it look and feel like to the end user?

Am I worrying about nothing major and will it really look more natural? I guess I can look at some of Apple's in-house and favorite third-party apps to see what they do and compare them to Windows and GTK+ apps.

pcwalton commented 8 years ago

Well, that was my point--Ribbons and Mac Toolbars seem broadly similar in terms of UX, enough that they might map to one another and still feel native. But I'm not 100% sure about it.

andlabs commented 8 years ago

It's definitely worth experimenting with :) Not an immediate goal (OpenGL and grids and tables come first), but still a good thing ot play around with.

jwells89 commented 8 years ago

In my (admittedly limited) experience with GNOME, GTK+ headerbars behave very similarly to OS X toolbars (particularly if you use the OS X 10.11+ ability to hide the titlebar). Perhaps mapping toolbars to header bars in GTK+ would be a better option than mapping to old style GTK+ toolbars?

andlabs commented 8 years ago

Probably. I've noticed that as well, though the usages are still slightly different mainly due to the available space and formatting of label text.

joaoventura commented 8 years ago

There are some controls which may make more sense in one or two OSes and not on the others, this may be the case. I would suggest that if the control is relevant in those platforms, maybe they could be implemented in libui and declared in some "extras.h" which would be appended to "ui.h" via #define.

My rationale is that libui could provide most crossplatform controls and one or other platform-specific control so that people (that are using bindings) would not need to learn Objective-C to interface with OS X or C++ for Win32. All in all, it would be great if I wouldn't have libui users and binding maintainers would not need to lean anything more than C and the binding language. It kind of reminds me of React's "Learn once, write anywhere"..

andlabs commented 8 years ago

Bah, the Windows Ribbon Framework flat out does not allow you to create or modify elements programmatically, you have to have everything in a precompiled binary format loaded once at the start of your program from an embedded Windows resource (can't pass in a byte array!), and then you hide and show things at will. That won't work for libui. (FWIW this kind of restriction is precisely why I don't add a declarative interface to either libui or package ui.)

In addition it seems like the WRF only lets you create one ribbon per application? Unless I can create multiple IUIFramework instances per process... But even then I would still have to deal with having to have the ribbon data created beforehand (and not even in XAML!).

andlabs commented 8 years ago

I wonder if we could use a rebar control with one of the predefined theme styles...

andlabs commented 8 years ago

Actually it seems MFC has its own Ribbon control that can be manipulated by code! Of course, we can't use MFC, nor can we copy the MFC source into libui, but we could use it as a reference to make a Ribbon lookalike...? (Depends on how much MFC ribbons look like Windows Ribbon Framework ribbons on each of the supported visual styles: Windows Classic, Windows 7 Basic, Windows 7 Aero, Windows 8, and Windows 10.)

data-man commented 8 years ago

wxWidgets has wxRibbon. http://docs.wxwidgets.org/trunk/group__group__class__ribbon.html

With most powerful features - DevExpress controls (commercial soft). https://www.devexpress.com/Products/VCL/ExBars/

andlabs commented 8 years ago

Okay so the MFC ribbon looks nothing like the WRF ribbon :|

ghaberek commented 8 years ago

wxWidgets has wxRibbon. http://docs.wxwidgets.org/trunk/group__group__class__ribbon.html

I've made several attempts in the past to use wxRibbonBar and it either felt half-assed, or ended up using a wxMenuBar and wxToolBar (or wxAuiToolBar) instead.

My number one gripe against wxRibbonBar is that there's no freakin' menu button. It also doesn't allow you to specify the size of the buttons; it simply auto-sizes them all to large and then makes them small or compact when there's no room left.

I guess what I'm getting at is, use the wxRibbonBar as a design model if you must, but be aware that it's in need of much improvement. I'm really surprised it made in into the wxWidgets library in its current state.

andlabs commented 7 years ago

So looking at the programs that come with Windows 7, a lot of them just extend the non-client frame into the client area and put controls on top of those. I experimented, and "Composited" theme subclasses of common controls seem to be designed with this in mind; for example, the navigation bar in Windows 7's Explorer uses a rebar in the glass area. We might get away with this, but I might write a full demonstration first. This will also have the advantage of not misusing the ribbon for an entirely different design philosophy than what it was intended, and might just be better overall, if Windows Explorer, Internet Explorer 11, XPS Viewer (which does not put its rebar in the titlebar, but still operates similarly), and the Desktop Gadget program have anything to say about it.

FWIW MFC has an almost perfect replica of the Windows 7 Ribbon. If need be I could clone it...

aoloe commented 7 years ago

this is also something i could use... : - )