Created attachment 139582 [details] Missing icons.odb The 'Table Control' icon (to insert a table control when editing a form) and several other icons have gone missing from the 'More Controls' tool bar (which itself is contained in the 'Form Controls' tool bar.) Tested in versions: 5.4.6.0 dev linux - was ok (not broken) 6.0.0.1 windows - broken (regressions) 6.0.0.2 linux - broken 6.0.1.0 dev linux - broken See 2 screen shot attachments, * first one of 6.0.0.2 (fail), and * 2nd one of 5.4 Also missing these icons: spin, vertical slider, calendar, group, grid, etc. Steps to reproduce. 1) Open the attached database 2) Open the form in Edit mode 3) Left click on the More Controls icon in the Form Controls tool bar. It has a check mark, and to the right of the a circle with a black dot in it, and then 3 dots below these two.) (Not to be confused with the similar looking icon for "Activation Order"). 4) Notice that there are now only 6 icons in the new tool bar (or pallet) that appears. Note: There used to be 13 icons in this toolbar, so others are missing too . Workaround: You can Menu to Tools > Customize, etc ... and manually fix this.
Created attachment 139583 [details] screenshot: missing icons
Created attachment 139584 [details] screenshot: before the icons dissapeared
You are right. Seems the tablecontrol has been forgotten. You could add it with right mousebutton and then > Customize Toolbar... but it should be a default-control. Spin and scroll-Bar aren't shown. You could aktivate them. Could be someone decided this two controls aren't used so often. All other fields I could see at the toolbar for Form Controls. Tested here with OpenSUSE 42.2 and LO 6.0.0.3 64bit rpm Linux
The change was done by: author Yousuf Philips <philipz85@hotmail.com> 2017-12-07 02:34:43 +0400 committer Yousuf Philips <philipz85@hotmail.com> 2017-12-19 00:50:41 +0100 commit e027dc4629db2959e2c62b97b463c1846849dbd7 (patch) tree 300bf01ad8ad109f986022a2ca13633ccef6f243 parent 35589bc4e390282f1e26b9900addc3742e61b3ff (diff) tdf#81475 Organize the form toolbars @Jay, is it intended, thus RESOLVED NOTABUG, or is it a regression?
From the 13 controls that were in the more controls toolbar, 6 are still present, 4 were moved to Form Controls toolbar (Image Button, Date Field, Numeric Field, Group Box), 2 were set to hidden (Spin Button, Scrollbar) and 1 was removed (Table Control). Table Control shouldnt have been removed, but assume Spin Button and Scrollbar are exclusive to calc and arent used in Base, so its fine to keep them hidden by default. (In reply to Howard Johnson from comment #1) > Created attachment 139583 [details] > screenshot: missing icons The 4 added controls are missing from your screenshots as you modified the Form Controls toolbar. Resetting the toolbar in the customization dialog will result in them appearing.
Confirming in Version: 6.1.0.0.alpha0+ Build ID: 0f28c8612f4269cec95688b53d182c7c0169236d CPU threads: 4; OS: Mac OS X 10.13.3; UI render: default; Locale: fr-FR (fr_FR.UTF-8); Calc: group threaded
Well, for sure, the missing table insert button is a mistake, as that is a control used regularly. I can't really say whether it was a mistake to hide the spin counter and vertical slider, although I have seen the spin button used in database forms. My question as to the appropriateness of these changes would be more with regard to: - XML forms, where such controls are used more frequently - Basic IDE dialogues, where these controls are also used fairly frequently. I'm assuming that the XML forms now suffer from the same issue as database forms since they rely on Writer. It would be worthwhile checking whether the additional tool toolbar in the Basic IDE Dialog builder has also been affected by this change.
(In reply to Alex Thurgood from comment #7) > I can't really say whether it was a mistake to hide the spin counter and > vertical slider, although I have seen the spin button used in database forms. Then i'll unhide them. > I'm assuming that the XML forms now suffer from the same issue as database > forms since they rely on Writer. XML forms utilize the same toolbars .xml files as Design View, so that do suffer the same issue. > It would be worthwhile checking whether the additional tool toolbar in the > Basic IDE Dialog builder has also been affected by this change. Basic IDE dialog builder toolbars weren't changed by my commit. (In reply to Howard Johnson from comment #1) > Created attachment 139583 [details] > screenshot: missing icons Seeing Howard's customization of the Form Controls toolbar shows that the reorganization i did was a step in the right direction and if there are further improvements to these toolbars that would benefit Design View and XML Forms, please file a bug report with the suggestions.
Patch - https://gerrit.libreoffice.org/49671
(In reply to Yousuf Philips (jay) from comment #8) > > Seeing Howard's customization of the Form Controls toolbar shows that the > reorganization i did was a step in the right direction and if there are > further improvements to these toolbars that would benefit Design View and > XML Forms, please file a bug report with the suggestions. Well I always found it a bit strange that OOo had 2 toolbars for what essentially are design tools and could probably all have been put on a single toolbar (à la main toolbar in Writer as was). Anyway, I suppose it is horses for courses. As long as all of the tools are accessible some how (e.g. tick/untick in the toolbar config), with the most used ones easily available, then I'm all for it.
One thing I would add is that the default (Breeze ?) icons which use the dollar sign do not add clarity IMHO to the situation. If I have to read the tooltip each time, then I'm clearly not gaining any time advantage ;-)
Hi Yousuf. Thank you for working on this. Base surely needs all the help it can get. Here are a few of my thoughts on this subject: First, I think the "More Controls" bar should probably have ALL other available controls that are not somewhere else, sort of a catch all; given it's name "More..." it's what a user would expect. While I have not yet used the scroll bar, or spin box, I might someday. Without it being somewhere that is reasonable to find, one might not know it even exists to try it out. Next, I don't know, please help me understand why we might want to remove any items from any existing menus. To me, these items are the end-user's API, if you will. Taking away menu choices that are documented in a variety of places in the world, leaves one to think that LO is now smaller than it once was. What is a user to think who is looking for one of these features and can't now find it? Also, and in parallel with this, as an end user for a couple of years now, I would expect that existing features either persist, are improved, but not disappeared, ... unless replaced by other functionality, and even if so, they should be depreciated first. Perhaps there should be a "Depreciated" menu bar??? Never thought I'd be saying that about the LO user interface, but here I am saying it. --------- And while I'm on the subject, I would expect that newer LO versions with any menu bar changes, would try really hard to respect any prior customizations users made to their menus, as much as possible. Why offer the user the ability to customize, if newer versions erase their changes? Having a menu all jumbled in a newer version is the kind of thing that I would expect only from the newer people at Microsoft, and not what I would expect from LibreOffice. But I want to hear you out as to what the goals of any menu reorganization is about. How did this reorganization start, what input was taken from users, and the like. I really do appreciate your work on Base! Thanks.
(In reply to Alex Thurgood from comment #10) > Well I always found it a bit strange that OOo had 2 toolbars for what > essentially are design tools and could probably all have been put on a > single toolbar (à la main toolbar in Writer as was). Actually there are 3 form related toolbars (Form Controls, More Controls, and Form Design) and i believe it would be difficult to merge all these into a single toolbar. (In reply to Alex Thurgood from comment #11) > One thing I would add is that the default (Breeze ?) icons which use the > dollar sign do not add clarity IMHO to the situation. If I have to read the > tooltip each time, then I'm clearly not gaining any time advantage ;-) I had suggested Andreaz fix the form icons in october, but he hadnt gotten around to it, so i'll remind him again. (In reply to Howard Johnson from comment #12) > Next, I don't know, please help me understand why we might want to remove > any items from any existing menus. To me, these items are the end-user's > API, if you will. Taking away menu choices that are documented in a variety > of places in the world, leaves one to think that LO is now smaller than it > once was. What is a user to think who is looking for one of these features > and can't now find it? Some form controls are not used in particular modules than others, e.g. spin button and scrollbar are used only in calc, so its important to not present them when they arent applicable. > Also, and in parallel with this, as an end user for a couple of years now, I > would expect that existing features either persist, are improved, but not > disappeared, ... unless replaced by other functionality, and even if so, > they should be depreciated first. Perhaps there should be a "Depreciated" > menu bar??? Removing or hiding them from the toolbar or menubar doesnt remove it from the app, so users can always still add it using the customization dialog. > And while I'm on the subject, I would expect that newer LO versions with any > menu bar changes, would try really hard to respect any prior customizations > users made to their menus, as much as possible. Why offer the user the > ability to customize, if newer versions erase their changes? All prior customization arent overwritten when a user upgrades, which is why you are still seeing your customized form controls toolbar and not the new one which is now in 6.0. > Having a menu all jumbled in a newer version is the kind of thing that I > would expect only from the newer people at Microsoft, and not what I would > expect from LibreOffice. > > But I want to hear you out as to what the goals of any menu reorganization > is about. How did this reorganization start, what input was taken from > users, and the like. Menu and toolbar reorganizations happened after analysis of usage metrics collected in the OOo days. You can read my first 6 comments in bug 81475 to see that kind of work that was involved in doing it. > I really do appreciate your work on Base! Well i havent really done any work on Base as there arent any usage metrics for it. :D
Yousuf Philips committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=603d1773a2dfea6b347f44ddacef478577098caf tdf#115447 tdf#81475 Restore form controls used in forms It will be available in 6.1.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Yousuf Philips committed a patch related to this issue. It has been pushed to "libreoffice-6-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2460d20c9a10920944b470d5ff5871f2bdb328f5&h=libreoffice-6-0 tdf#115447 tdf#81475 Restore form controls used in forms It will be available in 6.0.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.