the soft MIME matching via KMimeType::is() is way too.. soft. it can match
application/x-dvi as plain/text (and use ps thumbnailer) which is not ideal
(should use only textthumbnail thumbnailer for plain/text and ps
thumbnailer for application/x-dvi)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
so that the uic tool does not generate code that uses variables with
the name of the private KMediaWidget class (KMediaWidgetPrivate)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
who tought using the same shortcut for multiple actions is going to work?
the single character shortcuts are very likely to conflict with other
shortcuts aswell
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
the reason for checking the preffered offers first should be obvious - it
is questionable which match should be done first. should it be the glob or
the exact match? chicken and egg thing
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
mostly to make the MIME types check consistent by using KMimeType::is()
for the comparison (as done by KPreviewPropsPlugin::supports() for example)
and to filter the ThumbCreator service type (to avoid invalid KMimeType
checks)
fixed KFileMetaInfo regression for plugins that use globs aswell
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
none of the plugins support it and it slows down the thumbnail
preview generation (or fetching of existing thumbnail)
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
previously autoloaded modules would be loaded in arbitrary order regardless
of what phase they are ment for from Kded::initModules() but phase two
should be done by ksmserver
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
if it is false then modules that are not ment for full session are not
automatically loaded on init so it shall serve as a hint when debugging
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
with commit de8c7f6af1d79c6b3cd3e8b2a21a56a020163b73 (in kde-workspace) I
changed the behaviour of favicon KDED module to not down-scale the favicons
to 16x16 and that ofcourse means large favicons (e.g. 256x256, yes some
websites have favicon with such size) may be overlayed on top of 32x32 icon
which does not look OK.
with this change the icon overlay will match the visual ratio of any
other icon overlay, unfortunetly that means scaling the favicon (i.e. for
large icons such 256x256, favicon with size 16x16 may be up-scaled to 32x32
) but it will still look better than it used to
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
it cannot be detached even if not copied (as done when it is not in
QImage::Format_ARGB32 format) because image is constant reference but if it
is converted it will be actually detached, also QByteArray takes ownership
of the data
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
why does a method named reloadStyleSettings reload graphics effects level
settings and not application style settings?
Signed-off-by: Ivailo Monev <xakepa10@gmail.com>
