File extension filters in KFileDialog currently behave differently under Windows when using Native dialogs as follows:
1. Filters are sorted. For applications that have a usual filetype (for example, a text editor that usually opens .txt files) this is extremely annoying as the default filter becomes the alphabetically first one (in the previous example, something like .doc would thus become the default since it comes before .txt). Normal Windows apps don't do this and KDE doesn't do this under Linux or with non-native dialogs, so there's no reason for it to do so with native dialogs enabled. 2. Extensions that aren't all lower case are simply thrown out. For example, if you say "*.PDF|PDF Files", it will be completely ignored. 3. Anything in parens is thrown away with no warning or indication given to the developer. This patch (apply against trunk/KDE/kdelibs) fixes all that by: 1. Not sorting the filter list. 2. Converting all extension to lower case. Personally I think they should just be passed on verbatim since that's what KDE does, but I can see the argument for removing filters that only differ in their capitalization. 3. Changing ( and ) to [ and ], thus keeping Qt happy and keeping the original text relatively intact. I would just commit this but it seems that sorting of the filters was added specifically in r893509 so I thought I'd check here to see if anyone could provide a decent reason why. Personally I find it very annoying and everyone I've talked with on IRC has agreed that it's a little odd and goes against the basic principle that developers using KFileDialog::getOpenFileName (and related) shouldn't get non-cosmetic differences in behavior due to platform and native/non-native preferences. Rob
kfiledialog.patch
Description: Binary data
_______________________________________________ Kde-windows mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-windows
