Please combine all windows into one window: main editor window, font info, and the Python editor/console. It’s a nightmare to find and switch between all the windows when working on several fonts at the same time, especially on the font info of several fonts at the same time.
In comparison: VSCode has brought such a productivity boost because it has a text editor, a file browser, git interface, and a console (and more) all in the same window.
There are some aspects that make it more difficult than how it is done in VSCode or other mac apps that use the Tabbar to collect documents in one window.
The most important is that a single document already has tabs.
And each window has its own toolbar. Unifying that is difficult or confusing.
And Macros need can access the current Tab. But if the macro “window” is the current tab (1), it is not clear what “font” tab should be used (if could be the last viewed tab) but that is not transparent for the user.
And I like to see and edit view next to the font info when setting or checking vertical metrics. The Font Info should be the easiest to integrate into the main window (it is like that in Glyphs Mini).
On the other hand, there are request of splitting the window to allow better multi monitor support.
As this is a lot of work, this will probably not make it for Glyph 4, lets see.
Would it be possible to make the macro window minimizable? That is a smaller change that I would both welcome and make use of.
done
But I would recommend to use the Command+Option+M shortcut to show/hide the macro window.
This. People with two displays often keep the Font Info on one display, and the main window on the other.
What you cannot do right now is differentiate between info and main windows in the Window menu. Both windows have exactly the same title. So it is a bit of a roulette which window you are activating when you pick it from the menu.
Thanks.
I’ll keep that in mind.
Have you tried opening them in different “spaces”? With an app that snaps a window to half/quarter of the screen, it seems pretty easy to configure any layout you want and swipe between them.
No. I work daytime as a type engineer and juggle numerous open fonts at the same time, and having them in different spaces is really impractical. In my own work, I don’t want to be limited by the needs of people who only ever work on one font ever in front of their 3 monitors.
Just to clarify, when you say “Combine all windows into a single window”, you are talking per-document, right? Not all documents into a single window.
Here, would you be satisfied with a reduced scripting interface that is integrated into the main window? No multiple macro tabs or other extended debugging features and more like a REPL console?
Not all documents into a single window.
Yes
Here, would you be satisfied with a reduced scripting interface that is integrated into the main window? No multiple macro tabs or other extended debugging features and more like a REPL console?
REPL console would be the coolest. That’s actually another feature request I have that I haven’t ever voiced yet.
I just think that the window setup should be configurable. I’m not a Cocoa programmer but it’s all based on NSViews in the end, isn’t it? It should be possible to arrange them either as a split view inside a single window or as separate windows.
As in no 
One window per document
Ah, I misunderstood the request a bit.
So it is mostly about the font info window? I’m not adding the macro window into the document (but a REPL sounds interesting).
The problem is not about actually putting things in a tab. But making sure that all other pieces (e.g. the scripting) are fine with it. So that font.currentTab.masterIndex works. And what master to display in the Kerning panel when the font info tab is active.
Btw, I don’t think having the font info as a tab is good idea. Tabs are inconvenient because you still have to switch between them. Sometimes I already want to the font view and the edit view to be visible next to each other. These are separate categories of views and already shouldn’t be mixed in tabs. Tabs only make sense for edit views.
I was more thinking to have the font info as a panel on the sidebar, and the same goes for the console and a REPL console. This allows different categories of data to be worked on simultaneously while keeping everything in one window.
Ideally, this would be flexible. If you face backlash over this idea from existing users, why not offer both a separate window and a panel?
I’ll think about this. One needs a rather big screen to make that work.
What part of the font info would be most useful to have next to the edit view?
That would obviously be the OT features.
The other font info tabs make not so much sense to have next to the glyph overview.
I care mostly that they aren’t separate windows, so a main tab would be okay, I guess.
Btw, if you consider putting stuff into more tabs, why not consider a multi-window tab system like a browser where users can move tabs across? Of course, to not cause confusion, windows should be limited to one font, meaning that one window shouldn’t be allowed to contain tabs from different fonts. This would allow for several different edit views, separate font view and edit view next to each other, font info etc. to be freely mixable in windows as users prefer. This would be very flexible and should satisfy all users.
So there would be one main window per font which contains the font view. All other edit views and font info views can be moved freely across any number of additional windows.
In this case, I think it would make sense the decouple the OT features from the font info. It could be argued whether or not they belong together anyway.
It would be so cool to be able to edit features in one window, and see the shaping update immediately (upon manual recompiling) in the other windows.
Agreed. “Features” needs to be decoupled from Font Info.
Or at least needs to be in focus when exporting font for testing.
This is how it’s working already. Not for you?