Obsolete now, because ImplicitDefaultAction mode from D21971 is needed for D15580.

• Rebase on master

• checkedAction() also looks in submenus for checked actions

D15580 depends on this code (not this Differential Revision, currently) now. Before landing this, I have to think about checkedAction(). Theoretically, it doesn’t find checked actions in submenus, while the connection to the signal QActionGroup::triggered(QAction*) does.

I managed to test your patch now.

In D15580#554079, @simgunz wrote:

Should I configure the toolbar so that if the user changes to "text alongside icons" the toolbar appears like this?
(the user can then expand the remaining icon-only buttons one by one by right clicking on them if he needs to visualize the text)

Didn’t yet test this, but I like some of Nate’s ideas.

simgunz added a dependent revision: D15580: [WIP] New annotation toolbar.

In D15580#546492, @ngraham wrote:

Typically the color chooser includes a "transparent" item.

If this survey is a circular dependency, we probably should turn this whole task into a survey.

In D15580#514707, @ngraham wrote:

In D15580#513826, @simgunz wrote:

• How would you fit the annotation actions in the Reviews tab?
• Would you create a sub-tab in it (as in Gwenview where the tabs are at the bottom)? -
• Can you provide a minimal mockup of this?

Having it tabbed like Gwenview was what I was envisioning, yeah. Basically copy the UX of Gwenview's sidebar, but inside Okular's Reviews tab.

In D15580#513253, @ngraham wrote:

Some thoughts:

In D21755#483631, @simgunz wrote:

What I am probably not understanding is. Is ToggleActionMenu meant to be a general component that you want to use in other parts of KDE? Or is it just meant for Okular?

In D21971#503218, @simgunz wrote:

Suggested changes:

• Make QToolButton::MenuButtonPopup, and ToggleActionMenu::ImplicitDefaultAction the defaults in the constructor so we can call it as d->aMouseModeMenu = new ToggleActionMenu( QIcon(),QString(), this);

@simgunz Thanks for your feedback. I have just got some more private to-do, so if I do not look at your feedback later today, please wait at least until wednesday. :)

Icons are there: D22617.

• Add missing .ColorScheme-Text { to 24px versions of snap-page.svg

• Add missing id=currentColorScheme to 24px versions of snap-page

What does fill:currentColor mean, by the way?

• Remove color attributes, which were added by scour-icon

I assume that fill="currentColor" also doesn’t work as expected, fixing that now...

• Fix id=current-color-scheme attributes which were removed by scour-icon.

In D22617#500361, @ndavis wrote:

In D22617#500346, @davidhurka wrote:

• Why does the stylesheet need a background?

You only need to add the classes that you will use. If you want to use the window background color, you can use the Background class.

This would help to fix/implement bug 377886. The missing part is tweaking the search field above the annotation tree view.

By the way, the suggested stylesheet in https://community.kde.org/Guidelines_and_HOWTOs/Icon_Workflow_Tips#Breeze does not follow https://hig.kde.org/style/icon.html as far as I can understand it.

• Why does the stylesheet need a background?
• How are the color scheme properties in the stylesheet mapped to the reduced breeze palette in the HIG? (I think neutral or Beware Orange do not clearly map.)

• Adapt view-pages-facing and -facing-first-centered to use ndavis' suggested files

In D15580#500264, @simgunz wrote:

@davidhurka Thanks for looking up the bug numbers

Do you know if adding the bug numbers separated by a comma without repeating the keyword BUG would work?

In D22617#500212, @ndavis wrote:

In D22617#500031, @davidhurka wrote:

I can’t follow you here. Centering the first page is a feature / technical detail of Okular, but it indicates that the first page is somehow special, like the cover page of a book. But your document could be a single chapter of the book as well, so the first page is just a regular odd-numbered page. That page should be aligned right.

Since it's an icon for Okular and the feature is called "Facing Pages (Center First Page), I don't understand what the problem is with making the top symbol centered.

Here's what I had in mind:

view-pages-facing-first-centered.svg355 BDownload

view-pages-facing-first-centered.svg361 BDownload

You could consider to add these bugs as BUG keywords to this patch: 386578, 374728, 352310, 330518, 341914, 157289

In D22617#499767, @ndavis wrote:

Nice work!

I know a lot of monochrome icons currently use the bottom right position for the folded corner, but I think we should start using the top right. The bottom right clashes with our convention of putting additional symbols in the bottom right and all of our color icons use the top right for the corner fold.

In D22617#500131, @ndavis wrote:

I'll give the latest changes a proper review in a little while.

In D22617#500046, @davidhurka wrote:

What is the icons-dark directory good for? The icons in there are mostly just the same as in icons.

Non-Qt apps, since they don't work with our stylesheets. Hopefully an XDG standard for coloring symbolic/monochrome icons will fix that and then we can drop icons-dark.

What is the icons-dark directory good for? The icons in there are mostly just the same as in icons.

• Rename pagelayout-* to view-pages-*

• Remove 24px icons
• Flip snap-page icons vertically, so the corner fold is at the top-right
• Make pagelayout-single link to snap-page
• Flip pagelayout-* icons, except pagelayout-single

In D22617#499767, @ndavis wrote:

Nice work!

I know a lot of monochrome icons currently use the bottom right position for the folded corner, but I think we should start using the top right. The bottom right clashes with our convention of putting additional symbols in the bottom right and all of our color icons use the top right for the corner fold.

I’m not sure whether I did everything correctly. If I did, this is too complicated.

• Plotting applications: KmPlot, LabPlot and KAlgebra overlap in the feature of plotting functions - KAlgebra and KmPlot especially should probably be the same applications, as they provide very similiar features, but both apps lack features of the other one.

I want to add another example of inconsistency: Automatic scrolling (that scrolling that happens when you drag something to the edges of a scrollable view.)

Sorry, I forgot about this.

(Added screenshots)

Yes, problem solved. The icon is now visible with a dark color theme.

In D22145#491372, @ngraham wrote:

Show the local file path, which handles the case of locally-downloaded remote files

How does it work when the document is not local, or is deleted?
E. g. do

okular https://20years.kde.org/book/20yearsofKDE.pdf

• Forgot to de-rename out_firstpage in doxygen
• Fix compilation by renaming a parameter I named “default”
• Fix grammar in PageViewItem

Changed 3 more lines yesterday.
Now removing [WIP]; I have some remaining questions (inline coments without “done”), but these are not important for this patch.

• Describe consequences of negative width/height
• Add note to RegularArea::contains() concerning simplify()

Not sure, but that one looks like the inductive stylus I once had. (That one worked pretty bad.)

In D21271#485445, @aacid wrote:

You don't have a committer account, right?

AFAIK these events are only generated for inductive styluses, because a capacitive touchscreen can’t detect proximity with acceptable quality, even less for a stylus.

In D21759#484966, @aacid wrote:

In D21759#484499, @steffenh wrote:

Hi @aacid,
thanks for testing,

Also it doesn't work? or not how i would expect it?

I'm doing ctrl+wheel zoom here with the mouse over the a and ends up being over the p.

I was expecting it to end up being over the a too?

to begin the width of the document is smaller than the viewport with, so we have no horizontal scrollbar and we can not make a horizontal scrolling.

Sure, but at some point there will be a scrollbar, and at that point you can make it scroll to the "correct", position, no?

Would it make sense to request icons for the view modes?

• For Single Page, something like tool_pagelayout would be nice. (It’s just a page, i. e. a rectangle with a folded corner.)
• Facing Pages would have two pages.
• Overview would have 2 or 3 pages, arranged like the discs in save-all. Arranging in a horizontal row would be misleading if the user configured the Overview column count.

• Replace function-like macro by lambda, like done for Color Mode menu in D21195

View mode actions are now organized in QActionGroup * PageView::viewModeActionGroup.
(Uhm, ignore the last commit)

• Replace function-like macro by lambda, like done for Color Mode menu in D21195

In D21755#482891, @simgunz wrote:

I tried it by only adding the actions to it and it does not work, no menu is shown. Adding the signal connection is also not enough. After that I gave up for now (I am lazy). But I think it needs to be a little more user-friendly.

Sometimes I think it makes sense to move the context menu to the widget it belongs to. That widget would accept the context menu event, and create a context menu. Basically the same context menu that is currently created by Part.

• Small improvements based on latest comments by Albert.

Thanks for marking the typos.

• Remove comment on vertical text, remove the word concatenate
• Don’t export text entity reordering functions

Left some changes lying arround, here they are.
Rename m_topMessage, improve callflow description, improve fitWindowToPage description.

In D21755#482896, @simgunz wrote:

To be more clear, I think that the code below should provide a default working action menu (basically as it was before, but customizable if necessary):

d->aMouseModeMenu = new ToggleActionMenu( this );
d->aMouseModeMenu->addAction( d->aMouseSelect );
d->aMouseModeMenu->addAction( d->aMouseTextSelect );
d->aMouseModeMenu->addAction( d->aMouseTableSelect );

I could imagine to add a parameter ToggleActionMenu::MenuLogic to the constructor.

enum MenuLogic {
    DefaultLogic = 0x0,
    /**
     * Automatically makes the triggered action the default action, even if in a submenu.
     * When a toolbar button is constructed, the default action is set to the first checked action in the menu.
     * setDefaultAction() provides a fallback if no action is checked.
     */
    ImplicitDefaultAction = 0x1
};

• Fix parent object QWidget to QObject, remove redundant function call

In D21755#482891, @simgunz wrote:

I have tested this patch and added some inline comments. It seems to me that ToggleActionMenu requires way more external code to make it work, compared to ToolAction, which is quite automated. I think that some things could be made default in ToggleActionMenu, and some aspect hidden as well e.g. manage the QActionGroup internally without having the user have to manage it and set the action eveytime.

• Set popup mode of Color Mode menu, because ToggleActionMenu respects it now.

• Select correct default action at startup
• Describe name ToggleActionMenu
• Let the toolbar buttons respect menu properties like enabled state, and add the menu to updateActionStates().
• Make popup mode configurable correctly, and set popup mode of mouse mode menu.

In D21195#477747, @ngraham wrote:

I would recommend making the toolbar button show the text of the actual color change mode that's currently active, much like how the selection tools toolbar button currently does. Otherwise you won't know which mode it will invoke.

• Fix rebase on D21755

• Rebase on D21755, to use ToggleActionMenu.
• Show the last used color mode on the toolbar button of the Color Mode menu. (Normal Colors is a radio option now, like the other color modes.)
• Add color mode menu to updateActionState().

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

• Add license headers

In D21755#481269, @simgunz wrote:

Currently I am using ToolAction in the new annotation toolbar to selected among different geometrical annotation. [...]
For this purpose I need that the action are checkable, and that the ToggleActionMenu is checkable displaying the selected action (exaclty as ToolAction).

[...] For my use case, I would probably need to be able to display tooltips for each action in the ToggleActionMenu, to describe what they are.

[...] I need to use it for Geometrical annotations and for the Stamp annotation. For this last one I would need to display the different available stamps, so each action in the ToggleActionMenu should just be a checkable action with a full width image and no text. [...]

In T10201#189124, @niccolove wrote:

In T10201#188377, @davidhurka wrote:

Is there a consensus that the titlebars are not liked enough by the users, possibly because they appear to waste too much space while looking empty?

If so, I want to suggest this: Make the menubar titlebar button expandable, so the menubar can be shown inside the titlebar.

Are you suggesting this in addition or replacement of Nate's idea of tools area with the same color?

From my point of view, this is complete now. 3 TODOs left (see revision description at the top).

• Remove accidentally inserted #include
• remove repeated calls to QToolButton::setMenu()
• Update class documentation

In D15580#480855, @simgunz wrote:

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

• Work arround connection problem by using QPointer