> 1. SWHX is completely new, open source and cross-platform Great news!
> 2. The old version was the bench mark to which other's hoped to attain > and worked great. I disagree and there are many who would side with me. It wasn't stable and it wasn't easy to code against. > 3. The version you speak of, as I have heard, was a version that was > modified for a company you worked for - a company who's owner was a > liar/fraud and never paid for the services he hired Edwin to do. I > believe > also, that that version was left "buggy" BECAUSE of the non-payments and > therefore, was never completed/fixed/updated/made right. I am not speaking of the custom version but of the fully available version specifically. I would not talk about the custom version because I know it was written by Edwin from virtual scratch and I am aware of the bugs associated with that. You can ask developer friends of mine who worked at Turner whether or not they could use the publicly available Screenweaver for their projects and they will tell you resoundingly no. They tried but it was far too unstable and buggy. As to the other part, the non-payments and lying etc., I wrote out the other side of the story but I decided to delete it because it really doesn't belong on Flashcoders. Suffice to say the following: There are two sides to every story and painting Edwin as an innocent man who got screwed out of money hardly encompasses the entire story. I had used the public version of Screenweaver prior and attempted to use it after at a different company and had nothing but problems and other developers I know did too. It was written by somebody who didn't know C++ that well when he started (Edwin divulged to us that he was learning it as he wrote Screenweaver), and that's why it had the problems it did. It scored the worst on all the measurements when compared to three other wrappers. It had the largest executable file size, it had the largest base memory footprint, it had the worst frame rate performance, it used by far the most CPU during an animation and alpha blending test (it would spike to 25-40% cpu while other wrappers barely hit 5% and mProjector maxed at 2%) and it performed even worse when Outlook was open. > 4. Nicolas only did a port from C++ to C on the windows platform. > Edwin/team have taken it from there to the mac platform. Haxe/Neko make > everything else possible, crossplatform and very consistent with a > standard of coding that remains from platform to platform. That sounds promising. > 5. That's not true - and is a slap in the face to the guys who worked on > it. Of whom, I am good friends with. Screenweaver was for-profit with 3 > partners. The company folded and later, Edwin encouraged going open > source with it because it was collecting dust and there were alot of > requests for it to return. I apologize if any of the developers who came on after were offended. My comments had nothing to do with any developer who came on after Edwin decided to open the source to other developers. They had nothing to do with that decision and their efforts on the project since that decision are not what I'm discussing. If they whipped it into shape, great! If they rewrote it from scratch, fantastic! The bottom line is it had many problems before he opened it up and that says nothing about the quality or dedication of the developers who came on after. Why did the company fold if Screenweaver was so great? Is it because the demand for Flash wrappers was too low, or because the competition was too tough or perhaps because Screenweaver wasn't stable enough or maybe Edwin got busy doing other things? That's a separate discussion. > Mainly based on the buggy issues with OTHER wrappers. Unfortunately, almost nobody knows about mProjector because it wasn't marketed as heavily as the other wrappers, and yet, it's the best one out there as far as performance, stability and ease-of-development goes. It doesn't have some of the features some of the other wrappers out there have, though, and that's its primary weakness as I see it. > "I invite anyone to share a negative experience they had with mProjector > > 6. Ok. The UI sucks and is completely off track with other wrapper > applications. In an attempt to be "innovative", they've left other's > behind who don't have time to "think" like their innovators. Fair enough. That's a fair critique since it is part of the wrapper. You could put a Porsche engine in a VW Bug and you could put a VW Bug engine in a Porsche. I'd opt for the VW Bug with the Porsche engine if my job was to win races. mProjector's UI is straightforward to me. I don't have a problem with it. That being said, the UI for the wrapper creation tool is not the only measurement one should use. mProjector has an extremely powerful and easy-to-code-against API. Beyond just that, the way it does things in general is very smart. Let's talk about the system tray, for instance. In Screenweaver (and I speak of the pre-open source version), you created a separate 16x16 swf and had to write about 15 lines of code using a variety of Screenweaver methods to load it, show it and place it in the system tray. If you wanted to animate or update the icon with information, you had to do so via LocalConnection and write all that code to do that in both movies. In mProjector, you set aside a 16x16 area in your main movie (we used -16,-16 to 0,0) to act as the icon. With a SINGLE LINE OF CODE, mProjector will draw that 16x16 square into the system tray and make that 16x16 square in the application invisible (which is why we put it outside the bounds of the stage). Since it's technically still in your main movie, animating it, setting properties and such, is as easy as accessing any other movieclip or textfield or whatever in your movie. It's an extremely elegant and brilliant approach, especially compared to Screenweaver's clunky solution. There are plenty of other examples of how mProjector handles things brilliantly (like window to window communication using direct access, etc.) in ways that are completely familiar to Actionscript coders. The API is made for Flash developers and Actionscript coders, and learning it is as easy as learning the API to a component, including the documentation being installed into the Help window and code hints in the actions panel, too! I can go on and on about the brilliant ways that mProjector makes developing against it a breeze. I've had the good fortune to have experience coding against all the major wrappers available (and those no longer available) and it's by far the best. I'm sorry you don't care for the UI, but if you gave the wrapper itself a chance beyond the UI of the front end, I think you'd agree that it's as solid as it gets. > creating a SWHX app is cake and updating the SWHX engine/files to the > latest > releases is a commandline away - it's so easy, a caveman could do it. Command line methods are usually for more experienced developers and didn't you learn the lesson from Geico that you shouldn't make remarks about the intelligence of cavemen? ;) > In fact, I've been running Xray with it for the past 3 weeks and it's run > wonderfully and has been a beauty to maintain/update. I'm glad to hear the new version is performing better than the old one. Indeed, it appears that Screenweaver deserves another look. _______________________________________________ Flashcoders@chattyfig.figleaf.com To change your subscription options or search the archive: http://chattyfig.figleaf.com/mailman/listinfo/flashcoders Brought to you by Fig Leaf Software Premier Authorized Adobe Consulting and Training http://www.figleaf.com http://training.figleaf.com
