• Quite a few bug fixes (such as when dragging an Editor Tab from one Editor Window to another when there is only one Tab in the initial Editor. At present this destroys the contents of the Tab, this won’t be the case in Beta 2).
• New Editor Windows will be dockable by default (with full-screen option next to the X on the Form’s Titlebar)
• Unit Cloning will become a standard option along with “New Edit Window”
• A “RADSplit” menu will be placed in the IDE
• Unit Cloning will be added to the context menu of the Editor
• (Possible) The dock’s Title Bar will be removed when an editor is docked, and you’ll be able to drag tabs or the editor itself to split them from their docked position.
• (Possible) Side-by-Side (Vertical or Horizontal) Editing for Forms/DataModules and their Source will be added as an option. So the Form and its Source (for example) will appear next to each other in the same Editor

Today I am happy to announce a full BETA release is available for RAD Studio 2007 to XE2!

Please head over to the temporary RADSplit page to watch a short demonstration video covering installation and various use-cases, as well as the installation download for the BETA.

Enjoy!

The update has been committed to the SVN repository, and an updated zip file has been uploaded too!

You can find more information on TTwitter, as well as the necessary download information/link on the TTwitter page.

Feel free to post comments here on this blog entry, or as comments on the Google+ entry (if you have a Google+ account).

• I have found and fixed multiple bugs, including one encountered by many of you which resulted in being unable to properly/accurately read values returned by Lua functions invoked by your Delphi code.
• Fixed a serious bug regarding Lua Stack Alignment (all tests now indicate that the Stack is properly maintained in all areas of Lua4Delphi).
• Refactored everything to use Interfaces now, including Stack Managers!
• You need to change all declarations of Delphi procedures to be registered with Lua. You need to change var AStack: TL4DMethodStack to var AStack: IL4DMethodStack, a minor change from your perspective, but makes a massive difference to the inner-workings.
• You can now read and write Lua tables and metatables. This is the key piece of the puzzle to be used by the next update (which will introduce all the Wrapper Units).
• The XE2 BasicLuaIntegration.exe demo has now been updated to demonstrate how to read and write Lua tables. Consider this code as a rough example only, as it adds no useful function to the demo at this time.

This is a prepartory update, to address everything which prevents the Wrapper Type system from working properly. The next update will be the single largest update thus far, and (assuming no major bug reports with this update) should be available within a week.

I’m planning a some-what improptu webinar for around 1:30PM UTC (London time), and will update this post with the URL to join. No registration is required!

So, if you’re confident enough to update your copy of Lua4Delphi (and make the necessary changes to your existing implementing code), feel free to do so now. If you’d rather wait for a demonstration of these changes and additional features, 1:30 PM London time is when the webinar begins.

Please keep in mind I still have a fairly annoying cough, so I ask for forgiveness in advance should I struggle to speak at times.

These are the very same idiots (and their descendants) whom whole-heartedly proclaimed at the rise of the Personal Computer that it spelt imminent doom for the common Calculator. Well, I’ve yet to encounter an office where every desk didn’t contain at least one common Calculator, alongside the Desktop Computer used to perform the more complex tasks.

Let us ignore the semantics of the term “PC” for a moment, and presume that they are using it to describe the traditional Desktop Computer, found in almost every home and office in the technological world.

Why is it that the birth of every new gadget simply must spell doom for whatever technology is at that time the most prevalent? I’ve genuinely been trying, and have yet to find a single example of a gadget’s birth leading imminantly to the death of other (more widely adopted) technologies… not a single example!

Indeed, it seems that the misguided fools who make such masochistic associations perceive that technology works in much the same way as America’s crusade (whoops, I mean “war on terrorism”): a ceaseless battle, which can never be won but always expands its reach to the next richest territory (device) to acquire its wealth (users) before it moves on to the next.

Technology simply does not work this way, never has worked this way, and never will work this way.

Gadgets exist to serve specific needs, in precise recognition that no one solution suits all. Your tablet device is useless as a phone, and your phone is useless when it comes to word processing, spreadsheets or database manipulation. Likewise, your Desktop Computer is useless in terms of portability.
The point is that no one device meets every need, and so diversity is required.

You cannot use the iPad (for example) as the basis for your proclamation of the death of the Desktop Computer (again, for example). You cannot claim that the iPhone spells imminent doom for the iPad, or that some new type of gadget as-yet unimagined requires the death of any existing technology to reach its rightful place in the market.

When you buy a device, you’re buying a product to meet a need. You’re not buying into a cult, requiring that you announce your absolute obedience through the renouncement of all other devices.
Your device does not come with a set of commandments featuring such biblical gems as “thou shalt not worship any other devices“, or “burn the unbelievers for they impact on our profit margins“.

This leads us neatly to another issue I want to mention:

“Native development will be dead within a year“

I read statements almost identical to the above when .NET was announced, with developers pledging their undying faith for Microsoft’s then-newest money spinner (now largely rendered worthless by Windows 8, by the way).

Indeed, similar statements were made with regard to almost all development frameworks, and yet native development still runs strong.

When performance and quality are primary considerations in a software product, native development is always chosen (by any executive who either listens to his/her team, or has one iota of knowledge of software development).

With Microsoft’s latest abomination (namely Windows 8) bringing a bastardized form of HTML5 and JavaScript to the desktop (quite frankly the dumbest idea in the history of dumb ideas), proclamations of the impending death of native development are once again running strong.

Of course, the type of thought-deprived fools making these inane statements haven’t considered that just because HTML5 and JavaScript work fine for the Web, it doesn’t mean they will work so well for other purposes. Indeed, this is why there has always been a clear division between technologies for the Desktop, and technologies for the Web (the two are simply so different that a clear line must always divide them).

I myself toyed with the idea of using JavaScript and HTML (HTML5 didn’t exist at the time) as a means of extending Desktop applications way back in 2008, only to abandon the idea in short-order when realizing the practical limitations of what I have since termed as “Frankensystems”.

A growing number of developers have begun to realize (as a different many of us – myself included – had realized long ago) that any form of runtime framework introduces critical limitations in the development of our software.
All of these can be summed up by the simple truth that, when you develop for a runtime framework, what you can produce is restricted only to what is made available by the runtime framework.

You will never, for example, encounter a Device Driver written in C#, or HTML5/JavaScript… it simply cannot be done, because the frameworks provide no means of accomplishing this.

So, while self-proclaimed “web developers” rejoice at this foolish belief that Windows 8 will make it easy for them to apply what they know of HTML and JavaScript to producing fully-functional Desktop applications, this simply isn’t true (at least, not in the way they think).
I’ve actually had a conversation with a web developer who genuinely believed they’d be able to use Joomla as the foundation of a complete Desktop application for Windows 8. I’m not joking! I won’t mention their name here to spare them the embarrassment, but sufficed to say I haven’t laughed so hard in a long, long time.

Anyway, the point I’m trying to make is that the same masochistic desires for one technology to succeed through the death of its more commonly adopted forebears runs as strong in the software industry as it does in that of the gadget.

I can sum this rant up by simply pointing out the following:

• The PC didn’t kill the Calculator.
• Mobile Gadgets haven’t killed the Desktop Computer.
• .NET didn’t kill native development (indeed, it has now begun to reinforce the market’s demand for native development)
• Windows 8 won’t transform web developers into software moguls, or advance software development in any positive way.
• If you believe that one technology’s success requires another’s utter failure, you need your head examined.

Despite the headline image (the mock tombstone), I shall not bid a peaceful rest to the Desktop Computer (or native software development)… not now, not ever. The simple truth is that there will always be a need for them, in whatever form into-which they evolve.

If you’ve properly read and understood this article, then I shall bid a peaceful rest to whatever misguided belief you may have held on this subject.

So, now here’s another poll I’d like to get your opinion on…

How much focus do you believe Embarcadero should apply to bug fixing versus new features in Delphi XE3?

I’m interested to see what the majority consensus is on this issue. As with the previous poll, there is a purpose to my asking this.

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Thanks again!

My well-known “anti-Apple” bias…

I want to be completely transparent about this… it is no great secret that I have a very strong anti-Apple bias (for reasons not of interest to this article). My bias plays no part in this article, nor are the pro’s and con’s of Android, Windows Phone or iOS, Google, Microsoft or Apple discussed here.

This article is intended to be fully objective, and serves merely to provide some fundamental understanding I believe is lacking at present.

My background…

Most of you only know me as a Windows developer using (primarily) Delphi and FreePascal/Lazarus.

What you may not know is that I do actually produce more than a few Android apps for clients (to be used within their respective companies as a replacement for PCs in certain departments such as dispatch).

I have subcontracted the development of the same apps for iOS devices where requested (based entirely on my designs), and I currently have two Android apps in development (one of which I’m also developing for Windows Phone, and am contemplating releasing on iOS as well).

The “mobile Apps” I have developed for clients had the requirement of being able to run on both Tablets and Phones.

© Robert Scoble

Why this article?

© Samsung

This article is born of a Google+ posting by Robert Scoble (a well-respected employee of Rackspace), in which he casts his opinions on various statements made by the CEO of Samsung

regarding the supposed lack of success of Android (more specifically: Samsung’s lack of success in the Tablet market) from Samsung’s perspective. This article also addresses many other statements around the Internet where the user count of an App between different platforms is used to judge the popularity of one platform over another (a naive practise at best, deliberately misleading at worst).

With the above said, let’s get on with the subject at hand…

The Device Divide

Let’s begin by taking a look at the differences between phones and tablets, as this is a major consideration many developers are simply ignoring, and many others not properly handling.

Android Tablet (Left), Phone (Right)

Physical Size

This is the most obvious difference, but also one of the most significantly overlooked.

Mobile phones tend to have a much smaller display than tablets (goes without saying). This means that the amount of information you can display on a phone at any one time is substantially less than the amount you can display on a tablet (stating the obvious again, I know).
The tendency of many developers (as I have witnessed more often than I’m happy to admit) is to essentially squeeze all of the information into the available display (sometimes by simply making the text, images and controls smaller overall). This kind of design is entirely ignorant of providing the best user experience for any given form-factor, and almost never works well.

With a phone, the limited real-estate afforded by the typical 3-4″ display means that the user interface needs to be concise. Simplicity is paramount as the display simply isn’t large enough (or even necessarily of high enough resolution) to accommodate large numbers of controls or menus.

In contrast, tablets have much more screen real-estate (7-10.1″), so more consideration should be given to logically dividing groups of controls and menus. That’s not to say that tablet apps should be in any way convoluted or overcomplicated, but rather that the larger display simply means that our apps can do more easily, and display much more at any one time, thus making it logical to exploit the additional real-estate to the benefit of the user.

Remember: Just because it is possible to produce a single app with a single GUI which will run on both phones and tablets, that doesn’t mean you should!

Connectivity

Connectivity

Given that mobile phones are primarily communication devices, it is a fairly safe assumption that these devices will almost always be connected to the Internet by one means or another (be that WiFi, 2G, 3G or 4G). That’s not to suggest that “mobile phones are always connected”, just that they are almost always connected, therefore it is acceptable for an App to rely on an Internet connection being present as the chances are it always will be when the app is required by the user.

Unfortunately, the same is not always true of tablet devices. Indeed, while iPads all have a SIM slot and 2G/3G data (edit: I’m now informed that not all iPads have a SIM slot… I didn’t know this), the same cannot always be said for Android tablet devices. A simple example is that I have the WiFi model of the Motorola Xoom tablet, which means it is only connected to the Internet when a WiFi network is present (or when I choose to tether it to my phone to share its data connection, but not everyone has the ability to do this).

Since not all Android tablets have a constant data connection, it is not a safe assumption that these devices will be connected to the Internet at any given moment. This means that your app should (if at all possible) be less dependant on Internet connectivity when running on a tablet device (certainly in the context of Android, anyway). Your app is no good on a tablet if it’s unable to function without an Internet connection when the tablet isn’t connected (I said it, even though it need not have been said).

Remember: Your app should behave gracefully when in the absence of an Internet connection, especially when running on an Android tablet!

Phone Virtual Keyboard

Ergonomics of input

Technically this topic relates to the difference in physical size between phones and tablets, but is in some ways more complicated so I’m discussing it separately.

We carry our phones everywhere, and for the most part they serve their purpose just fine. A fairly major issue occurs, however, whenever it becomes necessary to type any significant amount.

Personally I find it almost impossible to type an e-mail on any smart-phone (whether using a touchscreen, digit buttons or even a “full” QWERTY keyboard on the device itself).

To address this, phone apps should require as little typed input from the user as possible. There are countless instances I’ve encountered where an app requires me to type when it would easily have been possible to have used some form of logical selector (such as a “Progression Tree” or even a numeric slider).

Remember: When it comes to phone apps, the less typing involved the better!

Tablet devices provide for a much better typing experience, as the display size allows for larger (thus more accurate) virtual keyboard keys, and even for a more ergonomic virtual keyboard layout. It is therefore acceptable to allow for your app to involve more typed input from the user on a tablet device.

On a similar note: Tablet devices are being used more and more in offices now with a physical keyboard (sometimes even a physical mouse). This makes typing even easier as a physical keyboard provides instant tactile response both prior to and after pressing each key.

Differing performance

I believe it is fair to say that the majority of smart-phones on the market are of substantially lower performance than tablets. I of course acknowledge that there are some handsets currently – and soon to be – on the market which match or, in some cases, even exceed the performance of certain tablets, but these need to be considered as niche devices rather than common-place.

So, with the above in mind, and dependant on the features of your app, it may be necessary to scale for performance according to the most common hardware between phones and tablets.

For example: if you desire to include a fancy animated user interface, with lots of objects moving around or even high-detail animation in the background (both of which can often be tacky and should be given a great deal of consideration before making your decision to include such things), this may work great on most tablet devices, but could cause very low performance on phones.

Remember: It is generally better to conform to the lowest common denominator when it comes to performance, as this will make the largest possible user-base available for your app.

The tablet version of your user interface can include more performance-intensive elements than the phone counterpart, so you should accommodate this in your design (where applicable).

This consideration is not only limited to the user interface, of course, as, dependant on what your app is doing, it is possible that certain background processes could perform quite slowly.

If, for example, you are processing an XML dataset for display, it would be better to process less of it on a phone than on a tablet. This makes sense for two reasons, the first being that the phone will likely take longer to process the same portion of the XML dataset, and the second being that it gives you incentive to display less of the data on the screen at any one time (which is better given the smaller display of a phone, too)

Remember: The amount of “work” you make the device perform should be relative to the typical purpose of the device (less for a phone, slightly more for a tablet)

On a phone?

Different devices have different purposes

You may think this is as plain as the nose on your face, but it is actually the most commonly overlooked issue when it comes to making mobile apps.

Using myself as an example, I don’t do everything with my phone what I do with my tablet, and vice-versa. This is because different devices have different purposes (as almost anyone would agree without hesitation).

When you are planning your app, one of the very first questions you need to be asking yourself (and/or your team) should be “is this app for the phone, the tablet, or both?”
In many cases, your app will be best suited to either one type of device or the other, and acknowledging this early in the design process will not only spare you a lot of disappointment, but will save you a lot of design and development time too.

Remember: There is no point in developing your app to support both phones and tablets when only one of these device types will generate any user interest.

Whether your specific app is best suited to one, the other or both… that’s up to you to determine. Likewise, you should make your intended target device type clear in your app’s product description, to better guide prospective users as-to the best use of your app.

Parallel: You wouldn’t use your phone to do word processing, spreadsheets or database management! You wouldn’t use your tablet to place telephone calls (VOIP not-withstanding). You wouldn’t use your desktop PC as a mobile phone. You use the right device for any given job!

The Culture Clash

Moving away from the differences between phones and tablets, there is another equally important consideration developers need to make when targeting different mobile platforms (such as iOS, Android and Windows Phone) with the same app.

A person’s decision when choosing between devices is a direct expression of their culture.

An iOS user, for example, is a very different animal to an Android or Windows Phone user. Likewise an Android user is a very different animal to a Windows Phone user. I mean this in a very serious (non-insulting) way, and I don’t say this lightly… it is a well-studied phenomenon.

A person’s choice between iOS, Android and Windows Phone is (in almost all instances) anything but utilitarian. Studies (you can find them with a Google search) have shown that each consumers’ decision is almost always the result of their receptiveness to one marketing campaign over another. This bias of reception is in turn a result of who that individual is at a cultural level.

To put it quite bluntly: you’re either brainwashed by Apple, Google or Microsoft.

These studies typically involve teams of people at retailers asking a simple question to customers at the checkout paying for their iOS, Android or Windows Phone product: “what made you choose this device over the others?”. The results always clearly conclude that the overwhelming majority of customers based their decision entirely as a result of a particular advertising/marketing campaign, rather than a carefully considered weighing of each devices’ pros and cons.

This isn’t at all surprising, and is why marketing firms are paid so much money to create the most compelling campaigns. This observation extends far beyond mobile devices, of course, and influences almost every purchase decision a person makes throughout their entire life. Nobody (not even the marketers themselves) is entirely immune to its influence.

Why does this matter?

Well, given that iOS, Android and Windows Phone users are all culturally and socially different in so many ways, it means that their expectations, requirements and tastes also differ. This creates something of a “culture clash” when it comes to apps transcending the different platforms.

These differences are often ignored entirely by app developers, many of whom I would suggest have never even given it a moment’s thought, and this has led to a lot of inaccurate conclusions when it comes to the comparative popularity of the various platforms.

When the producer of a highly popular app releases the same app on two rival platforms (for example on both iOS and Android), they almost always try to make the app look, feel and perform the same way.

At first glance, this may seem appropriate as it saves on design time, and without considering the cultural and social differences between the users of each platform, you would have no reason to predict that your app’s popularity would differ significantly between them.

Even if the “look and feel” aren’t designed to be identical between platforms, often apps are developed with one platform in mind, and the other platform is tagged on as almost an after-thought, resulting in an inappropriate user experience for that platforms’ user-base. This also results in the satisfaction of users between platforms being disproportionate, and is still a failure to properly understand the platforms’ users.

Flurry "Stats"

So, when Mr. “I made a popular app, so listen to what I have to say” publishes an article condemning a platform as “less popular” based on nothing but the user count of their own product between two platforms, what they’re actually demonstrating is that they have failed to consider the cultural and social differences between the users of each platform, and therefore their product is simply not as popular on one platform as it is on the other.

The solution is fairly simple…

What I am suggesting (with the exception of such things as Games which will obviously want to look, feel and play the same way no matter the platform) is that you should have an entirely separate design and development process for each target platform.

You need to research the differing cultures of each target platforms’ respective users, and your design needs to reflect those differences as best you possibly can.

Even before you get to that stage, you need to actually consider whether your app (at its most fundamental level) is even remotely appealing to the users of each particular platform in the first place. There are certain types of app which hold little-to-no interest with the users of one platform, while standing to be immensely popular on another.

It is up to you (and/or your design team) to determine whether it is even worth pursuing a platform with your particular app.

One way of garnering this kind of information is to create a poll, asking your prospective users what their platform is, and whether your app is of interest to them. You can also visit community forums centric to particular platforms, and essentially “test” the popularity of your app as a concept before you even begin the detailed planning phase.

The best way to determine whether your particular app will be popular on any given platform is to diversify your team (to have an equal number of designers and developers from each target platform‘s user-base). Ask their opinion, and value their genuine responses.

Should it be apparent that your app could be well-received by a particular platforms’ user-base, allow your team(s) to come up with designs specific to each of those platforms, and invest as much time as it takes to achieve the full satisfaction of your design/development team(s).

Remember: Most mistakes in the success of an app occur before development even begins; with poor planning, a poor design, or a lack of adequate market research.

In conclusion…

I genuinely believe that if you heed the advice I have provided in this article, you and (where applicable) your team(s) will be able to produce a successful mobile app.

Failure need not be an option if you understand the users, the diversity of those users, the devices and their diversity. An idea is only poor if it is developed inconsiderately.

All of the mistakes I’ve indicated in this article are easy to avoid if you’re willing to put in the effort, and there is no reason why you shouldn’t be able to reach at least one market’s audience (perhaps even all of them).

A shameless “plug”…

Should you feel that the insights I have shared here are beneficial to your work, I am available (through my company LaKraven Studios Ltd) to contract as a consultant (as well as a developer on certain platforms).

I have proven experience in many facets of the software design, development, branding and marketing industry, as well as a wealth of resources I can bring to to any team. Above all, I understand the users of software! I may be able to spare your company from disappointment, as well as save you money (and time) on your investment.

My anti-Apple bias (should that be of concern to you) is one of business ethics. I acknowledge the merits of Apple’s products, and am more than happy to assist in the design/development process of apps on Apple platforms.

If this offer is of interest, feel free to leave a comment or contact me by any of the means displayed on the “Contact Me” widget on the right-hand column.

Blackberry

Whoops, I almost forgot…

Blackberry devices exist too. I’m told people still use these, but nobody I know (thus why I almost forgot about them).

Feel free to leave the humorous comments expressing your hatred of me for the picture of the broken Blackberry… it’s meant in good fun!

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

Thanks!

Recently I’ve been getting questions regarding progress on certain projects, so I thought I’d make things clear for everyone and declare my intended development focus.

Lua4Delphi

Lua4Delphi remains at the top of the list as it is already available, in use by myself and others, and is closest to its final phase of development (the open source portion, I mean). The very next update is huge, and introduces the most impressive features such as the Wrapper Type support (which works in two directions: wrapping Delphi types for use from Lua, and wrapping Lua-defined “virtual classes” for easy use from Delphi).

A major refactoring took place over the last 48 hours, which bases every class on a corresponding set of Interfaces. This has been done to address some memory management considerations, as well as to make expansion and derivation substancially easier (without having to break the interface).

This update is going to be released next week, and I will be running multiple webinar sessions at that time to demonstrate all the new features (and changes). This update was originally scheduled for Sunday Feb 19th, but was postponed due to my having flu (pretty hard to spend a few hours, several times in a day, talking to an online audience when you literally cannot speak). The extra time afforded by the delay has actually been very good, since I’ve found and resolved bugs nobody has actually noticed thus far, but would be very problematic for those using Lua’s “Coroutines”!

The Professional suite is of particularly high priority as the final features are released!

GeNUI

Those not subscribed to the Blaise Pascal Magazine (thus unable to have read my article in this month’s issue) will be wondering what the GeNUI project is, but don’t worry it’s actually quite strait-forward.

You will know this project by its original (old) name, TKinect. With Microsoft’s recent utter betrayal of those of us whom created the PC demand for official Kinect support, myself and a few of the others whom have contributed to the development of the TKinect project began to look at other similar motion-based input devices available on the market. We quickly discovered the ASUS Xtion PRO Live, a controller using the pure PrimeSense technology and SDK, proving to be vastly superior to the Kinect in every single way (including price). As such, the focus of what was then known as the TKinect project shifted to support all motion-based input devices in this category. With that in mind, the name “TKinect” no longer makes sense, and so a new name was concieved.

GeNUI stands for “General Natural User Interface”

This project also expands its reach to Lazarus and FreePascal as well as Delphi, and targets Win32, Win64, Linux32, Linux64, and Mac OS X (awaiting support for the PrimeSense SDK on OS X).

GeNUI isn’t exactly going to happen over night! Unilaterally supporting different kinds of hardware with the same top-level components/controls is architecturally complex (though not impossible as I have done this before). I dare not speculate at this point when we can expect a production-ready release of the GeNUI suite… but the idea is to get this project moving forward very quickly.

If you own a Kinect for Windows controller (I don’t, and I refuse to pay for one given that it’s identical in every way to the Xbox controller, and twice the price… for absolutely no reason), your assistance in testing would be very helpful. It appears as though Microsoft have screwed us all by revoking support the original Xbox controller on the final release version of the SDK (certainly I have been unable to get it to work).

TTwitter

I’m going to stop using the name TTwitter, and instead start using the name of the Social Networking component suite Social Delphi, which incorporates more than just Twitter integration for Delphi and FreePascal/Lazarus…. including other Social Networks (such as LinkedIn and Google+), but also other web-based APIs of worth.

Having spent incalculable amounts of time trying to patch up the existing version to address certain known bugs with the OAuth library, only to continue having bugs reported… I’ve scrapped the entire existing codebase and started again! Everything, right down to the architecture is being rebuilt, including my own OAuth and OAuth 2.0 libraries (to replace the third-party one I’ve been having problems with).

The new design provides a series of pre-compiled DLLs you can use to avoid all issues between Delphi and Indy versions. This also means that each portion of the suite can be used from other programming languages provided a viable “Header” to import the methods from the various DLLs.
The DLLs provide support for ANSI and Unicode in the same way as the WinAPI (MethodNameA for ANSI Strings, MethodNameW for WideString), and the individual Delphi/Lazarus components (such as TTwitter) simply provide a Class Layer on top of the flat imported API.

This project is being consistently and aggressively developed… with a release very soon (sooner than you may think)!

Moving forward…

These projects (along with the LaKraven Studios Standard Library on which they’re built) constitute the last of my open source developments. Other small open source projects may be released over time, but nothing on the scale of these.

The following projects are on indefinite hold for the forseable future (due to time and financial constraints):

• ADL SDK for Delphi – Hit a major road-block with this long ago due to the complete lack of header units for any language from which to translate into Pascal. This project is scrapped!
• AGE (Another Game Engine) – As fun as it is to develop game engines, this project is far too time-consuming (particularly with my original co-developer having to pull out due to his new job in South Africa). This project isn’t scrapped, but is on indeifinite hold.
• Emotiv EPOC SDK for Delphi – Rolled in to the GeNUI project!
• LakRemotes – Very small project, with minimal growth expected. Given how easy it is to map remote controls, this project is not a problem at all.
• Link-Grammar Parser for Delphi – Minimal support and updates required, this project will be maintained passsively, and updated by request to support any changes in newer versions of the LGP DLL.
• RADPlates – Rolled into the RAD Power Pack project, which is not open source, and not entirely free (the base is free, as is the RADPlates module).
• TDockPanel – It works as intended, so no updates required. It’s basically just a composite component to make it quicker and easier to set up edge-aligned docking… consider it complete.
• TKinect – Rolled into the GeNUI project!
• TRttiIterator – Indefinite hold on future updates, but what’s already available works very well!
• TTwitter – Rolled into Social Delphi.

My LuaRAD project has now become a commercial project! Given the scope and scale of it, it’s the only way I’m going to raise enough investment to hire the necessary development and support staff.

All project pages will be updated this Sunday. Consider this a major downsizing of my active developments, in order to focus more heavily on the important ones.

It’s also important to remember that I make my money by doing contract development work. Clients take priority over personal projects, always!

Blog Housekeeping

Starting today, I’m going to start removing old blog articles, especially those serving as information leading towards a release. I’ve noticed that many people have been commenting on very old articles asking for download details which were provided in a later post. I’m tired of having to constantly point people in the direction of the actual release posts, so it’s just easier to remove the irrelevant.