[PATCH] Fix menu item widths in KStyle-based styles

Robert Knight robertknight at gmail.com
Wed Jan 2 17:17:53 GMT 2008


Hi,

> How about the attached alternative? There is no reason to not add the
> margin, is there?

Committed, thanks (rev. #756054)

Regards,
Robert.

On 02/01/2008, Maksim Orlovich <mo85 at cornell.edu> wrote:
> <snip>
>
> > Meanwhile QMenuPrivate::calcActionRects() iterates over each action in
> > the menu to be displayed and calculates the maximum item width (using
> > the current style's sizeFromContents() which includes the shortcut
> > text width) and also the maximum "tab width" (width of the shortcut
> > text).  It then adds the maximum tab width to the maximum item width
> > at the end to get the final width.
>
> Thanks. Nice catch.
>
> >
> > I think the error here is in the QMenu code, since I would consider
> > the shortcut text part of the contents of a menu item and so the style
> > should have control over the amount of space allocated for it.
> > However, I also don't think this bug can be fixed within Qt since it
> > would break existing 3rd-party styles.
>
> The expectation has always been that styles are coded against whatever Qt
> does, and not anything one would think logical or find in the
> documentation.
>
>
> Attached is a trivial patch
> > against KStyle which fixes the problem, although the documentation
> > needs updates as well to explain the problem.
> >
> > One question is what to do about the AccelSpace enum value in
> > kstyle.h.  Removing it would be BIC.
>
> How about the attached alternative? There is no reason to not add the
> margin, is there?
>
> Note: if you're fine with it, please commit, I have no net access on my
> development machine atm, and might not for a few days
>
> -Maks
>




More information about the kde-core-devel mailing list