Age | Commit message (Collapse) | Author |
|
Since this is intended to be template code upon which to build a full
application, I didn't like that the prior license required the full
license text to be reproduced in distributions.
I want the code to be a base for developers to use when starting a Cocoa
application, like the template code that's generated in a new Xcode
project. As such, I want people to be allowed to remove my license when
distributing the code.
|
|
Set a BSD-3-Clause license on all the application code so that it can be
freely used as a base template for an application.
Use the GNU GPLv3+ for the log script as it's a helper utility that
isn't compiled into the application.
|
|
Make the window's `contentView` the `_scroll_view` so that resizing the
window causes the scroll view to resize with the window instead of
having a fixed size.
|
|
|
|
Originally, I hoped to include the application name from the Makefile at
compile time, but that ended up being thorny due to application names
with spaces and escaping concerns. Then I tried putting the application
name in a constant, but didn't like that this required duplicating it in
yet another place.
Ultimately I've decided to stick with what I had originally, getting the
application name at runtime from the bundle's Info.plist dictionary.
|
|
Switch to a constant-stored application name from the Makefile-defined
one. This makes it easier to render the application name without
worrying about escaping differences between the Makefile and
Objective-C. But I still don't like it compared to what I had before.
|
|
This isn't working with the spaces handling. Not sure if I want to keep
going with this approach as it feels like spaces and escaping is going
to get hairy to deal with.
|
|
Now that we've confirmed that the "Open Recent" menu item is inserted
automatically below the "Open" menu item in document-based applications,
we can safely remove our custom one from the File menu.
|
|
|
|
|
|
Match the brace format from "Document.h".
|
|
This subclass ended up not being needed. I ended up using a regular
`NSWindowController`.
|
|
Remove the old test code now that this is working.
|
|
Removing the pointer fixed the cascade, and now new document windows
open shifted by a full titlebar height.
Did a bit of searching on GitHub for `-cascadeTopLeftFromPoint:` and
found this code that does what I was trying to do:
https://github.com/dsa28s/android-studio-apple-m1/blob/c555e84728bfd82a0f9e705af012da37fb52291f/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m#L1399
The above code taught me about the `NSEqualPoints` function, which is
basically what I wanted to initialise the variable. But now I suppose I
don't actually need to do an initialisation of the variable.
|
|
Add some debug logs to see why the window cascade isn't shifting by the
height of a titlebar. `cascade_offset` appears to be changing values in
an inconsistent way and I haven't yet figured out what I'm doing wrong.
|
|
When creating a new document with Apple-N, try to cascade the new window
so that it opens a bit below and to the right of the previous window.
Store the previous window origin in a static variable for a relative
reference point.
Currently this seems to cascade, but not by a full titlebar height and
corresponding horizontal position. Needs some adjustment.
|
|
Add a "Your document contents here" label to the center of the
NSDocument window similar to the one that Xcode's document-based app
template.
Took inspiration from this Stack Overflow answer to get the center point
of the window's content view:
https://stackoverflow.com/questions/6560842/getting-the-center-point-of-an-nsview/14811056#14811056
|
|
Add the basic necessities for a document-based application. This is what
I came up with on 2023-09-10. The `DocumentWindowController` was just an
initial idea and doesn't do anything: we create the required window
controller in `Document`.
The `CFBundleDocumentTypes` entry enables us to interact with text
files.
This confirms that the "Open Recent" menu does get added automatically
below the "Open" menu.
|
|
* Remove the `NSTextFinder` code as it's not necessary to get a find bar
for an `NSTextView`.
* Remove the commented notes for the "Find" menu.
|
|
Add a find bar leveraging NSTextFinder. It turns out I didn't need to do
anything custom with `NSTextFinder` since `NSTextView` conveniently
already has a `usesFindBar` property to turn on built-in support for it.
I discovered that by looking at the TextEdit source code available here:
https://developer.apple.com/library/archive/samplecode/TextEdit/Introduction/Intro.html
I added an `NSScrollView` because you kind of need one to implement
`NSTextFinder`. Not sure if the finding functionality would still work
without the scroll view.
Also use the proper `-performTextFinderAction:` selector for the "Find…"
menu item to open the find bar.
Now we can confirm that the "Find" menu items work correctly.
|
|
This is done now.
|
|
I get the sense that the word order, particularly for the "Help" menu
item, may be different in other languages. Rather than force a certain
word order by concatenating strings, include the application name in the
localisation by making it a format string with an argument.
|
|
Don't think concatenating is the right approach here, but good enough
for now.
|
|
I miscopied this title when I was looking at a template MainMenu.xib in
Xcode.
While I was trying to make a test translation strings file using the
AppleGlot dictionaries, I discovered the mistake.
|
|
Make the menu items localization-capable by wrapping their titles in
`NSLocalizedString`.
Generate a base Localizable.strings file with `make genstrings`.
|
|
|
|
|
|
Just discovered this property which enables basic undo/redo
functionality on the NSTextView.
I can now confirm that the Undo and Redo menu bar items do in fact work.
|
|
|
|
Now that we have a working Font menu built by `NSFontManager`, we can
remove our custom Font menu code.
|
|
I don't understand why, but on Mac OS X 10.15, three menu items in the
automatically-generated Font menu don't have a Command key modifier.
Detect when this happens and add the modifier to the mask.
These menu items correctly had a Command key modifier when I tested the
code on macOS 13.
|
|
Do this so we don't have to bother with forward declarations.
|
|
Check if the Command key is included in the modifier mask. If not, then
add it.
|
|
|
|
This creates the whole font menu for me, and the actions work correctly,
very nice! Read about this in the `NSFontManager` documentation.
The only hitch is that some menu items don't appear to have the proper
keyEquivalents set. For example, "Show Colors", "Copy Style", and "Paste
Style" are all missing the Apple key from the shortcuts.
|
|
Turns out the problem was that I just didn't update the keyEquivalent
after copy-pasting this paragraph. Now it works correctly.
As for the tab bar menu items, it looks like those are inserted
automatically in an Xcode-generated app, so it isn't strange that
they're there.
|
|
|
|
|
|
Create the View menu based on MainMenu.xib. Need to investigate this
more, as some default menu items appeared even without me adding
anything to this menu. My menu has "Show Tab Bar" and "Show All Tabs"
even though I haven't added these. And it already had an "Enter Full
Screen" menu item without any shortcut tied to it, which appears to
override mine with a shortcut.
|
|
Add the actions based on MainMenu.xib that target First Responder.
The others require an NSFontManager, so I have to read up on what's
required for that.
|
|
Still need to set the actions on these menu items.
|
|
|
|
Don't have the actions yet, but this is the structure.
|
|
|
|
I learned about tags and that there are new names for the NSTextFinder
identifiers starting in 10.7. But these still don't seem to be doing
anything.
But I tried adding an NSTextView to a window in a base Xcode project and
the Find actions don't seem to work there either. So now that I have
this, I'm thinking the rest of the problem lies elsewhere. Perhaps the
NSTextView isn't connected enough to enable the Find actions.
|
|
|
|
Most options seem to work, except for Undo, Redo, and the Find commands.
|
|
|
|
This enables the "Close" menu item in the File menu and allows it to
work.
|
|
|