| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Make this more like a template where users will have to fill their own
information in these fields.
|
|
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.
|
|
Since this menu item is inserted automatically by the OS, we don't need
to localise it at the application level.
|
|
I wanted a way to get logs from the application when running the bundle
rather than invoking the binary directly on the command line.
This command provides something similar to what you would get in Xcode.
|
|
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.
|
|
These are useful to have active to highlight easy to catch mistakes.
|
|
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
|
|
This target no longer really makes sense with the .app bundle build.
|
|
|
|
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.
|
|
Previously I had changed the build rules to use the *.lproj directories,
but that doesn't copy the *.strings files when they change. Update the
targets so that the updated strings files do get copied into the .app
bundle.
|
|
* Remove some old commented targets
* Move the space-specific code to a single place
|
|
Add some conditionals to remove the targets that rename the bundle the
application name has spaces in it. This fixes the warnings and circular
dependency problems we had when building an application bundle with no
spaces where `APP_NAME` and `APP_NAME_NOSPACE` are the same.
The rules and organisation definitely need to be cleaned up, but the
idea works. We should eliminate one of these conditions and put all the
related rules together under a single `ifneq`.
|
|
It technically works, but with a lot of cruft:
$ make app
find: build/Nospace.app: No such file or directory
Makefile:52: warning: overriding commands for target `build/Nospace.app'
Makefile:40: warning: ignoring old commands for target `build/Nospace.app'
Makefile:62: warning: overriding commands for target `build/Nospace.app/Contents/MacOS/Nospace'
Makefile:44: warning: ignoring old commands for target `build/Nospace.app/Contents/MacOS/Nospace'
mkdir -p build/Nospace.app
mkdir -p build/Nospace.app/Contents
mkdir -p build/Nospace.app/Contents/MacOS
make: Circular build/Nospace.app/Contents/MacOS/Nospace <- build/Nospace.app/Contents/MacOS/Nospace dependency dropped.
cc \
-framework Cocoa \
-o "build/Nospace.app/Contents/MacOS/Nospace" \
src/MainMenu.o src/main.o src/AppDelegate.o
cp Info.plist "build/Nospace.app/Contents/Info.plist"
mkdir -p build/Nospace.app/Contents/Resources
cp -R Internationalization/en.lproj "build/Nospace.app/Contents/Resources/en.lproj"
cp -R Internationalization/fr.lproj "build/Nospace.app/Contents/Resources/fr.lproj"
I'd like to make it work without the warnings, or at least without the
circular dependency.
|
|
Now, `make app` doesn't error and says "Nothing to be done" when there
are no changes.
I adjusted the recipes to make the final bundle with spaces dependent on
all files in the no-space bundle.
Switch to `rsync` from `cp` so only the files that did change are
copied.
When updating the MacOS binary file, don't move it, otherwise that
triggers a recompile. Instead copy it to the with-spaces .app bundle. We
also need to remove the no-spaces version of the executable from the
with-spaces .app bundle.
Now I need to work out how to make all this work on application names
that don't have spaces in them.
|
|
This is why I was getting the "The application cannot be opened because
its executable is missing." error.
Now the application opens correctly from the .app bundle.
However, this revealed another problem with the make recipes: The
Info.plist file isn't copied from the space-substituted bundle directory
to the final .app directory.
|
|
Keep the temporary .app bundle with substituted spaces around and copy
the bundle directory so we don't end up rebuilding the executable file
when `make` is re-executed.
This does fail on `make` re-execution because the space-substituted
binary file was moved and no longer exists. Might have to think about
how to make that cleaner later.
The more pressing concern is that the final .app bundle with spaces in
it reports an error when I try to open it:
$ open build/Base\ Windowed\ Application.app
The application cannot be opened because its executable is missing.
Not sure what the problem is there yet.
|
|
This gets us the dependencies set up so they can use paths without
spaces, but creates a .app bundle with spaces as a final product.
It does so by moving the files where we substituted spaces with a
non-space character to file names with spaces.
I don't like this yet because `make app` builds a whole new binary and
everything else, but the resulting bundle is what we want.
|
|
Turns out my substitution wasn't working because I had used `ls` in the
`LPROJS` shell command, meaning there was no match to replace.
Fix the substitution and copy the whole directories to fix the problem.
|
|
Replace `APP_NAME` with the substituted `APP_NAME_NOSPACE`.
|
|
My idea is to use the no-space version of the app name in the Make
targets, and mv the files to the with-spaces version when everything is
built.
Decided to use the Unicode ZERO WIDTH NO-BREAK SPACE character U+FEFF as
the sentinel replacement character. We can always change it to something
else (like a string of unique characters) later if needed.
I took the Perl command from penguin359
(https://unix.stackexchange.com/users/6167/penguin359) on Stack
Exchange:
https://unix.stackexchange.com/questions/12273/in-bash-how-can-i-convert-a-unicode-codepoint-0-9a-f-into-a-printable-charact/12279#12279
|
|
I'm trying to set up the Make targets to build a .app bundle, but I'm
having trouble handling file names with spaces.
I sort of managed to do it using the strategy articulated by andrewdotn
(https://stackoverflow.com/users/14558/andrewdotn) with "${@}" in this
Stack Overflow answer:
https://stackoverflow.com/questions/14639906/can-gnu-make-handle-spaces/14640047#14640047
However, it doesn't seem to be working in the `subst` or `patsubst`
calls using "%" for the localisation files. I get the error:
make: *** No rule to make target `en.lproj', needed by `app'. Stop.
The error looks like it's saying that the
`build/$(APP_NAME).app/Contents/Resources/%.lproj` rule couldn't be
found, even though it is declared.
It looks like I'm going to have to explore other options to handle file
names, or at least application names, with spaces.
I copied the Info.plist file from Mass-menu and updated some fields to
work with this project. I also copied and modified the Make rules from
Mass-menu, but that project doesn't need to handle spaces in file names.
|
|
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.
|
|
Copy strings from AppleGlot dictionaries to test that our localisation
works properly.
Still some concatenated menu items that need translation.
|
|
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.
|
|
To support more languages.
Also, this document says that Base.lproj is for nib files and a quick
skim seems to indicate that translation files should live in a folder
named after the language code they use.
|
|
Make the menu items localization-capable by wrapping their titles in
`NSLocalizedString`.
Generate a base Localizable.strings file with `make genstrings`.
|
|
|
|
|
|
The `genstrings` command only outputs in UTF-16LE character encoding.
However, it's perfectly acceptable to use UTF-8 for a
Localizable.strings file. convert the output file to UTF-8.
|
|
|
