New annotation toolbar
Needs ReviewPublic

Authored by simgunz on Sep 17 2018, 3:52 PM.

Details

Summary

As discussed in the task T8076 I am proposing a new annotation toolbar to replace the current one.

The current implementation is very rough, but can be used as a first point to discuss how to proceed in the implementation.

The toolbar uses the current PageViewAnnotator engine based on XML files (with few modifications)

To test this revision
Temporary move the file .config/okularpartrc or the annotation tools may not match the ones in the buttons.

What is working and what is planned

See T8076

Diff Detail

Repository
R223 Okular
Branch
annotation-toolbar-stable
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 13047
Build 13065: arc lint + arc unit
simgunz created this revision.Sep 17 2018, 3:52 PM
Restricted Application added a project: Okular. · View Herald TranscriptSep 17 2018, 3:52 PM
Restricted Application added a subscriber: okular-devel. · View Herald Transcript
simgunz requested review of this revision.Sep 17 2018, 3:52 PM

To test this code temporary move .config/okularpartrc or the annotation tools may not match the ones in the buttons.

Nice approach👍 D15204, D15205 and D15580 conflict somewhat. Not bad, but whoever gets in later will have to adapt. Shall we try to coordinate?

How would the new color picker handle "multi-color" annotations? I ask, because D15205 brings selectable font color for typewriter tool. Inline note is very similar, so I had intended to submit a font color patch for inline note too. This would bring annotations with two different color values, namely background color and font color. Given the related poppler patch for FreeText has already landed, and typewriter is ready for review, that's not too hypothetical. We could even go one step further, and introduce a third color for the border.

It took some minutes until I realized how to change from ellipse to polygon (long left press). Now I find it good and easy. Would there be a way to make it even more self explaining?

@tobiasdeiminger I'll continue the discussion on the task T8076 related to this diff. So we can discuss the more UI related topics there.

I can't get this to compile on git master:

In file included from /home/dev/repos/okular/ui/pageviewannotator.cpp:1245:0:
/home/dev/repos/okular/moc_pageviewannotator.cpp: In static member function ‘static void PageViewAnnotator::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)’:
/home/dev/repos/okular/moc_pageviewannotator.cpp:83:21: error: ‘class PageViewAnnotator’ has no member named ‘slotToolDoubleClicked’; did you mean ‘slotToolSelected’?
         case 2: _t->slotToolDoubleClicked((*reinterpret_cast< int(*)>(_a[1]))); break;
                     ^~~~~~~~~~~~~~~~~~~~~
                     slotToolSelected

Are there some dependencies I'm missing? Or did it break when the Typewriter annotation patch went in?

Also, long press is never particularly intuitive; it's generally preferred to use a Split button instead. Spectacle uses one of these to good effect:

simgunz updated this revision to Diff 42831.Oct 4 2018, 5:47 AM
  • Check if chosen color is valid before storing it
  • Notify PageViewAnnotator when the color has changed
  • Add missing annotation tools actions
  • Add XML annotation tools and connect corresponding actions

Should compile now. Typewriter tool is not included yet. I add few more actions but the color picker works only for text annotation tools for now.

simgunz edited the summary of this revision. (Show Details)Oct 8 2018, 6:37 AM
simgunz edited the summary of this revision. (Show Details)

To test this revision
Temporary move the file .config/okularpartrc or the annotation tools may not match the ones in the buttons.

This won't be a necessity for the final version, right? We wouldn't want users to have to do this.

To test this revision
Temporary move the file .config/okularpartrc or the annotation tools may not match the ones in the buttons.

This won't be a necessity for the final version, right? We wouldn't want users to have to do this.

That is a good point. If I am not wrong there is a tool to update the configurations file of KDE apps during an upgrade (I think someone told me that in a phabricator discussion). Maybe we can use that tool. Otherwise I can store the same settings using a different key in the the configuration file (less clean solution) in order to not conflict with the existing settings of the users.

To test this revision
Temporary move the file .config/okularpartrc or the annotation tools may not match the ones in the buttons.

This won't be a necessity for the final version, right? We wouldn't want users to have to do this.

That is a good point. If I am not wrong there is a tool to update the configurations file of KDE apps during an upgrade (I think someone told me that in a phabricator discussion). Maybe we can use that tool. Otherwise I can store the same settings using a different key in the the configuration file (less clean solution) in order to not conflict with the existing settings of the users.

See https://techbase.kde.org/Development/Tutorials/Updating_KConfig_Files and/or https://techbase.kde.org/Development/Tools/Using_kconf_update

This change doesn't cleanly apply on the current master branch. Would you rebase the changes, or is there a branch it could be built against (I don't see annotation-toolbar branch yet)?

I am going to rebase it to master and push some new changes in a few days.

simgunz updated this revision to Diff 59017.Sun, Jun 2, 12:12 PM

Still very rough, but most of the tools and corresponding basic settings are now there.

Remember to move/remove ~/.config/okularpartrc before testing this.

Changes highlights:

  • Check if chosen color is valid before storing it
  • Notify PageViewAnnotator when the color has changed
  • Add typewriter annotation tool
  • Save annotation tool settings to file on exit
  • Add font selector
  • Add basic implementation of width selector
  • Remove delay from toolbar popups
  • Enable config actions based on selected annotation
  • Add arrow annotation
  • Add inner color selector
  • Set inner color icon to transparent if tool does not support it
  • Allow setting font color
  • Fix crash on application exit
  • Improve annotations default colors

getting there!

UI review of the latest version:

  • Having the annotation tools on the main toolbar makes it overflow for all but the largest window sizes. How about putting them in a secondary toolbar below the main one that's hidden until the user shows it by clicking on a "Show annotation tools" item on the main toolbar and/or menubar?
  • The Line width dropdown menu button should make the whole button clickable to show the drop-down rather than only the space under the arrow on the right
  • The entries in the Line width dropdown should visually reflect the width of the line. Could these graphics be generated programmatically rather than using icons?
  • Squiggle and Arrow need new icons; please file a bug on Breeze | Icons and request them
  • The draw-polygon icon might make it seem like that tool can only draw pentagons, consider using draw_polyline or draw-polygon-star instead
  • The Color button should actually show the current color rather than a generic icon
  • The Inner color button needs something to show that it exists; right now it just looks like whitespace in the toolbar. It should show its color like the other button, and for "no color", maybe an empty transparent square?
  • Straight Line is mis-named, it's for drawing anything but a straight line! :) Should be something like "Freehand line"
  • I can't figure out what Pin Annotation actually does
  • It's not clear to me how to select existing annotations once an annotation tool has been activated; consider maybe adding a "select annotations" tool or mode under the Selection dropdown menu.
simgunz edited the summary of this revision. (Show Details)Mon, Jun 3, 7:00 AM

There is a TODO list of the working and planned feature on task T8076. Some of your suggestions are already there and I added the missing one. I have updated the description of this review to point to that TODO for better clarity.

getting there!

UI review of the latest version:

  • Having the annotation tools on the main toolbar makes it overflow for all but the largest window sizes. How about putting them in a secondary toolbar below the main one that's hidden until the user shows it by clicking on a "Show annotation tools" item on the main toolbar and/or menubar?

Already in TODO

  • The Line width dropdown menu button should make the whole button clickable to show the drop-down rather than only the space under the arrow on the right

Added to TODO

  • The entries in the Line width dropdown should visually reflect the width of the line. Could these graphics be generated programmatically rather than using icons?

Added to TODO

  • Squiggle and Arrow need new icons; please file a bug on Breeze | Icons and request them

Already in TODO. (I was waiting before requesting icons to see if I managed to get something working :-) )

  • The draw-polygon icon might make it seem like that tool can only draw pentagons, consider using draw_polyline or draw-polygon-star instead

I'll set it to draw_polyline

  • The Color button should actually show the current color rather than a generic icon

This should already work.

  • The Inner color button needs something to show that it exists; right now it just looks like whitespace in the toolbar. It should show its color like the other button, and for "no color", maybe an empty transparent square?

Also the icons of color and inner color need to be done from scratch. I was thinking at a circle fillable with the current color and a border to show it exists.

  • Straight Line is mis-named, it's for drawing anything but a straight line! :) Should be something like "Freehand line"

Have you removed .config/okularpartrc ? Otherwise the toolbar picks up the annotation in you custom orders and the buttons are mismatched.

  • I can't figure out what Pin Annotation actually does

If checked the current annotation tool is kept selected after use (as double-click does in the current Okular). Needs a better name/tooltip. Added to TODO.

  • It's not clear to me how to select existing annotations once an annotation tool has been activated; consider maybe adding a "select annotations" tool or mode under the Selection dropdown menu.

Currently you need to click Esc to deselect the annotation, then you can select the annotations (standard Browse mode). If instead 'pin annotation' is unchecked, the annotation is deselected automatically and you can select annotation. Beside the fact that clicking on an annotation does not select it (added to TODO) and that selecting and annotation does not switch to Browse mode (added to TODO), it works as the current version of Okular. I think we do not need a dedicated Selection tool.

getting there!

UI review of the latest version:

  • Having the annotation tools on the main toolbar makes it overflow for all but the largest window sizes. How about putting them in a secondary toolbar below the main one that's hidden until the user shows it by clicking on a "Show annotation tools" item on the main toolbar and/or menubar?
  • The Line width dropdown menu button should make the whole button clickable to show the drop-down rather than only the space under the arrow on the right
  • The entries in the Line width dropdown should visually reflect the width of the line. Could these graphics be generated programmatically rather than using icons?
  • Squiggle and Arrow need new icons; please file a bug on Breeze | Icons and request them
  • The draw-polygon icon might make it seem like that tool can only draw pentagons, consider using draw_polyline or draw-polygon-star instead
  • The Color button should actually show the current color rather than a generic icon
  • The Inner color button needs something to show that it exists; right now it just looks like whitespace in the toolbar. It should show its color like the other button, and for "no color", maybe an empty transparent square?
  • Straight Line is mis-named, it's for drawing anything but a straight line! :) Should be something like "Freehand line"
  • I can't figure out what Pin Annotation actually does
  • It's not clear to me how to select existing annotations once an annotation tool has been activated; consider maybe adding a "select annotations" tool or mode under the Selection dropdown menu.
  • The Color button should actually show the current color rather than a generic icon

This should already work.

My mistake, it totally does work!

  • The Inner color button needs something to show that it exists; right now it just looks like whitespace in the toolbar. It should show its color like the other button, and for "no color", maybe an empty transparent square?

Also the icons of color and inner color need to be done from scratch. I was thinking at a circle fillable with the current color and a border to show it exists.

Yep, that sounds good. Also I found out why it looked invisible: its icon disappears when using the Line tool, or any other tool that doesn't have an inner color, and does not restore its icon when using a tool that does have an inner color. It should probably become conditionally and temporarily disabled instead.

  • Straight Line is mis-named, it's for drawing anything but a straight line! :) Should be something like "Freehand line"

Have you removed .config/okularpartrc ? Otherwise the toolbar picks up the annotation in you custom orders and the buttons are mismatched.

Yep, I did. Did it again for good measure. It still says, "Straight Line":

  • I can't figure out what Pin Annotation actually does

If checked the current annotation tool is kept selected after use (as double-click does in the current Okular). Needs a better name/tooltip. Added to TODO.

Can't we just keep the old double-click behavior? I think that's good. Various other similar tools use a double-click to mean "activate this tool and then keep it active after you've used it once" so it's not a totally alien UI. Then we could keep the pin icon as an additional visual status indicator of whether the current tool is "sticky" or not.

  • It's not clear to me how to select existing annotations once an annotation tool has been activated; consider maybe adding a "select annotations" tool or mode under the Selection dropdown menu.

Currently you need to click Esc to deselect the annotation, then you can select the annotations (standard Browse mode). If instead 'pin annotation' is unchecked, the annotation is deselected automatically and you can select annotation. Beside the fact that clicking on an annotation does not select it (added to TODO) and that selecting and annotation does not switch to Browse mode (added to TODO), it works as the current version of Okular. I think we do not need a dedicated Selection tool.

Got it. My first impulse to deselect the currently-active annotation tool was to to click on it again. Currently this does nothing. Maybe it should de-select it.

  • I can't figure out what Pin Annotation actually does

If checked the current annotation tool is kept selected after use (as double-click does in the current Okular). Needs a better name/tooltip. Added to TODO.

Can't we just keep the old double-click behavior? I think that's good. Various other similar tools use a double-click to mean "activate this tool and then keep it active after you've used it once" so it's not a totally alien UI. Then we could keep the pin icon as an additional visual status indicator of whether the current tool is "sticky" or not.

Using double-click is probably used to some [how many?] Okular users, but others asked for something like a sticky button. An option to make selected actions sticky by default, without sticky button, would be perfect for me.
From other applications I know left-click: use the tool, right-click: stop using the tool. If there is no fallback tool (see below), the tool will be remembered for the next left click.

Actually, I don’t know any application where a tool automatically deselects. Do you have an example?

  • It's not clear to me how to select existing annotations once an annotation tool has been activated; consider maybe adding a "select annotations" tool or mode under the Selection dropdown menu.

Currently you need to click Esc to deselect the annotation, then you can select the annotations (standard Browse mode). If instead 'pin annotation' is unchecked, the annotation is deselected automatically and you can select annotation. Beside the fact that clicking on an annotation does not select it (added to TODO) and that selecting and annotation does not switch to Browse mode (added to TODO), it works as the current version of Okular. I think we do not need a dedicated Selection tool.

Got it. My first impulse to deselect the currently-active annotation tool was to to click on it again. Currently this does nothing. Maybe it should de-select it.

Clicking a selected tool to deselect sounds ok to me, although they are probably an exclusive action group. That would allow to use exactly one shortcut to enable and disable a single annotation tool.

Does right-click still work to deselect a tool? That is how I know it from many other applications (not all).

anthonyfieroni added inline comments.
part.rc
2

Increase version.

Using double-click is probably used to some [how many?] Okular users, but others asked for something like a sticky button. An option to make selected actions sticky by default, without sticky button, would be perfect for me.
From other applications I know left-click: use the tool, right-click: stop using the tool. If there is no fallback tool (see below), the tool will be remembered for the next left click.

Actually, I don’t know any application where a tool automatically deselects. Do you have an example?

It's very common in the Mac world, which is what I'm most familiar with outside of the Linux world.

Sticky-by-default would probably be okay as long as we can make it very clear how to un-select the tool. Probably implementing multiple methods would be good (hit esc key, left-click again on the tool, right-click anywhere, etc).

If we remove the sticky button, we have two options:

  • set sticky by default, we will make some users that use the non-sticky mode unhappy
  • set non-sticky by default and use double click to stick, we go back to the current situation (bug 358057)

I we keep the sticky button, the double click to stick becomes pretty irrelevant.

To sum up, I would:

  • keep the sticky button to make the feature clearly visible to the user (see bug 358057). As it is now this feature is hard to discover, took me years to figure it exists.
  • make the tool sticky by default on first installation, then save the state of the sticky button (if a user prefer non-sticky annotation, after unchecking the sticky button he will have it unchecked when he relaunch Okular)
  • disable annotation on right click anywhere (as current Okular)
  • disable annotation on left click on annotation (as current Okular) [ I have sent a patch to Qt to modify QActionGroup, https://codereview.qt-project.org/c/qt/qtbase/+/255770)
  • disable annotation on Esc (as current Okular)

Foxit reader has a "Pin" button. How is it implemented in other readers?

Sticky-by-default would probably be okay as long as we can make it very clear how to un-select the tool. Probably implementing multiple methods would be good (hit esc key, left-click again on the tool, right-click anywhere, etc).

To sum up, I would:

  • keep the sticky button to make the feature clearly visible to the user (see bug 358057). As it is now this feature is hard to discover, took me years to figure it exists.
  • make the tool sticky by default on first installation, then save the state of the sticky button (if a user prefer non-sticky annotation, after unchecking the sticky button he will have it unchecked when he relaunch Okular)
  • disable annotation on right click anywhere (as current Okular)
  • disable annotation on left click on [activated] annotation [button] (as current Okular) [ I have sent a patch to Qt to modify QActionGroup, https://codereview.qt-project.org/c/qt/qtbase/+/255770)
  • disable annotation on Esc (as current Okular)

Seems both compatible and is what I consider optimal.

If someone does (not) want sticky, the pin button can be set to the desired state, and then removed together with the shortcut, because it is a normal toolbar now, right?

Or: Why is this still PageViewToolBar? It is not anymore in the PageView?

Or: Why is this still PageViewToolBar? It is not anymore in the PageView?

I'll move it, added to TODO

Or: Why is this still PageViewToolBar? It is not anymore in the PageView?

I'll move it, added to TODO

Actually the code of the other toolbar (Browse, Zoom, Selection) is managed in the file pageview.cpp. In which file would you move the code of PageViewToolBar?

Or: Why is this still PageViewToolBar? It is not anymore in the PageView?

I'll move it, added to TODO

Actually the code of the other toolbar (Browse, Zoom, Selection) is managed in the file pageview.cpp. In which file would you move the code of PageViewToolBar?

Because it’s now a normal toolbar (defined in part.rc), the actions just need to be constructed and connected at some time. And we need some code to show/hide that toolbar when annotations are activated/deactivated, just like the PageViewToolBar is shown/hidden now.

So why do we need this class (PageViewToolBar) at all? It is just convenient, because it bundles all the annotation actions (ac->addAction(annArrow) and so on) and their slots and some more. But it is not a toolbar itself. Maybe AnnotationToolBarController is a more accurate name. And AnnotationToolBarController would be at the same place as PageViewToolBar was. Or do I understand something wrong?

So I think the new class PageViewToolBar is fine (I have looked at the code now), just the name is misleading now.

simgunz updated this revision to Diff 59208.Wed, Jun 5, 4:02 PM
  • Use draw-polyline icon for Polygon
  • Increase version of part.rc
  • Change icon of strikethrough (remove symbolic suffix)
  • Add TODO in code
  • Rename PageViewToolBar to AnnotationActionHandler
  • No need to forceHide mechanism
  • Use KToggleAnnotationToolBar to show/hide toolbar (not working)

I renamed PageViewToolBar and moved to a file by itself. I took inspiration from Dolphin for the name.

There is still code to be cleaned though.

ui/pageview.cpp
664–665

Anyone knows how KToggleToolBarAction is supposed to work?

Currently it does nothing.

Reading the code, it seems that the constructor where the toolbar is specified by name does nothing, unless there is some other magic going on.
https://api.kde.org/frameworks/kxmlgui/html/ktoggletoolbaraction_8cpp_source.html#l00061

aacid added a subscriber: aacid.Tue, Jun 11, 10:40 PM
aacid added inline comments.
ui/pageview.cpp
664–665

You're right, it seems it never has. Can you use the other one?

simgunz added inline comments.Wed, Jun 12, 6:34 AM
ui/pageview.cpp
664–665

Is it there a clean way to obtain a reference to the toolbar from within this class?
I guess that KMainWindow::toolBar(name) is a possibility, but how do I get a reference to the main window?

aacid added inline comments.Thu, Jun 13, 9:38 PM
ui/annotationactionhandler.cpp
132

no i18n?

ui/pageview.cpp
664–665

right, that's actually a tricky question.

I'll try to figure it out, but you may want to play with stuff and not wait for me, a close friend of mine is getting married so don't expect anything from me until monday/tuesday

simgunz added inline comments.Fri, Jun 14, 5:49 AM
ui/pageview.cpp
664–665

Your help is appreciated. No rush, I can work on other things in the meanwhile.

What I tried so far:

Calling this in setupActions of PageViewAnnotator:

qDebug() << KMainWindow::memberList();
qDebug() << KMainWindow::memberList().count();
qDebug() << KMainWindow::memberList()[0]->toolBars().count();

I get

(Shell(0x55c3e0f80fc0, name="okular::Shell#"))
1
0

So it seems that the toolbars have not been created yet at this point. I'll keep experimenting.

simgunz updated this revision to Diff 59781.EditedFri, Jun 14, 10:22 AM

Changes:

  • Added opacity action
  • Cleaned width action
  • Added action to access advanced settings for all annotations
  • Big code refactor:
    • m_toolDefinition is now a QDomDocument, so that the toolElement are not randomly deleted when the associated QDomDocument goes out of scope.
    • AnnotationActionHandler acts directly on PageViewAnnotator instead of emitting signals
  • Further code cleaning in pageview.cpp
  • Annotations work only in Normal mouse mode, and switch to it when they are selected

Commits:

  • Remove unused variable
  • Remove tooltips that are never shown in any case
  • Add width action icons
  • Use KToggleAction
  • Make m_toolsDefinition a QDomDocument
  • Remove unused method
  • Refactor code and remove obsolete code
  • Detach annotation when mouse mode is not Normal mode
  • Use Qt5 connect syntax where possible
  • Add Advanced Settings dialog
  • Set better action names
  • Add opacity selection action
  • Fix width text

Code is still messy in some parts, I'll clean it at the end.

davidhurka added inline comments.Sun, Jun 16, 5:02 PM
ui/toolaction.cpp
71

Why remove this tooltip?

To make ToolAction (or my inferior ToggleActionMenu) more universal to use it for a Change Colors feature, it would be nice if tooltips are not needed anymore.

simgunz added inline comments.Sun, Jun 16, 6:37 PM
ui/toolaction.cpp
71

That tooltip does not appear anywhere in the UI in practice, at least I have not manage to make it appear. Have you?

Now I am using ToolAction to show other things, so the tooltips, if needed, need to be set outside. Still a TODO.

Where is ToggleActionMenu defined?

simgunz updated this revision to Diff 59954.Sun, Jun 16, 7:27 PM

Added the favorite tools.

Now only the stamp tool is missing.

PS: As usual, the code is still messy, I'll refactor it. For now I am more interested in feedback on the UI/UX

Commits:

  • Rename XML actions
  • Keep a state of the selected tool
  • Add favorite annotation tools
  • Correctly enable annotations
  • Fix advanced settings not saved

For now I am more interested in feedback on the UI/UX

Do you have screenshots?

ui/toolaction.cpp
71

The tooltip should become visible when you hover the toolbar button with the three selection tools. It’s in the main toolbar by default. See also D21622. On my Okular it worked, on yours not?

ToggleActionMenu is still a TODO in D21755. ;)

What will you use ToolAction for? In that case I probably shouldn’t break it.

simgunz added a comment.EditedMon, Jun 17, 2:58 PM

Favorite annotations:
The Star adds the currently selected tool to the favorite list, the bookmark symbol displays the list of the favorite tools:

Once the star is clicked a custom annotation name is asked to the user. Clicking cancel aborts the action:

Customize the favorite tools:

Opacity selector:
Activates on click and displays a list of possible opacities with an icon:

simgunz updated this revision to Diff 60004.Mon, Jun 17, 6:51 PM
  • Fix and simplify width action
  • Fix and simplify opacity action
  • Fix annotation tools actions
  • Rename color action
  • Formatting

Don’t have UI feedback that asks for action already in this patch. :)

  • Maybe the 4 left buttons should indicate that they require further action (drawing). Currently they look like buttons in a word processor, where you have to select the text first. *1) Using the existing dynamic annotation icons might look better, as soon as someone made them more low-resolution friently.
  • The first two separators look a bit like only the first four buttons are annotation tools, and the next 3+2 buttons are just options. I. e. there is not a mutually exclusion between the 4+3+2 buttons, but only between the 4, 3, and 2 individually. Maybe it’s better to group them not with separators, but with ToolActions/ToggleActionMenus. Could be tested later by customizing the toolbar via Configure Toolbars.

*1) Maybe an interesting idea: Select some text in Text Selection mode, then just click the annotation button.

Don’t have UI feedback that asks for action already in this patch. :)

  • Maybe the 4 left buttons should indicate that they require further action (drawing). Currently they look like buttons in a word processor, where you have to select the text first. *1) Using the existing dynamic annotation icons might look better, as soon as someone made them more low-resolution friently.

I am more in favor of using standard breeze icons for the annotation tools. I opened a bug to ask for the icons (https://bugs.kde.org/show_bug.cgi?id=408283), so we can ask for a specific design that make them understandable.

  • The first two separators look a bit like only the first four buttons are annotation tools, and the next 3+2 buttons are just options. I. e. there is not a mutually exclusion between the 4+3+2 buttons, but only between the 4, 3, and 2 individually. Maybe it’s better to group them not with separators, but with ToolActions/ToggleActionMenus. Could be tested later by customizing the toolbar via Configure Toolbars.

I agree in removing the separators.

*1) Maybe an interesting idea: Select some text in Text Selection mode, then just click the annotation button.

simgunz updated this revision to Diff 60168.Thu, Jun 20, 7:07 PM
  • Remove unuseful annotation separators
  • Correctly set favorites action enabled
  • Properly trigger favorite action
  • Allow unchecking annotation actions
  • Minor refactor
  • Save state of continuous mode