Thursday, February 21, 2013

Software Patent Reform

Recently, President Obama participated in a Google+ Hangout where he was asked about his views on software patents. You can watch it on YouTube. It was refreshing to hear that he understands patent trolls are harmful and more patent reform is needed. However, it does not appear that he completely understands how much damage software patents can do.

Patents make sense when seeing an idea through to its fruition requires requires a significant risk. New drugs and new hardware often have such requirements. The protection therefore must be equative to the risk. Most software ideas that are patented do not meet this criterion.

Software CEOs with shareholders but who also don't happen to agree with the idea of patenting software (like myself) are put in an awkward position. Because software patents exist, they make a company more valuable and are required in some situations to protect the company. At Real Software, we have applied for patents on technology developed for Real Studio even though we disagree that they should exist because we have a fiduciary responsibility to our shareholders and want to protect our customers as well. Software patents are an evil we must deal with as long as they continue to exist.

It is my hope that the President, Congress and future leaders will continue to examine and refine the patent process to protect those that deserve protection and stop protecting those that use it to stifle innovation or extort money from smaller companies who can't afford to defend themselves even when they are in the right. I encourage those of you in the US to contact your representatives in Congress and ask them take part in this important discussion.

Tuesday, February 19, 2013

Aero Glass: Not Dead Yet!


Those already using Windows 8 know that the Aero Glass theme first introduced in Windows Vista is now no more.  In a quest to combine the look/feel of a tablet and desktop, Microsoft has gone with a more "Metro" aesthetic look, i.e. flat and dull.  Does this mean you should ignore supporting an Aero Glass UI?  Perhaps. There are still a lot of Vista/Windows 7 users out there and the Aero Glass UI still works well on those older versions of Windows, especially considering the apparent slow adoption rate of Windows 8. It will take time before Aero Glass is truly dead.

In light of all this, what exactly is an Aero Glass UI?  When you look at a typical Windows app most don't actually utilize a full Aero Glass UI because it is actually a bit of a pain to support since certain conditions need to be met and some things do not work as you'd expect.  Here are some examples showing apps that don't support the Aero Glass UI, partially support it, or fully support it:


No Aero Glass support
Partial Aero Glass UI



Full Aero Glass UI


Supporting the Aero Glass UI in Real Studio is fairly easy, but as I mentioned there are some caveats.  Take the example AeroText.rbp found in the Real Studio folder under Example Projects\Platform-Specific\Windows\



This example creates a partial Aero Glass window using declares.  With some minor adjustments in AeroWindow.Open (note the highlighted changes in blue):


Dim m As MARGINS
m.cxLeftWidth = 0
m.cxRightWidth = 0
m.cyBottomHeight = 0
m.cyTopHeight = -1


And AeroWindow.Paint:


g.FillRect( 0, 0, Self.Width, Self.Height )

This partial Aero Glass window can become a full Aero Glass UI like this:




Now, the caveats.  Sadly not all Win32 controls render properly on an Aero Glass UI. There are mainly issues with controls that draw text due to how GDI renders text (see how the text of that PushButton isn't opaque).  The only solution here is to draw your own with GDI+ or what most apps do, create a partial Aero Glass UI and put controls on the non-translucent areas.  You'll find that Menus have the same issue, so you'll have to find other solutions for that as well.  Here's an example of what Paint.NET does to handle menus:


In conclusion, supporting Aero Glass may be more trouble than it's worth, considering it is also not supported on Windows 8 (or Windows XP).  However, if you are targeting a vesion of WIndows that supports it, you might find the extra effort needed to create these visual effects to be worth it.

Friday, February 15, 2013

iOS Update

It's time for another update on our progress towards iOS support. Lately we've been working on toolbars, navigation and the splitview, which is a control specific to iPad.

In the screenshot below, you can see the toolbar on the bottom. In this example, it's using icons. 



Toolbar with Icons
But they don't have to be icons. You can use regular buttons as well:


Notice that the the left-most button looks unusual. That's because iOS controls support styles. In this example we have applied a style to that button in the toolbar. We have also applied a style to the titlebar to make it green. Notice the First and Done buttons in the screenshot above? We've got navigation working as well.

If you've ever used the Mail or Settings apps on the iPad, you know that they looks a bit different from the iPhone. On the iPhone you start with a list, select an item and then view the details in another layout that slides over the list. On the iPad, however, the list and detail views are displayed at the same time (at least when the iPad is held in landscape orientation). This is accomplished with a control called a splitview. It essentially holds two layouts. This makes it easy to take the two layouts you would use for your iPhone app and use them with a splitview to create the iPad version:
The above example shows two simple layouts (called "views") that have been dragged into a splitview control. Notice that the titlebar of View2 has been styled not only with a different color but with a different font as well. In most cases you won't need or want to change the look with a style but it supports them if you need them.

Unlike most iOS development tools, we are using native controls. We've noticed others that appear to be using native controls but really, they are just drawing controls that look like native controls. The difference in this case is not skin deep. Native controls, like on the desktop, have automatic features (such as accessibility) that you get essentially for free by using them. And should Apple decide to change the look and feel of the native controls, you get those changes for free. Drawing the controls rather than using the native controls might be faster for the tool developer but it's not the what's best for the application developer or their users.

If you want to get a head start on learning about iOS development, come to the Real Studio Developer Conference. We have several iOS-specific sessions planned so you can learn all the details and start planning your iOS projects.

Stay tuned. We will have another update on iOS soon.

Thursday, February 14, 2013

A Great Day for the Web

Opera Software announced they are no longer going to develop their own HTML rendering engine, Presto, for their popular Opera browser and are instead switching to WebKit, the engine in Safari and Chrome.

With Opera switching to WebKit, that leaves Firefox and Internet Explorer as the outliers. Hopefully Opera's move will put pressure on at least one of these outliers to switch, ideally both. That would make life a lot easier for web developers who today have to test on at least three different browsers. To me, that just makes no sense. If Firefox and IE switched to WebKit (which I know is unlikely but hey, I would have said the same about Opera), then web developer productivity would certainly  improve. And hopefully, like Opera, more developers will be improving WebKit rather than being spreading out their effort among three different rendering engines.


Robert O'Callahan of Mozilla said this is a "sad day for the web". I agree with John Gruber that this is a sad day for Mozilla but it's a great day for the web.


Once they complete this switch, we will likely add Opera to the list of browsers supported by the web framework in Real Studio, giving our customers one more choice of browser for their customers.


Friday, February 8, 2013

FolderItem.Launch Tip


It's the little things that get us most times. When you handle Tech Support, you often see similar questions pop up, over and over again. We try and address these in the documentation when possible. Here is an example that trips up even our pro developers every once in a while. 

When using the FolderItem Launch method you have to use the full name of the application, that means including the extension.

This will not work:

dim f as FolderItem = SpecialFolder.Applications.Child("Calculator")
f.Launch

But this will:

dim f as FolderItem = SpecialFolder.Applications.Child("Calculator.app")
f.Launch

So, make sure to include the extension on all platforms when using FolderItem, and you're set.