Re: [platform-ui-dev] Macro recording capabilities

[Fabio Zadrozny <fabiofz@xxxxxxxxx>]

On Mon, Jan 16, 2017 at 2:21 PM, Mickael Istria <mistria@xxxxxxxxxx> wrote:

On 01/16/2017 05:04 PM, Fabio Zadrozny wrote:

Also, my suggestion is that that the whole IDE will be able to have record/playback, not only the text editor (but, I have to start somewhere, so, providing it for the text editor will be the first step... and it's actually the most thing requested in bug 8519 if you take a look at its comments... the first comment is on textpad macro functionality, then, the comment #4, from Ed Burnette, gives another example also only with text and find, then #9 says about vi (same thing, just text)... so, if you read more about the comments, you can see that most of them are only for the macro record/playback within the text editor -- personally, it's one of the reasons I keep having to open notepad++... just to copy some text to it, record/playback macro and copy it back -- a bit annoying having to copy back and forth, but really helpful in many occasions).

This one uses a keyboard shortcut also. The shortcut changes text, for sure, but the request of the user is more to have the combination of text edit AND keyboard shortcut in a macro, it's not only text editor. There is no guarantee that the shortcuts affects text only and many commands/shortcuts do more than editing text in Eclipse IDE.

I have the impression the vast majority of them want also to invoke a command or a shortcut in combination with plain text edition. Ability to record shortcut+text editions seems to be a must-have for successful macro record/playback. If you want a consistent recorder, you'll probably have to put it at the SWT layer to make sure you can properly handle text edits and shortcuts and menus...

So, there are many user stories in that bug for macro record/playback in the text editor AND it'll be possible to extend it later on to add the support for other views to record things in the whole IDE as you're saying.

​​Agreed... in my first message I already pointed that I'll make "changes in the AbstractTextEditor and KeyBindingDispatcher to be aware of the macros"​. 

My experience with SWTBot recorder is that it's really worth hitting the lowest level possible (SWT) to record events and actions.If the recorder hits a level too high right now and misses to handle shortcuts, menus... later, this can invalidate the whole implementation and require a full rewrite on a lower level.
The playback part can easily be changed and replaced.

I think my experience differs here... usually a full record/playback of the UI (such as swtbot, squish, pyautogui)​ is too brittle to be useful and will usually fail by many things later on just because something in the UI changed or the user interacted with the screen (which I'm considering is not acceptable for a macro/playback engine inside of a product such as Eclipse). It shouldn't deal with any menu or other UI element and should record the effects of the action the user did (as in my previous example of the replace/find, it shouldn't record the Ctrl+F and hit of the Find in the dialog and later hit on the replace, but actually record a "find text" action and a "replace text" action to be played back later on).

For instance, swtbot uses Display.post() for playing back -- but this just doesn't work at all for something which should be not brittle... i.e.: I went on to debug a record/playback with that API and it started playing back in a different instance of Eclipse (the one that was debugging the other one which should be the target just because that one lost focus and this one gained it) -- also see: http://dev.eclipse.org/mhonarc/lists/platform-swt-dev/msg08180.html, so, I think such a solution is simply unworkable for a reliably record/playback engine.

Cheers,

Fabio