I'm wondering if it would be useful to switch from developing in Flash IDE to Flash Builder. Still a bit confused if this will mean having to abandon all my previous Flash work, or if it just opens up and plays nicely in FB. I've actually done a fair amount of Flex development, but am having a hard time imagining how the two overlap. I'm curious to hear from people that have made the switch... is it worth it? Or should I just stick to working in the IDE?
Both Flash IDE and Flash Builder have their own importance in the field of design and development. We choose one from both according to our need. Hope the points below i am covering will helpful for choosing the right IDE.
Flash Professional is the software series what continued the Macromedia Flash line of apps. It is used to make interactive Flash content that is based on the timeline. The timeline makes it easy to use for animation and other linear content. With ActionScript programming, though, you can jump in the timeline and, if you wish, stay in one frame. It has extensive set of tools to create, edit and import media and use it in the project. You can do a lot without coding and you can also do a lot with just coding. The code editor itself isn't as feature rich as...
Flash Builder (formerly known as Flex Builder) is, which is Adobe's modified Eclipse IDE made specially for Flex development. Its main focus is to create code, especially in XML-based Flex. Flash Builder is designed for programmers and has the bells and whistles that Eclipse has. This is also better tool to write ActionScript than Flash Professional's script editor, but its main focus is in Flex. There is no timeline as such, and products are usually rich internet applications (RIA) or Adobe AIR -desktop apps. Despite the lack of timeline, you can animate elements.
Summary
Flash Professional
Best tool (of these three) for animation
Has timeline, but can be modified with code
Coding in ActionScript (based on ECMA Script standard)
Create and edit graphical content
Flash Builder
Based on Eclipse IDE
Focus on Flex programming (based on XML), also ActionScript
Has some basic interface design tools
No timeline: non-linear logic
Flash Builder is for programmers.
Flash Professional is a design tool for graphic artists, used in game development etc. Its a mix of designing and coding. But for robust code only stuffs, its Flash Builder.
If still you have any confusion then just checked out these links:
http://www.adobe.com/flashplatform/
http://www.quora.com/What-is-the-difference-between-Flash-Professional-CS5-and-Flash-Builder-4
http://help.adobe.com/en_US/as3/learn/WS5b3ccc516d4fbf351e63e3d118a9b90204-7fd6.html#WS5b3ccc516d4fbf351e63e3d118a9b90204-7fba
http://www.adobe.com/products/flash.html refers to the traditional Flash IDE that is a member of the Creative Suite family.
http://www.adobe.com/products/flash-builder.html refers to the actionscript code editor built upon Eclipse.
You will not have to "abandon" all of your flash work. Most serious developers use both programs side by side with Flash Professional being the main animation/ design program and Flash Builder being the main coding editor. You can publish from either program. Personally, I have found that browser swf files are easier published from flash pro, while mobile apps for iOS and android are easier to publish in flash builder (just easier to deal with icon images, xml metadata files, package explorer, etc).
Related
Just new on software testing...
Regarding testing, I think GUI applications are pretty difficult to automate. Some testing involves with interacting particular GUI objects in particular sequence (e.g., clicking buttons). The interface often changes from one window to another. And the timing and sync sometimes also pose an issue (e.g., recording mouse clicks and replaying may screw up).
Is there any solution for testing such applications with less human labour? Thank you for sharing your experience.
Yes, GUI apps are indeed tough to automate. Regardless of the app's technology (Swing, web, WPF, iOS), you first have to focus on automating high-value tests. Moreover, test automation shouldn't be at just the GUI level, it should be a mix across unit, integration, and functional (GUI) tests too.
Are you working on a web app? If so, have a look at great open source tools like Watir or WebDriver. (I'll also pitch Telerik's Test Studio to you; however, for full disclosure I'm their evangelist for that tool.)
Desktop applications (or mobile) bring a lot of challenges to automation, and it's totally dependent on what platform you're working with. Test Studio supports WPF, but you can also look to other commercial and a few free tools. I don't know of any tools for Swing apps, but that lack of knowledge is due to me having been out of that domain for many years. (And maybe I'm so out of it that Swing's not even the normal Java GUI toolset...)
iOS and Android are tough ones to find reliable automation tools for. I know the Frank framework/API will work on iOS (Test Studio has a free recorder in the App Store), but I don't know of any other tools that reliably support the extraordinary matrix of Droid hardware and OS versions.
Regardless of your platform and toolset, you need to learn the basic approaches for dealing with GUI testing: focus on high value tests, learn to avoid duplication through approaches like Page Object Pattern, learn how to deal with synchronization/timing issues in your specific application.
It's a long haul, but if you work carefully it's totally worth it.
(And fun, too, IMO.)
I want to automate a sequence of task on Adobe Premiere Pro CS6,
thats all repeating tasks, and while doing manually consumes lots of time, :)
that stars from: importing video file, image files, doc file-> making a sequence -> adding files on sequence with predefined height , width-> inserting scripts -> analyzing them -> adding marks on particular word on metadata-> and finally exporting it..
I want to make all these task automatically done with some scripts on adobe premier pro or anythign else...
appreciating
Premiere is scriptable, as are the other Adobe Creative Suite apps, using their Extendscript API. Extendscript uses javascript. There's an official Adobe IDE for it called Extendscript Toolkit, that has a script editor, debugger and a object model viewer.
There's one problem, for premiere the documentation is perplexingly scarce. It's a pity, because for other programs like After Effects there is a thriving community of developers doing amazing stuff with extendscript.
The Adobe Javascript guide is here and some class information specifically for Premiere can be found here.
If you are on the PC platform, try having a look at a free windows automation package such a AutoIT or AutoHotKey. I have been using AutoHotKey for several years now and this tool can be used to automate pretty much anything you can think of. It is a scriping language, there is a learning curve, but easy to use if you follow the many tuts and samples out there.
It doesn't seem to be officially supported, mentioned or used much (maybe because most user think programming is 'nerdy' stuff and don't touch it?) - anyways:
http://forums.adobe.com/message/5310306
Unfortunately the documentation is scare and I don't know which version may support scripting (and which OS).
I've been using smalltalk for a while now and I love the language and the concept. What I just hate is the System browser. This tool doesn't even resemble a modern IDE. How am I supposed to code without tabs, outlines and handy shortcuts? I often find myself implementing a selector and noticing that it would be nice to isolate a piece of code in a separate (private) selector, just for readability shake, but I don't. Because it takes like 5 mouse clicks and I have to navigate away from the selector I am working at, and navigate back to it. Oh wait, I can't! Because it has syntax errors, because I haven't finished it yet! Kills me. And I don't have a 24 inch display to open 3 browsers.
Sorry for a little rant. My question is, is there a real IDE (Eclipse, Net.Beans, VS) for smalltalk? Maybe for some commercial version of smalltalk?
You might want to check out tODE. It's at a very early stage, but it is an attempt to provide a Smalltalk IDE in the web-browser and is a break from the traditional Smalltalk IDE. With that said, I don't think you'd want to start using tODE right away, but you can keep an eye on it as it evolves.
Dale
Pharo is trying to have the Nautilus Browser ready for Pharo
1.4. I suspect there will be a flood of awesome new tools as the system stabilizes over the next few releases.
There's the Glamorous Inspector.
Spoon has been mounted as a WebDAV filesystem, so you can use whatever tool you like. Spoon is not another Smalltalk, but a testbed for revolutionary Smalltalk technology, which can be incorporated into any other Smalltalk (it's currently on top of Squeak)
There is the Tiling Window Manager to help you organize
Since Squeak and Pharo are live, dynamic, open systems powered only by volunteers, anyone sufficiently motivated can create the next generation of tools ;-)
p.s. I feel your pain. The 20-browsers-open thing is a drag. Let's invent the future!
Historically, the real "IDE" is the Smalltalk one, and one could claim that the others are just an adaptation to the limits of traditional textual programming languages (not rethorical, just check out the evolution of typical development environment UIs and how they are adding features that exists in Smalltalk from the very beggining, like the senders and references in VS).
Just a side note: actually more than 2000 open-source projects in the SqueakSource repository were coded without tabs, outlines and shortcuts (I think still in Squeak you can cross reference any text selecting and pressing with Alt-6). I can't tell you how sad I feel when I must to go back to file based developement, still don't understand why most developers love to sweep text, mess with line numbers and page up-down files in directories. The good news for you, is that you have many options:
There is an alternative browser called BobsBrowser (works in Pharo 1.3) which lets you browse
Class hierarchy windows exploring each class
System Category window
Unsaved edits
Recent classes
Recent methods
Method categories for instances and classes
Unsent methods
Driller relating every structural information
etc.
The advantage over the Whisker browser is that the hierarchical lists are attached to a window while in BobsBrowser you can detach them.
It all depends of the different activities you're performing when you're developing. With some experience in Smalltalk you'll find that you prefer some browser for exploratory insights and others for refactorings, etc. BobsBrowser for example is good for knowledge organization or custom navigation of Smalltalk classes and categories, the hierarchies you can see are the organizations from the Smalltalk reflective meta-architecture at any level (classes, senders, implementors), and they are expandable/collapsable (in the classic system browsers you can only expand the system categories and subcategories).
The instance variables were shown historically in the Smalltalk/V flavors, and there is an old goodie (from Squeak 2.7 IIRC) to enable it back again but almost nobody today maintains the classic System Browser in Squeak/Pharo. Adding that feature to OmniBrowser would be more complicated though because is a browser framework (as every serious framework, it took some time to learn it for the first time), although the effort of the Squeak/Pharo community is absolutely incredible, still the Smalltalk community needs more developers.
You have also a commercial Smalltalk which isn't public (downloadable) yet but includes IDE-like features of traditional programming environments
And I don't have a 24 inch display to open 3 browsers.
You could give the Whisker Browser a try. It lays out the methods side-by-side so that you don't have to position all these windows manually.
I played with it a few years ago but I'm not sure what state it's in right now.
I don't know how mature it is, but the Etoile project has an IDE called CodeMonkey for writing Smalltalk applications. It's not specifically for Squeak, and instead uses their own smalltalk implementation, but it may be worth looking into. Unfortunately, it's only available in their SVN repository, so it's a pain to compile and install.
I've been developing for Windows and *nix platforms for quite some time, and am looking to move into Mac development. I am tossing up between using ObjC/Cocoa and C++/Qt4.5.
The C++/moc semantics make more sense to me, and improving knowledge in Qt seems like a sensible thing to do given that you end up with a skill set that covers more platforms.
Am I likely to handicap my applications by skipping Cocoa?
The sample Qt applications look pretty Mac-native to me, but they are quite simple so potentially don't tell the whole story. Are there other pros to the Xcode way that Qt doesn't have, such as packaging, deployment, etc.?
Here's an easy way to answer it:
If you were developing a Windows app with .NET or MFC, would you handicap your applications by using Qt? If the answer to that is yes, then the situation is likely to be the same on the Mac.
A few negatives I can think of off the top of my head:
Licensing
Qt apps, while good, are not completely a native UI experience and there's things a native UI designer can do in Cocoa which boggle the mind. While I can't be sure that all the same functionality isn't available in Qt, I doubt it.
Qt is always a little behind. If Microsoft or Apple come out with a great new technology, you have to wait for the Qt developers to update Qt.
However, with all that said, only you can determine the business value of using Qt. If you think cross-platform development is going to be a major part of your development, then Qt might be worth it, despite the issues mentioned.
Ask yourself: how many of the best Mac applications that you know of use Qt instead of native Cocoa?
For our robotic systems, we originally wrote our control software in C++ using the cross-platform wxWidgets library (we avoided Qt due to some licensing concerns), because we felt that we had to target Windows, Linux, and Mac platforms for our end users. This is what we shipped for over a year until I started tinkering with Cocoa.
Right away, the thing that most impressed me was how quickly you could develop using Cocoa. Eventually, we decided to drop support for Linux and Windows and rewrite our entire control applications in Cocoa. What had taken us years to put together in C++ required only three months to completely reimplement in Cocoa.
Aside from the "lowest common denominator" interface issues that others have pointed out, the rapid development allowed by Cocoa has become a competitive advantage for our company. Our software has advanced far more quickly since our conversion to Cocoa, and it has allowed us as a new company with one developer to pull even with 10-year-old competitors that have 20-man development teams. This appears to be a common story in the Mac development space, where you see a lot of small teams who are able to create products that compete with those of much larger companies.
As a final note, using Cocoa gives you the ability to stay on top of the new APIs Apple is continually rolling out. We're now working on a new control interface that will make heavy use of Core Animation, something that would be painful to deal with using Qt.
I'm currently developing both with QT (actually PyQT, but it makes no difference to your question) and native Cocoa app. For me it's no brainer, I'd chose Cocoa. It's really worth time to explore Cocoa in general, there are many great concepts within the Cocoa framework, and Objective-C 2.0 as well.
I'd use Qt if you want this to be a crossplatform application.
You can have a look at the QMacCocoaViewContainer class. It acts as some kind of wrapper for generic Cocoa views, so you can also have Cocoa elements which are not officially supported by Qt.
Of course this means learning a little about Cocoa and Objective C and how a Cocoa UI would need to look like. But if you already know Qt well and if it’s not like your application is all and only about the GUI this could be a good way to go.
And don’t forget about the QMacStyle::WidgetSizePolicy or you won’t understand why your tables come out so huge.
Obviously, the best option is to use a cross platform suite that supports native widgets.
With QT4 you can build your base user interface. Then just add native support for your specific target platform.
Sure, Cocoa has a lot of fancy stuff (and you can still use them trough QT4), but let me be clear. I see a lot of fancy Apps on the AppStore, pretty ones, but most of then are just crap, expensive.. what ever. I really missed my Kate text editor, my okular viewer, my krita drawing software... those are just better than the commercial and expensive alternatives and are free. so i just tweak the source code a little bit too have a REAL native and great experience.
What if i have to use a linux app on my main computer with is a mac os x? or windows? or whatever? only?
For example, why on earth i have to buy a expensive ,fancy but far less featured image editor software for my mac like pixelmator when i can use a full featured real image manipulation software like Gimp? YES Gimp is gtk2 based which is a pain on any platform, specially on Mac because is really ugly. Gimp should be ported to QT4. Inkscape should be ported to QT4 too, and it would feel so great.
Is so simple to do.. gosh!
http://doc.qt.nokia.com/4.7-snapshot/demos-macmainwindow.html
Even you can add support for the the new native lion fullscreen feature, unified title and toolbar menus, etc
I , as a user, i really care about efficient, featured, good and cross platform apps, i don't really care about developer's convenience or laziness .
I do a lot of cross-platform development (Mac, Windows, Linux), and for some projects use Qt. It is a fine framework, and provides a rich class library. If you need to deploy on multiple platforms, cannot afford to spend the time/effort on platform-specific front-ends, or the "generic" support for each platform is sufficiently good, then use Qt.
However, Qt inevitably suffers in some ways from the lowest common denominator syndrome, and sometimes does not feel quite native enough. There are also certain features that are either difficult to support, or are simply not provided in the Qt libraries. So if you can afford the time and effort, or your app really demands the attention to detail and fit & finish, then developing separate front-ends may be worth it.
In either case, you ought to be writing your back-end (aka domain) code in a platform-neutral and front-end neutral manner. This way, the front-end is easily replaced, or modified between platforms.
You could always start with a Qt front-end and go for a quick time to market, then develop a native front-end down the line.
In practice, I've noticed that a Qt app on Windows looks most "native", while on Mac there are certain subtle telltale signs that make it look/feel not quite right. And Mac users tend to have much higher expectations when it comes to UI/UX!
Since posting this, i've been learning the Cocoa / Objective-C way, and have been quite impressed. Despite what I initially thought was quite a quirky syntax, Objc appears to be a very effective language for implementing UI code, and the XCode sugar - things like Core Data and bindings - make short work of all of the boring bits.
I spent a while with the QT examples and documentation before digging into cocoa, and tend to agree with what has been said above w.r.t being slightly behind the curve and less 'aqua-ish' - albeit from a fairly trivial inspection. If I absolutely had to be build a cross-platform app i'd probably use QT rather than trying to separate out the UI code, as it seems like it would provide close-enough visuals, but for mac only purposes, Cocoa seems like a definite win.
Thanks all for your responses, they've all been very helpful!
DO NOT use Qt for a Mac app. You will get no hardware acceleration for 2D rendering, and you will not be able to deliver ADA compliance.
Depending on what kind of apps you want to write, another contender is REALbasic now called Xojo.
The move from C++ is pretty easy (I have 15 years C++ experience) and the framework and IDE extremely productive. You have the added bonus of being able to deploy to Linux and Windows with trivial effort. Their framework compiles to native code and uses native widgets so you don't have an emulated look and feel.
The big reason for learning Cocoa and coding in Objective-C is if you want to hone your iPhone skills or are chasing a really fancy user experience. If you wanted to rival the cutting edge of WPF development then I'd recommend Cocoa.
I need to write a desktop application that can run on Mac (Windows and Linux soon) that can get data from MySQL and allow users to transfer files from their desktop to the server.
I know I can write a desktop app in AIR, how would Fireworks play into this?
Can AIR connect to MySQL?
Can one FTP files with AIR?
On a second note, can one write such applications as a ring-tone maker, a disk repair/partitioning utility in AIR? I know AIR uses web technology, but what other thigns are possible?
-Jason
Do you mean Adobe Fireworks? I would use Fireworks for the interface design. It also has some customizable assets.
Here is the product page where they have a lot more info on what it's capable of.
http://www.adobe.com/products/fireworks/features/?view=topnew
An AIR application is a desktop version of a Flash Application. So anything you can do in a Flash Application you can do in an AIR application. Flash Apps work with MySQL so you should be able to get an AIR app to work with MySQL.
AIR apps can also access the local file system. For instance you can write an AIR file loader application.
Fireworks is my design tool of preference. If you are working with digital graphics there is little need to look beyond FW to things like Photoshop and Illustrator. All of the CS5 software intro screens were designed in Fireworks. It has the best 32 bit PNG output I have seen and the colors are dead on without that issue from PS changing its output from the authoring environment.
From experience, I would not recommend spending time with AIR. Web apps are the way to go and the investment in a desktop or even mobile specific device app is going to be tough to justify because of programming maintenance costs, version releases and the speed new technology is released.
You could use Fireworks for the creation of images for the UI ( User Interface ) for most parts its okay enough, if you need advanced shadowing and color options you can look into photoshop, but fireworks is just great for the basic graphical stuff.
Im not sure if you question was maybe related to the UI since fireworks itself should have nothing to do with building the Air application.
You can use different solutions to build your air application, maybe off topic but if you have not decided how to build the AIR app I would look into Adobe Flash Builder 4,5, flex and the AIR development library's. Flex is also great to easily change the user interface (CSS) where you could create the images with fireworks :)