Qt Creator - 'undeclared' error for Qt4 projects
by Syam Krishnan
Hi
I am trying a Qt4 project on Qt Creator on Fedora 29. I get 'undeclared'
errors by the IDE (not the compiler) for pretty much all library
functions/types - both Qt and non-Qt. But compilation and execution work
just fine. Only the IDE shows these errors.
Screenshot here: https://pasteboard.co/HXhWMJZ.png
Any idea on what is wrong?
Thanks,
Syam
5 years, 3 months
Profile corrupt
by Klaus Kolle
My current profile / login on Fedora KDE 29 is corrupted in some parts.
I was thinking of deleting either the .kde or the .config folders (or
rather rename them) in order to let the KDE and programs reinitialise
ther settings. I don't want to delete the whole profile (home
directory), because there are a lot of other things that I would like to
preserve.
My intentions are to move part of the settings back from the backups for
those programs and KDE parts that are not corrupted.
Amongst other problems I see is that LibreOffice doesn't like Danish
letters in file or pathnames. But if I start it from commandline with an
empty env (env -i pgmname) it works well.
Another thing I see is that my computer does not respect the settings
for locking the screen when away for the set period of time and it
doesn't go to sleep some time later.
And there is some other problems as well, but that would be a long list.
The profile has been living for quite some years now, so it is probably
the constant upgrading that may have corrupted it.
Which of the two folders should I rename first - .kde or .config? OR
maybe a totally different.
Thanks
|<
--
Med venlig hilsen
Klaus Kolle
Teknikumingeniør, B.Sc.EE., e-mail : klaus(a)kolle.dk
Master of IT www : www.kolle.dk
Kollundvej 5 Telephone : +4586829682 / +4522216044
DK-8600 Silkeborg, Denmark
"Leave me alone, I know what I'm doing!"
Kimi Räikönen, Abu Dhabi F1 race 2012.
Planlægning er tanker om noget man agter at gøre en gang i fremtiden,
hvis omstændighederne tillader det.
Klaus Kolle 2006
Perfection is achieved not when nothing more to add, but when there is
nothing more left to take away.
Antoine de Saint-Exupery
5 years, 3 months
Updates - A difference of opinion
by Ed Greshko
Yesterday I enabled updates-testing and updated.
This update included kernel-4.19.15-300. Today, dnf and pkcon tell me there are no
packages to update.
However, dnfdragora-updater is telling me there are 5 updates available in the
kernel-4.19.14-300 series.
None of the "refresh" options of dnfdragora clears it out.
So, where is it getting the idea that a lower version of the kernel needs to be install?
--
Right: I dislike the default color scheme
Wrong: What idiot picked the default color scheme
5 years, 3 months
Different approach to KDE and XFCE desktop testing?
by Lukas Ruzicka
Hello KDE and XFCE teams,
I am writing to you on behalf of the Fedora QA team, because you are the
stakeholders of release-blocking desktop environments in Fedora.
We believe that there is need to revisit and review some of the approaches
we
have in desktop testing. I hope that I can clarify in the text.
*How do we test desktop applications?*
Currently, there are three desktop environments, which block the Fedora
releases: GNOME, KDE, and XFCE (on ARM). Among others, there is a test case
called “Desktop Menus” [
https://fedoraproject.org/wiki/QA:Testcase_desktop_menus ] which is used
for all three desktop environments.
*What is the purpose of the Desktop Menus test case?*
The purpose of the “Desktop Menus” test case is to test that applications
listed
in the menu do generally work. That means that each application in the
default
system menu must launch without crashing and withstand basic usage. [2]
*What problems can arise when trying to follow the test case?*
This approach leaves a lot of space for variability, because the terms are
not
clearly given, especially when talking about “basic functionality” of the
desktop applications. In the past, there have been some disputes during
Blocker
Review meetings, or during Go/No go meetings whether basic functionality is
broken or not. It's usually up to group judgement to decide what is a basic
functionality and what it beyond that, which means as testers we need to
err on
the side of doing more testing rather than less.
Testing the “Desktop Menus” test case is one of the most time consuming test
case we currently have. In GNOME, there are currently about 40 applications
in
the default menu and all need to be started and their basic functionality
tested. In KDE, the number of applications is even higher, and some
application
types (like web browsers) are even present as several different
applications.
The scope of this test case also covers testing the subcomponents in the
Control
Center (or a similar equivalent) and, usually, such subcomponents are
numerous.
Testing XFCE on ARM is also rather time consuming, because the ARM devices
we
can use for testing are very slow and there are some application that make
little sense on an ARM motherboard (e.g. a CD writing software). Thus,
doing a
thorough Desktop Menus test case requires a rather longish time frame and we
lose time we could devote to different problems.
Besides that, the test case is also very boring, so it usually gets tested
by
Fedora QA members only, with few inputs from the community. So, before the
Beta
and Final release we are able to do such tests a couple of times, but the
overall coverage is not big.
*What could we do about it?*
At Fedora QA, we have been trying to come up with some ideas to make the
situation a little better than it is now. The goal is that the important
areas
get enough attention and testing they deserve, and we avoid shipping broken
and
under-tested software. See the ideas below and please tell us if you could
adopt
all/some of them, or if you have different suggestions to improve the
current
state, we'd love to hear them too.
- The list of pre-installed applications could be pruned of those which
don't make much sense for that particular purpose (e.g. CD writing software
on ARM, or perhaps on any system nowadays).
- Pre-installed applications could be deduplicated where possible (e.g.
not having several web browsers pre-installed by default).
- We could define a list of "important" applications that would be
tested thoroughly and the basic functionality criterion would apply just to
them. That would tell QA where to focus. (This would obviously contain
applications like system settings, file browser, text editor, browser,
terminal emulator, etc. But e.g. a screenshot utility would probably not
fall into the list. Also, in case of duplicated apps, only one of those
could be marked as "important", and the others would* not). The rest of the
applications would be just best effort in terms of QA, and wouldn't block
the release.
- Last but not least, you could help us more with release validation
before relevant milestones (Beta, Final) :-) If there's anything that
should be improved on our part (communication, instructions, etc), we'd
love to hear that.
Please, let me know what you think about the ideas proposed above. Do you
have
any other ideas that could help us improve the quality (with the same
amount of
testing force)?
Best regards,
--
Lukáš Růžička
FEDORA QE, RHCE
Red Hat
<https://www.redhat.com>
Purkyňova 115
612 45 Brno - Královo Pole
lruzicka(a)redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
5 years, 3 months
