Issue 118751 - appearance - color list box too small
Summary: appearance - color list box too small
Status: CLOSED FIXED
Alias: None
Product: Writer
Classification: Application
Component: configuration (show other issues)
Version: 3.4.0 Beta (OOo)
Hardware: PC All
: P5 (lowest) Normal (vote)
Target Milestone: 4.0.0
Assignee: Ariel Constenla-Haile
QA Contact: Diego Valle Rosado
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-10 21:16 UTC by David Rankin
Modified: 2022-10-28 12:54 UTC (History)
3 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
screenshot showing color listboxes that are too small to be navigated efficiently (44.87 KB, image/jpeg)
2012-01-10 21:16 UTC, David Rankin
no flags Details
Patch to change count of dropdown lines to 10 (486 bytes, patch)
2013-02-07 12:13 UTC, hanya
no flags Details | Diff
Patch to change count of dropdown lines to 10, fixed to be applied to first listbox also (666 bytes, patch)
2013-02-13 11:47 UTC, hanya
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description David Rankin 2012-01-10 21:16:34 UTC
Created attachment 77115 [details]
screenshot showing color listboxes that are too small to be navigated efficiently

AOO 3.4 beta on Arch Linux i686

  The Tools->Options->Appearance color listboxes (dropdowns) are way to small vertically. They are limited to 4 colors shown out of a very large list that makes navigation to find the wanted color very difficult. I agree with keeping the listbox, but the number of visible colors should be increased so the user sees at least 10. See the attachment for a screenshot of the problem. Thanks.
Comment 1 Diego Valle Rosado 2013-02-07 02:47:42 UTC
Hi.

This reporte isn't a bug, is like proposal or suggestion to improve the word processor, ant I submit a email about this suggestion to bugzilla.

Regards,
Diego Valle
Comment 2 Diego Valle Rosado 2013-02-07 05:32:10 UTC
Change of status
Comment 3 Diego Valle Rosado 2013-02-07 06:19:06 UTC
Change status: confirmed for review and improvement if it's necessary

Diego Valle
Comment 4 hanya 2013-02-07 12:13:19 UTC
Created attachment 80220 [details]
Patch to change count of dropdown lines to 10
Comment 5 Diego Valle Rosado 2013-02-12 23:26:20 UTC
This bug was resolved, to change count of dropdown lines to 10.

Regards
Comment 6 hanya 2013-02-13 01:53:07 UTC
The patch was just attached, not applied to trunk yet.
Comment 7 Ariel Constenla-Haile 2013-02-13 03:49:50 UTC
Reopening.
Assigning to myself to review the patch.
Comment 8 Ariel Constenla-Haile 2013-02-13 04:07:58 UTC
(In reply to comment #4)
> Created attachment 80220 [details]
> Patch to change count of dropdown lines to 10

@hanya: the patch misses the first list box (General - Document background)

The entries are set originally for the first listbox, in the loop they are copied:


for( sal_Int32 i = 1; i < nCount; i++ )
{
   if(aColorBoxes[i])
   {
	aColorBoxes[i]->CopyEntries( *aColorBoxes[0] );
	if( i < sal_Int32(sizeof(aColorLBHids)/sizeof(aColorLBHids[0])) )
	   aColorBoxes[i]->SetHelpId( aColorLBHids[i] );
         aColorBoxes[i]->SetDropDownLineCount( 10 );
   }
}

That's why the index starts are 1, the entries are copied from the first list box to the other listboxes. Before entering the loop, you should set the count of drop lines to aColorBoxes[0]
Comment 9 hanya 2013-02-13 11:47:33 UTC
Created attachment 80269 [details]
Patch to change count of dropdown lines to 10, fixed to be applied to first listbox also

@Ariel: Thanks for review. I fixed the patch as you said.
Comment 10 SVN Robot 2013-02-13 15:24:34 UTC
"arielch" committed SVN revision 1445663 into trunk:
i118751 - Increase colour list boxes line count
Comment 11 Ariel Constenla-Haile 2013-02-13 15:27:48 UTC
@hanya: thanks for the patch!

Fixed on trunk.
Comment 12 Diego Valle Rosado 2013-02-15 01:46:33 UTC
Hi Ariel!

I saw that you has assigned this bug. That means that once is fixed , you will close this bug?

Regards
Comment 13 Ariel Constenla-Haile 2013-02-15 02:07:51 UTC
(In reply to comment #12)
> I saw that you has assigned this bug. That means that once is fixed , you
> will close this bug?

Usually, when the bug has a patch, it is assigned to the developer that will review the code and commit it.

I reviewed the patch, find it good, committed it, and changed the status to RESOLVED as FIXED, because it resolved the bug, and it is fixed, on "trunk" (the code where development for the future release happens).

Now the bug has to be VERIFIED as FIXED, you can do this by downloading a build from the build bots that has revision number >= 1445663 

Usually, before the release, all VERIFIED bugs are checked once again (because in the development cycle, it might happen that a fix gets broken by some other change).

The last step is verifying the fix once a public release has been made. So, once OpenOffice 4.0 is out, the bug has to be verified, it the fix works, then the bug is CLOSED as FIXED.

At any time, if the bug is not fixed, it can be REOPENED.