LiveCode Forums.

..........

Tell that to the (highly creative!) marketing department of RunRev

..........

Right now RunRev are behaving as they always have: too fast and too furious. Trying to get all sorts of jazzy new features rolled into the thing without sorting out buckets of things that have been lurking in the background for yonks.

Many people have tried to point this out many times.

---

[-hh] wrote:I'm wondering about the criteria for version numbering. From 6.1.3 to 6.5 there is a big jump, introducing great new features but, unfortunately, also conservating old *elementary* bugs and bringing up new bugs in up to now functional parts.

As long as a version has (well known) *elementary* bugs, new features are, in my opinion, not worth an increase of 1/10 of a version number. So this version must have numbered 6.1.5, not 6.5.

The user-facing elements in v6.5 may indeed appear relatively slim, but looking a little deeper we find that it's one of the most significant upgrades in this history of the product.

Here's an excerpt from a post by Kevin Miller to the use-livecode list:

6.5 wasn't a case of adding a few minor features. We didn't do what we usually do and "bolt-on" the resolution independence code to the existing architecture. Instead, we replaced the entire graphics architecture for all graphics on all platforms in the entire engine.

It was a ton of effort and we got "just" one big feature this release - resolution independence. It might seem like a bitter pill to swallow for just that feature. Of course that isn't the point. We now have a modern graphics layer and we can do so much more with it over the next few versions, as Ben has outlined. We have so much scope now to expose additional graphics features, re-implement theming and so forth.
...
Rather than changing (just!) the graphics architecture, we've touched almost every single line of code in the entire engine on every platform.

http://lists.runrev.com/pipermail/use-l ... 95577.html

The unusually large scope of this release was identified in the Release Notes included with the many pre-release versions available over the last few months:

The first step to supporting resolution independence was to completely refactor LiveCode's graphics layer. This involved writing and integrating an entirely new 2D graphics library that allows for scaled drawing. In addition to 2D graphics rendering, the library also handles text and image rendering. As such, nearly all aspects of LiveCode's drawing routines have been touched.

For as long as I've been buying software a general pattern has emerged with version numbers: x.0 means really big with lots of new stuff, and x.5 means kinda big with some new stuff. Lesser revisions tend to use smaller increments, with x.x for anything with new features and x.x.x for builds that only fix bugs.

Many companies will jump from a lower number to x.5 when the scope of changes warrant it to communicate the larger scope of revisions, and with v6.5 RunRev did the same with LiveCode.

Then you can explain a client (the CEO) that he can't even see an LC icon in the dock of his beloved old PPC, that LC freezes if he clicks 'User samples', that his new mainstack isn't movable to top left if he hides the toolbar or that he sees garbage or can't scroll if right aligning a column of numbers or simply a list of numbers. You can hardly say: "Oh, nobody needs such exotic things, this may not be known to the dev team". But you can say: "Wait a few weeks, 6.1.6 is coming soon and with 6.2 all elementary things will be working".

Although the testing period for 6.5 lasted many months, for a variety of reasons many developers (including myself) didn't spend much time testing their applications with this radically new version, and are only now discovering issues post-release. This is unfortunate for everyone, not the least those of us who didn't test, but as Kevin noted the team is currently working on a 6.5.1 to address any issues reported.

The pattern of major-overhaul releases requiring quick turnaround of a bug-fix release soon after isn't unique to RunRev. One of the oldest adages in the software world is that if any package is labeled dot-oh or dot-five you can expect bugs to be discovered after release, and the dot-dot version that inevitably follows is the one you'll be using for real work.

When the first Developer Preview release of 6.5.1 is available I'll certainly be doing more testing than I did with 6.5, and I would encourage anyone finding issues with 6.5 to do the same.

Bug reports can be filed here: http://quality.runrev.com/


As for the specific issues you cited, I'll do my best to provide what helpful guidance I can on those:

- "can't even see an LC icon in the dock of his beloved old PPC"
This is not an issue I've seen myself, though it may be worth noting that Apple abandoned PPC more than 8 years ago, and while RunRev has done an admirable job of continuing to provide support for all these years later very few other devs bother and the APIs required for that are being deprecated very soon. All that said, PPC should still be supportable, so as you see issues with it please first search the bug database for an existing report and submit your notes there, and if none can be found please open a new report for it.

- "LC freezes if he clicks 'User samples'"
This is another I've not seen myself, but may be related to the PPC issue you mentioned above and should be reported.

- "his new mainstack isn't movable to top left if he hides the toolbar"
This sounds like the sort of thing related to the windowBoundingRect global property, but in the builds I've been using that appears to get reset to the appropriate bounds when the toolbar is hidden. So again, it may related to a deprecated API for PPC and your report will help them pin that down.

- "he sees garbage or can't scroll if right aligning a column of numbers or simply a list of numbers."
There may be one of a few possible causes for that, ranging from OS limitation on the amount of text that can be rendered in a single line to issues related to the current implementation of right-alignment in the current field object. The field object is being rewritten to support Unicode, as is much of the rest of the engine, and during this transitional state our work as testers can play an important role in identifying issues so that they can be addressed.

FWIW, a tabAlign token is reserved in the engine and expected to be available for independent column alignment, but in the meantime we should still explore any anomalous rendering issues to find both engine-based solutions for future builds and to see if there may be workarounds available in the current version.

For example, the DataGrid is often a very good way to display content in lists, support both independent column alignment and unusually large amounts of data in lists. If may be that switching that display from a single field to a DataGrid may resolve the issue immediately for you.

When you submit those bug reports, it would be helpful if you'd take a moment to post their record numbers here so interested members can add their own notes and track the progress.

Going forward I'll be putting in a bit more effort to take advantage of the many weeks of Developer Preview and Release Candidate builds before release so that I can help catch any regression issues with features my apps rely on, and I hope we'll see more developers do the same.

..........

I do feel that Mr Gaskin is, like very many others, on the roller-coaster of ever onwards, ever upwards. While that may not necessarily be a bad thing, those of us who use PPC computers and so forth (meaning older but not b*ggered computers)
either through financial constraints or through a lack of conviction that having the latest thing is an absolute must (I fit into both these categories), can feel excluded. Beyond that, the desperate scramble to be either ahead of the "game" or at least in the front row, can mean that some rather important things get sacrificed. RunRev are guilty (if that is not too strong a word) of overlooking quite a lot in their mad scramble to capture a market; which I am not entirely sure they are capturing.

I believe that a more conservative viewpoint might be better.

I have been developing since 2009 an ongoing program for Sanskrit digitisation; it has NOT made me any money worth talking about, and that is not my first priority. The program does exactly what I want it to do, and my "road-map" for it will ALL work within the "confines" of RunRev/LC 4.5. However, the standalone "f*cks up big" on any fdorm of Windows post XP, which is a major snag. This is due to the fact that Livecode fails to stop Windows imposing it own fonts (rahther than my 'odd' ones) on the textFields of the standalone.

I have been banging on about this ever since the time I tried the thing out on Windows Vista (2010 as far as I recall); the problem has NOT been solved.

Now that may sound very selfish indeed of me, that I am only concerned about my corner; but in this respect I do feel I am not alone; there are many 'quibbles' about certain areas of functionality (or lack thereof) in Livecode that have NOT been sorted
out miles down the road from when they first cropped up. I feel that the reason those quibbles have not been sorted out is because they are not seen as the glittering prize of being the killer app. However what RunRev seem to fail to see is that the glittering prize of the killer app is a moving target, and that while they are desperately chasing the moving target they are making an awful lot of people who depend on rather humble things fed up.

I work in 2 areas:

1. I make small programs for content delivery and reinforcement in my EFL language school in Bulgaria; thgese are deployed in my school and a few others (friend of mine) on a wide varaiety of second-hand comnputers running a wide variety of Debian-derivative forms of Linux (predominantly, but not exclusively, varieties of Ubuntu). I program almost all of these using RR/LC 2.2.1 (!!!!!!!) there having been no obvious advantages in this respect since that release
(still cannot play movies properly on Linux inside a LC standalone). Rarely I use 4.0 or 4.5 because I want to mess around with drop shadows without having to switch back and forth between LC and GIMP.

2. As mentioned above. The few people who use my Devawriter Pro who have bothered to get back to me tend to use machines that are either G3/G4 Macs, older INTEL Macs, PCs running Windows XP.

Obviously standalones I hive off for PPC don't show their icons on Macs.

While I regularly download Community releases of Livecode, and contributed a week's income to the Kickstarter campaign, and enjoy mucking around with the thing, and have made the "Hack Attack" stack, I don't really feel that RunRev are doing
the right thing.

What is my idea of the "right thing"?

It is that RunRev should remove ALL the bugs that have been 'there' in Livecode for donkey's ages before they do anything else whatsoever.

The font substitution problem with post-XP Windows IS a bug as it renders anything that attempts to leverage a non-standard Unicode font inoperable.

[-hh] wrote:None of these is special to PPC.

You may want to update the summary for #11125, which notes PPC.

Just because you try to put these 'elementary bugs' into question, here the numbers.

I didn't use the phrase "elementary bugs" so I'm not sure who's being quoted there. If they're in question at all it's only because they're not yet resolved.

Thanks for posting the bug numbers; I've added myself to the CC for those and look forward to seeing the progress.

With #11125 I've not seen that myself, and while the report has been acknowledged it's not yet been confirmed - it's hard to say whether that means they haven't been able to reproduce it, but given the number of people using LC on OS X it would seem odd if it were common but no one else has mentioned it yet. Have you found others who've experienced that? Do you see this consistently on all OS X machines you've tested, or just some? This is a long shot, but does the problem persist after repairing permissions?

Re #11345: good reproducible example, as least as far as the alignment goes; I wasn't able to get it to generate "garbage", just misalignment of otherwise-readable text. The issue has been confirmed, and will likely be addressed when the rest of the field revisions are completed. In the meantime, it may be possible to come up with a workaround, but from the example text provided it's difficult to determine what you're looking for. Do you have a mock up stack of what you'd like the finished element to look like?

Re #11438: not a difficult fix as I noted in that report today, and as such it's surprising that even though it was submitted just two weeks ago it managed to survive the 6.5 checklist. You noted that it takes only five minutes to fix - did you include the fix to their IDE in your example stack? I think I overlooked it if you did. The upside is that while it's an annoyance in the IDE it won't affect any standalones.

Re. "LC freezes if he clicks 'User samples'": Yes, appears to be limited to v6.5. I didn't see a bug report for that, but if you submit one it may be helpful to note that it appears to hang on a call to ulLogit from the socketClosed handler in the stack script.

After all, you made me curious. You do ('beta') testing with a stable release of 'kinda big with some new stuff'?

How else can one test for regression issues?

richmond62 wrote:...those of us who use PPC computers and so forth (meaning older but not b*ggered computers) either through financial constraints or through a lack of conviction that having the latest thing is an absolute must (I fit into both these categories), can feel excluded.

I can appreciate the desire to continue the useful life of older machines, and indeed I was disappointed to find that the battery on my wife's old PPC Mac is soldered onto the motherboard, effectively killing an otherwise-usable machine.

But one of the challenges with continuing to use PPC is the security risk - Apple stopped providing updates for it years ago, so any Internet use is a risk that only grows with each new year:
http://reviews.cnet.com/8301-13727_7-20 ... erpc-macs/

While it would be nice if Apple were as interested in the longevity of their systems as their users are, in our house we solved the problem with my wife's machine by simply moving her to one of my x86 laptops running Ubuntu. I could have put OS X on it but Apple says that's illegal, so to comply with Appler's requirements we went Linux. With Thundebird, Firefox, and LibreOffice, pretty much everything she needs to do is well covered, and the latest Ubuntu runs well on it so she gets the security she needs as well. And now that she's on a machine using the same Ext4 file system I use on all my systems at home we even get to share the same backup drive.

So while I was initially disappointed to see the OS X updates stop for PPC, and then more so to discover the silly soldered mobo battery, ultimately I have to thank Apple for nudging us toward a more secure alternative at no cost with Linux.