Whenever the bar 'Drawing object properties' pops up, the (future) graphics object assumes the same default properties (apparently set by LibreOffice). 1) Although several of the properties submenus mention a 'default' property, the user apparently has no way of setting his standard there. 2) As long as this is impossible, the properties shown should be those last used by the user. As it is now, if I insert a set of graphic figures in a document all of which have the same graphic properties, I have to redefine these properties for every single figure that I insert.
I think I can understand your proposal, but for me it is not clear, what kind of properties you are thinking of. You mentioned the toolbar "Drawing object properties". In this toolbar I can only find the "imagage mode" with a default set. On the other hand, if you open the image properties (via context menu or format => image => properties) you have a lot of properties with a (I assume) default property. It's the same with the properties in the sidebar. So my question is: Can you make your proposal more concrete? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' after the requested informations are given. Additional information: Recently I dicovered the extension PicTool, that perhaps could provide a workaround. But I haven't used it until now
We may have a misunderstanding here, maybe due to the fact that at least one of us (me) is using a German localization, but we have to refer to some English surface which I do not see. Do the following steps: - Have a Writer file opened which contains a drawing. - Click on the drawing. - A symbol bar pops up which in the German version is called 'Zeichenobjekteigenschaften' (Drawing object properties). - The first symbol on the bar is called 'Linienfarbe' (line color). It always shows blue, regardless of the color of the object you clicked. - The fourth element on the bar is a combo box called 'Linienbreite'. It always shows the same value, regardless of the actual value of the object concerned. - The fifth symbol is called 'Füllfarbe' (filling color). Again, it is always blue. You can change these values and apply them to your object or to a new object. But as soon as you close this symbol bar, the next time that it opens it will again offer you its favorite values. On the other hand, on this symbol bar, I do not see the property 'Image mode' that you mention.
Sorry, my fault. I had a look at properties of images not of drawings. I can confirm your bug. I think it is not the problem, that writer doesn't remeber the recent used colour. If you open "Line Colour" or "Fill Coulour" the recent colour is shown. But it would be very userfriendly, if this colour is also shown in the icon itself, so that you immediately can click on it. I'm not realy sure, if this is what you like to have. Or do you really want to define a favourite colour (I assume this has to be added to tools => options => LibreOffice => Application Colours)?
There is some interference here with another bug that I reported concerning this symbol bar (taken up by Yousuf Philips): The fill color item occurs doubly in v. 5.4.2.2. And in one of its occurrences, it does show the current color. Maybe we can keep this one and discard the blue picture. Please remember that color is not the only property to be applied to drawings. I am referring to all of them. As far as properties chosen by the user go, there are, in fact, three desiderata: - If I click on a drawing, the properties displayed in the properties bar should be those of the object in question. Instead, they are always the same. - If I insert a series of such drawings in a document (remember we are talking about text documents, not pictures), then it is more probable that all of them have the same graphic properties than that each of them will be different. Therefore, it would be helpful if Writer could simply remember the properties used last and then, if the properties bar pops up again, offer the same values to be applied to the next drawing, so I do not need to set them again. - Several of the properties menus and combo boxes on this symbol bar have an option 'Standard' (probably 'Default' in the English version). This could be useful if the user were actually allowed to define his standard. As it is now, he is not, and he is not even told what these defaults are, so these defaults are useless.
steps: 1. open writer 2. draw a shape 3. change the line and fill colors in toolbar split buttons 4. deselect shape 5. reselect shape 6. split button colors no longer have the recently applied colors in the icon portion of the split button Maxim: Any thoughts why .uno:XLineStyle and .uno:FillColor are resetting back to the default blue colors after the toolbar looses context?
*** This bug has been marked as a duplicate of bug 72991 ***
Maxim: The duplicate bug is about remembering it after closing and reopening writer, this issue is the the used colors are lost within a single session simply by the change of the contextual toolbar.
(In reply to Yousuf Philips (jay) from comment #7) > Maxim: The duplicate bug is about remembering it after closing and reopening > writer Well, the original report there says nothing about it, only comment 1 mentions closing writer (and anyway I was assuming that whoever will work on this, will implement both parts). But I'm fine with keeping those two parts separate, as long as Bug 72991 will be marked as dependant on this one, and Bug 83789 & Bug 71413 will be duplicated to this one instead.
(In reply to Maxim Monastirsky from comment #8) > Well, the original report there says nothing about it, only comment 1 > mentions closing writer (and anyway I was assuming that whoever will work on > this, will implement both parts). But I'm fine with keeping those two parts > separate, as long as Bug 72991 will be marked as dependant on this one, and > Bug 83789 & Bug 71413 will be duplicated to this one instead. Fine by me, go for it. ;D
*** Bug 83789 has been marked as a duplicate of this bug. ***
*** Bug 71413 has been marked as a duplicate of this bug. ***
*** Bug 120681 has been marked as a duplicate of this bug. ***
*** Bug 134515 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 154270 ***