I'm testing Slackware current, which includes KDE 3.5.10. After I finished the update on my testing partitions, I booted into KDE 3.5.10. Looks the same as 3.5.9 except the panel applet handle menu pointers (the black arrow heads) are much larger.

Here is a snapshot of 3.5.9:

Snapshot-3.5.9

Here is a snapshot of 3.5.10:

Snapshot-3.5.10

I suppose (sigh) I will learn to live with the larger menu pointer arrows, or continue using 3.5.9. In the 3.5.10 change log I found some mention about modifying the handle arrows. However, I have found no information about reducing the size of the black arrow heads.

Anybody have an idea how to configure the size? Or is the new size non-negotiable, as is sometimes typical with KDE developers?

I liked the smaller non-intrusive size.

I run current on a separate partition, but KDE4 not 3.5.10.

In 3.5.9 you can set these handles to fade or, by locking the toolbar, have them disappear entirely.
Not exactly the answer you were looking for, but at least you won't have to look at them.

Right click on the panel (kicker) and select configure panel, then the appearance tab.
Below the section to set transparency is an advanced button. You can select "fade" or "hide" here.

You can choose to lock the panel when you right click on it - same effect as "hide" above I think.

As far as changing the arrow size, it might be related to the font or font size used by the panel, but I would be guessing. It may also be related to dpi setting - another guess.

HTH

Yes, I knew about the fade option. I might have to adapt to that option.

[rant]I get tired of cosmetic changes like this. I wish developers would leave well enough alone. The look-and-feel of a person's desktop is highly subjective and significantly personal. Developers should not force their cosmetic changes upon users without providing user's the option of deciding. Version 3.5.10 likely is the last of the 3.5 series and now I'm probably stuck with the large arrows.[/rant]

I just upgraded my 3.5.9 to 3.5.10 on 12.1 using the -current KDE packages. Not the best practice, but -current is not too far off from 12.1 so I don't expect huge problems. My experiences may be different though as a result.

FWIW, I'm not seeing the same degree of size problems with the arrow. In fact, depending on the style used, I'm not seeing any. I do note that the size seems to be more variable when switching between styles and there are styles where the arrows are far larger than I would like, but still within the confines of the applet handle. Then again, I usually have these fade so I'm not used to paying attention. None are as bad as with your examples.

As I'm running these packages on 12.1 and not current, YMMV.
This "might" be significant (maybe a problem in -current and not a KDE bug) I'll see what I get in -current running the same packages (still not sold on KDE4 )

Steve

OK, running 3.5.10 on -current.

The problem here seems to be limited to the "KDE classic" style.

This seems to be what you are using based on what I see in the pictures, but it's hard to be certain.

My experience here is that using "light style, second or third revision" gives arrows of more appropriate size.

Actually, they all seem to be fine here with the exception of the "KDE Classic" Style

I'm amazed you tracked the problem to the style!

Yes, KDE Classic is what I use. I have been using that style for many years because the style worked best on my-then old hardware. Like the proverbial old pair of jeans, I now am quite comfortable with KDE Classic. Additionally, I don't like the new-fangled styles (Keramkik, Plastik, etc.) or the metallic look.

Okay, I'll play with the other styles. I now have two options although neither is as gratifying as my original configuration.

I really hate when developers are presumptive or fail to test thoroughly.

Me neither. I won't even bother testing KDE4 until all apps are available. By then perhaps the basic desktop will be at version 4.3 or 4.4 and might be fairly bug free. I still run NT4 on my Windows box and VM. I can run 3.5.x for a long time too.