a)
Is it technically possible to create some feature like ‘linked nodes’?
Something like component-technique but only for nodes.
F.e. when designing the stroke-caps of ‘s’,‘c’ etc. or when creating serifs. For now the creepy work-around is to make a rough placeholder stroke-cap, change them and so on …
(have a look on the image for illustration)
b)
Is it possible to keep the macro-panel ‘open’,
when switching through the screens it falls to the background.
Maybe there are better solutions to integrate this window?
c)
Last point is just an annotation, without a right solution
the menus - loaded with all the wonderful scripts and plugins -
could be organized better. For know I don’t know how to logical list,
but maybe some like: every ‘adding-method’ on the top, every ‘deleting-method’ on the bottom of list)
And maybe - in the distant future - there could be an extension-library like often in text-editors. So you could make these extensions available only for the actual design phase.
A: this looks like a good idea on first sight but can become a nightmare. Imagine you make some last minute changes to on of the glyphs. And implementing it is not trival.
B: I will think about is. It shouldn’t occupy to much space.
C: you can put the scripts in folders inside the script folder. That helps a bit. I’m working on a solution for the plugins.
b: Why not arrange your windows accordingly, e.g. Macro window to the right, other windows to the left? Or bring it to the front with cmd-opt-M.
I am against making it a floating window. It would only be in the way. That was the reason we turned the Palette from a floating window into a sidebar.
For b) @all:
I dont mean ‘palette’, but ‘macro’-panel I use 13" …
The point was, that the macro-window gets lost and has to get back via shortcut. ( f.e. the behavior of the ‘palette’ - before new interface - was also not like this … It stayed by side the main app )
Maybe there is a possibility to ‘hook’ helper-windows to the left or right.
I know, but please tell me, because I would really love to know: What is so great about hiding one half of a window under another? And what exactly is wrong with arranging the windows next to each other? In other words: What are you trying to achieve that you need to obstruct a Font window with the Macro window?
I arrange my windows all the time (I use Divvy to precisely align the windows), and I have no problems with that on an 11" screen. I am sure it works on 13" as well. I did, however, have problems with floating windows. I kept moving the palette to the side or turning it on and off because it constantly got in the way. If that is the solution you want for the Macro window, then the shortcut Cmd-Opt-M is the better solution.
And why do you need the Macro window in front all the time? For the result of a Python script? Put this line in your script then:
Glyphs.showMacroWindow()
And every time the script executes, the Macro window will move to the front.
thats true, meanwhile I use the command-line Glyphs.showMacroWindow()
(what irritates me was, - while using macs active-corners - that the macro-panel flips ‘behind’ the glyphs.app and not staying ahead. No matter, command line is a good workaround)
@georg
linked-nodes:
True,
… Also components could be a nightmare too … :).
Of course at the end, it is your decision what are the best features for glyphs.
script and plugin libraries:
First I must resign with the sub-folders-method. But waiting for a better solution
If you want to use Mission Control, you can use live corners for showing just the app’s windows too. Then the window should be displayed to the others.
