Presently its easy to add a bullet or numbering list through the toolbar, but its not possible to change the type of bullet or numbering through the toolbar, so users are left to open 'bullet and numbering' dialog to do so. So it would be good to port the code presently available in the sidebar into the toolbar, if that is the easiest route. The ability to do this from the toolbar is available in most office suites - MS Office, WPS/Kingsoft Office, Google Docs, WordPerfect Office.
great idea ;)
Let's try this one.
Created attachment 109062 [details] bullet list drop downs from other apps Here is how the bullet drop down looks in other office suites. I think it would be better to have the new bullet drop down entries look similar to the numbering drop down entries, as having such a large entry with just the bullet characters seems like a waste of space. Alternatively, with smaller entries in the bullet list drop down, similar to ms word, we could fit quite a number of entries in it.
Created attachment 109067 [details] WIP screenshots I already have fully working popups. Instead of porting the Sidebar control, I decided to try to reuse the same control as in the Bullets and Numbering dialog, so that's what I have right now. It's the same layout with the same items as in the dialog. The toolbar button is now a split button, so clicking the button itself still activates/deactivates the bullets state as before. The "More" button looks (and highlights) like a menu item - in the same way as the last item in the "Slide Layout" button in Impress (In fact I used the same control as there, for the current implementation). I can push it as-is if that matters. Any suggestions?
Looks good to me. Is there anyway to highlight the currently selected one, as i know this is also a missing feature in the dialog?
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=261f84a08d8631d70c62d849cd11b21bc9d1f106 fdo#85804 Introduce bullets and numbering popups It will be available in 4.4.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.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=853e9c00a359b93c546e2e8a5fcee9e8aebf49b8 fdo#85804 Use the new popups in the sidebar too It will be available in 4.4.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.
I must say that it looks beautiful Maxim. Thanks. If you can, there is slight bit of adjustment that is needed. There needs to be 2 or 3 pixels padding at the top row, like the padding at the bottom of the bottom row. Also is is possible to have the dialog open up to the bullet and numbering tabs.
Hi Maxim, Was wondering if you got a chance to see comment 8. Also i noticed that the drop downs are white, while other drop downs have a different color.
(In reply to Jay Philips from comment #8) > There needs to > be 2 or 3 pixels padding at the top row, like the padding at the bottom of > the bottom row. I didn't find a way of doing it. I'm able to increase/decrease the space below the 2 rows and above the separator (right now it's 1px), but not at the top. (In reply to Jay Philips from comment #9) > Also i noticed that the > drop downs are white, while other drop downs have a different color. It takes the menu background color, and probably your desktop theme has white background for menus. The intention probably was to make it look similar to a real menu. As you can see the "More" item even has the same highlighting color as a menu item. Anyway, we have also other menu like popups, like the new/open buttons, and many others, and they all have a menu background, so I'm not sure this is necessarily a bad thing. Now, both issues are inherited from svtools::ToolbarMenu, which is the control that I use for this popup. You can find both issues in other svtools::ToolbarMenu based popups, like Slide/Slide Layout in Impress, and the popups from the 3D-Settings toolbar. But if these issues are really annoying you, I guess I'll need to replace the current implementation with a new .ui based one.
(In reply to Maxim Monastirsky from comment #10) > Now, both issues are inherited from svtools::ToolbarMenu, which is the > control that I use for this popup. You can find both issues in other > svtools::ToolbarMenu based popups, like Slide/Slide Layout in Impress, and > the popups from the 3D-Settings toolbar. Thanks for pointing that out. I see in impress, the slide borders make it look not so obvious with this issue. Are these bullet entries images, so maybe i could add a similar border around them to mimic that effect. > But if these issues are really > annoying you, I guess I'll need to replace the current implementation with a > new .ui based one. We can always come back to this issue at a later stage if need be, as what we have now is more than sufficient. :D I have a long list of split/group buttons that i want to implement and wondered how easy they are to create. The first type are simple ones which just contain a list of uno commands, separators, and submenus similar to the context menu (i just got a hang of how to work with context menus today :D) and the new/open/insert field buttons. If i understand it correctly the new/open/insert field buttons are just pulling the entries out the the menu bar. The second group of split/group buttons are buttons like in impress's alignment and arrange buttons which simply shows buttons from an existing toolbar. You can see my previous laundry list of these buttons in attachment 103175 [details] and attachment 103420 [details]. Thankfully you and kendy knocked out the two hardest ones. Thanks again for that.
(In reply to Jay Philips from comment #11) > Thanks for pointing that out. I see in impress, the slide borders make it > look not so obvious with this issue. Are these bullet entries images, so > maybe i could add a similar border around them to mimic that effect. These items aren't images. We draw them at runtime using system fonts. I think I'll just try to shift the whole drawing 1-2 pixel down inside each item. Hope it will look better that way. > I have a long list of split/group buttons that i want to implement and > wondered how easy they are to create. Not so hard in theory, but each one needs a dedicated coding. > If i understand it correctly the > new/open/insert field buttons are just pulling the entries out the the menu > bar. Well, not exactly. The new/open buttons are indeed reusing the same menus as in the menu bar, but they aren't "just pulling the entries out the menu bar", because if you look at the menu xml, it doesn't have sub menus for these items. Instead there is a piece of code ("controller"), that is registered for each such command, and it's responsible for filling this sub menu, and for executing its items. So we reuse this code for the toolbar too. Regarding the insert field button - it has nothing to do with the menu bar. It uses a different menu, that was simply made similar to the one from the menu bar. So whatever change you want to do, you should do it in two places. (It could be a good idea to unify this code at some point.) I'm not aware of any easy way to "just pull the entries out the menu bar".
(In reply to Maxim Monastirsky from comment #12) > These items aren't images. We draw them at runtime using system fonts. I > think I'll just try to shift the whole drawing 1-2 pixel down inside each > item. Hope it will look better that way. As it is being drawn at runtime, could we draw a border around it. > > I have a long list of split/group buttons that i want to implement and > > wondered how easy they are to create. > Not so hard in theory, but each one needs a dedicated coding. Could we not write a single function that could be called to generate the necessary drop down menu entries according to a provided list of menu items, in a way similar to how the right-click context menu is being generated. In this way, it would easier to create these drop downs split/group buttons, easier to change them like it is with the context menu and there would be no repetition of large amounts of code. > > If i understand it correctly the > > new/open/insert field buttons are just pulling the entries out the the menu > > bar. > Well, not exactly. The new/open buttons are indeed reusing the same menus as > in the menu bar, but they aren't "just pulling the entries out the menu > bar", because if you look at the menu xml, it doesn't have sub menus for > these items. Instead there is a piece of code ("controller"), that is > registered for each such command, and it's responsible for filling this sub > menu, and for executing its items. So we reuse this code for the toolbar too. Yes what i meant was that they both have the same list, so they must be pulling from the same source. :D > Regarding the insert field button - it has nothing to do with the menu bar. > It uses a different menu, that was simply made similar to the one from the > menu bar. So whatever change you want to do, you should do it in two places. > (It could be a good idea to unify this code at some point.) > > I'm not aware of any easy way to "just pull the entries out the menu bar". Recently that different insert field menu was scrapped when we found out that the images werent showing up in the drop down menu, or atleast that is what i understood from the code. ( http://cgit.freedesktop.org/libreoffice/core/commit/?id=4aa2791ea6ee72d429cb8ddcaffd0a9fe647e3db )
(In reply to Jay Philips from comment #13) > Could we not write a single function that could be called to generate the > necessary drop down menu entries according to a provided list of menu items, > in a way similar to how the right-click context menu is being generated. Sure, we could write one controller, that shows a different menu based on the command of the button it was pulled from. We're already doing this in various places. In Impress/Draw all drop-down that show buttons from an existing toolbar, are in fact sharing the same code. It just checks the command of the button, and shows the appropriate toolbar. Although there could be some complex cases where this simplified approach won't work. > Recently that different insert field menu was scrapped No, it's still a different menu.
Created attachment 110410 [details] screenshot with borders (In reply to Jay Philips from comment #13) > As it is being drawn at runtime, could we draw a border around it. Attached a screenshot with borders (the tick marks item has a double border, because it's the currently selected). Is this the right direction?
(In reply to Maxim Monastirsky from comment #14) > Sure, we could write one controller, that shows a different menu based on > the command of the button it was pulled from. We're already doing this in > various places. In Impress/Draw all drop-down that show buttons from an > existing toolbar, are in fact sharing the same code. It just checks the > command of the button, and shows the appropriate toolbar. Although there > could be some complex cases where this simplified approach won't work. Beautiful. So should i open a bug report about this? (In reply to Maxim Monastirsky from comment #15) > Attached a screenshot with borders (the tick marks item has a double border, > because it's the currently selected). Is this the right direction? Looks great. Could you possibly move the content of each image down by 2 pixels, as you can see in '1)' that its nearly touching the top border.
(In reply to Jay Philips from comment #16) > Beautiful. So should i open a bug report about this? Sorry but I don't understand, bug report about what?
(In reply to Maxim Monastirsky from comment #17) > (In reply to Jay Philips from comment #16) > > Beautiful. So should i open a bug report about this? > Sorry but I don't understand, bug report about what? I was wondering how to proceed with the creation of this split/group drop down controller.
(In reply to Jay Philips from comment #18) > I was wondering how to proceed with the creation of this split/group drop > down controller. Just create it for the first popup, and then re-use for the next ones. Or find an already existing one that doesn't have so much logic related to a specific button, and add it there. But I'm wondering whether you understand that a new code should be added anyway for each case, it's not just like editing some xml?
(In reply to Maxim Monastirsky from comment #19) > Just create it for the first popup, and then re-use for the next ones. Or > find an already existing one that doesn't have so much logic related to a > specific button, and add it there. But I'm wondering whether you understand > that a new code should be added anyway for each case, it's not just like > editing some xml? Unfortunately i'm not a c++ developer so i would be unable to create the function/controller needed to simply the creation of new buttons.
(In reply to Jay Philips from comment #20) > Unfortunately i'm not a c++ developer so i would be unable to create the > function/controller needed to simply the creation of new buttons. Sure, not a problem at all. If you have any popup that we already have all the needed commands for it, just CC me to that bug, and I'll try to find a time for it. (And BTW, I never programmed in C++ before I started contributing to LO, so you could also try it at some point...)
(In reply to Maxim Monastirsky from comment #21) > Sure, not a problem at all. If you have any popup that we already have all > the needed commands for it, just CC me to that bug, and I'll try to find a > time for it. (And BTW, I never programmed in C++ before I started > contributing to LO, so you could also try it at some point...) Thanks for the help. I have created the new bug report (bug 87079) and CCed you in it. (I hope to try to get into C++ programming once i've gotten more used to other aspects of the code base)
This bug fix comes with LibreOffice 4.4 (release notes https://wiki.documentfoundation.org/ReleaseNotes/4.4) The “Bullets” and “Numbering” toolbar buttons now have drop-down menus so it easier to change the list style without opening the lists dialog. See a graphic of the work: https://wiki.documentfoundation.org/File:Bullet_Drop_Down.png
Hey Maxim, Did you ever get a chance to push the borders fix as i still dont see it in the builds.