MonkeyBread Plug Ins

Yes but I do but are you expecting those who don’t like using plug ins to write there own ice, compiler etc?

not ice i meant IDE

Anyway, back to my somewhat long lost original post, I guess the answer is it is a matter of opinion, economics and personal preference.

And time constraints.

For me the reason to avoid plugins and encrypted classes when possible are:

  1. The person or small company may stop supporting them… The case i know of that bit the most people was the Fireye PDF classes… Luckily I stuck with Asher’s open source code. Although more limited, I have been able to update them for language changes and still use them… Those using the ones he sold are stuck.

  2. Cost… If you make your primary living from Xojo than keeping current with a bunch of 3rd party stuff can make sense. But if not it’s hard to justify.

Well, maybe you try them. Of course you can reinvent the wheel a lot of times, but you don’t need to. You probably can develop better applications and make more money by using your time wisely.
So if you get your job done in much less time using a plugin library for a few dollar, why not use it?
You already decided to use Xojo instead of Xcode and Visual Studio, didn’t you?

1 Like

Time is everything. Knowing how to write a declare statement to do X, Y or Z is of little value in regards to programmer knowledge. Invest time in things that matter such as algorithms, technologies you have not explored before, unit tests, documentation, etc…

Ultimately this is really, as mentioned before “Horses for Courses”. No one size fits all customers. I held off MBS for so long, however re-subscribed to it after a few years with the OmegaBundle last year. The DynaPDF and the full MBS suite have worked extremely well for me.

Where I do kind of draw the line generally is sometimes I want a new GUI control, and I see it elsewhere (no names mentioned! :slight_smile: ) however it’s part of a suite $100+ and I just want one control, not 10, so I either work around it or draw it manually!

I still believe that there should be more generic controls in Xojo like StatusBar and a better grid but I work with what I have!

C’est la vie.

I’m with the original poster in that over the years (at the old forum) various questions I asked or was interested in one of the replies would be to use a plugin. I’m not saying that was bad advice or off-topic as it answered the question at hand. I’m not a professional programmer/developer (or whatever the preferred term is) so it was never vital that I needed a ‘quick fix’ to get a product to market.

From a learning point of view I’d rather know how something is done. Isn’t it great when replies come in, little snippets are suggested, at times they don’t completely address your particular problem at hand but usually there’s enough to run with (or pose further questions).

Someone above used fixing a motor car as an analogy. Well, when my car needs servicing or fixing I take it to the garage, pay the mechanic to fix it. Why do I do this? Because I have absolutely NO interest in fixing motor cars.

[quote=17932:@Karen Atkocius]Is MacOSLib mostly carbon declares? If so Is that an issue with Cocoa and potentially a big issues over time?

  • Karen[/quote]

Well Carbon (or more rightly now CoreFoundation) is present & underlies a lot of Cocoa
So its not really going away
The Carbon UI kit is and many other components are

But MacOSLib is really “Cocoa safe” code

Wading through docs or code
For MacOSLib you may find it very difficult to lift just a handful of classes out

For me the argument to use 3rd party needs very careful consideration, after all my clients are not engaging me just to get the job done - they need it done properly. Complex and non-open source solutions are riskier because they are harder to replace or patch if the vendor is non-responsive.

When you think about it conceptually Xojo has plug-ins (with their own API) but Xojo can be considered as a plug-in to an OS. Xojo’s purpose is to make new plug-ins for that OS.

When Xojo has a set of cross-platform USB and Midi libraries I could conceivably give up MBS. If MBS were to disappear and the plugins to suddenly stop working for some reason I might have to figure out how to do the stuff myself (God forbid). In the meantime we have products to ship, and whatever gets the job done most efficiently for my client is what I have to choose. They don’t pay me to learn to be a better programmer, they pay me to get the job done.

1 Like

Well, that’s true, but what puts food on my table is selling software, not learning what a plugin is doing for me. Not that learning stuff like that is a bad thing, but in many cases these are highly specialized pieces of code that I would spend way too much time investigating, coding, and maintaining. I’d rather concentrate on my business logic that’s what I can sell.

I own the MBS and Einhugur plugins, both are highly recommended, and in my opinion a good value for the money.

Regarding my own use of MBS plugins-
I’ve made requests to Christian to wrap what couldn’t be done in RS/Xojo alone in order to deliver applications. I’ve also looked to MBS functionality for speed. There are instances where Christian’s plugins are faster than the Xojo alternative. I understand that saving something like .3/sec isn’t a big deal for a single process- but when you multiply that by thousands, it quickly becomes relevant.

Last but not least, time is money… There have been many cases over the years where a job required functionality that was possible to build out in RS, but time constraints presented a problem. This not only applies to the use of plugins, but to purchasing source code as well: I purchased FTP suite for a specific project because the cost of the code was far less than the cost to develop an in-house solution, not to mention much faster. This is also discounting the time and energy debugging your own solution.

In the end, it depends on the individual, time allowances, and what your time is worth. Your customers don’t care how you provide a feature and the majority could care less about the development time needed and complication of the feature- they want it, the sooner the better. If Christian and MBS stop making plugins that I need, I’ll find a solution when that time comes. I don’t foresee MBS going away anytime soon though.

Well, by extension, one might say that to get good at programming, one should keep away from Xojo itself as it insulates us from lots of the messy underpinnings of what we’re doing. In fact, I suppose we should probably stick to assembly language if we want to get REALLY good ;-}.

We have made what we consider to be excellent use of a number of the MBS plug-ins, including DynaPDF, and various Einhugur plug-ins as well. We would certainly not want to be without them. Why would it be acceptable to use function “X” if Xojo Inc. decides to implement it, yet not if it requires a plug-in?

As others have mentioned, relying on a third party can be a problem if s/he/they stop supporting their product. However, both Christian and Björn (Eiríksson from Einhugur) have proven their commitment to ongoing development and support as far as we’re concerned.

If either one of them stopped supporting their products, I would think it would almost be a necessity for Xojo to purchase / take over the line and incorporate it into Xojo in some way. WAY too many users rely on them, I think that removing them from the equation would render Xojo quite a bit more limited. I know I’d have to look for another solution, there is no functional alternative for the Einhugur grid for what I do.

My impression is Xojo does not see it that way.

Not sure why, the third-party market fills in a lot of the Xojo holes. Take that away, and you have, well, holes. I hope it never comes down to that.

From the moment on where I started to play around with the various example projects coming with the MBS plugins, I found my way into the MBS realm. Plus, in my experience Christian is always responding to questions and if something is not working as expected he comes up with solutions and suggestions very quickly.

From my perspective he is one of the most dedicated contributors to the Xojo community and my own first steps into Realbasic (at that time) date back to a training he was giving in Frankfurt, 5 years back. And I believe to observe that, since he became a father, he has even doubled his efforts. I think I owe him a beer, or two … :slight_smile:

Anyway, MBS plugins help me to realize my visions of software quite quickly, in combination with Xojo. This is important to me because programming is not my only work.

As a backup plan, for me it is good to know that I could achieve similar features and effects by using declares ( and/or MacOSLib). But by using Christian’s examples and plugins, I am just so much quicker.