I believe the issue is because the resources were relative symlinks and the symlinks were copied, rather than the file contents themselves. Is there a way in GNUmakefile to include resources from different directories?

On 4/26/25 22:55, Gregory Casamento wrote:
For whatever reason it isn't copying the resources properly.  I believe it is an issue with the GNUmakefile, because NONE of the xib/storyboard resources were properly copied.   I'm going to address this on a branch and submit a PR.

GC

On Fri, Apr 25, 2025 at 3:19 PM Ethan C <[email protected]> wrote:

    After adding all the resources and setting the main storyboard to
    Main.storyboard, it gives me an error saying that -[NSXMLDocument
    initWithData:options:error] is being called with data = nil. I
    have just committed this change, and I can't debug further.

    On 4/25/25 13:13, Gregory Casamento wrote:
    If you commit your changes (I presume you have) I'll take a look.

    On Fri, Apr 25, 2025 at 2:04 PM Ethan C
    <[email protected]> wrote:

        After disabling the pasteboard, the app now builds and links.
        However, only the miniwindow shows up, and it complains about
        not being able to find its resources. I don't know the
        GNUstep resource system well so some help would be appreciated.

        On Fri, Apr 25, 2025, 10:10 Ethan C
        <[email protected]> wrote:

            Thanks Patrick, Greg!

            Hi everyone,

            I have written a GNUmakefile. The main obstacle is the
            pasteboard functionality.

            GNUstep implements the OpenStep/pre-10.5 OSX pasteboard
            (see the GNUstep docs
            
<https://www.gnustep.org/resources/documentation/Developer/Gui/Reference/NSPasteboard.html>
            and the Apple docs
            
<https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CopyandPaste/CopyandPaste.html>);
            I have no idea how it integrates with the system's
            clipboards. This pasteboard contains a single item, which
            may have multiple representations.

            Modern macOS implements the post-10.6 OSX pasteboard (see
            the Apple docs
            
<https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/PasteboardGuide106/Introduction/Introduction.html#//apple_ref/doc/uid/TP40008099>
            - "Pasteboard Concepts" is the most important part), and
            OpenOutliner expects this to work. This pasteboard is a
            list of items (for example, if you copy a selection of a
            webpage which contains an image it should put a rich text
            and an image onto the pasteboard), each of which may have
            multiple representations. Additionally, it starts using
            Uniform Type Identifiers (UTIs) in order to refer to
            types rather than use the old pasteboard type strings (at
            least in 10.6 those old strings were still supported but
            were deprecated).

            It looks kind of complicated to implement the new
            pasteboard API, so maybe we could try porting
            OpenOutliner to the old pasteboard API or temporarily
            disabling all the features which need the pasteboard. Do
            any of you have opinions on this?

            The Uniform Type Identifiers framework, part of
            LaunchServices, seems to be implemented by Boron so we
            could probably do that. (However, that would make
            gnustep-gui depend on Boron, which may or may not be
            wanted.) We might want to implement in Boron the new
            Uniform Type Identifiers framework
            
<https://developer.apple.com/documentation/uniformtypeidentifiers?language=objc>
            introduced in macOS 11 Big Sur, which is object-oriented
            (UTIs are of type `UTType*` rather than `NSString*`, and
            it provides an Objective-C API). Although OpenOutliner
            doesn't use the new UTI APIs, it would be useful to
            implement in case newer apps need it, and regardless it
            seems to be a cleaner API.

            Thanks,

            Ethan

            On 4/25/25 08:01, Gregory Casamento wrote:
            Ethan,

            Mine is gcasa.  I would like to help a little if I can. 
            Also, expanding libs-xcode, if it needs it, to handle it.

            Yours, GC

            On Fri, Apr 25, 2025 at 4:11 AM Patrick Cardona
            <[email protected]> wrote:

                On 2025-04-24 18:50:21 +0200 Ethan C
                <[email protected]> wrote:

                Hello Ethan,

                > I started on the porting at
                https://github.com/ethanc8/OpenOutliner.

                Great!

                > You can
                > grep for "FIXME-GNUstep" for the things that don't
                work yet (the whole thing
                > doesn't compile yet). If you give me your GitHub
                username I can give you
                > commit access to my fork.

                Mine is: pcardona34

                >
                > On 4/24/25 08:14, Patrick Cardona wrote:
                >> Hello Ethan,
                >
                >> Thanks for this mention. I shall look at this.
                >
                >> On 2025-04-24 04:57:47 +0200 Ethan C
                <[email protected]> wrote:
                >
                >>> Hi everyone,
                >
                >>> David Chisnall recently mentioned on Lobsters
                >>>
                
<https://lobste.rs/s/btjtkr/what_software_do_you_dream_about_do_not#c_i2m53u>

                >>> a clone of OmniOutliner 3 he wrote in 2017, and
                said it would be easily
                >>> portable. Its source is on GitHub
                >>> <https://github.com/davidchisnall/OpenOutliner>
                if you want to look at it.
                >>>  From the README it looks like a decently
                complex application with lots
                >>> of functionality, so it could be quite useful to
                port it. See also Liam
                >>> Proven's comment about why he uses outliners
                >>>
                
<https://lobste.rs/s/btjtkr/what_software_do_you_dream_about_do_not#c_owdlc8>

                >>> to get an idea of what outliner users would
                want. I might take up this at
                >>> some point, but I doubt it as I am quite busy
                and have too many side
                >>> projects already :)
                >
                >>> Thanks,
                >
                >>> Ethan Charoenpitaks
                >
                >
                >

-- Patrick Cardona - France
                MUA: GNUMail - Hardware: Raspberry Pi pi400 Model
                OS: Debian 12 (RPI-OS Lite) - Desktop: GSDE




-- Gregory Casamento
            GNUstep Lead Developer / Black Lotus, Principal Consultant
            http://www.gnustep.org - http://heronsperch.blogspot.com
            https://www.patreon.com/bePatron?u=352392 - Become a Patron
            https://www.openhub.net/languages/objective_c
            
https://www.gofundme.com/f/cacao-linux-a-gnustep-reference-implementation



-- Gregory Casamento
    GNUstep Lead Developer / Black Lotus, Principal Consultant
    http://www.gnustep.org - http://heronsperch.blogspot.com
    https://www.patreon.com/bePatron?u=352392 - Become a Patron
    https://www.openhub.net/languages/objective_c
    https://www.gofundme.com/f/cacao-linux-a-gnustep-reference-implementation



--
Gregory Casamento
GNUstep Lead Developer / Black Lotus, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
https://www.patreon.com/bePatron?u=352392 - Become a Patron
https://www.openhub.net/languages/objective_c
https://www.gofundme.com/f/cacao-linux-a-gnustep-reference-implementation

Reply via email to