Context TopToolbar for all apps

[Andreas-Kainz]

The following context toolbars are available

• default
• any (not used in cool atm)
• Text
• Table
• Graphic
• Draw
• TextObject
• DrawText
• DrawFontwork
• Cell (calc)
• EditCell (calc)
• HandoutPage (impress)

There is no changes to the existing non context related toolbar

Signed-off-by: andreas kainz [email protected] Change-Id: I6856df49fbcb30160b73fbf94d25a3d5f0cfd555

Summary

review is very welcome, there are a lot of changes, but for the default layout it should look like it is in master. At least for writer.

TODO

• [ ] styles, fonts, fontsizes are type: 'html' and can't be context related, can you fix this @eszkadev
• [ ] please review the default layout in impress and draw @pedropintosilva

Checklist

• [ ] Code is properly formatted
• [ ] Documentation (manuals or wiki) has been updated or is not required

[Andreas-Kainz]

goal to submit this PR is

1. default layout should be perfect
2. html elements should be context related

stuff for future PR's:

• commands that would be useful but not yet available
• future layout stuff

[pedropintosilva]

I just tested again this and try to hack around the issue with how they appear and hide but I cannot stop thinking that while on mobile makes perfect sense and it reduces number of taps etc on the desktop the number of icons is so differently big that I'm afraid I have two little problems with it:

• Too many icons, too frequently flashing (show/hide) since they depend on selection
• It might be worst for user's memory since now even basic elements change position at a frequent rate

[pedropintosilva]

I wonder what's your thoughts @jancborchardt

[pedropintosilva]

https://user-images.githubusercontent.com/65948705/146366998-58627aca-d935-4983-8d10-257af266ad1b.mp4

[Andreas-Kainz]

* Too many icons, too frequently flashing (show/hide) since they depend on selection
* It might be worst for user's memory since now even basic elements change position at a frequent rate

totally agree with you but there are two things to remember:

• text related stuff is complete useless for e.g. drawing and graphic stuff
• gdoc's do the same

the biggest issue about the juming UI (I don't like) is that you have insert commands at the end of the toolbar if you move them to the right with the existing spacer element, than the UI is may smoother and that's the reason I keep thinking of #3871

[Andreas-Kainz]

fyi I don't want to have this PR asap in master. The PR is to see what's possible and how it was done. There are some open tasks to fix before AND of corse there has to be an design decission how it should look and work.

[jancborchardt]

Agree with your feedback @pedropintosilva – maybe it's alleviated by not using the animation but rather directly switching the display/visibility?

[kendy]

fyi I don't want to have this PR asap in master.

@Andreas-Kainz: Thanks for the work! This sounds good - as we'd like to keep master half-frozen for the COOL release until February.

[pedropintosilva]

yeah maybe (and reiterating @jancborchardt take) maybe having no animation so, having it switching instantly would be a better option and would leave a better impression

[Andreas-Kainz]

@pedropintosilva could you rebase this PR to master. I wouldn't like to work on this PR to make it happen.

[jancborchardt]

yeah maybe (and reiterating @jancborchardt take) maybe having no animation so, having it switching instantly would be a better option and would leave a better impression

An alternative to the animation shown in the video could be a vertical switching out of the toolbar. Because:

• It would keep the advantage of the animation → showing people something changed
• But it doesn’t have the con of there needing to be 2 animations, one for hiding the existing stuff, one for displaying further things?

There might also be another way of improving the horizontal animation, just thinking aloud. :)