Bug 66827 - Can't select other fill than color in Writer --> Drawing functions
Summary: Can't select other fill than color in Writer --> Drawing functions
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.1.0.2 rc
Hardware: Other All
: high major
Assignee: Miklos Vajna
URL:
Whiteboard: target:4.2.0 target:4.1.1
Keywords: regression
Depends on:
Blocks:
 
Reported: 2013-07-11 16:10 UTC by Florian Reisinger
Modified: 2013-08-19 10:43 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Reisinger 2013-07-11 16:10:20 UTC
Problem in Version: 4.2.0.0.alpha0+
Build ID: 6a9aa432f53b53310ce56588508d151e15112b16

Reproduce: Open Writer -> Insert shape ("Show drawing functions" is your friend)
I draw a rectangle. As long as "mode" is color you can do what you want, it will work. Changing w.g. to "None", "Hatching", "Gradient" and Bitmap will result in resetting to the "Color" chosen [WORKING in DRAW]

Works in Version 4.0.4.2 (Build ID: 9e9821abd0ffdbc09cd8c52eaa574fa09eb08f2)
Comment 1 Jorendc 2013-07-11 21:05:48 UTC
I can confirm this behavior tested using Mac OSX 10.8.4 with LibreOffice 4.1.0.2 RC

How to reproduce:
* Open Writer
* View > Toolbars > Drawing
* Draw rectangle in modus 'color'
* Deselect rectangle

Behavior: modus is still 'color'. _same as in Draw_

* Change modus to 'hatching' for example
* Draw again a rectangle

Behavior: no hatching is drawn, just a regular rectangle as with modus 'color'. _same as in Draw_

* deselect rectangle
* reselect it

Behavior: modus is reseted to 'color'. _Modus in Draw is still 'hatching' (but no hatching is applied too)_

So, looks to me also a draw issue?

Kind regards,
Joren
Comment 2 Florian Reisinger 2013-07-12 06:43:42 UTC
Hi Joren,

In my master Draw is working...
Comment 3 jun meguro 2013-07-20 07:18:38 UTC
Reproduced "Ubuntu rc3" and "Win rc2".
Comment 4 Samuel 2013-08-13 08:51:26 UTC
Can confirm this bug in LO Version: 4.1.0.4
Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28
The "Drawing Object Properties" Toolbar do not work as expected.

"right click" -> "Area..." on the circle to set color "none" work as expected.

OS Debian 7.1 amd64
Comment 5 Samuel 2013-08-13 10:54:17 UTC
Use the new sidebar (experimental feature) work.
Comment 6 Michael Stahl (allotropia) 2013-08-15 22:08:35 UTC
regression from:

commit d884f8f65cc73cf932cde1e40cadf13556a7d44e
Author:     Miklos Vajna <vmiklos@suse.cz>
AuthorDate: Tue Feb 12 16:14:23 2013 +0100

    SwFrmDlg: initial gradient background UI

specifically the 2 changed entries in bastyp/init.cxx apparently have some side effect...
Comment 7 Michael Stahl (allotropia) 2013-08-16 18:45:22 UTC
so what happens for this drawing toolbar is that a "uno:.FillStyle" is
dispatched, which is turned into WhichId SID_ATTR_FILL_STYLE  10164

This causes an SfxItemSet with one item to arrive in
SdrEditView::SetAttrToMarked and
sdr::properties::AttributeProperties::ItemChanged,
where in the old version the item is applied but not in the new version;
the difference is the old one had WhichId 1014 XATTR_FILLSTYLE
new one is 123 RES_FILL_STYLE, i.e. the added one.

The different WhichIds come from TransformParameters calling

 sal_uInt16 nWhich = rSet.GetPool()->GetWhich(nSlotId);

where previously the entry from the secondary pool created in
XOutdevItemPool::XOutdevItemPool was returned but now
we get the one from the primary (sw) pool instead.
Comment 8 Miklos Vajna 2013-08-16 19:10:00 UTC
I'll take care of this.
Comment 9 Commit Notification 2013-08-16 19:18:02 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f694f14ab64f48e40365fd877e201a0382297368

fdo#66827 sw: rename SID_ATTR_FILL_GRADIENT to SID_SW_ATTR_FILL_GRADIENT



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.
Comment 10 Commit Notification 2013-08-16 23:14:08 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=823cab696bdaa059e5d1243a636e7d975b2110cc&h=libreoffice-4-1

fdo#66827 sw: rename SID_ATTR_FILL_GRADIENT to SID_SW_ATTR_FILL_GRADIENT


It will be available in LibreOffice 4.1.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.
Comment 11 Miklos Vajna 2013-08-17 08:46:30 UTC
Fixed on master, backported to -4-1, so marking as resolved.
Comment 12 Commit Notification 2013-08-19 10:43:32 UTC
Miklos Vajna committed a patch related to this issue.
It has been pushed to "libreoffice-4-1-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c1ba41e17fbf5039067b46df5c433a5811353d8b&h=libreoffice-4-1-1

fdo#66827 sw: rename SID_ATTR_FILL_GRADIENT to SID_SW_ATTR_FILL_GRADIENT


It will be available already in LibreOffice 4.1.1.

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.