I have been spending some time looking at the disaster that macoslib has become. I am giving some thought to rewriting most or all of it.
What I have in mind for what we’ll call macoslib2 includes the following,
First, introduce a plugin to add support for Objective-C blocks and provide base implementations for many Cocoa controls. Users would be able to use object method delegates to implement blocks. The idea behind the base controls is that it’s not so easy to get controls defined entirely by declares to play well with the framework. These base controls would implement just enough to be able to see them in the IDE; all other functionality would be done in Xojo code. This may seem a little complicated, but it anticipates the shift to xojo plugins (thanks, Bob, for a great XDC blog post).
Second, get rid of all of the Carbon and older code. I imagine there are some people still building Carbon applications; they can use the existing library code.
Third, get all of the accumulated “convenience code” and similar stuff out of macoslib. This wrecked macoslib for some users.
Fourth, rewrite the remaining code to use types other than Ptr for declares.
I wouldn’t mind help, but I’ll probably need to be rather more torvaldian in my management.
What would be most helpful right now would be to know who is using macoslib, and for what, and what people might like to see.
I ran into that just recently. First I don’t know Cocoa and don’t write declares myself.
Joe R posted code awhile back to get the listbox highlight colors using cocoa declares but it depened on a few thigs fro MacOSLib… As simple as the final declares were, pulling the little bits I needed to get it to work from MacOSLib was not trivial for me.
This is exactly what I am trying to avoid with iOSKit. I’m trying to make it so that each of the modules works independent of all of the others except for the Foundation module which will be needed by everything. This will hopefully mean that if you don’t need camera access, for example, that you can remove the AVFoundation module, or if you don’t need IAP you can remove the StoreKit module.
When rewriting MacOSLib, I hope that the same separation of frameworks will be possible so that the classes can be properly split apart and removed when not needed.
If you haven’t explored it yet I encourage you to take a look at and/or adapt Declare Maker which could help with processing the different classes so that you don’t have to write everything by hand from scratch.
Well theoretically yes, although I’m not sure how much stripping is happening because when I compile iOSKit with no references to modules like StoreKit and AVFoundation anywhere in any of the views or other modules the compiling progress window still says “Compiling StoreKit” or “Compiling AVFoundation” which leads me to believe they might not be stripped out. Maybe @Joe Ranieri or another engineer can comment on this? (Could be another place to further optimize build times.)
Dead code stripping happens at link time, since it requires all of the interdependencies to be known. All of the code will be compiled, but not all of it will be present in the final binary.
No
All those menu items in it that are localized end up in your project as well
I’ve mentioned this before
When we grab MacOSLIb for our use we severely trim it before using anything in any projects because of all the extra bits that wont be stripped
[quote=184763:@Charles Yeomans]I have been spending some time looking at the disaster that macoslib has become. I am giving some thought to rewriting most or all of it.
What I have in mind for what we’ll call macoslib2 includes the following,
First, introduce a plugin to add support for Objective-C blocks and provide base implementations for many Cocoa controls. Users would be able to use object method delegates to implement blocks. The idea behind the base controls is that it’s not so easy to get controls defined entirely by declares to play well with the framework. These base controls would implement just enough to be able to see them in the IDE; all other functionality would be done in Xojo code. This may seem a little complicated, but it anticipates the shift to xojo plugins (thanks, Bob, for a great XDC blog post).
Second, get rid of all of the Carbon and older code. I imagine there are some people still building Carbon applications; they can use the existing library code.
Third, get all of the accumulated “convenience code” and similar stuff out of macoslib. This wrecked macoslib for some users.
Fourth, rewrite the remaining code to use types other than Ptr for declares.
I wouldn’t mind help, but I’ll probably need to be rather more torvaldian in my management.
What would be most helpful right now would be to know who is using macoslib, and for what, and what people might like to see.[/quote]
Charles this is so very great as MANY of us rely on the MacOSLib project. Thank you very much!
[quote=184763:@Charles Yeomans]Fourth, rewrite the remaining code to use types other than Ptr for declares.
[/quote]
Congratulations for your idea. I guess everything has been said, but just one thing : we know 2015 will be 64 bit. You want to make sure all variables are safe. In the short life of iOS which is a close cousin of Mac OS X, all early declare code was 32 bit. When Xojo went 64 bit, a lot of that stopped working.
I guess Jason King and Ulrich Bogun who each went through that transition can probably tell what you have to look for. I remember also posts from Norman explaining what was necessary to make code 64 bit safe.
[quote=184781:@Jason King]This is exactly what I am trying to avoid with iOSKit. I’m trying to make it so that each of the modules works independent of all of the others except for the Foundation module which will be needed by everything. This will hopefully mean that if you don’t need camera access, for example, that you can remove the AVFoundation module, or if you don’t need IAP you can remove the StoreKit module.
When rewriting MacOSLib, I hope that the same separation of frameworks will be possible so that the classes can be properly split apart and removed when not needed.
If you haven’t explored it yet I encourage you to take a look at and/or adapt Declare Maker which could help with processing the different classes so that you don’t have to write everything by hand from scratch.[/quote]
I’ll take a look at the project. For rewriting existing code, the declares are already there.
Among the ideas I forgot to mention was that I intend to move everything into namespaces following the Mac OS libraries; e.g. ObjC, Foundation, AppKit, etc.
[quote=184805:@Michel Bujardet]Congratulations for your idea. I guess everything has been said, but just one thing : we know 2015 will be 64 bit. You want to make sure all variables are safe. In the short life of iOS which is a close cousin of Mac OS X, all early declare code was 32 bit. When Xojo went 64 bit, a lot of that stopped working.
I guess Jason King and Ulrich Bogun who each went through that transition can probably tell what you have to look for. I remember also posts from Norman explaining what was necessary to make code 64 bit safe.[/quote]
Yep; 64-bitness would be of course part of the plan.
It’s actually not that difficult to migrate declares to 64bit. It took me about two days to do it in iOSKit. Basically anything which is a CGFloat, one of the structs like NSRect, CGPoint, etc, or uses a Memory block has to be updated. Creating a bridge class which can be used anywhere outside of a declare to wrap the 32/64bit versions and then returns the proper version from a method was what I did and it works very well.
Can you elaborate on this? Is there some new type which will allow you to do this? Since the Ptr is 4 bytes on 32bit and 8 bytes on 64bit it would seem to be safe to me?
[quote=184813:@Jason King]
Can you elaborate on this? Is there some new type which will allow you to do this? Since the Ptr is 4 bytes on 32bit and 8 bytes on 64bit it would seem to be safe to me?[/quote]
I’ve been encouraged to rethink this idea. There is no new type; one would define a struct id with a single field value as Ptr. But it turns out that this might create more problems than it solves.