Thursday, December 17, 2009
Tuesday, December 15, 2009
Thursday, December 3, 2009
It's been a year since we introduced the new REAL Software Website and the feedback has been very positive! Following are some tips on how to take full advantage of all the great features.
How to Register your Account:
To register your Account select the "Create New Account" button at the login page:
Enter the email address linked to your REAL Software Account to receive an email with instructions on how to create a log in. If you are unsure what email address is linked to your Account email Customer Service.
Once logged into your Account you can access all your License Keys, your Order History and any Previous Downloads available for those keys.
Did you Register but don't see all of your keys in your Account? It's possible you have created more than one account. Send an email with your keys and/or email address to Customer Service and we can merge all your accounts together. You may find you have expired keys you didn't even remember you owned! Just yesterday a long time user of REALbasic was planning on purchasing a new Windows Pro key, upon registering his Account he learned he owned an expired Windows Pro key already! He purchased a Renewal instead and saved $149!
In your Account you can also update your contact information. Keeping your email address current will keep you informed of REAL Software special offers and discounts throughout the year.
You can contact us at email@example.com if you have any questions about your Account, or anything else REALbasic, and we will be happy to assist you further.
Tuesday, December 1, 2009
"We recently introduced a new feedback system that allows users to rate the importance of bugs and new feature requests," commented Geoff Perlman, REAL Software Founder and CEO. "This new system has allowed us to really focus on the quality improvements for this release that are most important to our customers."
The complete list of improvements and new features in REALbasic 2009 Release 5 can be found in the release notes in the product download section, www.realsoftware.com/download.
Monday, November 23, 2009
Chome's hidden agenda is to improve WebKit adoption in order to force Microsoft's hand into better supporting modern web technologies such as CSS3 and HTML5. Google doesn't plan to make money from Chrome, they intend to improve web standards and compliance so they can in turn write better web apps that run on all platforms. It is those web apps such as Google Docs where they can make money. Remember, Google is a business, they're not simply going to devote so many resources to Chrome OS just to help people. There is always a bigger agenda.
Now, I'm all for this tactic. Microsoft really does need to get their act together, and competition from Mozilla, Apple, and Google has already forced them into putting a ton more resources into IE. Will it work? I'm not sure, there are already signs that Microsoft is again trying to fight standards with IE9 just as they did in the Netscape days.
Chrome OS is an interesting concept, but I'm not betting on it. Apple tried the webapp-only model on the iPhone and failed horribly. Why would Chrome OS be any different? For example, Macs are frequently bashed for not playing games well. Chrome OS won't be able to play games at all (flash doesn't count, I'm talking about real games) and does anybody expect that gamepad, joystick or G15 keyboard to work? That's just an example, there are a TON of things users will be unable to accomplish with Chrome OS. Enough that I believe Chrome OS will remain nothing more than an interesting concept.
Now, I'm a power user for sure, so my view could easily be skewed. But it does not make sense for REAL to put significant resources into coding for an operating system that will likely have an adoption rate lower of that of Ubuntu. The only consumers who will get this will be the ones who recieved it on their netbooks, and only if said netbook will have it pre-installed. That said, since everything runs on the web, there isn't much we'd need to do. REALbasic can already compile code for Linux (most popular web server) and has an included CGI template, so go write a web app right now.
Wednesday, October 28, 2009
Thursday, October 22, 2009
Wednesday, October 21, 2009
Tuesday, October 20, 2009
Tuesday, September 29, 2009
Once that is loaded, you can now search for WebKit. Knowing that WebKit is a library I prepend my search of WebKit with Lib, so instead of just searching for webkit (which actually turns up quite a few hits), I'll search for libwebkit:
You want to mark the first hit of libwebkit-1.0-1 for installation, then apply. For those who like the command line approach, you can launch the terminal and type:
sudo apt-get install libwebkit-1.0-1
You are now ready to enjoy the new HTMLViewer using WebKit!
Thursday, September 17, 2009
Over the years we have had many different systems for gathering bug reports and feature requests. We used to have a system that was pretty transparent. You could search it, contribute additional information to a particular issue, etc. We could get a sense of how important a case was based on the number of you that added that case to your watch list. This system was very specific to your needs, which are the needs of a software developer. As a result, this system was created in-house.
A few years ago, an argument was put forth internally here at REAL Software that we shouldn’t be re-inventing the wheel by building and continuing to maintain our own, custom bug database system but instead should use one of the commercially available systems. There was a lot of sense in this argument. These systems had features that our system did not and they were maintained by others allowing us to focus on what we do best. But these systems were not without their downsides. The theory behind FogBugz, the system we use today, is to make the system of entering a bug as simple as possible for the end user because if you ask too much, users won’t provide feedback. The other assumption is that most users don’t need to search through your bug database. These assumptions are all quite reasonable for 95% of software users. It became obvious to us late last year that you, our customers, are not in that 95%. You are like us. You are software developers. You understand the importance of providing lots of detailed information. You want to search our bug database to see if a report has been filed before and see if a workaround exists. You will tell us which cases are more important than others.
With this in mind, we decided early this year that we needed a new Feedback system. FogBugz is fine for most software companies whose customers are not software developers, but it’s not ideal for customers who are. However, if you are looking for a feedback system for your product, I would certainly recommend it. We spent some time looking at what was good and bad about our old system and what was good and bad about FogBugz. We then set out to build a new Feedback system that would give you and us the best of both systems.
While the old system was designed to be opaque, the new system is almost totally transparent. You can search, and the searching is actually very cool. It’s simple and yet very powerful. It also includes relevancy information to help you track down the case that is the most likely match. You can filter reports by product, version, status and more. You can keep a list of your favorite cases to make it easy to keep track of them. You can contribute to existing reports, adding workarounds, example projects, etc. that others can use. If there is information that should be for our eyes only, you can mark the information you add as private. And last but most certainly not least, you can put your most important cases in order of your personal priority. This and the priorities of others are put together to create a score. This allows us to see what the most important cases (both bugs and feature requests) are. You will be able to see them too because the new Feedback system will show you the top 20 cases by score. We have added this because we want you to see that we are making an effort to address the most important cases first. That’s not always possible of course and some bugs get addressed as soon as they come in because they are very easy to fix and an engineer might be working on that part of the code when the bug is reported.
In the past, the score of a case was essentially the number of people that added that case to their watch list. Anyone could add any number of cases to their watch list to increase the priority. The problem with this is that it didn’t give us a true picture of what your priorities are. In the new Feedback system the only cases that are scored are those that are within the top 5 open cases on your personal priority list. The new Feedback system makes it easy for you to reorder your cases so that we can see your personal priority. Also, in the case of REALbasic, the edition of REALbasic you are using affects the score your top 5 open cases receive. Professional Edition users are given 3 times the priority of Personal Edition users. REAL Studio Edition users are given 10 times the priority. We are doing this because the more you invest in us, the higher we feel your priority should be. That doesn’t mean that a Studio user would always get higher priority. For example, if fifteen Personal Edition users put a particular case at the top of their list, that would have a higher score than a case at the top of a single REAL Studio Edition user’s priority list. This scoring system will help us understand which cases should be addressed to have the maximum impact on you, our customers.
When we have changed systems in the past, we have asked you to go through your cases and help us move them over to the new system. For some of you, this was a lot of work. We will not be asking that of you this time. We have automated the process of moving the cases over. However, we will need you to do one thing. Because you can’t search our current Feedback system, it is implied that all cases are private in that others outside of REAL Software can’t view them. We would not want to accidentally expose to everyone a case you thought was private. As a result, you will need to tell us (via a web page) which of your reports should be private and which should be public.
This new Feedback system runs on Mac OS X, Windows and Linux and will ship soon with REALbasic 2009 R4. It’s going to help us better serve you and it’s going to better allow you to help each other - whether it’s providing a workaround for a bug, or discussing the pros and cons of a particular feature. We look forward to your comments and suggestions.
Use the following links to view larger versions of the screenshots:
Friday, August 28, 2009
Thursday, August 20, 2009
Pairs are handy for this, because we can prepare a list of percentages and colors and pass that to our method. The left value will contain the percentage, the right value will contain the color. Our gradient will be a simple red-yellow-green gradient:
dim colors(2) as pair
colors(0) = 0.0 : &cFF0000
colors(1) = 0.5 : &cFFFF00
colors(2) = 1.0 : &c00FF00
This basically says that at 0%, it should be red. At 50%, it should be yellow. At 100%, it should be green. We'll pass this array a method which defines the width, height, and direction of the gradient:
Function CreateGradient(Width As Integer, Height As Integer, Points() As Pair, Vertical As Boolean = false) As Picture
dim p as new picture(width,height,32)
dim i,x,w,nextstart as integer
dim pointOne,pointTwo as pair
dim colorOne,colorTwo,blendedColor as color
dim pct as double
for i = 0 to ubound(points) - 1
pointone = points(i)
pointtwo = points(i + 1)
colorone = pointone.right
colortwo = pointtwo.right
if vertical then
w = (pointtwo.left.doublevalue * height) - nextstart
w = (pointtwo.left.doublevalue * width) - nextstart
for x = 0 to w
pct = x / w
blendedcolor = rgb((colorone.red * (1 - pct)) + (colortwo.red * pct),(colorone.green * (1 - pct)) + (colortwo.green * pct),(colorone.blue * (1 - pct)) + (colortwo.blue * pct))
p.graphics.forecolor = blendedcolor
if vertical then
p.graphics.drawline(-1,x + nextstart,p.width + 1,x + nextstart)
p.graphics.drawline(x + nextstart,-1,x + nextstart,p.height + 1)
nextstart = nextstart + w
And that's all you need to create better gradients on-the-fly. Just for fun, here's the colors you need to draw a gradient similar to Apple Mail's toolbar buttons:
dim colors(3) as pair
colors(0) = 0.00 : &cDADBDD
colors(1) = 0.50 : &cD6D7DA
colors(2) = 0.51 : &cC8CBCE
colors(3) = 1.00 : &cDDE0E3
Monday, August 17, 2009
Thursday, August 13, 2009
- Turn on the Canvas.DoubleBuffer property.
- Turn off EraseBackground. EraseBackground causes the drawing area to be erased first, which will be flushed to the screen immediately causing flicker. This is important for both Canvas and ContainerControl classes. In ContainerControls, make sure the instance has it disabled, and if your code creates one of your ContainerControl subclass "out of thin air" then make sure your subclass has this disabled as well. Keep in mind that sometimes control artifacts can be left behind depending on the type of drawing you're doing, since they weren't erased first. My only suggestion is to try it and see how it works for your case.
- Only draw using the Canvas.Paint event. As much as we programmers like to say "Canvas, display this now" using the backdrop property, it is the wrong way to do it. Instead, when you want the canvas to forcefully update, use the refresh method. The backdrop property is only useful from the window editor, when you want to display a static / non-changing graphic.
- Whenever you call RectControl.Refresh, pass the optional EraseBackground parameter to it with a false value. This will prevent the control from erasing itself pre-refresh. See tip 2 above.
Monday, August 3, 2009
Wednesday, July 29, 2009
One of the great things about so many people having broadband internet access is that it makes it practical to have a video-based demonstration of your product available via your web site. If you've never done this before, it's not that hard but there are a few gotchas that can cause you some grief. Since they have already caused me that grief, please learn from my mistakes rather than your own. If a picture is worth a thousand words then a video must be worth at least two thousand.
Here are my top 10 tips on creating an effective demo video:
Tip #1: Keep it short
Some people don’t have a long attention span. The longer your video is, the more likely you will lose your audience. So make your video only as long as it needs to be and no longer. Decide up front what the point of your video is and focus only on making that point. For example, in the Introduction to REALbasic video, I don’t mention most of REALbasic’s features. That’s because the point of the video is not to familiarize the viewer with all of REALbasic’s features, but instead to give them a general feel for what it’s like to use REALbasic. The two things you do most in REALbasic are build a user interface and write code, so the video focuses on those two topics. If you can’t seem to keep the video under 10 minutes, considering breaking it up into a series of videos.
There may be other factors that limit the length of your video. For example, if you are going to put it on YouTube, it must be no more than 10 minutes long. You should determine ahead of time how you will host your videos so you know about limitations like this. Another potential limitation can be file size which can affect the length of your video and, in some cases, video quality.
People also like to know how much time they will need to devote to watching your video so make sure that’s clear before they start. Ideally, you should put the length of the video on the web page where the video is displayed.
Tip #2: Get feedback early in the process
It can be really frustrating to spend hours on your video only to find out that you left out something important or communicated something in a way that makes sense only to you. The best way to avoid this is to record a rough draft and get feedback from others. I use Screenflow for Mac OS X to create screen recordings. With it you can simply start recording the screen, do your demonstration and talk. Screenflow will record everything. Don’t worry about ANY polish at this point. Just record your demonstration so that you can see how it flows. Don’t worry if you make mistakes. The point of this rough draft is to look for any major flaws in the overall demonstration. If you find any, record another rough draft until you think your demonstration (both on screen and what you will say) is pretty solid.
At that point, get feedback from appropriate people (ideally those that are the intended audience). Let them know you want any and all constructive criticism they have. Takes lots of notes and take the criticism seriously. Keep recording rough drafts until the only feedback you are getting is that the video needs polish.
Tip #3: Know your aspect ratio ahead of time
There are a few different aspect ratios. For example, standard television uses a ratio of 4:3 which is the ratio of the width of the screen to its height. If the width of the area of your screen you intend to show is 800 pixels,for example, then the height would have to be 600 pixels. For more information on aspect ratios, see this article on Wikipedia.
YouTube recently switched to 16:9 which is the widescreen format used by most of the movies you watch on DVD. So if you plan to host your videos via YouTube, you will want to be prepared to use the 16:9 format.
How do you prepare? After you record your video, Screenflow will let you crop the video to a specific size in pixels. If you are using something other than Screenflow, make sure it provides this feature. Experiment to find the right height or width and then adjust the other size to match the ratio you are using. For example, if you are using 16:9 and the width that works for you is 1250 pixels, divide 1250 by 16 (78.125), drop the decimal portion (if there is one) and then multiply that value by 9 to get the height. In this case, that would be 702 (78 * 9 = 702).
Getting this right will take some experimentation. In almost all cases, the person watching your video does NOT need to see your entire screen. Doing that will only distract them and make it more difficult for you to get your message across. Instead, make sure you arrange your windows so that you show just what is needed and so that it can be cropped to the aspect ratio you will be using. I do this by doing a short Screenflow recording (perhaps 30 seconds) then cropping it to 16:9. I use iMovie to create titles and apply transition effects. So my next step is to create an iMovie project using the same ratio (16:9) and import my video. Then I can preview the video to see that it is going to work correctly. Getting this right for your rough draft will save you hours of time and a lot of frustration later on.
Tip #4: Write a script
Ten minutes may seem like a long time but it goes by pretty fast. If you are going to get your point across, every word must count. Write a script of exactly what you intend to say and follow it. This will help you keep your message focused. When recording without a script, people tend to add non-words like "um", "uh", etc. These non-words will make your presentation sound less professional. Make sure you include any directions you need to remind you what to demonstrate as well. Remember that your on-screen actions take time so you may not have as much time to talk as you think. You can then time yourself following your script to make sure you will stay within whatever time limit you have.
Tip #5: Keep the presentation focused
The best demonstrations are those that are extremely focused. Don’t allow anything to distract the viewer from your message. Keep this in mind when determining what you will show. If it doesn’t support your message, don’t show it. Remember, time is at a premium. Don’t assume the viewer will watch the entire video. If you don’t keep them interested, they may stop watching. When recording your video, make sure there isn’t anything that could be a distraction, like unnecessary icons on your desktop or edges of other windows in your video.
Tip #6: Make use of pan and zoom
When you introduce a topic, the viewer needs to understand the context. Showing them the entire window, for example, will help. After that, you can zoom-in on the part of the window or screen where the action is. This will help keep the viewer focused. If you are hosting your video on YouTube, it will really help the user to be able to see what you are demonstrating. I didn’t consider this when I made the first Introduction to REALbasic video and as a result, it was difficult to follow. The updated version makes extensive use of zooming and is much better as a result. Screenflow makes it easy to zoom in and out and this can be done after you finish recording. It also makes it easy to pan from one place to another. I do this quite a bit in the Introduction to REALbasic video so that I can stay zoomed in, but still keep the viewer focused on what I’m showing them. Screenflow also has some other effects you can use. One feature allows you to highlight the foreground window. This causes everything else to be shaded. I use this effect in the Introduction to REALbasic video. Screenflow can highlight just the cursor as well. I do all my video recording on Mac OS X so I can use Screenflow, but there are almost certainly tools for Windows and Linux that provide similar features.
Tip #7: Make sure you’ve got quality audio
I’ve seen some video demonstrations that use text rather than voice to guide the viewer. While there may be times when this makes sense, try to avoid this if possible. Effective demonstrations should be similar to what they would be if you were standing in front of the person to whom you are demonstrating. Explaining your point with audio will be far more effective than using text. Text is fine when you are introducing a new topic but not for the entire demonstration.
The quality of your audio is another important factor. Make sure you have a quiet place to record so that background noise won’t be recorded and provide another distraction. The microphone built in to your computer is fine for recording a scratch audio track, but it’s not good enough for your final version. It will pick up too much of the sound around you and it will sound like you are too far away from the microphone (because you are). As a result it will not sound professional. Invest in a decent USB microphone. Logitech makes some good ones. This will allow make your audio sound much more professional. If you happen to own the video game, Rockband, the USB microphone that comes with it works with the Mac quite well. I haven’t tried it on Windows or Linux but I suspect it will work there as well.
Don’t try to record your audio and video at the same time for your final version. You will make too many mistakes and this will just be an exercise in frustration. Plan to re-record the final audio after you have finished editing the video. Screenflow provides this ability and any good screen recording/editing software will offer this. You don’t have to record all the final audio at once either. You can record segments of it and insert them as you go.
Finally, if you don’t have a voice that comes across well when recorded, find someone who does. You don’t need to sound like a radio or TV announcer but your voice does need to be clear and easy to understand.
Tip #8: Introduce yourself
People want to know who is talking to them. At the beginning of your demonstration, make sure to introduce yourself. This will make your demonstration feel more personal. If you have the opportunity, record a thirty seconds of yourself talking with video, or include a picture of yourself.
Tip #9: Fix your mistakes
The more polished your demonstration is, the better. A polished demonstration is a more credible one. Since you can re-record both the video and audio as many times as it takes to get it right, there’s really no excuse for having mistakes in your demonstration. The kinds of mistakes I’m talking about are things like selecting the wrong menu, clicking the wrong button, spelling mistakes, using nonsense words (as I described earlier), etc.
If you try to record your entire demonstration perfectly, you will end up doing it over and over again and just get frustrated. Instead, think of your demonstration as a movie. Movies have scenes, each of which is shot separately and not necessarily even in chronological order. You can shoot a scene from your demo, make sure it’s right and then move on to another. Screenflow makes it easy to do this because it allows you to make a new recording and add it to an existing project. You can add new audio tracks as well. As I mentioned earlier, it’s a good idea to record a scratch audio track while you are recording the video from your computer. If you don’t do this, you might find that you don’t actually have enough time to say what you want to say. When you are done with the video and the scratch audio, you can use the scratch audio as a guide and re-record the audio to get it just right. When you’re done, it’s easy (at least in Screenflow) to delete the scratch audio track.
Tip #10: Export to the highest quality you need, but no higher
When you are finished with your demonstration, you will need to export it via whatever software you used to put the final version together. That might be Screenflow, it might be iMovie, etc. The higher quality, the better your demonstration will look and the easier it will be to watch. However, the higher quality, the larger the file will be, which may exceed the limit of your hosting service. So be careful. Also, you’ll probably be surprised at how good a movie exported at a medium level of quality looks. Again, experimentation will help a lot.
Tip #11: Bonus tip - Creating cross-platform videos
Screenflow is great for recording videos on the Mac. I’m sure there are applications like Screenflow for Windows and Linux but I’m not familiar with them. However, if you have a Mac or access to a Mac, there is a way to use Screenflow to do screen recordings on Windows and Linux. You can run Windows or Linux using Paralells or VMWare on the Mac and use Screenflow to do your recording. You can do this when running Windows/Linux in a separate window or in full screen mode. Either way, you can use Screenflow to crop your recording to the appropriate size. The downside to this method is that a few of Screenflow’s features that help you to enhance your video (such as highlighting the foreground window) won’t work. However, Screenflow does detect the cursor on Windows so you can enhance the cursor but this doesn’t appear to work on Linux.
Demonstration videos take far longer to create than screenshots or feature descriptions but can be far more effective at getting a message across (and closing a sale as a result). They can also be more effective at teaching your users how to be effective with your software product. The better they are at using your product, they more productive they will be. This will almost certainly lead to your users recommending your product to others and that leads to more sales.
Wednesday, July 22, 2009
In case you were not already aware, I want to point out some convenient features of the REAL Software website. As of December you can see all your REALbasic, REAL Studio & REAL Server license keys, their expiration dates & renewal and upgrade options in one place. Just log in and go to Account -> My License Keys.
Another great option, even when you are not logged in, is the Renewal & Upgrade Assistant, located on the right side of the Store page. Simply enter a license key into the Assistant to view all the Renewal and Upgrade options for that key.
Want to know the most recent release you can access with your expired REALbasic key? Log in and go to Downloads -> Previous Versions. Previous versions available for the keys in your account are available here to download (releases from 2007-present only).
Have you registered but don't see you license keys in your account? Most likely you have multiple accounts, perhaps under different email addresses or names. Send me an email with your keys and/or the email addresses you use and I can merge all your accounts together!
Contact us at firstname.lastname@example.org if you need help with your account or anything else.
Tuesday, July 7, 2009
AUSTIN, Texas, USA (July 7, 2009) — REAL Software, creator of REALbasic, a cross-platform development tool for creating software for Mac, Windows and Linux, is now shipping REALbasic and REAL Studio 2009 Release 3. This release boasts more than 100 improvements and 31 new features, including the addition of OpenGL support for 3D images and animation.
"REALbasic is powerful enough to allow me to develop 2D applications requiring a complex interface faster than any other compiler," commented Stephan Keith, a REALbasic Developer. "With the introduction of OpenGL to REALbasic, and its extraordinary interface development tools, I should be able to develop 3D applications 50% to 70% faster over those using traditional C-programming methods."
The new OpenGLSurface control does require a knowledge of the OpenGL language. However, there are some open source projects that are implementing a RB3D-compatible API on top of the OpenGL for developers who currently use RB3D.
The complete list of improvements and new features in this release can be found in the release notes in the product download section, http://www.realsoftware.com/download. REALbasic and REAL Studio are available in a free 30-day trial edition. REAL Software recently published an Introduction to REALbasic video on YouTube.com.
Wednesday, June 24, 2009
Wednesday, June 17, 2009
We recently changed the price of REALbasic Personal Edition for Linux to $99, which is the same as the Personal Edition for Mac and Windows. However, if you are developing an open source project, Personal Edition for Linux is still free for you.
To obtain your free Linux key contact Customer Service and provide them with documentation about your project, such as your name on an open source website.
We are making this change because most commercial software that has a free version for Linux is typically free only for open source projects.