Thread: [Camelbones-devel] Thinking about CamelBones - not an April Fool's joke. :-)
Brought to you by:
shermpendley
From: Sherm P. <she...@gm...> - 2009-04-01 19:37:48
|
I've been thinking about CamelBones. The fact is, I'm just not happy with it. Well OK, I'm not very happy in general - I'm still struggling with ADD and depression. But personal problems aside, I think that the overall design, to put it bluntly, stinks. I can say that without being rude, because I designed it. :-) First, a little history. When I began CamelBones, it used a shared framework that had to be installed in one of the various Frameworks/ directories. The framework itself was compiled against a particular libperl version. It wasn't binary-compatible with any other libperl, and so it was tied to a particular OS version for that reason. Apps that used the framework however, used only its "public" face, so they could use any OS version, so long as the correct framework for that OS version was installed. A number of people (myself included, to be honest) weren't entirely happy with asking their users to install a 3rd-party framework. They (we) wanted to support 100% self-contained, drag-and-drop installs. So, I devised the current scheme as a workaround. The framework is now included in the .app bundle, so there's no need to install it separately. All of the libperl-specific code is contained in a set of separate "support bundles," which are also included inside the framework. The framework examines the system when it's first loaded, and loads the appropriate support bundle. The problems with the workaround became apparent over time. First and foremost, in order to work on any given OS version, the framework that's bundled in an app has to have the support bundle for that OS version's libperl. That led to the Tiger version of CamelBones being released months after Tiger itself, and to the current lack of Leopard support. Additionally, having to build against a variety of Perl versions makes the build system absurdly over-complicated. In addition to the obvious maintenance nightmare, the byzantine build system also presented a huge barrier to entry for anyone who wanted to help contribute to the project. So, while I could conceivably cobble together a working Leopard build of the current design, I don't really want to. For one thing, the build procedure is as much of a pain in my own ass as it is in anyone else's. And for another, it won't solve anything; the cycle will simply repeat itself in June, the rumored release date for Snow Leopard. So, I've decided to refactor the design, and break it in two. The first part will be the Perl module, which I'm tentatively calling Mac::BridgeSupport. It will compile and install just like any other CPAN module, and will in fact be available through CPAN - I have to use my PAUSE account for *something*, right? As the name implies, it will use .bridgesupport files to export the contents of various Objective-C and C frameworks, making them available from Perl code. The other half of the project will be the embeddable framework. This will be static-linked against the latest libperl.a, to make it entirely independent of the system libperl. The framework's job will be to present an Objective-C interface for the embedded Perl interpreter. So, before I start writing and rearranging code, what do y'all think? sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net |
From: Rachel B. <sea...@ma...> - 2009-04-01 19:53:32
|
On Apr 1, 2009, at 12:37 PM, Sherm Pendley wrote: > So, before I start writing and rearranging code, what do y'all think? I'm probably one of the more determined, albeit quieter, users of CamelBones; I use CB to power Perl scripting in my MU* client, Atlantis. After the Leopard issue, I'm probably one of the only people besides Sherm who's actually dug into the framework build process enough to create a Leopard-compatible CamelBones. So, er, yes, I'll attest that the build system is a) a pain in the ass, b) really Byzantine, and c) did I mention it's a pain in the ass? Luckily, Sherm helped me through it and we were able to get a functional-for-my-situation Leopard CB put together, but I agree that the build system is an incredibly high bar to entry for anyone wanting to contribute to the project. I do think breaking the project into two halves makes sense; the two use-cases generally seem to be rather different anyway. There are the people who want to write Cocoa-UI apps in Perl, which seems the more common usage case, and the people who want to write Cocoa apps with the ability to run Perl code (my usage case). While pieces of each are useful to the other, the division should make the code both more maintainable and a lot easier to debug. So, I'm in favor, and I'll toss in my assistance wherever I can. :) --Rachel |
From: ravi <rav...@g8...> - 2009-04-01 21:17:16
|
On Apr 1, 2009, at 3:53 PM, Rachel Blackman wrote: > There are the > people who want to write Cocoa-UI apps in Perl, which seems the more > common usage case, and the people who want to write Cocoa apps with > the ability to run Perl code (my usage case). Speaking unofficially for the former, I want to mention (after thanking Sherm profusely for CamelBones) that for the Perl developer trying to write Mac GUI apps (which you would call a Cocoa app, but to a Perl programmer that is already opaque) the biggest pain is the lack of slightly more advanced examples or documentation. I can build a fairly sophisticated Perl/Tk application based almost entirely on the Perl/Tk documentation and examples (without delving into Tcl'ish Tk syntax). But, it seems to me that very soon after working through the excellent CamelBones tutorial, I hit the brick wall of having to know Cocoa/Objective-C syntax to proceed further. To date, I have no idea how to dynamically create UI elements (other than elements in lists) in Perl using CamelBones. I am not sure this post is appropriate on camelbones-devel, and if not, my apologies (I believe there is no camelbones-users mailing list?). --ravi |
From: Rachel B. <sea...@ma...> - 2009-04-01 21:32:49
|
On Apr 1, 2009, at 1:49 PM, ravi wrote: > On Apr 1, 2009, at 3:53 PM, Rachel Blackman wrote: >> There are the >> people who want to write Cocoa-UI apps in Perl, which seems the more >> common usage case, and the people who want to write Cocoa apps with >> the ability to run Perl code (my usage case). > > Speaking unofficially for the former, I want to mention (after > thanking Sherm profusely for CamelBones) that for the Perl developer > trying to write Mac GUI apps (which you would call a Cocoa app, but to > a Perl programmer that is already opaque) the biggest pain is the lack > of slightly more advanced examples or documentation. *snip* I would take this to mean, 'please provide either better documentation' or 'please provide more Perl-ish wrappers for the most common UI elements.' The power of CamelBones, fwiw, is that you can speak to /any/ Cocoa object, regardless of whether or not Sherm has written a bridge for it. Which means you don't have to wait for someone to write, say, a wrapper to let you use, say, WebView... no, you just can instanciate one and do all the good stuff on it. The problem, of course, is that by letting you speak to /any/ Cocoa object, you have to use Cocoa syntax to allow you to actually call the appropriate methods. (And that documenting everything that Cocoa can do is probably way beyond the scope of the project!) I'd suggest that the better solution there is thus to write wrappers (one for NSWindow, one for NSTextView, one for NSTableView, for NSButton and so on) and put those together into a community repository associated with the CamelBones project. Those can be written by the community; they don't require Sherm himself to write them. A 'Cocoa Concepts for Perl Users' might not be a bad document to write up for the project, though. I admit I hadn't really thought of that, since I always go at it the other way, calling small Perl snippets from a Cocoa program. :) |
From: ravi <rav...@g8...> - 2009-04-01 22:11:51
|
On Apr 1, 2009, at 5:32 PM, Rachel Blackman wrote: > The power of CamelBones, fwiw, is that you can speak to /any/ Cocoa > object, regardless of whether or not Sherm has written a bridge for > it. Which means you don't have to wait for someone to write, say, a > wrapper to let you use, say, WebView... no, you just can instanciate > one and do all the good stuff on it. The problem, of course, is that > by letting you speak to /any/ Cocoa object, you have to use Cocoa > syntax to allow you to actually call the appropriate methods. Exactly! > I'd suggest that the better solution there is thus to write wrappers > (one for NSWindow, one for NSTextView, one for NSTableView, for > NSButton and so on) and put those together into a community repository > associated with the CamelBones project. Those can be written by the > community; they don't require Sherm himself to write them. > > A 'Cocoa Concepts for Perl Users' might not be a bad document to write > up for the project, though. I admit I hadn't really thought of that, > since I always go at it the other way, calling small Perl snippets > from a Cocoa program. :) Wrappers or "Cocoa Concepts for Perl users" document are both excellent ideas, but I would be happy even with (a) a simpler document that helps me figure out how to translate a Objective-C Cocoa function/ method/call into an equivalent one in Perl via Camelbones (there is a conversation between Sherm and me on this a year or two ago, in the archives), or (b) some sample code that demonstrates for two or three elements (NSButton, NSTableView) how to create and modify them dynamically. --ravi |
From: Sherm P. <she...@gm...> - 2009-04-02 01:55:18
|
On Wed, Apr 1, 2009 at 4:49 PM, ravi <rav...@g8...> wrote: > On Apr 1, 2009, at 3:53 PM, Rachel Blackman wrote: > > There are the > > people who want to write Cocoa-UI apps in Perl, which seems the more > > common usage case, and the people who want to write Cocoa apps with > > the ability to run Perl code (my usage case). > I'm pretty squarely with Rachel on this one. I'm quite comfortable with Objective-C, and that's my default language for writing Cocoa apps. I consider Perl when it's a better fit for the problem - i.e. if I'm writing an app that needs to do a ton of text wrangling, I'd consider Perl for that. I'd consider it for a SOAP client app, because Apple's Web Services API is absolutely horrid, and the SOAP::Lite module on CPAN is much less so. And, I'm of the opinion that Perl would make a very nice embedded scripting language for "hybrid" apps such as Emacs, FireFox, Blender, or even MS Office, where the app's "core" is written in a fast compiled language, with much of the "higher level" functions being provided by way of scripted extensions. Speaking unofficially for the former, I want to mention (after > thanking Sherm profusely for CamelBones) that for the Perl developer > trying to write Mac GUI apps (which you would call a Cocoa app, but to > a Perl programmer that is already opaque) the biggest pain is the lack > of slightly more advanced examples or documentation. This is one reason why learning Objective-C is critical - it's Cocoa's native language, and Apple has written *tons* of excellent documentation about it, all of which assumes a basic knowledge of Objective-C. Given my own opinion that CamelBones is not meant to replace Objective-C, I honestly don't see much value in reinventing that wheel. Learning to write Cocoa applications in Objective-C is a necessary first step. Learning how - and perhaps more importantly, when - to write them in Perl is an advanced topic. I can build a > fairly sophisticated Perl/Tk application based almost entirely on the > Perl/Tk documentation and examples (without delving into Tcl'ish Tk > syntax). Then why not simply use Tk? I don't mean to be snarky - I'm serious. If Tk is a better fit for your way of thinking and doing things, that's what you should be using. Or Wx - Apple provides the WxPerl bindings right out of the box. > But, it seems to me that very soon after working through the > excellent CamelBones tutorial, I hit the brick wall of having to know > Cocoa/Objective-C syntax to proceed further. To date, I have no idea > how to dynamically create UI elements (other than elements in lists) > in Perl using CamelBones. Loading UI elements from Nib files is a key part of Cocoa. Creating UI elements in code is rarely done in Cocoa apps. If that's how you prefer to work, then Cocoa in *any* language may not be the right choice for you. I'm sorry if this sounds harsh; I don't mean it that way. I'm honestly trying to understand your point of view, but it's difficult for me. I *like* Cocoa and its way of doing things. If you don't, then why would you choose to use Cocoa to begin with, in any language? There are quite a few GUI toolkits for Perl, one of which (Wx) is even included right out of the box. > I am not sure this post is appropriate on camelbones-devel Quite appropriate, yes. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net |
From: ravi <rav...@g8...> - 2009-04-02 03:10:08
|
On Apr 1, 2009, at 9:55 PM, Sherm Pendley wrote: > > This is one reason why learning Objective-C is critical - it's > Cocoa's native language, and Apple has written *tons* of excellent > documentation about it, all of which assumes a basic knowledge of > Objective-C. Given my own opinion that CamelBones is not meant to > replace Objective-C, I honestly don't see much value in reinventing > that wheel. Learning to write Cocoa applications in Objective-C is a > necessary first step. Learning how - and perhaps more importantly, > when - to write them in Perl is an advanced topic. > >> I can build a >> fairly sophisticated Perl/Tk application based almost entirely on the >> Perl/Tk documentation and examples (without delving into Tcl'ish Tk >> syntax). > > Then why not simply use Tk? I don't mean to be snarky - I'm serious. > If Tk is a better fit for your way of thinking and doing things, > that's what you should be using. Or Wx - Apple provides the WxPerl > bindings right out of the box. > Yes, I did flirt with WxPerl, and for quick, small stuff I have also used Pashua. But I like working with CamelBones, which is the first such toolkit I came across, so I was loathe to abandon it (especially since I had a misconception of its use!). I will not contest your point on what the right goal for CamelBones is. If it is primarily a means for an Objective-C/Cocoa programmer to gain access to a scripting language for particular functionality, which is entirely sensible, then clearly I have my expectations wrong. > Loading UI elements from Nib files is a key part of Cocoa. Creating > UI elements in code is rarely done in Cocoa apps. If that's how you > prefer to work, then Cocoa in *any* language may not be the right > choice for you. > > I'm sorry if this sounds harsh; I don't mean it that way. No worries, I don't take it that way either! Perhaps I am missing something... I am not a UI programmer so its very likely I am... take a situation where I need to add a variable checkboxes (with variable text labels) to my UI depending on the user startup configuration. My naive approach is to read the user config at application startup and then generate the UI -- this is how I have done it in Perl/Tk in the past (which again may not be the best way, either!). The good news (for me) is that I have been intending to bite the bullet and start learning Objective-C, so perhaps in the future I will be able to return to CamelBones to call upon my Perl strengths from within Objective-C. --ravi |
From: Sherm P. <she...@gm...> - 2009-04-02 04:02:15
|
On Wed, Apr 1, 2009 at 10:43 PM, ravi <rav...@g8...> wrote: > > since I had a misconception of its use!). I will not contest your > point on what the right goal for CamelBones is. If it is primarily a > means for an Objective-C/Cocoa programmer to gain access to a > scripting language for particular functionality, which is entirely > sensible, then clearly I have my expectations wrong. What you're describing is different from what I'm used to - but that doesn't mean that it's wrong. Perl's motto is, after all, "there's more than one way to do it." > Perhaps I am missing > something... I am not a UI programmer so its very likely I am... take > a situation where I need to add a variable checkboxes (with variable > text labels) to my UI depending on the user startup configuration. My > naive approach is to read the user config at application startup and > then generate the UI -- this is how I have done it in Perl/Tk in the > past (which again may not be the best way, either!). Depending on the specific situation, that may actually turn out to be the best way. Never say "never!" My point is simply that what you're describing usually isn't the *first* approach that most Cocoa developers would think of. Using code to create a GUI on the fly isn't done very often. But, it is possible - Interface Builder itself, for example, does exactly that to build a UI on the fly, then serialize it to a Xib/Nib archive, and it uses only public AppKit methods to do so. But you're right - it may well be the first approach that a Perl developer would think of. I've always thought of CamelBones as providing an alternative language for Cocoa, for those occasions when Perl is a better fit than Objective-C. Perhaps I've been thinking too narrowly. Perhaps it could also provide an alternative, more "Perlish" approach, for those occasions when a more dynamic GUI is needed. It's an approach that's not very well-supported in "traditional" Cocoa, in any language. > The good news (for me) is that I have been intending to bite the > bullet and start learning Objective-C, so perhaps in the future I will > be able to return to CamelBones to call upon my Perl strengths from > within Objective-C. I'd certainly encourage that - in my opinion, a programmer should learn as many languages as he or she can. After all, a carpenter who only knew how to use a hammer would be in trouble when it came time to cut a board! That said, I hope you don't leave us entirely. Your ideas and feedback in this conversation are valuable, in large part precisely *because* they're so different than anything I'd have thought of on my own. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net |
From: ravi <rav...@g8...> - 2009-04-02 16:33:03
|
On Apr 2, 2009, at 12:02 AM, Sherm Pendley wrote: > > But you're right - it may well be the first approach that a Perl > developer would think of. I've always thought of CamelBones as > providing an alternative language for Cocoa, for those occasions > when Perl is a better fit than Objective-C. Perhaps I've been > thinking too narrowly. Perhaps it could also provide an alternative, > more "Perlish" approach, for those occasions when a more dynamic GUI > is needed. It's an approach that's not very well-supported in > "traditional" Cocoa, in any language. I am curious... if you faced a situation where you had to read a user config file (a plist file, I guess, in Mac OS terms?), and based on what's in there, you had to create UI buttons, how would you do it in traditional Cocoa style? Or is this a very rare case? > That said, I hope you don't leave us entirely. Your ideas and > feedback in this conversation are valuable, in large part precisely > *because* they're so different than anything I'd have thought of on > my own. No worries... I don't plan to leave the list! I still have 4-5 CamelBones based active apps that I use/maintain. --ravi |
From: Sherm P. <she...@gm...> - 2009-04-02 17:45:59
|
On Thu, Apr 2, 2009 at 12:05 PM, ravi <rav...@g8...> wrote: > On Apr 2, 2009, at 12:02 AM, Sherm Pendley wrote: > > > > But you're right - it may well be the first approach that a Perl > > developer would think of. I've always thought of CamelBones as > > providing an alternative language for Cocoa, for those occasions > > when Perl is a better fit than Objective-C. Perhaps I've been > > thinking too narrowly. Perhaps it could also provide an alternative, > > more "Perlish" approach, for those occasions when a more dynamic GUI > > is needed. It's an approach that's not very well-supported in > > "traditional" Cocoa, in any language. > > I am curious... if you faced a situation where you had to read a user > config file (a plist file, I guess, in Mac OS terms?), and based on > what's in there, you had to create UI buttons, how would you do it in > traditional Cocoa style? Or is this a very rare case? It's a rare case. Apple's Human Interface Guidelines strongly discourage adding and/or removing interface elements, preferring to enable and disable them instead. So, I'd look for ways to do it that way first. As a trivial example, I use gmail, and I'm typing this in FireFox. I haven't used the "back" button recently, so this page is the latest item in my browser history. The "History / Forward" menu item is still present, but greyed out and disabled. The page has finished loading, so the "View / Stop" menu item is still present, but greyed out and disabled. So, what I would try to do first is find a way to apply the suggestions in the HI guidelines. I'd ask myself, is there any way I could arrange a static Nib so that the buttons are always present, and then enable or disable them according to user preferences? Or, is there a way I could arrange it to use a table or outline view, with a variable number of button cells? If all else failed, I'd write code to create the buttons and add them to the superview. As I said, never say "never." :-) Creating and setting up a hierarchy of UI controls is actually more tedious than difficult. The preference for static Nibs comes from Apple's HIG, not from any great difficulty in building an interface dynamically. You create NSView subclasses with -initWithFrame:, which defines their (default) size and position. You'll probably need to set a number of other options that are specific to the particular view type you're creating as well, such as the target object and action selector for a button, or the data source object for a table or outline view. Then, you add the view to its parent view with -addSubview:. If the parent view is resizable, you'll need to set the appropriate options in the children with -setAutoresizingMask: - that's what is happening when you set the "struts and springs" options in Interface Builder. That's probably the biggest conceptual difference between Cocoa and other kits, as far as creating a dynamic interface is concerned; rather than having a separate "layout manager" object, in Cocoa you set the layout options for each subview separately. Alternatively, if you can require Leopard for your app, you might want to consider using Core Animation and layers, which unlike "old-school" Cocoa views, *can* use a layout manager. It's a little early to ship anything that's Leopard-only IMHO though, so I haven't done a whole lot with CA yet. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.net |
From: Matt S. <ma...@se...> - 2009-04-02 22:44:17
|
On Wed, 1 Apr 2009, Sherm Pendley wrote: > So, I've decided to refactor the design, and break it in two. > > The first part will be the Perl module, which I'm tentatively calling > Mac::BridgeSupport. It will compile and install just like any other CPAN > module, and will in fact be available through CPAN - I have to use my PAUSE > account for *something*, right? As the name implies, it will use > .bridgesupport files to export the contents of various Objective-C and C > frameworks, making them available from Perl code. > > The other half of the project will be the embeddable framework. This will be > static-linked against the latest libperl.a, to make it entirely independent > of the system libperl. The framework's job will be to present an Objective-C > interface for the embedded Perl interpreter. > > So, before I start writing and rearranging code, what do y'all think? I don't mind - I just want to get a CamelBones for Leopard, so I can start writing apps again ;-) Matt. |