Basic grouches about LiveCode 8

[Richard Gaskin]

Mark Waddingham wrote:

> On 2015-10-06 04:54, Richard Gaskin wrote:
>> Monte Goulding wrote:
>>> On 6 Oct 2015, at 1:15 pm, Richard Gaskin wrote:
>>>> some really long script somewhere to create every control and
>>>> set every property?
>>>
>>>  ^ this
>>
>> Where can I read that?
>>
>> I wonder what the break-even ROI calculation for that effort looks
>> like....
>
> Exceptionally good. We moved to dynamically built menus in the
> revMenuBar a long time ago, and as a result it became a great deal
> easier to maintain (and a lot of bugs were fixed in the transition) -
> this is essentially an extension of that work.
>
> Having the principal components generated on-the-fly means that they can
> become more customizable. For example, you've pointed out you'd like to
> add a button to the revMenuBar to pop up various components.

I think that must have been someone else.  My LC workspace is a very 
simple one in which I very rarely ever see revMenubar:
<http://fourthworld.net/lc/rg-lc-ide.png>


> With the old model, you'd have to patch the revMenuBar yourself, and
> each time we do an update you need to update your patch.
>
> The new way of doing things means that it should be relatively
> straightforward to enable the menubar buttons to be customizable (a bit
> like the 'Toolbar Editor' you get on Mac in many apps).

I do run a set of patches in a plugin on launch to cover for fixes in 
queue, and one just-for-fun patch that updates the revMenubar colors and 
fonts to fit in more nicely with Ubuntu's default theme.  Near as I can 
tell most of my patches (aside from one related to topcolor) work the 
same in both v8 and the current product v7.

Whether I modify object properties or script lines it seems about the 
same to me, except that object names are less likely to change between 
builds than lines in a script that does everything and thus requires 
frequent changes, no?

As long as patchers work on objects after startup, seems to make little 
difference whether the stack was prefab or built during boot from a script.


> At the moment, the script is basically the refactored code from the
> stack based revMenuBar to be but in a neater structure (the code for
> various things was spread out, and in some cases very difficult to see
> how changes should be made).

Looking forward to seeing the changes you have in mind.


> If you would be interested in helping to add the relevant hooks to the
> revMenuBar to make it customizable based on user preference then it is
> probably worth starting a discussion on such a thing.

I have a tool in the works that'll help that conversation along....

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com