Create a window without the use of Objective C?

Discussion in 'Mac Programming' started by Paprikachu, May 24, 2012.

  1. Paprikachu, May 24, 2012
    Last edited: May 24, 2012

    macrumors newbie

    Joined:
    May 24, 2012
    #1
    Hi there,

    I want to create my own little GUI library in C++. I wondered if it was possible to create windows and other elements without using Objective-C(++). I couldn't find anything with Google. Is there a way?

    /pap
     
  2. macrumors 68000

    Sydde

    Joined:
    Aug 17, 2009
    #2
    No.

    The GUI components of Carbon, the non-Objective-C part of the API are essentially deprecated and may be unusable. Carbon (look up "Core Services") is the transitional interface between Classic Mac OS and OS X, comprising legacy calls some of which go all the way back to Lisa. As such, it is designed for a 32-bit system and will not work on 64-bit. If you want a library that you can continue to use, you will simply have to glue C++ onto some Cocoa – once the library is compiled, you will never know the difference.

    Of course, you could employ XWindows, gaining the benefit of broader Unixy compatibility, but that might be a can of worms.
     
  3. macrumors 6502

    Joined:
    Mar 8, 2004
    #3
  4. thread starter macrumors newbie

    Joined:
    May 24, 2012
    #4
    I write my own Library because they both suck. There is no good GUI Framework/Library out there that emphasizes modern C++ style.
     
  5. macrumors 68000

    Sydde

    Joined:
    Aug 17, 2009
    #5
    Then write a library that glues into Cocoa. Obscure the objective-C within your library and it will look just like C++ to the app code, though you may also have to write methods that handle other objects (like NSStrings and NSArrays). Basically, to make your own C++ guilib, you would have to glue onto huge sections of AppKit and Foundation frameworks.
     
  6. thread starter macrumors newbie

    Joined:
    May 24, 2012
    #6
    I just started to create a simple, empty window (Ofc i know that it won't show up because there is no message loop yet). However, the linker claims that some symbols are missing.

    The applications consists of 4 files: main.cpp, window.hpp/cpp and window_impl.mm.

    main.cpp:
    Code:
    #include "window.hpp"
    
    int main()
    {
    	gui::window wnd("foobar");
    }
    
    window.hpp:
    Code:
    #ifndef WINDOW_HPP
    #define WINDOW_HPP
    
    #include <string>
    
    namespace detail
    {
    	typedef void* window_handle;
    
    	extern window_handle create_window(std::string const& title);
    	extern void destroy_window(window_handle handle);
    }
    
    namespace gui
    {
    	struct window
    	{
    		typedef detail::window_handle native_handle;
    
    		window(std::string const& title);
    		~window();
    
    		native_handle handle();
    
    	private:
    		native_handle handle_;
    	};
    }
    
    #endif // WINDOW_HPP
    
    window.cpp:
    Code:
    #include "window.hpp"
    
    namespace gui
    {
    	window::window(std::string const& title)
    		: handle_(detail::create_window(title))
    	{}
    
    	window::~window()
    	{
    		detail::destroy_window(handle_);
    	}
    
    	detail::window_handle window::handle()
    	{
    		return handle_;
    	}
    }
    
    window_impl.mm:
    Code:
    #include <string>
    #import <Cocoa/Cocoa.h>
    
    namespace detail
    {
        NSWindow* create_window(std::string const& title)
        {
            NSWindow* window = [[NSWindow alloc] init];
            NSString* objc_title = [NSString stringWithCString:title.c_str() encoding:NSASCIIStringEncoding];
            [window setTitle:objc_title];
            return window;
        }
        
        void destroy_window(NSWindow* window)
        {
            [window release];
        }
    }
    I compiled all cpp/mm files with
    and it worked. Then i tried to link with
    but the linker says:
    What am I doing wrong?
     
  7. macrumors 601

    Mr. Retrofire

    Joined:
    Mar 2, 2010
    Location:
    www.emiliana.cl
    #7
    You use probably the wrong linker options. I used:
    which reduced the error output to:

    This is probably a problem between Objective-C and C++ (i.e. the linker can not see your defined symbols).
     
  8. Paprikachu, May 28, 2012
    Last edited: May 28, 2012

    thread starter macrumors newbie

    Joined:
    May 24, 2012
    #8
    Thanks a lot! I could solve the last problem by declaring the functions as extern "C". However, when i run the application (For now i built a normal program, not a .dylib) i get an NSException with the following trace:
    Any ideas what i could've done wrong? I'm totally new to Objective-C++.
     
  9. macrumors 603

    Joined:
    Aug 9, 2009
    #9
    What do the error messages say? They say there's no autorelease pool in place. So that's what you did wrong.

    If you don't know what autorelease is, or why it needs a pool, then you need to study the fundamentals more thoroughly. Without a solid understanding of the Cocoa Foundation classes, you can't possibly achieve your goal.

    Autorelease, and release/retain should be covered very early in any decent tutorial. If you haven't studied this before, see the Advanced Memory Management Guide.


    One of the error messages also said:
    Code:
    Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
    So you'll have to learn to do that using the debugger. Using the debugger is another fundamental and essential skill.


    The Mac Developer Library has a lot of resources for learning fundamentals.
    https://developer.apple.com/library/mac/navigation/
    See the "Getting Started" and "Guides" resource types.
     
  10. macrumors 601

    Mr. Retrofire

    Joined:
    Mar 2, 2010
    Location:
    www.emiliana.cl
    #10
    Your window initialization is probably not the correct way.

    See Tasks -> Creating Windows
    https://developer.apple.com/library...ple_ref/doc/uid/20000013-DontLinkElementID_11

    And which functions are now "extern "C""?

    Btw, Window Programming Guide for Cocoa:
    https://developer.apple.com/library...l/WinPanel.html#//apple_ref/doc/uid/10000031i

    Me too. I find your work interesting. ;-)
     
  11. thread starter macrumors newbie

    Joined:
    May 24, 2012
    #11
    Wow. I'm really impressed how ****ed up the Cocoa API is. Seriously, I've never seen such a bad API. Forcing someone to use some particular kind of memory management (here: reference counting) is the worst thing that an API ever can do.

    The problem is: For various reasons i have to do the reference counting on the C++ side. This means that i have pointers to reference counted pointers to reference counted objects. Inefficient. Also, i don't need intrusive reference counting (because it's again, inefficient, but also because i need week references), but also exception-save RC. (which Cocoa's RC is clearly not)

    Or, in short: The Cocoa way of managing objects is conceptually bu****it and not suited for any kind of application.

    Anyway, thanks again for all the links you provided me with.

    The functions that my GUI library uses internally, window_create and window_destroy. (I renamed them to have the name of the class at the front so i can get all functions related to windows with autocompletion by typing "window".)
     
  12. macrumors 65816

    Joined:
    Nov 26, 2007
    Location:
    Austin, TX
    #12
    So, Qt sucks, WxWidgets sucks, cocoa sucks.

    You're one of those huh....
     
  13. thread starter macrumors newbie

    Joined:
    May 24, 2012
    #13
    Yes, yes and yes.

    One of who?
     
  14. macrumors 603

    Joined:
    Aug 9, 2009
    #14
    Pick your poison, then deal with it.

    You're making a Facade. At some point, every instance of the Facade pattern must deal with the imperfections of the underlying subsystem. Logically, this is required. If the underlying subsystem already had the perfect interface, no Facade would be needed at all.

    So pick one of the available "sucky" things (Qt, WxWidgets, Cocoa, whatever) and deal with it. That will mean understanding it completely, and working with it on its own terms, regardless of what you perceive as the amount of suckiness therein.

    You could start by building your Facade on top of something like Qt or WxWidgets, which may be closer to what you want to deal with. This adds another layer, but it's a starting point. If you factor things well enough, you may be able to replace that underlying subsystem with something else later.
     
  15. macrumors 65816

    Joined:
    Nov 26, 2007
    Location:
    Austin, TX
    #15
    One of the folks who claim anything they didn't create themselves is crap. I've worked with folks with that attitude. With that type either they are not nearly as brilliant as they think they are, or even if they are brilliant, their attitude keeps them from working effectively in a team, or they waste a hell of a lot of time reinventing the wheel because they think they can do it better.

    Not wanting to start a war with you or anything .. I'm just sayin' ....
     
  16. macrumors 68000

    Sydde

    Joined:
    Aug 17, 2009
    #16
    If Cocoa is so intolerable, Qt sucks, WxWidgets is a PITA and nothing else is suitable, it seems to me the best choice would be Xlib. Just go right to the bottom and build the who UI design from the most portable windowing API there is. It would be a whole lot of work, but the result would be a sense of accomplishment – and probably major burn-out with a desire to embark on a different line of work.
     
  17. macrumors 603

    Joined:
    Jul 29, 2003
    Location:
    Silicon Valley
    #17
    ... except for making money developing mobile applications. None of the ivory tower, theoretically more "beautiful", development scheme's come anywhere close to producing the same magnitude of total mobile market revenue. I wonder why?
     
  18. macrumors 6502a

    GorillaPaws

    Joined:
    Oct 26, 2003
    Location:
    Richmond, VA
    #18
    Either that or he could design a robot arm that would key-in the Objective-C and design the GUI for him via a custom language the OP architects, that way he wouldn't have to code in such an "intolerable" environment.
     
  19. macrumors 603

    Cromulent

    Joined:
    Oct 2, 2006
    Location:
    The Land of Hope and Glory
    #19
    XCB is a better choice than Xlib in my opinion as it has several advantages over Xlib.

    http://en.wikipedia.org/wiki/XCB
     
  20. macrumors 6502a

    Joined:
    Oct 26, 2010
    #20
    Reminds me of

    [​IMG]

    Good luck.
     

Share This Page