Re: failing initialization of KStandardAction/KConfigWatcher on macos

[Alexander Semke]

On Freitag, 22. September 2023 18:38:31 CEST Alexander Semke wrote:
> Hi,
>
> we've got a problem reported from a user using labplot on macos. The start
> of labplot fails, the application is hanging and the sample of the running
> process points to the following call stack:
>
> Heaviest stack for the main thread of the target process:
>   11  start + 1903 (dyld + 25631) [0x7ff8021a641f]
>   11  ??? (labplot2 + 89750) [0x10e717e96]
>   11  ??? (labplot2 + 501311) [0x10e77c63f]
>   11  ??? (labplot2 + 494708) [0x10e77ac74]
>   11  ??? (labplot2 + 505861) [0x10e77d805]
>   11  KStandardAction::_k_createInternal(KStandardAction::StandardAction,
> QObject*) + 2997 (libKF5ConfigWidgets.5.dylib + 182085) [0x1113df745]
>   11  KStandardShortcut::shortcutWatcher() + 63 (libKF5ConfigGui.5.dylib +
> 76383) [0x10ff97a5f]
>   11  ??? (libKF5ConfigGui.5.dylib + 75750) [0x10ff977e6]
>   11  KConfigWatcher::create(QExplicitlySharedDataPointer
> const&) + 272 (libKF5ConfigCore.5.dylib + 249968) [0x1114b1070]
>   11  ??? (libKF5ConfigCore.5.dylib + 252061) [0x1114b189d]
>   11  QDBusConnection::sessionBus() + 44 (QtDBus + 21452) [0x1116e73cc]
>   11  ??? (QtDBus + 8736) [0x1116e4220]
>   11  ??? (QtDBus + 8902) [0x1116e42c6]
>   11  ??? (QtCore + 2211491) [0x112b5cea3]
>   11  QSemaphore::acquire(int) + 110 (QtCore + 171262) [0x11296acfe]
>   11  QWaitCondition::wait(QMutex*, QDeadlineTimer) + 83 (QtCore + 186499)
> [0x11296e883]
>   11  ??? (QtCore + 186603) [0x11296e8eb]
>   11  __psynch_cvwait + 10 (libsystem_kernel.dylib + 16638) [0x7ff8024c40fe]
> *11  psynch_cvcontinue + 0 (com.apple.kec.pthread + 20884)
> [0xff8003782194]
>
>
> This problem is not reproducible on my MacBook nor was it ever reported
> earlier by any other macos users.
>
> Does somebody has an idea for what can go wrong during the DBus
> initialization in KConfigWatcher::create()?

The problem was "somehow" solved after reinstalling macos on user's macbook...
So, we're good here now and not looking anymore into this weird problem.

--
Alexander

failing initialization of KStandardAction/KConfigWatcher on macos

[Alexander Semke]

Hi,

we've got a problem reported from a user using labplot on macos. The start of
labplot fails, the application is hanging and the sample of the running
process points to the following call stack:

Heaviest stack for the main thread of the target process:
  11  start + 1903 (dyld + 25631) [0x7ff8021a641f]
  11  ??? (labplot2 + 89750) [0x10e717e96]
  11  ??? (labplot2 + 501311) [0x10e77c63f]
  11  ??? (labplot2 + 494708) [0x10e77ac74]
  11  ??? (labplot2 + 505861) [0x10e77d805]
  11  KStandardAction::_k_createInternal(KStandardAction::StandardAction,
QObject*) + 2997 (libKF5ConfigWidgets.5.dylib + 182085) [0x1113df745]
  11  KStandardShortcut::shortcutWatcher() + 63 (libKF5ConfigGui.5.dylib +
76383) [0x10ff97a5f]
  11  ??? (libKF5ConfigGui.5.dylib + 75750) [0x10ff977e6]
  11  KConfigWatcher::create(QExplicitlySharedDataPointer
const&) + 272 (libKF5ConfigCore.5.dylib + 249968) [0x1114b1070]
  11  ??? (libKF5ConfigCore.5.dylib + 252061) [0x1114b189d]
  11  QDBusConnection::sessionBus() + 44 (QtDBus + 21452) [0x1116e73cc]
  11  ??? (QtDBus + 8736) [0x1116e4220]
  11  ??? (QtDBus + 8902) [0x1116e42c6]
  11  ??? (QtCore + 2211491) [0x112b5cea3]
  11  QSemaphore::acquire(int) + 110 (QtCore + 171262) [0x11296acfe]
  11  QWaitCondition::wait(QMutex*, QDeadlineTimer) + 83 (QtCore + 186499)
[0x11296e883]
  11  ??? (QtCore + 186603) [0x11296e8eb]
  11  __psynch_cvwait + 10 (libsystem_kernel.dylib + 16638) [0x7ff8024c40fe]
 *11  psynch_cvcontinue + 0 (com.apple.kec.pthread + 20884)
[0xff8003782194]


This problem is not reproducible on my MacBook nor was it ever reported
earlier by any other macos users.

Does somebody has an idea for what can go wrong during the DBus initialization
in KConfigWatcher::create()?


Regards,
Alexander

D25877: [KColorschemeManager] Add option to reenable following global theme

[Alexander Semke]

asemke added a comment.


  +1

REPOSITORY
  R265 KConfigWidgets

BRANCH
  systemthem (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D25877

To: davidre, #frameworks, ngraham
Cc: ahmadsamir, asemke, kossebau, ngraham, kde-frameworks-devel, LeGast00n, 
GB_2, michaelh, bruns

D25877: [KColorschemeManager] Add option to reenable following global theme

[Alexander Semke]

asemke added inline comments.

INLINE COMMENTS

> davidre wrote in kcolorschememanager.cpp:220
> Should we also do this for the other overloads? Or would that behavior change 
> be a blocker? ALso an application would want to call 
> `KColorSchemeManager::createSchemeSelectionMenu(const QString 
> , QObject *parent)` probably if the custom scheme is saved 
> between launches.

I'm not the author of this code but I don't see why this should be a blocker. 
With this you wouldn't break anything and would simply add more consistency 
across different applications.

REPOSITORY
  R265 KConfigWidgets

BRANCH
  systemthem (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D25877

To: davidre, #frameworks, ngraham
Cc: ahmadsamir, asemke, kossebau, ngraham, kde-frameworks-devel, LeGast00n, 
GB_2, michaelh, bruns

D25877: [KColorschemeManager] Add option to reenable following global theme

[Alexander Semke]

asemke added inline comments.

INLINE COMMENTS

> kcolorschememanager.cpp:220
> +{
> +return createSchemeSelectionMenu(QIcon(),QString(), QString(), parent);
> +}

why not to use reasonable default values here like 
QIcon::fromTheme(QStringLiteral("preferences-desktop-color") and i18n("Color 
Scheme")? This function should be used then by all applications and this will 
help to get a more consistent behavior across the different applications.

REPOSITORY
  R265 KConfigWidgets

BRANCH
  systemthem (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D25877

To: davidre, #frameworks, ngraham
Cc: ahmadsamir, asemke, kossebau, ngraham, kde-frameworks-devel, LeGast00n, 
GB_2, michaelh, bruns

D25877: [KColorschemeManager] Add option to reenable following global theme

[Alexander Semke]

asemke added inline comments.

INLINE COMMENTS

> davidre wrote in kcolorschememanager.h:130
> I thought it would be nice to have as a convenience function if an 
> application has changed the scheme to easily go back to the system color 
> scheme. I don't know if it should be a slot. I put it there because 
> activateScheme is here.

I think the only communication channel with KColorSchemeManager is via the menu 
created in createSchemeSelectionMenu(). Setting back the default scheme will 
also be done via this menu. I don't see why an application would need such a 
helper function - there is simply no other handling of the color schemes in the 
applications except of that menu.

Also, if somebody would still need such a helper function, he/she could use 
activateScheme(QModelIndex()) instead of followSystemScheme(). activateScheme() 
exists already and an empty QModelIndex() could be interpreted as the default 
color scheme.

REPOSITORY
  R265 KConfigWidgets

BRANCH
  systemthem (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D25877

To: davidre, #frameworks, ngraham
Cc: asemke, kossebau, ngraham, kde-frameworks-devel, LeGast00n, GB_2, michaelh, 
bruns

D25877: [KColorschemeManager] Add option to reenable following global theme

[Alexander Semke]

asemke added inline comments.

INLINE COMMENTS

> ngraham wrote in kcolorschememanager.cpp:107
> "Default" is probably fine.
> 
> FWIW the parent menu item is actually mis-named, at least in Kate. It's 
> called "Color Theme" when it should be "Color Scheme"
> 
> Also this menu should be universal, and not re-implemented on a per-app basis.

Yes, was also wrong in LabPlot. Just corrected 
https://invent.kde.org/kde/labplot/commit/262f37b59193ed88bf680b155dc6ecd37bd11419.

We should have maybe in this class only one public function KActionMenu 
*createSchemeSelectionMenu(QObject *parent) which internally sets the string to 
"Color Scheme" and the icon to "preferences-desktop-color". With this we'd 
enforce a consistent look. Or this is menu is automatically created for 
KXmlGuiWindow applications...

REPOSITORY
  R265 KConfigWidgets

BRANCH
  systemthem (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D25877

To: davidre, #frameworks, ngraham
Cc: asemke, kossebau, ngraham, kde-frameworks-devel, LeGast00n, GB_2, michaelh, 
bruns

D25877: [KColorschemeManager] Add option to reenable following global theme

[Alexander Semke]

asemke added inline comments.

INLINE COMMENTS

> kcolorschememanager.cpp:107
>  });
> +m_data.prepend({i18n("System color scheme"), QString(), 
> QIcon::fromTheme("edit-undo")});
>  endResetModel();

Many applications like kdevelop, digikam, labplot, etc. create a menu "Color 
Scheme" in the main menu bar and add then menu item via KColorSchemeManager. By 
using "System color scheme" here we'd have "Color Scheme" -> "System color 
scheme" with this repeated "color scheme" string. Can we simply use "Default" 
or "System" or "Desktop" here?

> kcolorschememanager.cpp:229
>  qApp->setProperty("KDE_COLOR_SCHEME_PATH", index.data(Qt::UserRole));
> -
> qApp->setPalette(KColorScheme::createApplicationPalette(KSharedConfig::openConfig(index.data(Qt::UserRole).toString(;
> +if (index.data(Qt::UserRole).toString().isNull()) {
> +qApp->setPalette(qApp->style()->standardPalette());

if (index.row() == 0) would also do the job and is simpler and faster.

> kcolorschememanager.h:129
> + */
> +void followSystemScheme();
> +

What should be the use-case for this new function and should it really be a 
slot?

REPOSITORY
  R265 KConfigWidgets

BRANCH
  systemthem (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D25877

To: davidre, #frameworks, ngraham
Cc: asemke, kossebau, ngraham, kde-frameworks-devel, LeGast00n, GB_2, michaelh, 
bruns

D23119: Fix dates being on the wrong locale when setting an application language individually

[Alexander Semke]

asemke added a comment.


  In D23119#519676 , @asemke wrote:
  
  > The original problem in LabPlot was reported by a windows user. The 
proposed fix won't fix the problem on windows. I think the only way to get the 
proper strings on Windows is to get the current language of the application, to 
create a QLocale with the proper language and to use QLocale::toString(const 
QDateTime , const QString )... If this is correct, then we're 
are back to my original question I asked on IRC/Matrix - how to determine the 
current application language?
  
  
  @aacid I solved this problem in 7a10577b52504f6466ecaaedefc8db8d84ffc3d9 
. 
This is not really nice but it works and I accept this hack, at least as a 
temporary solution, since we want to do the next release of LabPlot soon...

REPOSITORY
  R263 KXmlGui

REVISION DETAIL
  https://phabricator.kde.org/D23119

To: aacid
Cc: yurchor, apol, kde-frameworks-devel, asemke, LeGast00n, GB_2, michaelh, 
ngraham, bruns

D23119: Fix dates being on the wrong locale when setting an application language individually

[Alexander Semke]

asemke added a comment.


  In D23119#524720 , @aacid wrote:
  
  > In D23119#519676 , @asemke wrote:
  >
  > > The original problem in LabPlot was reported by a windows user. The 
proposed fix won't fix the problem on windows. I think the only way to get the 
proper strings on Windows is to get the current language of the application, to 
create a QLocale with the proper language and to use QLocale::toString(const 
QDateTime , const QString )... If this is correct, then we're 
are back to my original question I asked on IRC/Matrix - how to determine the 
current application language?
  >
  >
  > Are you saying that the old code actually half works on Windows?
  
  
  What works on windows well is switching of the application language in 
general:
  F7349563: labplot_ukrainisch.png 
  
  Here you see the current release candidate running on windows. The windows 
desktop is German, the application language in LabPlot was set to Ukrainian. 
This works well. What doesn't work is the handling of QDate/QDateTime that is 
shown in the menu on this screenshot and marked red. Originally this problem 
was reported to us for the German-English combination (desktop in German, 
application language English).
  
  > I find that surprising since it means that setting the LANGUAGE environment 
variable on Windows does things, which according to a quick internet search 
doesn't seem to be the case
  
  I don't understand the whole mechanism here now but I see that 
kswitchlanguagedialog_p.cpp writes the new language into the new file 
klanguageoverridesrc. The content of this file for the example above is
  
[language]
labplot2=@ByteArray(uk:en_US)
  
  I assume, based on this information, and not on the value of LANGUAGE which 
is not existing on Windows, the i18n-stuff is properly initialized and we show 
the correct strings.
  
  Btw, klanguageoverridesr is put into QStandardPaths::GenericConfigLocation 
which is C:/Users//AppData/Local on Windows.I'd say this is wrong and 
nedds to go into the Roaming folder.

REPOSITORY
  R263 KXmlGui

REVISION DETAIL
  https://phabricator.kde.org/D23119

To: aacid
Cc: yurchor, apol, kde-frameworks-devel, asemke, LeGast00n, GB_2, michaelh, 
ngraham, bruns

D23119: Fix dates being on the wrong locale when setting an application language individually

[Alexander Semke]

asemke added a comment.


  The original problem in LabPlot was reported by a windows user. The proposed 
fix won't fix the problem on windows. I think the only way to get the proper 
strings on Windows is to get the current language of the application, to create 
a QLocale with the proper language and to use QLocale::toString(const QDateTime 
, const QString )... If this is correct, then we're are back to 
my original question I asked on IRC/Matrix - how to determine the current 
application language?

REPOSITORY
  R263 KXmlGui

REVISION DETAIL
  https://phabricator.kde.org/D23119

To: aacid
Cc: yurchor, apol, kde-frameworks-devel, asemke, LeGast00n, GB_2, michaelh, 
ngraham, bruns

D23119: Fix dates being on the wrong locale when setting an application language individually

[Alexander Semke]

asemke added inline comments.

INLINE COMMENTS

> asemke wrote in kxmlgui_unittest.cpp:1089
> This is maybe not Qt but the locale defintion files which are probably distro 
> specific. I just checked on SLES and on openSuse.
> 
> for ukrainian:
> 
>   LC_TIME=uk_UA.UTF-8 locale mon
>   
> січень;лютий;березень;квітень;травень;червень;липень;серпень;вересень;жовтень;листопад;грудень
> 
> for russian:
> 
>   LC_TIME=ru_RU.UTF-8 locale mon
>   
> Январь;Февраль;Март;Апрель;Май;Июнь;Июль;Август;Сентябрь;Октябрь;Ноябрь;Декабрь
> 
> This is, except of capital letters for ru_RU, correct.
> 
> On Mac I get however
> 
>   
> січня;лютого;березня;квітня;травня;червня;липня;серпня;вересня;жовтня;листопада;грудня
> 
> and
> 
>   
> января;февраля;марта;апреля;мая;июня;июля;августа;сентября;октября;ноября;декабря
> 
> which is possessive case and is wrong if you reffer to the name of the month 
> itself.
> 
> @aacid on your distribution you'll most probably get the same output as on my 
> Mac. Under the assumption that Qt evaluates the locale definition files, your 
> test will probably fail on other distributions which do this correctly.

@aacid the discussion about declensions in slawic languages is not relevant to 
your patch I'd say. Maybe it's better to use in the test a language like German 
or any other languages where we don't have this additional complication.

REPOSITORY
  R263 KXmlGui

REVISION DETAIL
  https://phabricator.kde.org/D23119

To: aacid
Cc: yurchor, apol, kde-frameworks-devel, asemke, LeGast00n, GB_2, michaelh, 
ngraham, bruns

D23119: Fix dates being on the wrong locale when setting an application language individually

[Alexander Semke]

asemke added inline comments.

INLINE COMMENTS

> yurchor wrote in kxmlgui_unittest.cpp:1089
> AFAIK this is broken on Qt level. Cf. calendar widget in KOrganizer 
> (Ukrainian)
> 
> F7273188: cal.png 
> 
> https://bugs.kde.org/show_bug.cgi?id=256952
> 
> There are new specifiers for the primary and alternative month names in glibc 
> but Qt does not implement them (must be something like " " instead of 
> " " in formatting). Rafal Luzynski (the author of the glibc patch) in 
> a private message (2018-01-25) promised me to send the patch for Qt but this 
> has not happened yet.

This is maybe not Qt but the locale defintion files which are probably distro 
specific. I just checked on SLES and on openSuse.

for ukrainian:

  LC_TIME=uk_UA.UTF-8 locale mon
  
січень;лютий;березень;квітень;травень;червень;липень;серпень;вересень;жовтень;листопад;грудень

for russian:

  LC_TIME=ru_RU.UTF-8 locale mon
  
Январь;Февраль;Март;Апрель;Май;Июнь;Июль;Август;Сентябрь;Октябрь;Ноябрь;Декабрь

This is, except of capital letters for ru_RU, correct.

On Mac I get however

  
січня;лютого;березня;квітня;травня;червня;липня;серпня;вересня;жовтня;листопада;грудня

and

  
января;февраля;марта;апреля;мая;июня;июля;августа;сентября;октября;ноября;декабря

which is possessive case and is wrong if you reffer to the name of the month 
itself.

@aacid on your distribution you'll most probably get the same output as on my 
Mac. Under the assumption that Qt evaluates the locale definition files, your 
test will probably fail on other distributions which do this correctly.

REPOSITORY
  R263 KXmlGui

REVISION DETAIL
  https://phabricator.kde.org/D23119

To: aacid
Cc: yurchor, apol, kde-frameworks-devel, asemke, LeGast00n, GB_2, michaelh, 
ngraham, bruns

D23119: Fix dates being on the wrong locale when setting an application language individually

[Alexander Semke]

asemke added inline comments.

INLINE COMMENTS

> ltoscano wrote in kxmlgui_unittest.cpp:1089
> Declensions: 
> https://en.wiktionary.org/wiki/%D1%8F%D0%BD%D0%B2%D0%B0%D1%80%D1%8C#Declension

there is no declension in Russian for the nominative case. The name of the 
month is январь and not января, but it is первого января (on January 1st) and 
not первого январь.

https://doc.qt.io/qt-5/qlocale.html#monthName - QLocale must return the name of 
the month, meaning the nominative case  and not one of its declensions.

> aacid wrote in kxmlgui_unittest.cpp:1089
> Yes, it may surprise you, but i did actually run the tests before submitting 
> this code change.

The question was rethoric. I was rather surprised about the validnes of the 
check you did here.

REPOSITORY
  R263 KXmlGui

REVISION DETAIL
  https://phabricator.kde.org/D23119

To: aacid
Cc: apol, kde-frameworks-devel, asemke, LeGast00n, GB_2, michaelh, ngraham, 
bruns

D23119: Fix dates being on the wrong locale when setting an application language individually

[Alexander Semke]

asemke added inline comments.

INLINE COMMENTS

> kxmlgui_unittest.cpp:1089
>  QCOMPARE(QLocale::system().language(), QLocale::Russian);
> +QCOMPARE(QLocale::system().monthName(1), QString::fromUtf8("января"));
>  

does this test work? The name of the month is "январь" in russian, not "января".

REPOSITORY
  R263 KXmlGui

REVISION DETAIL
  https://phabricator.kde.org/D23119

To: aacid
Cc: apol, kde-frameworks-devel, asemke, LeGast00n, michaelh, ngraham, bruns

restore dialog sizes and QTBUG-40584

[Alexander Semke]

Hi,

after having read the documentation of KWindowConfig::restoreWindowSize(), I
understood how to properly restore the dialog sizes. I'm in a process of fixing
this now in LabPlot (20 dialogs or so):

https://cgit.kde.org/labplot.git/commit/?
id=ebfa6b4243dec41b6c656483a57401de4b387793

https://cgit.kde.org/labplot.git/commit/?
id=817125ca5f2c3d1141e52342e9e0239ea9f4f4ed

Basically, the pattern I need to add now everywhere is something like this:

//restore saved settings if available
create(); // ensure there's a window created
KConfigGroup conf(KSharedConfig::openConfig(), "FunctionValuesDialog");
if (conf.exists()) {
KWindowConfig::restoreWindowSize(windowHandle(), conf);
resize(windowHandle()->size()); // workaround for QTBUG-40584
} else
resize(QSize(300, 0).expandedTo(minimumSize()));

I'm wondering why not to move this logic completely into
KWindowConfig::restoreWindowSize() so that in the application code, until
QTBUG-40584 is adressed, we can simply do

KConfigGroup conf(KSharedConfig::openConfig(), "FunctionValuesDialog");
KWindowConfig::restoreWindowSize(windowHandle(), conf);

Were there any arguments against this?

https://bugreports.qt.io/browse/QTBUG-40584 - this one was closed last year
with "Incomplete" even though David actually provided enough information...

--
Alexander

D15076: Build failures with KSyntaxHighlighting 5.49

[Alexander Semke]

asemke added a comment.


  In D15076#315803 , @cgiboudeaux 
wrote:
  
  > In D15076#315797 , @asemke wrote:
  >
  > >
  >
  >
  >
  >
  > > /usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: 
cannot open output file ../../../bin/cantor/backends/cantor_nullbackend.so: Not 
a directory
  > > 
  > >   
  >
  > OK, I can reproduce and ironically, the issue is caused by a fix in 
kcoreaddons to fix build with the commit I mentioned before.
  >
  > Short version:
  >  the cantor stuff uses the  kcoreaddons_add_plugin macro with the 
INSTALL_NAMESPACE parameter pointing to "cantor/backends" This creates a 
cantor/backends subdir in ${CMAKE_BINARY_DIR}/bin/
  >
  > The build fails locally because the linker can't create the cantor 
executable in ${CMAKE_BINARY_DIR}/bin. There's already a directory using the 
same name.
  
  
  I see. Thanks for the explanation. Since there is no urgent need to use for 
ECM 5.49, we can stick to 5.15 for a moment. Or are there any reasons not to do 
so?

REPOSITORY
  R55 Cantor

REVISION DETAIL
  https://phabricator.kde.org/D15076

To: asemke, #kde_edu, #cantor, #frameworks
Cc: cgiboudeaux, mpyne, cullmann, kde-edu, narvaez, apol

D15076: Build failures with KSyntaxHighlighting 5.49

[Alexander Semke]

asemke added a comment.


  In D15076#315583 , @cgiboudeaux 
wrote:
  
  > In D15076#315506 , @mpyne wrote:
  >
  > > I don't know the cause myself but the ECM version works up until 5.38.0 
in my own testing. So presumably the change in behavior is something introduced 
in that release of ECM?
  >
  >
  > Then that's easy: 7af93dd2 

  >
  > Finding why the cantor build fails requires more output (VERBOSE=1 make 
-j1) after removing CMakeCache.txt
  
  
  With this I'm getting
  
[ 25%] Linking CXX shared module 
../../../bin/cantor/backends/cantor_nullbackend.so
cd /home/alex/Projekte/cantor/build_debug/src/backends/null && 
/usr/bin/cmake -E cmake_link_script CMakeFiles/cantor_nullbackend.dir/link.txt 
--verbose=1
/usr/bin/c++  -fPIC -std=c++0x -fno-operator-names -Wall -Wextra 
-Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith 
-Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla 
-Wdate-time -std=c++0x -fno-operator-names -Wall -Wextra -Wcast-align 
-Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef 
-Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time 
-pedantic -Wsuggest-override -Wlogical-op -Wzero-as-null-pointer-constant 
-fexceptions -Wl,--no-undefined -Wl,--fatal-warnings -Wl,--enable-new-dtags 
-Wl,--no-undefined -Wl,--fatal-warnings -Wl,--enable-new-dtags  -shared  -o 
../../../bin/cantor/backends/cantor_nullbackend.so 
CMakeFiles/cantor_nullbackend.dir/nullbackend.cpp.o 
CMakeFiles/cantor_nullbackend.dir/nullsession.cpp.o 
CMakeFiles/cantor_nullbackend.dir/nullexpression.cpp.o 
CMakeFiles/cantor_nullbackend.dir/nullcompletionobject.cpp.o 
CMakeFiles/cantor_nullbackend.dir/cantor_nullbackend_automoc.cpp.o 
../../../bin/libcantorlibs.so.18.11.70 
/usr/lib64/libKF5KIOFileWidgets.so.5.49.0 /usr/lib64/libKF5Bookmarks.so.5.49.0 
/usr/lib64/libKF5Solid.so.5.49.0 /usr/lib64/libKF5KIOWidgets.so.5.49.0 
/usr/lib64/libKF5KIOCore.so.5.49.0 /usr/lib64/libQt5Concurrent.so.5.11.1 
/usr/lib64/libKF5JobWidgets.so.5.49.0 /usr/lib64/libKF5XmlGui.so.5.49.0 
/usr/lib64/libKF5Completion.so.5.49.0 /usr/lib64/libKF5IconThemes.so.5.49.0 
/usr/lib64/libKF5Archive.so.5.49.0 /usr/lib64/libKF5ItemViews.so.5.49.0 
/usr/lib64/libKF5Service.so.5.49.0 /usr/lib64/libKF5ConfigWidgets.so.5.49.0 
/usr/lib64/libKF5ConfigGui.so.5.49.0 /usr/lib64/libKF5ConfigCore.so.5.49.0 
/usr/lib64/libKF5I18n.so.5.49.0 /usr/lib64/libKF5WidgetsAddons.so.5.49.0 
/usr/lib64/libKF5Codecs.so.5.49.0 /usr/lib64/libKF5Auth.so.5.49.0 
/usr/lib64/libKF5CoreAddons.so.5.49.0 /usr/lib64/libQt5DBus.so.5.11.1 
/usr/lib64/libQt5Widgets.so.5.11.1 /usr/lib64/libQt5Gui.so.5.11.1 
/usr/lib64/libQt5Network.so.5.11.1 /usr/lib64/libQt5Xml.so.5.11.1 
/usr/lib64/libQt5Core.so.5.11.1 
-Wl,-rpath,/home/alex/Projekte/cantor/build_debug/bin 
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: 
cannot open output file ../../../bin/cantor/backends/cantor_nullbackend.so: Not 
a directory
  
  This error for cantor_nullbackend.so I always get for the second and later 
make calls. The first fails for cantor_maximabackend.so.

REPOSITORY
  R55 Cantor

REVISION DETAIL
  https://phabricator.kde.org/D15076

To: asemke, #kde_edu, #cantor, #frameworks
Cc: cgiboudeaux, mpyne, cullmann, kde-edu, narvaez, apol

D14434: add functions to access keywords

[Alexander Semke]

asemke added a comment.


  In D14434#300211 , @dhaumann wrote:
  
  > @asemke Are you sure you reference the correct Task? I cannot find anything 
about keyword lists in your link.
  
  
  @dhaumann yes, I'm sure this is the correct task. That task is about the 
refactoring of the "login-mechanism". The "login" should be only done if needed 
or if possible. At the moment the login to some systems has to _always_ be done 
because the list of keywords is fetched dynamically during the runtime - this 
makes T4760  impossible. The keyworkds are 
needed to properly highlight the content. After the move to KSyntaxHighlighting 
we can use static lists of the keywords provided by this library and there is 
no need to login anymore until there is a real need for this, i.e. the user 
starts calculations.

REPOSITORY
  R216 Syntax Highlighting

REVISION DETAIL
  https://phabricator.kde.org/D14434

To: jpoelen, #framework_syntax_highlighting, dhaumann, asemke
Cc: vkrause, cullmann, asemke, kde-frameworks-devel, kwrite-devel, michaelh, 
kevinapavew, ngraham, bruns, demsking, sars, dhaumann

D14434: add functions to access keywords

[Alexander Semke]

asemke accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R216 Syntax Highlighting

BRANCH
  keywordlist

REVISION DETAIL
  https://phabricator.kde.org/D14434

To: jpoelen, #framework_syntax_highlighting, dhaumann, asemke
Cc: vkrause, cullmann, asemke, kde-frameworks-devel, kwrite-devel, michaelh, 
kevinapavew, ngraham, bruns, demsking, sars, dhaumann

D14434: add functions to access keywords

[Alexander Semke]

asemke added a comment.


  In D14434#299932 , @dhaumann wrote:
  
  > In general looks good to me, so +1. I would like to have another +1 from 
@cullmann, @vkrause or @asemke
  
  
  +1
  
  > What I wonder is whether you really need the keyword lists from the 
Definition, or whether you want the currently active keyword lists from the 
current State / Context. I can see that both is useful.
  
  As just replied to the mailing list, both would be useful. But let's do this 
maybe step by step. With this change T4760  
will become possible. After this I'll have a look at how to simplify the 
completion logic in Cantor.

REPOSITORY
  R216 Syntax Highlighting

REVISION DETAIL
  https://phabricator.kde.org/D14434

To: jpoelen, #framework_syntax_highlighting, dhaumann
Cc: vkrause, cullmann, asemke, kde-frameworks-devel, kwrite-devel, michaelh, 
kevinapavew, ngraham, bruns, demsking, sars, dhaumann

Re: how to get the list of keywords in KSyntaxHighlighting

[Alexander Semke]

Hi Dominik,

> sorry for the delay, I only now saw your mail.
> Jonathan meanwhile posted a patch that adds this:
> https://phabricator.kde.org/D14434
Yes, I saw it already. Will this make into the 5.49 release of the frameworks?


> However, pushing this further, what Kate also needs is a way go get
> all keyword lists that are matched in the current context. This allows
> for instance for context based auto completion that Kate also supports.
> 
> Would that be of interest for you as well
I think this makes sense. At the moment there is some custom logic for 
completion in Cantor's code. To refactor all this logic will take more time. 

Now I'd simply remove the manual maintanence of keywords in Cantor like it is 
done for Maxima at the moment (keywords orginally copied from Kate's code). 
For some other "backend systems" like Octave and R the keywords are obtained 
dynamically during the runtime from the backend which makes the presence of 
the actual backend system required, even if the user simply wants to _read_ a 
saved project. This is what I want to re-factor now to make https://
phabricator.kde.org/T4760 possible - the user should be able to read Cantor's 
worksheets without the backend system being present on the target system. 
Moving to KSyntaxHighlighing with the new functions added by Jonathan will 
make this possible.

So, if it's not a big problem to extend the APIs as done by Jonathan now, 
let's go for it even though Cantor is maybe the only consumer of this APIs 
now.


Thanks and Regards,
Alexander

how to get the list of keywords in KSyntaxHighlighting

[Alexander Semke]

Hi,

I'd like to remove the maintenance of syntax keywords in Cantor (e.g. https://
cgit.kde.org/cantor.git/tree/src/backends/maxima/maximakeywords.cpp) and to 
switch to KSyntaxHighlighting.

Cantor uses its own highlighters and I'd need to get the list of keywords from 
KSyntaxHighlighter for this (constructor in https://cgit.kde.org/cantor.git/
tree/src/backends/maxima/maximahighlighter.cpp). If I see it correctly, 
DefinitionData holding the keyword lists is not part of the public API. I don't 
see how to get the list of keywords.

Ideally, there should be something like

QStringList Definition::keywordListsNames() const;

to get the list of available section in the xml syntax file and

QStringList Definition::keyworkList(const QString& name) const;

to get the actual keywords for the specified section.


Would this make sense or is there already another way to get the keywords?


Regards,
Alexander 

D13643: Add LabPlot project file icon

[Alexander Semke]

asemke added a comment.


  Thank for this work. It looks nice to me. However, maybe it's better for 
people from VDG and Breeze teams to accept this or to raise objections.

REPOSITORY
  R266 Breeze Icons

REVISION DETAIL
  https://phabricator.kde.org/D13643

To: mtrescott, #labplot, #vdg, #breeze
Cc: asemke, ngraham, kde-frameworks-devel, michaelh, bruns

Crash on windows when resetting the toolbar items to the default values

[Alexander Semke]

Hi,

https://bugs.kde.org/show_bug.cgi?id=387610

we've got this bug reported, happens on windows only. Can somebody check this 
with another KF5-application on windows? Any ideas what is causing this crash?

Thanks and Regards,
Alexander

proposal to extend and to improve KColorSchemeManager

[Alexander Semke]

Hi,

I recently switched from using Digikam's code for the handling of color 
schemes in the application to KColorSchemeManager in LabPlot [1].

It works, but there're couple of things that I miss:

* "Default"-entry in the color scheme menu to easily switch to the 
default desktop color scheme
* save the settings for the selected color scheme and load the proper 
scheme on start
* automatically set the corresponding action in the scheme menu checked 
for the used color scheme on start
* include couple of "kf5 default" color scheme definition files as part 
of KF5 so the application don't need to provide them on their own

* standard name and icon used for the color scheme menu title
* main menu bar and QMdiArea don't get updated on color scheme changes. 
For QMdiArea I added a "hack" in LabPlot now [1], the problem with the 
menu bar still remains.


At the moment it looks to me like different applications (digikam, 
kdevelop, krita, labplot, kstars, etc.) take care of these points on 
their own or don't handle them at all.
It would be great to provide this kind of functionality in a central 
place. This would also help to provide a common behavior for all 
KF5-based applications.


Any thoughts on this?


Regards,
Alexander

[1] 
https://cgit.kde.org/labplot.git/commit/?id=c609edcb6255242ea25ad81ff6601061edcbe57f

Re: save and restore the geometry of KMainWindow

[Alexander Semke]

On 01.02.2018 20:52, Albert Astals Cid wrote:

El dimarts, 30 de gener de 2018, a les 21:06:02 CET, Alexander Semke va
escriure:


The state is already saved and restored there. Why not to do the same
for the geometry?

I think that it's generally frowned upon putting your position on screen
because it means "you know too much".

Basically it's supposed to be the window manager task, not your app.
And if the window manager doesn't do this the user has to move their 
windows around again upon start?
Especially when working on big displays where the user wants to have 
certain placements for different programs
it would be helpful also to restore the position on the screen 
automatically.


The size is being restored, at least for a couple of programs I checked 
(konsole, kwrite, dolphin). Is this done by kwin?
I don't think there is a big practical difference from the user 
perspective between "restoring the size" and "restoring the position"

with respect to "you know too much"...


--
Alexander

Re: save and restore the geometry of KMainWindow

[Alexander Semke]

On 30.01.2018 16:38, Milian Wolff wrote:

This works for me:
https://github.com/KDAB/hotspot/blob/4d1177d1631902dce1dd82f53553e97a7544b1fa/
src/mainwindow.cpp#L162
Thanks, that helped. I was using 
restoreGeometry(group.readEntry("geometry").toLatin1()) instead of


restoreGeometry(group.readEntry("geometry", QByteArray())) ... Hotspot 
is a nice tool by the way :-)


Why not to add this logic to KMainWindow and to make this automatically 
available for all/many KDE applications?


The state is already saved and restored there. Why not to do the same 
for the geometry?


--

Alexander

Re: save and restore the geometry of KMainWindow

[Alexander Semke]

resending this to kde-devel...


On 28.01.2018 18:45, Alexander Semke wrote:

Hi,

KMainWindow takes care of saving/restoring the state of the main 
window, menus and toolbars.
Also, the size of the main window is correctly stored and restored. 
However, I don't see how
to save and restore the position of the main window. I checked couple 
of KDE programs
like dolphin, konsole, etc. - nothing restores the last window 
position correctly. I also tried to
to do saveGeometry() to KConfigGroup in the destructor and to 
restoreGeometry() in
the constructor but this doesn't seem to work. Is this because of the 
window manager ignoring
the geometry hints as mentioned in 
http://doc.qt.io/qt-5/application-windows.html#window-geometry ?


Can somebody point to an application doing this correctly?

Thanks and Regards,
Alexander

save and restore the geometry of KMainWindow

[Alexander Semke]

Hi,

KMainWindow takes care of saving/restoring the state of the main window, 
menus and toolbars.
Also, the size of the main window is correctly stored and restored. 
However, I don't see how
to save and restore the position of the main window. I checked couple of 
KDE programs
like dolphin, konsole, etc. - nothing restores the last window position 
correctly. I also tried to
to do saveGeometry() to KConfigGroup in the destructor and to 
restoreGeometry() in
the constructor but this doesn't seem to work. Is this because of the 
window manager ignoring
the geometry hints as mentioned in 
http://doc.qt.io/qt-5/application-windows.html#window-geometry ?


Can somebody point to an application doing this correctly?

Thanks and Regards,
Alexander

Re: Default location of the settings file on windows when using KXmlGuiWindow/KMainWindow

[Alexander Semke]

On 12.12.2017 13:13, Kåre Särs wrote:

On måndag 11 december 2017 kl. 21:55:23 EET Albert Astals Cid wrote:

El dijous, 7 de desembre de 2017, a les 22:13:21 CET, Alexander Semke va

escriure:

Hi all,

https://bugs.kde.org/show_bug.cgi?id=387626
we've got this problem reported and I don't see how to easily fix this.
LabPlot's MainWindow inherits from KXmlGuiWindow. When saving the auto
settings in KMainWindow, KSharedConfig::openConfig() is used which uses
QStandardPaths::GenericConfigLocation for the location:
https://api.kde.org/frameworks/kconfig/html/classKSharedConfig.html#a32820
86 49f2e3f0ee895c9b11aa82205

According to the problem description in this ticket, I assume this is a
valid request since it makes a lot of sense to me, we have to use
QStandardPaths::AppDataLocation for the location of the config file. Do
I need to set here KMainWindow::setAutoSettings() with a KConfig having
the proper name and location? I'd actually expect this to be done by the
underlying framework(s)...

We read the settings in many places via KSharedConfig::openConfig()
which also defaults to the same rc file under
QStandardPaths::GenericConfigLocation. For all our custom and
application specific settings we can of course provide AppDataLocation
explicitely but this also looks to me like not the most optimal solution
since we'd need to touch the code at many places. How is this handled in
other KF5-applications? Can somebody share some best practices here?

You may try the kde windows list if noone answers here.

Actually I think kde-frameworks-devel would be a better place to take this up.
(CC:ing)

One problem is that we have have used GenericConfigLocation long before
AppDataLocation was introduced and there would be backwards compatibility
problems if we directly would just switch to AppDataLocation.
How about checking first whether the rc-file already exists in 
GenericConfigLocation? If it already exists, use it. If not, create a 
new one in AppDataLocation.
With this we shouldn't run into backward compatibility issues and should 
be fine (i.e. using the roaming folder) with the new default location 
for new users.



--
Alexander