[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

[shevegen]

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

--- Comment #105 from shevegen  ---
> It is a great DE and the developers don't mess with root access.

I myself use icewm but I use some great KDE applications such as
konsole. Okular is also fine. I don't use KDE5 myself, largely because
it became too much of a hassle to compile it from source. I can compile
most of it but then "startx" no longer works; it crashes soon after it
tries to load. KDE3 worked fine; I have no idea why the quality
decreased so much. For the record I can compile from source and use
startx for icewm, fluxbox, mate-desktop, xfce, lxqt. Somehow the big
DEs moved towards Average Joe - which is ok in itself, but they also
dumbed things down for the power users immensely. No idea why
the KDE devs joined that - perhaps economic reasons. See GNOME.

The issue in regards to pestering the superuser is deeper, though and
not solely confined to kio or any individual component. I could not
use kate as the superuser. I read the code and in the CPP source code
there are a few lines #define - so the whole application is deliberately
and maliciously crippled via ~5 lines. You remove it, then recompile
and it works fine. Other editors don't have this crippling aspect. I
have no idea why the kate devs went that route. I tried to explain to
them that it is utterly stupid to cripple functionality that works perfectly
well. The proper use may be to show a warning but continue to use
rather than this "I won't start at all because YOU ARE A BAD BOY".

I decide for my own anyway and other editors work fine so why is
some random average joe KDE dev thinking he knows it all better?
To the point of crippling functionality? The usual "argument" used is
"because YOU COULD KILL PEOPLE" aka "damage your system". I
could not care any less about it. I care about devs crippling my system
randomly and arbitrarily - that part is annoying. THAT is the big
problem with both KDE and GNOME - individual devs who think they
are right and then subject and subjugate the downstream users.

This point is made even worse by the fact that it's just a few crappy
#defines. I mean IF you really want to restrict the super user because
you hate the super user then at the least write beautiful code that
restricts this RATHER THAN THIS CRAP FEW #define STATEMENTS that
are an insult to any 8 years old that can use an editor as-is.

There used to be a work around for kate via an ENV variable. I tried
it - and it did not work. That was years ago. I then complained about
it. At first it seemed to effect change, but then, whoever is calling
the shots, decided that KDE is now going for the Average Joe and
Average Joe is never ever allowed to be super user. Ever. For
whatever the reason (again, I don't understand it, but these devs
cater to the average joe, and they have a point too - we power users
are in the minority now. Everything has been dumbed down and
the restrictions to cripple functionality in regards to the superuser
is PRECISELY one example of this dumb-down trend. And it will
continue, we all know that. The bigger the DE, the more and more
dumbed down it will be - just look at GNOME for where KDE is
headed. Note: I have nothing against simplifications or usability
improvements. What I have something against is the attempt
to restrict and cripple users deliberately rather than assume
that they know better and can decide for their own - and yes,
we can decide, but not when topdown developers want to coerce
others into their world view. And THAT is the fundamental problem.)

On Wed, Oct 27, 2021 at 10:44 AM lega99  wrote:

> https://bugs.kde.org/show_bug.cgi?id=179678
>
> --- Comment #104 from lega99  ---
> (In reply to Bo Weaver from comment #103)
> > (In reply to petrk from comment #102)
> > > That revert was stuck for a year. I don't see it going anywhere with
> > > dissatisfied users being called "vocal minority".
> > >
> > > I'm not speaking for myself, as I don't mind doing stuff via terminal.
> > > However, KDE lately was aiming more towards new users. Why would they
> be
> > > forced to learn their way around console, or to keep different file
> manager
> > > just to edit some files in restricted areas?
> >
> > I wrote about this back in 2019 and they aren't going to listen.  The
> > developers here seem to know better than you and me and are protecting us
> > from ourselves.  My best fix found is XFCE.  It is a great DE and the
> > developers don't mess with root access.  BTW I was a KDE user since the
> 90's
> > and finally gave up.
>
> Never finished the story, happiness there is a Krusader, so it is possible
> to
> start this file manager in root mode with sudo. Sometimes a great program
> Dolphin is nothing now. Discover the same hour works or doesn't work or
> nee

[konsole] [Bug 426344] New: [UI change / Feature request] Please (re)consider adding a simple "Rename Tab" functionality, above the "Close" Functionality, upon a right-click mouse button press event o

[shevegen]

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

Bug ID: 426344
   Summary: [UI change / Feature request] Please (re)consider
adding a simple "Rename Tab" functionality, above the
"Close" Functionality, upon a right-click mouse button
press event on a tab in KDE Konsole.
   Product: konsole
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: wishlist
  Priority: NOR
 Component: tabbar
  Assignee: konsole-de...@kde.org
  Reporter: sheve...@gmail.com
  Target Milestone: ---

I am running konsole 20.08.1 right now, compiled from source at:

   
https://download.kde.org/stable/release-service/20.08.1/src/konsole-20.08.1.tar.xz

(I show the source so that this is not assumed to be a package-issue on
any distribution xyz; it is the vanilla source from upstream KDE. I tend
to stick to it without trying to make any modifications in general.)

Upon trying to rename the KDE konsole tab, via the right-click
mouse button press event, triggering a popup-widget, I get
these entries:

Detach Tab
Current Tab Settings
Close

Close is quite simple to understand, and comes last, which makes sense to me.

Detach Tab I consider fairly useless but I don't mind really.

I actually tried to get a context menu entry point called "Rename Tab".

My memory may fail me, but wasn't there such an entry point available
in the past? I can rename the tab when I click on "Current Tab Settings",
and then on "Tab Title Format", but this requires two steps, whereas I
am almost sure that in the past a single step was enough.

My suggestion is:

- Could the "Rename Tab" be either brought back, or in the event that
it never existed in prior konsole versions (my memory is REALLY bad,
sorry), could it be added? I would suggest it to be situated above
"Close". Evidently putting "Close" on the bottom there makes sense,
so the only space would be above the "Close" entry point.

I also find it a bit strange, conceptually, to have users associate
"Rename Tab" with changing "Tab Title Format" - I don't quite want
to change the format, I only wanted to change the title of the tab
as-is. Or perhaps such an option exists and it was not compiled when
I batch-compiled KDE from source.

The above is really just a minor issue. I actually VERY rarely manually
rename tabs; I use ruby scripts. One uses qdbus (in the past dcop) to
quickly rename the tab e. g.

rti Hello world!
rti --unicode-snowman # We actually can use icons and
  # unicode in the konsole tab; KDE konsole
  # beats gnome-terminal with its eyes closed \o/

Now you may rightfully ask "if you have a commandline script, why use
a GUI?" Yep, you are right in about 99.5% of the cases, but sometimes
I need to also make use of the GUI specifically. And that was one of
the cases. The reason was actually that I had data from a file displayed
via "cat bla.md", and I needed to write down that information onto a 
hard DVD, to keep track of some of the file content there (e. g. 
linux distributions). And by default, my ruby script shows the particular
qdbus command too (makes it easier to quickly copy/paste). I could
of course add --silent to that commandline script, but I'd still have to
hit enter and when you need to actually copy data from a computer to 
something like a DVD, when you also have multiple tabs to work with
at the same time (and KDE konsole is not the only application with
multiple tabs, e. g. palemoon typically has multiple tabs here too),
then you sort of don't want to touch/modify a particular KDE konsole
tab until you have finished that task. That is why in such a particular
case, I actually move that KDE tab to the very right side, so that I 
keep track of it, and have its content be as closely attached to the
bottom area in that tab as possible. I am not sure if that setup
makes sense to anyone else, but I almost use KDE konsole like a
mini-tabbed-WM. :)

Unfortunately I don't have an old copy of KDE konsole (I tend to
quickly clean up and remove old variants the moment I can compile
new stable KDE releases, which these days happens very well; almost
all the old issues I had in the last ~2 years went away, excluding
a few exceptions that may not be solely related to KDE itself), so
I can not easily test whether older KDE konsole releases showed
the same behaviour, or whether this was changed. I believe IF it
was changed, the reasoning behind that change could be reconsidered.

Worded differently: I don't mind more options, even if I don't use
them, but options that I think useful and that may be removed, I
do mind. Ideally we could have KDE transition into a totally 
user-customizable set of widgets, at all times, but I understand
that this is not within the scope of this suggestion - it's just
an idea. (I had very difficult 

[systemsettings] [Bug 426063] New: Please consider improving the "The shared library was not found" error message, in particular with a way for the user to obtain more information about this, e. g. no

[shevegen]

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

Bug ID: 426063
   Summary: Please consider improving the "The shared library was
not found" error message, in particular with a way for
the user to obtain more information about this, e. g.
notifying them what exactly could not be found
   Product: systemsettings
   Version: 5.19.5
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: plasma-b...@kde.org
  Reporter: sheve...@gmail.com
  Target Milestone: ---

Hello KDE devs and everyone who may read such bug reports or issue
requests,

I think I may have reported something similar before, in other KDE
widgets.

At any rate, my issue is with this error message here specifically:

"The shared library was not found."

See the following picture:

https://i.imgur.com/eoQa7r3.png

This is from systemsettings5, on a black KDE konsole background;
I chopped it up quickly to just show the problem. The problem
is on the right side: "The shared library was not found"

The URL I was using, just to provide this info as well, was 
this:

https://download.kde.org/stable/plasma/5.19.5/systemsettings-5.19.5.tar.xz

I should add that I batch-compile all of KDE from source, so with
the today's release of a new plasma, I am compiling stuff again. So
I may have multiple different versions on the computer, since when
I am lazy, I just compile into /usr/ as the main prefix, even though
I also use a versioned AppDir layout sometimes (see GoboLinux for
this, such as /Programs/Htop/2.2.0 - do note that they have not
been able to keep up with KDE5 though. The last KDE release on
GoboLinux was KDE3.)

As a consequence of me compiling from source, on a modified 
slackware/zenwalk base system, I encounter some issues now and
then with KDE5 - not so much during compilation usually, but
lateron, such as when trying to start kwin from oldschool 
runlevel init 3, but also in using specific individual 
applications. Some work very well, such as KDE konsole or
okular; others work less well, or are a bit strange, such
as the systemsettings5 binary.

This feature request here is such an example for the "lateron"
problem - that is problems that show up when running the 
application at hand.

In regards to systemsettings5, some parts of this widget work
really fine, without problems, such as "Shortcuts". See the
above screenshot what is meant; that widget is shown
decently and it works.

"Window Behavior" also works fine - shows everything.

But other parts, such as "Display and Monitor", do not work,
and instead show a generic "The shared library was not found".

This message, as we can all agree, is almost TOTALLY useless.
Because it tells me NOTHING. I have to ask here: "what shared
library exactly was not found?". I mean, it is better than
nothing, but still quite useless. I assume that it refers to
some installed component that may be too old or not 
compatible, but I'd still like to know WHAT exactly is the
issue. As it is right now, the message "The shared library
was not found" is about as useful as "Aliens have taken 
over your computer and rendered it useless" - although one
could reasonably argue that that message is better than 
"The shared library was not found", because at the least
it identified SOME Aliens as being behind the culprit.
With systemsettings, though, we are currently left in the
dark.

I have noticed this, by the way, in other widgets too - 
in okular in the past, for example. So I assume that
this is more related in general to how KDE wants to 
present information to end users. I am fine if you
assume that the default end user is Average Joe, so you
may not want to burden him with too much information -
but then there should be an OPTIONAL way to query more 
information, and ideally in a per-widget or per-application
centric way because not everyone may use KDE5. I use
mostly individual KDE5 applications. (I'd use KDE5, but
I can not successfully start it, but this is a separate
issue not related to the issue request here. Note that
I can compile mate-desktop from source, and run it from
inittab runlevel 3 just fine. Some problems may also 
originate from qt5, such as qml-related problems, but
I don't want to make this issue request here too off-topic.
My primary point is for usability improvements and better
error reporting WITHIN KDE5/Plasma itself.)

On the commandline I may typically do "ldd" on some binary,
and if some shared object is missing, I tend to get some
message there, such as "missing /usr/lib/libtarzan.so"
or something like this. (Could be better too, but I 
digress here as well).

Anyway - I hope I could explain the use case leading to the
above issue request. What I would like to see here specifically
is that the error message "shared library" becomes MORE
SPECIFIC.

[Breeze] [Bug 421637] New: [breeze-icons] Some small build problem, but it goes away if one uses a separate build dir, and -DBUILD_TESTING=OFF -Wno-dev (URL: https://download.kde.org/stable/framework

[shevegen]

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

Bug ID: 421637
   Summary: [breeze-icons] Some small build problem, but it goes
away if one uses a separate build dir, and
-DBUILD_TESTING=OFF -Wno-dev (URL:
https://download.kde.org/stable/frameworks/5.70/breeze
-icons-5.70.0.tar.xz )
   Product: Breeze
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: Icons
  Assignee: visual-des...@kde.org
  Reporter: sheve...@gmail.com
CC: kain...@gmail.com
  Target Milestone: ---

Hey there KDE devs,

I would like to report a possible bug. I write "possible" because I
am not 100% sure if it is a bug. It is actually a compile-related
problem. I will explain this in a moment in more detail.

The program this report is about is called "breeze-icons".

I have used the following URL for this:

https://download.kde.org/stable/frameworks/5.70/breeze-icons-5.70.0.tar.xz

I compile all the KDE components from source, via ruby, an I would
like to state that things have improved a LOT in the last ~3 years
or so. From release to release I run into fewer and fewer problems.
A few problems are caused by my own noobness; but other problems
are at the least partially related to errors in some build script
or some other setup. Anyway.

When I write a "possible bug", I also actually mean that I managed
to compile breeze-icons successfully just now.

The variant that works fine for me is the variant used by the
LFS/BLFS team, and is briefly shown here:

http://www.linuxfromscratch.org/blfs/view/svn/x/breeze-icons.html

The two relevant factors here are, IMO, that they:

1) use a separate build directory

and

2) Use a specific commandline option, being:

cmake -DCMAKE_INSTALL_PREFIX=/usr -DBUILD_TESTING=OFF -Wno-dev ..

So when I did NOT use the two options "-DBUILD_TESTING=OFF
-Wno-dev", I run into this problem (I have indended this
4 spaces to the right):

[ 88%] Generating res/breeze-icons.qrc
Error copying directory from "/Depot/jjj/breeze-icons-5.70.0/icons" to
"/Depot/jjj/breeze-icons-5.70.0/icons/res"

So some copy-operation fails. IF I use a build directory
AND these two configure options to cmake, then the
program compiles without error.

I just did another compile-try again, and I can confirm
that I do not run into this problem with the above 
options; but without them, I run into these problems.
So I am quite sure that there is some small error in
the build-process. Maybe that it should require a 
separate build-dir, or maybe that it needs these
options, or perhaps both.

Either way I thought it may be best to report this.

I know too little about cmake to understand which
part of the copy-directory action fails.

I assume that I personally will not run into this
problem anymore, since it compiles fine for me now,
but if someone else runs into this I wanted to 
mention it. Perhaps a separate build-directory 
should be enforced by breeze-icons, I can not say
(I am not an expert when it comes to Makefiles or
cmake-build files, sorry). Anyway, that's my report,
keep up the improvements to the build setup - it 
actually helps a LOT the fewer problems there are,
in particular for distributions with a lack of 
manpower (such as GoboLinux; when I manage to 
compile the whole KDE suite, I can try to help
the GoboLinux guys, but it is of course easier
when things work with as few problems as possible,
out of the box; and as said, things did improve a 
lot over the last few years. I still remember the
KDE 4 days ... that was painful).

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kdelibs4support] [Bug 417197] New: Allow more fine-tuning of --version (or adding new options)

[shevegen]

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

Bug ID: 417197
   Summary: Allow more fine-tuning of --version (or adding new
options)
   Product: frameworks-kdelibs4support
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: wishlist
  Priority: NOR
 Component: general
  Assignee: kdelibs-b...@kde.org
  Reporter: sheve...@gmail.com
  Target Milestone: ---

This is a slight feature request, or rather, a change.

As-is situation:

We can usek

"kf5-config --version"

to find out the version of KDE5.

On my system, this command produces these results:

"QStandardPaths: wrong ownership on runtime directory /home/Temp, 99 instead of
0
QStandardPaths: wrong ownership on runtime directory /home/Temp, 99 instead of
0
QStandardPaths: wrong ownership on runtime directory /home/Temp, 99 instead of
0
Qt: 5.14.0
KDE Frameworks: 5.66.0
kf5-config: 1.0"

So 6 lines, split at a newline each.

The first three can be ignored, although in many cases I have no need for it to
tell me that there is a "wrong" ownership - it is not really relevant to me,
but this is besides the point.

The problem I have is that the --version flag returns 3 results. Most of the
time, though, I am only interested in the second line aka KDE Frameworks.

I use this in a ruby script to find out the version of programs on the local
computer system in general.

I do NOT suggest to change the current default - if people like it and rely on
it, that is fine. What I do, however had, suggest is to fine-tune the above,
and in particular allow a new commandline flag that will only return the
version string ode KDE Frameworks, such as:

"kf5-config --kde-frameworks-version"
"kf5-config --kdeframeworks-version"
"kf5-config --frameworks-version"

^^^ or something like this, and the returned string be:

5.66.0

To reduce downstream processing.

It is not a big deal because I can adapt the ruby code either
way, but a minor problem is that querying via kf5-config takes
a little time; it is a bit slower than, say, "grep --version".

So one goal of this is to make the above a bit faster, since
I would not need to determine the qt-version or anything
else. (Perhaps this may be the wrong application to file for,
but which other commandline variant can tell us the version 
of KDE on the computer system? I am fine with an approximation
by the way, no need to query all components from the commandline;
or I just write a ruby script that does so, but right now
I am more focused on a simple one-version solution).

Thanks for reading and considering - it has a very low priority
so I added it to the wishlist. On the other hand, I believe
this is not so difficult to add.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 411524] New: A suggestion to change font style listing to default to "regular" rather than "bold" or "italic", upon choosing a new font

[shevegen]

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

Bug ID: 411524
   Summary: A suggestion to change font style listing to default
to "regular" rather than "bold" or "italic", upon
choosing a new font
   Product: konsole
   Version: 19.08.0
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: font
  Assignee: konsole-de...@kde.org
  Reporter: sheve...@gmail.com
  Target Milestone: ---

This is not a "bug report", per se, but a slight feature
request; or, more accurately, a request to change a current
default behaviour.

Situation:

You can pick another font in KDE Konsole. I am using
19.08.01, compiled from source on linux. It works fine.

I typically use the font called "Hack". When I quickly
select this font, the drop-down listing for "Font Style"
has "italic" listed first, then "Bold Italic", then
"Bold", and then "Regular".

So I tend to not read what is written, assuming that
this refers to regular, so I select it. But instead I
wanted to pick "regular" instead.

I thus have two ALTERNATIVE suggestions to make:

- Either sort that list alphabetically, so that "bold
italic" and "bold" comes before "italic", then "regular".

The same would apply for "Fonts". I am not sure why it
is not sorted alphabetically. 

- Or, alternatively, my preference, would be to list 
there, at the least at font styles, regular as the
most commonly used setting, and default it to the top
listing. I may be wrong but I think this used to be
an old default, since I tend to re-use my old habits.
But I am not 100% certain.

Either way I think most users will prefer e. g. regular
over italic; and also regular over bold. Bold is not
that bad, but italic is ... quite annoying, IMO. I
think only very few users will prefer italic over
regular, so it may be better to have regular valued
over bold or italic.

At any rate I believe this may require a bit discussion
to reason in favour of the current default, or any
change in general, so that we can avoid ad-hoc changes
here. Something should be the default, so perhaps the
current behaviour also has some reasoning, although
I am not sure which one it would be.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 408417] New: [Feature request for okular] - Please consider adding a "save-as" .pdf file for .epub files, even if it is a lossy conversion

[shevegen]

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

Bug ID: 408417
   Summary: [Feature request for okular] - Please consider adding
a "save-as" .pdf file for .epub files, even if it is a
lossy conversion
   Product: okular
   Version: 1.7.2
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: EPub backend
  Assignee: okular-de...@kde.org
  Reporter: sheve...@gmail.com
  Target Milestone: ---

Hello okular (and kde) devs,

In the last some years I have noticed the .epub format increasing. I understand
the reasons why .epub is used more, but I am having some problems with this
format; in particular it takes quite some time for it to open in okular here,
much more so than typical .pdf files with the same amount of pages.

This is my primary use case for this request, actually - I would prefer .pdf
files in this case. (Or do the conversion into .pdf, while keeping the .epub
file as well)

So, I am just opening a few .epub files right now in okular and I notice the
"Save as" option - but we can only save as .epub or okular document format,
unfortunately.

I would like to ask whether it would be possible to add a "to pdf" save as
operation
here, for okular.

I am totally fine if not everything can be saved when an .epub is converted
into a .pdf
file, I really just need plain oldschool .pdf files. A warning/notification
could be issued
to the user if this is the case, so that the user may know that not everything
can be 
converted; that way other users would know that this is a lossy exchange, but
it would 
still be a new possibility for okular.

Perhaps even a commandline-only way for this operation, then I could use e. g.
ruby to
call system() and batch-convert the .epub files through okular. (Evince does
not even
have support for .epub files, which I find strange; yes, .epub is not like
.pdf, but
people use it in a VERY similar way if you ask me. On the GNOME bugtracker some
of
the devs pointed out to use something else, such as calibre. I think the
approach
taken by okular is better and I actually think that evince will eventually get
.epub support, despite what these individual devs stated otherwise.)

Anyway, not sure whether this is wanted or would be too much work for okular,
but I
guess since the KDE stack + okular already handles .pdf and .epub, perhaps a
"save
as .pdf format" option may be something to consider for the future.

Thanks for reading! Please disregard if it is unwanted functionality or may
be too difficult to add; I understand time constraints. It just seems like
a good time right now considering that okular has been quite active in 
seeing changes (the recent annotation changes for example).

-- 
You are receiving this mail because:
You are watching all bug changes.

[Breeze] [Bug 407527] Breeze icons needed for kcachegrind, kxstitch, knights, and smb4k

[shevegen]

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

shevegen  changed:

   What|Removed |Added

 CC||sheve...@gmail.com

--- Comment #12 from shevegen  ---
I like the change + icons; the new KDE site for applications looks better.

I hope you can extend the page in the future, also in regards to the
information
shown being up-to-date; the old page had this problem of mentioning application
that no longer existed, or existed in kde4 era only.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 407879] [KDE Konsole 19.04.1 - strange behaviour] "New Tab ->" shows a total listing of ... one entry, which must be selected

[shevegen]

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

--- Comment #1 from shevegen  ---
This image may help - easier to understand the problem I think:


https://i.imgur.com/R3S9jjG.png

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 407879] New: [KDE Konsole 19.04.1 - strange behaviour] "New Tab ->" shows a total listing of ... one entry, which must be selected

[shevegen]

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

Bug ID: 407879
   Summary: [KDE Konsole 19.04.1 - strange behaviour] "New Tab ->"
shows a total listing of ... one entry, which must be
selected
   Product: konsole
   Version: 19.04.1
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: tabbar
  Assignee: konsole-de...@kde.org
  Reporter: sheve...@gmail.com
  Target Milestone: ---

Linux OS here, KDE konsole compiled from source, version 19.04.1

All works sorta ok ...

I have defined a custom profile for my preferred KDE konsole.

Now the strange thing is - if I click on:

File -> New Tab

then the name of that single profile appears. I then have to select that
profile with the mouse cursor/pointer, in order to open a new tab.

What confuses me here is ... if the total selection is one (1), then
what is the point of me having to select on that single entry? I mean
if I already can not do any selection with the mouse, then why does
KDE konsole show me that one selection that I then have to click?

That makes no sense to me. Surely anyone thinking about this may come
to the same conclusion - what is the exercise here for the user, shall
the user train how to select a single entry in this dropdown-widget?

It may be that something was buggy or so; I think I had more than one
profile before, but since I only ever need a single profile, I always
remove all but one profiles. (Might be that a default profile keeps
on re-appearing but I personally really only want one profile and 
consider more than one profile confusing and an antifeature for me
personally).

Anyway. My suggestion is quite simple:


- Only show a DROP DOWN when there are AT THE LEAST TWO possibilities
to choose from. Personally I actually don't need this at all, since
I only want a single profile; but a more elegant solution could be
to mark this as an auto-pick solution or something, or some setting
(but I would recommend no setting here, as this may keep it simpler;
I am just providing alternatives to the current forced manual selection)

Right now I only have a single entry to choose from, and it is a bit
pointless to have to click on this single entry - I can not even click
on anything else there, so why is that even appearing at all ... it means
I have to make an additional step.

I can not say whether this is new or not, largely because I actually
dont even want to have any of this. ;)

(Normally I open tabs via the keyboard anyway but sometimes I use to
mouse to focus back on KDE konsole from my browser, so this is where I
may then use the mouse instead.)

I selected tabbar but I am not sure if this is the right name - I refer
to the tab bar on the top menu widget e. g. where you can open a new
tab.

If someone considers this to be a feature, I would be curious about
the explanation for when there is only a single entry (I understand
it when there are more entries, but not when there is a single
entry; although even when there are multiple entries, I actually think
it is cumbersome to want to select another entry IF the user defaults
to a specific variant already).

IF a setting is considered then I would recommend to default to "ignore
the case when there are fewer than two possibilities/entries". This
might solve the issue altogether while still allowing for flexibility -
not sure if anyone uses this option, but better be safe than sorry in
the event that others may depend on it, even if I consider it overall
to be not too terribly useful.

Thanks for reading.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 406661] New: konsole version 19.04.0 - compiled just now. Does the display of icons no longer work?

[shevegen]

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

Bug ID: 406661
   Summary: konsole version 19.04.0 - compiled just now. Does the
display of icons no longer work?
   Product: konsole
   Version: master
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: tabbar
  Assignee: konsole-de...@kde.org
  Reporter: sheve...@gmail.com
  Target Milestone: ---

I am not sure if I have found a bug/regression or not.

So here is the behaviour:

In KDE konsole 18.12.3 when I send this to a tab:

\e]32;utilities-terminal\a

I get the terminal-icon that appears to be the default,
on the left hand side of the tab at hand.

IF I do the very same on KDE konsole 19.04.0, no permanent
change appears to happen. Something appears to flicker but
then seems to be instantly reset.

The net result is that on konsole 19.04.0 I am not able to
change the icon, whereas on konsole 18.12.3.

I do not know if this is a bug or not or some side effect.
Although I think IF this is indeed how I describe, then I
think this is a bug; or a regression. IF it is a deliberate
change, it may be useful to mention it in the official 
announcement, and suggest to users how to change or what
to change in order to be able to change the icon.

I should perhaps also explain how I found out:

- I noticed that each tab now has a close button and I wanted
to try this out. I tried it out and realized that I do not
like this functionality because it occupies too much space
per tab (I use a custom .css file for the kde konsole tabs,
to visually distinguish between active tabs and inactive tabs,
and I use lots of icons for different kde konsole tabs, via
some ruby script. I then looked at editing kde konsole settings
and there is, thankfully, a setting that allows us to disable
the close button per tab. I did this, and then I tried to 
use another icon on the kde konsole tab and it did not work.
Not sure if this is just me or whether this is indeed a bug,
but I can guarantee to 100% that this behaviour works on 
18.x 100%. It does not seem to work on 19.x, at the least not
with my testing so far - didn't test it for long evidently since
the kde application release is out since only a few hours or so
at best.

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 406496] New: Okular 1.6.3 shows slightly peculiar behaviour with "german umlauts" (Umlaute) part of the directory name - and refuses to load the .pdf file at hand

[shevegen]

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

Bug ID: 406496
   Summary: Okular 1.6.3 shows slightly peculiar behaviour with
"german umlauts" (Umlaute) part of the directory name
- and refuses to load the .pdf file at hand
   Product: okular
   Version: 1.6.3
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: minor
  Priority: NOR
 Component: general
  Assignee: okular-de...@kde.org
  Reporter: sheve...@gmail.com
  Target Milestone: ---

Hello KDE developers,

I believe I have found a small bug; or, if it is not a bug, then at the least
it is
behaviour that is ... a bit confusing to me.

I should note that I have tried to open a specific .pdf file, and this failed;
I will
explain soon how this happened, but allow me to mention very early on that the
.pdf
file viewer called "evince", works under the very same situation. Okular on the
other
hand, does not work.

Now - I believe the issue is partially related to Encoding. In particular I am
not
using any Unicode/UTF* encoding, but instead I use the ISO encoding 8859-1.

I have a directory structure such as the following:

   
/Users/x/STUDIUM/TU_WIEN/166.212_Einführung_in_die_Biotechnologie_und_Bioverfahrenstechnik/2019/

Don't mind this so much; this is mostly a german lecture, thus "umlauts" are
part
of this. I do not rename these directories because they are automatically
created,
and the schemata for the script that does so, is to start with the LVA ID of
the
lecture at hand; and then the name of the lecture. So in this case, an umlaut 
must be part.

I am using the KDE konsole and I am in the directory that I just mentioned.

In this directory there is a single .pdf file, which has been merged of all
local .pdf files, and the name that I gave to this file was:

Alle_Folien_2019.pdf

Now - using "evince Alle_Folien_2019.pdf" works fine, the files are displayed
via evince. There are some warnings/errors on the commandline, due to encoding
issues (also within the .pdf itself), but it still opens fine and I can work
with it.

IF, however had, I use okular like this:

okular Alle_Folien_2019.pdf

Then okular shows this error message:

Could not open
file:///Users/x/STUDIUM/TU_WIEN/166.212_Einf�hrung_in_die_Biotechnologie_und_Bioverfahrenstechnik/2019/Alle_Folien_2019.pdf

I am not sure if you can see the problem, but the "ü" character, right
between the "Einf" und "hrung" part in the above file path, is displayed
improperly and, I think, incorrectly.

My LANG variable is set to en_US.ISO-8859-1 and within KDE konsole I
have, under the "advanced" tab, set the local encoding to ISO-8859-1.

I also tested changing this setting in KDE konsole to UTF-8, but the
same error appears.

Anyway - I hope this error description is useful. Now I will try to 
reason why I think this behaviour is a bug; or confusing.

First, what confuses me is that okular requires the absolute path.
I only provided the filename to okular, and I am right in that very
directory. So IF the faulty behaviour is due to the full pathname,
I think it may be better to not include a faulty pathname if we can
avoid it (and if the user provided that exactly). I can understand
that the current behaviour may be better in most cases - an absolute
path can be a lot easier to work with, for instance. I use that in
my own scripts a lot too. But in the example here, I believe this 
leads to the manifestation of that bug, where I now, as a user, have
no simple way to load the .pdf file via okular. As said, evince works
fine (but I don't know if evince makes use of a full path or not).

Either way, this is not exactly the main issue.

The main issue, in my opinion, is that okular chokes on that path
completely. KDE konsole works fine here and I can change, rename,
remove, create, files, directories, symlinks etc... all with umlauts
just fine. It works very well on my system. Evince works too - what
does not work is okular.

Now, it is actually trivial for me to work around - I just move that
.pdf file to a path that has no umlauts. And then it works. :)

So I know that this .pdf file works fine via okular; okular only
chokes on the umlauts part.

How to reproduce this?

Well, hopefully the above gave enough information, but perhaps for
those who may want to try it:

- Set all relevant settings to any ISO such as ISO-8859-1 or
some other variant like ISO-8859-2 or something like that.
- Perhaps also change LANG, and, most importantly, ensure that
KDE konsole has this setting too.
- Create some strange directory path, such as /tmp/foo/bar/aäa/
and then put some .pdf file into that directory that works.
- Navigate towards that directory via "cd", and then do
"okular *pdf" (or the name of the .pdf file at hand)

I believe this should reproduce the problem. Hopefully, because
other than that I have no idea how others could reproduce it.

I'll also 

[konsole] [Bug 180770] Provide a quadkonsole like interface

[shevegen]

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

shevegen  changed:

   What|Removed |Added

 CC||sheve...@gmail.com

--- Comment #31 from shevegen  ---
Great!

I also only noticed this very old report here due to Nate writing about.

So a few things:

- I remember having used Quadkonsole many years ago too and it was very nice.

I was also using yakuake and yakuake is quite cool on its own.

A few months or so I tried out the konsole split-view (or whatever it was
called) and the behaviour confused me completely, since I expected it to be
more to quadkonsole; and possibly to yakuake (although I can not say whether
there are marked differences, but from my limited testing, the behaviour in
yakuake in regards to splitting/modifying the views/panes, was less confusing
than in KDE konsole).

I have not yet tested the changes - so I rely mostly on what Nate wrote at
https://pointieststick.com/2019/03/31/kde-usability-productivity-week-64/ - but
from the screenshot, it indeed seems to be a lot closer to what quadkonsole
originally did. I can't say yet whether both seem to do the same (my memory is
also dim) but the change seems to be a LOT closer in making KDE konsole behave
more similarly to quadkonsole. So I wanted to add this perspective too, even if
it is ... hmm + 10 years late. But better a late comment than no comment.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 404255] [Feature request] Please consider making it possible to add some border/border-colour property to a KDE konsole tab

[shevegen]

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

--- Comment #1 from shevegen  ---
Sorry for the strange line wrappings - that html field here is a strange thing
...

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 404255] New: [Feature request] Please consider making it possible to add some border/border-colour property to a KDE konsole tab

[shevegen]

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

Bug ID: 404255
   Summary: [Feature request] Please consider making it possible
to add some border/border-colour property to a KDE
konsole tab
   Product: konsole
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: tabbar
  Assignee: konsole-de...@kde.org
  Reporter: sheve...@gmail.com
  Target Milestone: ---

This is a feature request. It has probably very low priority, but I would still
like to suggest
it.

I would like to suggest to add the possibility to add a border property to a
KDE konsole tab.

By default no border is used, so we need a boolean to distinguish it:
true/false, yes/no (has
border).

IF true, then a short border is displayed. I suggest minimal pixel size e. g.
1px. The user
may be able to customize this via an option field in preferences. By default,
no border is
selected. (Tooltip hint may inform the user that, if enabled, a border will
appear.)

Do note that this border will appear ONLY around the current active tab! That
is, the one
that is currently selected. Optionally a colour should be pickable, e. g. red
or crimson
or any such colours (RGB values perhaps; a KDE widget can appear to pick a
colour here).



Use case:

- I use KDE konsole a lot and I am quite happy with it. I should add that I do
not really
make use of the kde title in a tab. That is, my tab titles are very often
either "." for
blank; or contain something longer to indicate what this tab is doing.

I rename these tabs via scripts, from the commandline, so picking "." was the
second
best option next to "" empty (I believe a KDE konsole tab can not be "" empty?
But
either way, whether it is empty, or "." or some other single small character,
is 
pretty irrelevant to me - the point is that I don't want to see the title
there.)

This usage makes it a bit hard to find out which tab is the currently active
one.

That is the major reason why I would like to suggest some VISUAL indicator of
which
tab is currently active. I suggest a border, and I will probably keep it in
small
crimson-colour like 1px or so, to not disturb me. But other options may also be
possible - for example, the currently selected tab could be visually a bit
lighter,
or something like that. I am open for alternatives too! So please consider my 
feature request more as something generic rather than the specifics I have
written
above (but I had to pick something so that we can start a discussion).

Anyway if this is not wanted, I suggest closing it; perhaps at the latest in
2-3
years, so that this does not become a never-ending suggestion. :)

The ability to choose a colour can be optional. I think a slight border without
a specific colour would help too - right now I can not really instantly find
out which tab is the current active one (I usually then just use keyboard
shortcut to keep on working with e. g. tab 2 tab 3 tab 4 etc keyboard
shortcuts are also alt+1 for the first one, alt+2 for the second tab, and
so forth. I use up to 20 tabs or so; more is too difficult to manage; 
fewer than 6 is quite useless though. My typical range is between 11-19
or something like that)

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasmashell] [Bug 403367] New: Can not compile plasma-desktop 5.14.90 (also I could not find an entry called plasma-desktop so I filed this here)

[shevegen]

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

Bug ID: 403367
   Summary: Can not compile plasma-desktop 5.14.90 (also I could
not find an entry called plasma-desktop so I filed
this here)
   Product: plasmashell
   Version: master
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: Desktop Containment
  Assignee: se...@kde.org
  Reporter: sheve...@gmail.com
CC: plasma-b...@kde.org
  Target Milestone: 1.0

Linux system.

GCC is: g++ (GCC) 8.2.0

I used this URL:

http://download.kde.org/unstable/plasma/5.14.90/plasma-desktop-5.14.90.tar.xz

The compilation stops at about 41%:

[ 41%] Built target org.kde.plasma.kickoff-plasmoids-metadata-json
Scanning dependencies of target org.kde.plasma.trash-plasmoids-metadata-json
[ 41%] Generating org.kde.plasma.trash-plasmoids-metadata.json
About to parse service type file
"/usr/share/kservicetypes5/plasma-applet.desktop"
Found property definition "X-Plasma-API" with type "QString" 
Found property definition "X-Plasma-RootPath" with type "QString"  
Found property definition "X-Plasma-MainScript" with type "QString"
Found property definition "X-Plasma-ContainmentType" with type "QString" 
Found property definition "X-Plasma-DropMimeTypes" with type "QStringList"  
Found property definition "X-Plasma-DropUrlPatterns" with type "QStringList"
Found property definition "X-Plasma-NotificationArea" with type "QString"
Found property definition "X-Plasma-NotificationAreaCategory" with type
"QString" 
Found property definition "X-Plasma-DBusActivationService" with type "QString" 
Found property definition "X-KDE-ParentApp" with type "QString" 
Found property definition "X-Plasma-Provides" with type "QStringList" 
Found property definition "X-Plasma-PreloadWeight" with type "int" 
Found property definition "X-Plasma-ConfigPlugins" with type "QStringList"  
Found property definition "X-Plasma-StandAloneApp" with type "bool"
Found property definition "X-Plasma-RequiredExtensions" with type "QStringList"
Found property definition "NoDisplay" with type "bool" 
Generated 
"/Depot/Temp/rbt/plasma-desktop-5.14.90/BUILD_DIRECTORY/applets/trash/org.kde.plasma.trash-plasmoids-metadata.json"
 

[ 41%] Built target org.kde.plasma.trash-plasmoids-metadata-json
Scanning dependencies of target trashplugin_autogen
[ 41%] Automatic MOC for target trashplugin
[ 41%] Built target trashplugin_autogen
Scanning dependencies of target trashplugin
[ 41%] Building CXX object
applets/trash/plugin/CMakeFiles/trashplugin.dir/dirmodel.cpp.o
/Depot/Temp/rbt/plasma-desktop-5.14.90/applets/trash/plugin/dirmodel.cpp: In
member function 'virtual QVariant DirModel::data(const QModelIndex&, int)
const':
/Depot/Temp/rbt/plasma-desktop-5.14.90/applets/trash/plugin/dirmodel.cpp:156:98:
warning: this statement may fall through [-Wimplicit-fallthrough=]  
const_cast(this)->m_filesToPreview[item.url()] =
QPersistentModelIndex(index); 
  ^ 
/Depot/Temp/rbt/plasma-desktop-5.14.90/applets/trash/plugin/dirmodel.cpp:158:5:
note: here 
  default:
  ^~~ 
[ 41%] Building CXX object
applets/trash/plugin/CMakeFiles/trashplugin.dir/trash.cpp.o
[ 41%] Building CXX object
applets/trash/plugin/CMakeFiles/trashplugin.dir/trashplugin.cpp.o
[ 41%] Building CXX object
applets/trash/plugin/CMakeFiles/trashplugin.dir/trashplugin_autogen/mocs_compilation.cpp.o
[ 41%] Linking CXX shared library ../../../bin/libtrashplugin.so
[ 41%] Built target trashplugin
Scanning dependencies of target taskmanagerplugin_autogen
[ 42%] Automatic MOC for target taskmanagerplugin
[ 42%] Built target taskmanagerplugin_autogen
Scanning dependencies of target taskmanagerplugin
[ 42%] Building CXX object
applets/taskmanager/CMakeFiles/taskmanagerplugin.dir/plugin/backend.cpp.o
[ 42%] Building CXX object
applets/taskmanager/CMakeFiles/taskmanagerplugin.dir/plugin/draghelper.cpp.o
[ 42%] Building CXX object
applets/taskmanager/CMakeFiles/taskmanagerplugin.dir/plugin/taskmanagerplugin.cpp.o
[ 42%] Building CXX object
applets/taskmanager/CMakeFiles/taskmanagerplugin.dir/plugin/smartlaunchers/smartlauncherbackend.cpp.o
[ 42%] Building CXX object
applets/taskmanager/CMakeFiles/taskmanagerplugin.dir/plugin/smartlaunchers/smartlauncheritem.cpp.o
[ 42%] Building CXX object
applets/taskmanager/CMakeFiles/taskmanagerplugin.dir/taskmanagerplugin_autogen/mocs_compilation.cpp.o
[ 42%] Linking CXX shared library ../../bin/libtaskmanagerplugin.so
[ 42%] Built target taskmanagerplugin
Scanning dependencies of target
org.kde.plasma.taskmanager-plasmoids-metadata-json
[ 42%] Generating org.kde.plasma.taskmanager-plasmoids-metadata.json
About to parse service type file
"/usr/share/kservicetypes5/plasma-applet.desktop"
Found property definition "X-Plasma-API" with type "QString" 
Found property definition "X-Plasma-RootPath" with type "QString"  
Found property definition 

[kinfocenter] [Bug 403077] New: [Very simple feature suggestion for] Kinfocenter: commandline showing the content of the copy-to-clipboard generated string

[shevegen]

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

Bug ID: 403077
   Summary: [Very simple feature suggestion for] Kinfocenter:
commandline showing the content of the
copy-to-clipboard generated string
   Product: kinfocenter
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: All KCMs
  Assignee: hubn...@gmail.com
  Reporter: sheve...@gmail.com
  Target Milestone: ---

I would like to extend the commandline options for kinfocenter with one new
entry.

The kinfocenter GUI currently has a click-button called "Copy to Clipboard".

This is quite useful as it allows us to copy that output to e. g. some website,
like
here in the textview/textarea HTML widget. Currently we have to start the
kinfocenter widget for this, though.

I propose a new commandline flag, also shown in --help, that would "dump",
aka show, the very same information that is normally copied via that button
onto the commandline.

The name I suggest would be:

--paste-clipboard
or just
--paste

(or both).

The output would be exactly the same as via the copy-to-clipboard functionality
such as:


Operating System: Slackware 14.2
KDE Plasma Version: 5.14.5
Qt Version: 5.12.0
KDE Frameworks Version: 5.53.0
Kernel Version: 4.4.14
OS Type: 64-bit
Processors: 4 × AMD A8-7600 Radeon R7, 10 Compute Cores 4C+6G
Memory: 14.6 GiB of RAM

This should be an easy change because the functionality currently
already exists, assumingly, since the generation of that string
must be tied to the action when a user clicks the button copy-to-clipboard,
which already works as is.

I am not sure if the functionality is wanted by the KDE developers/maintainers
but I think we can already gain that information when we start the GUI as-is;
so
the only change proposed here is to be able to do so from the commandline
alone too, without starting the GUI.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kinfocenter] [Bug 403011] New: kinfocenter crashes when clicking on some tabs, if kirigami is not available

[shevegen]

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

Bug ID: 403011
   Summary: kinfocenter crashes when clicking on some tabs, if
kirigami is not available
   Product: kinfocenter
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: Energy Information
  Assignee: k...@privat.broulik.de
  Reporter: sheve...@gmail.com
  Target Milestone: ---

I compiled kinfocenter from this URL:

https://download.kde.org/stable/plasma//5.14.5/kinfocenter-5.14.5.tar.xz

Compilation worked fine.

I then started it - starting was fine.

I then clicked on the first tab called "About System". This worked fine,
no problem.

I then clicked on the second tab called "Memory". This also worked fine.

I then clicked on "Energy Information" and the moment I clicked this,
the kinfocenter application crashed.

On the commandline (I started it from the commandline) I can see this:

---

org.kde.kcoreaddons: Error loading plugin "kcm_energyinfo" "The shared library
was not found." 
Plugin search paths are ("/usr/lib64/plugins", "/Programs/Qt/5.12.0/plugins",
"/usr/lib64/qt5/plugins", "/usr/bin") 
The environment variable QT_PLUGIN_PATH might be not correctly set
virtual QStringList Solid::Backends::UPower::UPowerManager::allDevices() 
error:  "org.freedesktop.DBus.Error.Disconnected"
Error connecting to wakeup data changes via dbus
QQmlComponent: Component is not ready
:2:1: module "org.kde.kirigami" is not installed
Segmentation fault

---

I believe the error is that I have not installed kirigami. I will
try this next, but either way I believe that this application
should NOT segfault like that.

Clicking on the next tab also crashes the application.

org.kde.kcoreaddons: Error loading plugin "kcm_fileindexermonitor" "The shared
library was not found." 
Plugin search paths are ("/usr/lib64/plugins", "/Programs/Qt/5.12.0/plugins",
"/usr/lib64/qt5/plugins", "/usr/bin") 
The environment variable QT_PLUGIN_PATH might be not correctly set
QQmlComponent: Component is not ready
:2:1: module "org.kde.kirigami" is not installed
Segmentation fault

By the way on a side note, the message  "kcm_fileindexermonitor"
"The shared library was not found." is not super useful to me.

Can you guys also give the name of the shared library? It would
make it easier for me to find where it is since I register the
components locally; but this is an aside. I believe there should
be a prior check whether kirigami is available or not; and if not
then I would recommend displaying this in a widget somehow. Could
be a simple text, or with some red colours or something if you
want to get fancy - I believe showing the problem is better than
segfault. 

My host system:

  Operating System:  GNU/Linux
  Os Bit Type:   x86_64
  CPU Model: AMD A8-7600 Radeon R7, 10 Compute Cores
4C+6G, 2 cores
  CFLAGS in use: -O2 -fPIC -fno-strict-overflow -Wno-error
  RAM:   15313688 kB RAM (14954.8 MB) (14.6 Gig)
  Gcc Version:   8.2.0
  Glibc Version: 2.23
  Linux Kernel:  4.4.14
  Binutils Version:  2.31.51.20190105
Using Qt version 5.12.0 in /Programs/Qt/5.12.0/lib

-- 
You are receiving this mail because:
You are watching all bug changes.

[okular] [Bug 402268] New: Improve okular's error reporting when being unable to open .pdf files ("Okular component: The shared library was not found.")

[shevegen]

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

Bug ID: 402268
   Summary: Improve okular's error reporting when being unable to
open .pdf files ("Okular component: The shared library
was not found.")
   Product: okular
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: PDF backend
  Assignee: okular-de...@kde.org
  Reporter: sheve...@gmail.com
  Target Milestone: ---

Hello.

I am trying to use okular to read a local .pdf file, on my Linux system.

I should state that I compiled Qt from source, and all of KDE. For example, KDE
Konsole I compiled and it works fine (URL was:
https://download.kde.org/stable/applications/18.12.0/src/konsole-18.12.0.tar.xz
)

I was using this okular version:

https://download.kde.org/stable/applications/18.12.0/src/okular-18.12.0.tar.xz

The compilation worked without an error too.

When I try to start it, I get this:

"org.kde.kwindowsystem: Could not find any platform plugin"

And there is some kde-widget or something with this text:

"Unable to find the Okular component: The shared library was not found."

To me this is not very helpful. So I suggest to improve this message and the
handling of this altogether.

First, it currently states "The shared library was not found", but WHAT
is this shared library? The name appears to be missing.

I would suggest to include the name - either in the same sentence, or in
a sentence below. I have more than enough space in that widget so hit
me with more information. :)

When I know the name of the .so at hand, it makes it easier to google 
too; right now it is A BIT DIFFICULT to google for "the shared library
was not found".

I don't know enough of the internals of qt, kde or okular to know what
is going on. Perhaps the problem is in qt? Perhaps in some other kde
component. I have no idea. So my second suggestion is to expand
on the error message a little bit.

For example, something like:

"Qt is handling .pdf support, so make sure that bla-lib and bla-something
are installed and working".

Or if it is another KDE component, passing that information would help
too. 

The more information I have, the higher the chance that I can resolve
this problem but right now I am a blind man tumbling about the complexity
of KDE. Evince works out of the box but I read about the latest change
in okular for annotation so I wanted to try this out.

The awkward thing is that I am absolutely sure that months before
okular was working fine so I know that I have been doing something
wrong; but there is no trivial way for me to find out what (I also
compiled okular from source before when it worked).

Thanks for reading and considering.

PS: The error message improvements shown above do not necessarily have
to be implemented 1:1 - what is more important to me is that this
information can somehow be passed to me in a simple way, no matter 
how it is to be done. Could be a notification during the build time
too; or additional checks there. But I think the widget showing more
information would be a very simple addition and wouldn't be too 
confusing for other users either, since all we would show is additional
information (e. g. why I suggested to use another sentence, but the
name could of course also be shown in the one sentence only. Not sure
if there is a limit in how many sentences you guys want to show ... :P)

-- 
You are receiving this mail because:
You are watching all bug changes.

[kmail2] [Bug 399245] Restore UI functionality related to "Show HTML side bar"

[shevegen]

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

shevegen  changed:

   What|Removed |Added

 CC||sheve...@gmail.com

--- Comment #8 from shevegen  ---
(In reply to Christophe Giboudeaux from comment #6)
> I can close as duplicate of the other bug report where most comments can be
> reduced to "+1" if you prefer.

While you could reason that way, the problem is that the other thread has lots
more comments than the one here, so this is not ideal for discussions.

I think it may have been better to mark the original one as a feature request
and keep it open. Nobody would force xyz or you to work on it - it would just
be one feature request of many more (or, in the event that it removed existing
functionality, a regression, in which case the question is whether developers
should have a higher right to modify code that affects the users, and I think
the users should have a higher right if it comes to any functionality that has
been working at some point. Losing functionality is always bad.).

-- 
You are receiving this mail because:
You are watching all bug changes.

[kate] [Bug 400940] New: [Feature suggestion] kate embed konsole (aka, optionally a konsole-widget somewhere

[shevegen]

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

Bug ID: 400940
   Summary: [Feature suggestion] kate embed konsole (aka,
optionally a konsole-widget somewhere
   Product: kate
   Version: 18.08.3
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: wishlist
  Priority: NOR
 Component: general
  Assignee: kwrite-bugs-n...@kde.org
  Reporter: sheve...@gmail.com
  Target Milestone: ---

This is a feature suggestion for kate, the editor.

I accidentally clicked on the submit button before I could finish (I actually
first write content in my editor, then paste it into the textview widget here;
but when I typed the summary, I was trying to see if there was a duplicate, and
I thought I could find it but somehow I ended up misclicking ... and now I
can't find it again ... :\ :/)

This feature suggestion is to ask whether it may be possible to embed a widget
with KDE konsole within kate - ideally on bottom, but a user could decide
where.

The editor geany has a similar functionality, in that it allows you to embed a
vte-terminal, which is quite convenient. I'd love to have this for kate too.

I assume that it should not be too difficult to embed konsole into kate, since
I think yakuake embeds konsole already, so the code should be all there.

That leaves of course two questions:

(1) Whether the feature suggestion here has any merit or usability on its own.

I believe it may be useful to be able to use a konsole terminal within kate,
since some developers
may want to do so. It should be disabled by default so that most users do not
have this by
default - but there should be some option, perhaps under "advanced" or
something like that, where
a user could enable this.

(2) Whether there is someone willing and able to do implement this if (1) is
approved.

I do not know how difficult this task would be, but I believe it should not be
too difficult
since other applications, such as yakuake, do this already. (I do not know C++
that well to 
know how to do this myself.)

PS: I may have overlooked this functionality already existing, in which case it
could perhaps be made more prominent in the preferences setting or somewhere,
for a user to enable/disable this.

The options confuse me a little bit right now.

If this is not a good suggestion, please just close it. I suggest to keep this
issue open
not longer than a year at max, so as to not clutter the tracker database (when
I searched for
this I found suggestions that were almost 10 years old, which I think is way
too old, so I would
prefer this issue to be closed after a while either way.)

Thank you for reading!

-- 
You are receiving this mail because:
You are watching all bug changes.

[kate] [Bug 400939] [Feature suggestion] kate embed konsole

[shevegen]

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

shevegen  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REPORTED|RESOLVED

--- Comment #1 from shevegen  ---
Oops sorry - I clicked on the wrong button before I could finish. Hmm ... I
will try to close this ...

-- 
You are receiving this mail because:
You are watching all bug changes.

[kate] [Bug 400939] New: [Feature suggestion] kate embed konsole

[shevegen]

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

Bug ID: 400939
   Summary: [Feature suggestion] kate embed konsole
   Product: kate
   Version: 18.08.3
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: kwrite-bugs-n...@kde.org
  Reporter: sheve...@gmail.com
  Target Milestone: ---

SUMMARY


STEPS TO REPRODUCE
1. 
2. 
3. 

OBSERVED RESULT


EXPECTED RESULT


SOFTWARE/OS VERSIONS
Windows: 
MacOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-nm] [Bug 400219] Trying to compile plasma-nm fails for me (5.14.2) - due to qca-qt5

[shevegen]

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

--- Comment #1 from shevegen  ---
I noticed from another bug report to try
https://download.kde.org/stable/qca/2.1.3/src/ but that also fails for me,
probably because I am using
openssl 1.1.1:

/usr/include/openssl/rand.h:44:1: note: declared here
 DEPRECATEDIN_1_1_0(int RAND_pseudo_bytes(unsigned char *buf, int num))

I guess I will downgrade openssl and give it a try again but will only
do so tomorrow.

-- 
You are receiving this mail because:
You are watching all bug changes.

[plasma-nm] [Bug 400219] New: Trying to compile plasma-nm fails for me (5.14.2) - due to qca-qt5

[shevegen]

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

Bug ID: 400219
   Summary: Trying to compile plasma-nm fails for me (5.14.2) -
due to qca-qt5
   Product: plasma-nm
   Version: master
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: jgrul...@redhat.com
  Reporter: sheve...@gmail.com
  Target Milestone: ---

Hey KDE team,

I am trying to compile the latest plasma stuff.

Using this URL:

https://download.kde.org/stable/plasma/5.14.2/plasma-nm-5.14.2.tar.xz

The cmake-checks fail to find a required package:

"-- The following REQUIRED packages have not been found:

 * Qca-qt5 (required version >= 2.1.0), Support for encryption,
"

I have a look at this URL.

https://download.kde.org/stable/qca-qt5/

If you look, the latest release is +3 years old, almost 4
years old.

Age in itself is not necessarily a problem if it compiles,
but it does not compile for me - so I actually am, sort
of, filing two bug reports here. BUT, I mostly only care
about plasma, because that seems to be very frequently
having new releases so I assume it is actively maintained.
Not sure about qca-qt5, but I think you can understand that
the situation is not ideal if plasma itself works fine and
is maintained, but add-ons such as qca-qt5 are not.

Anyway, I will also show the specific error for qca-qt5:

(This is a bit long ... I just paste it for the sake of
completeness... comes after a bunch of __):


__

RBT->Extracter: Extracting `qca-qt5-2.1.0.3.tar.xz` to /Depot/Temp/rbt/ next.
RBT->Extracter:   tar -xvf /Users/x/SRC/qcaqt5/qca-qt5-2.1.0.3.tar.xz -C
/Depot/Temp/rbt/
RBT->Extracter: Finished extracting to `/Depot/Temp/rbt/qca-qt5-2.1.0.3/`.
RBT::Compile: Entering the directory /Depot/Temp/rbt/qca-qt5-2.1.0.3/
RBT::Compile: Now entering the directory
`/Depot/Temp/rbt/qca-qt5-2.1.0.3/BUILD_DIRECTORY/`.
Next running cmake -DCMAKE_INSTALL_PREFIX=/usr/
/Depot/Temp/rbt/qca-qt5-2.1.0.3/:
-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- Check for working C compiler: /System/Index/bin/cc
-- Check for working C compiler: /System/Index/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /System/Index/bin/c++
-- Check for working CXX compiler: /System/Index/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Deprecation Warning at CMakeLists.txt:20 (cmake_policy):
  The OLD behavior for policy CMP0020 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


-- Found Doxygen: /System/Index/bin/doxygen (found version "1.8.14") found
components:  doxygen dot 
-- Building with Qt5 support
-- Installed package is NOT relocatable
-- Checking for certstore..
-- Using built in certstore.
-- certstore path: /Depot/Temp/rbt/qca-qt5-2.1.0.3/certs/rootcerts.pem
-- Looking for include file sys/filio.h
-- Looking for include file sys/filio.h - not found
-- Performing Test MLOCK_TAKES_VOID
-- Performing Test MLOCK_TAKES_VOID - Success
-- Found Sasl2: /usr/lib/libsasl2.so
-- Found libgcrypt: -L/Programs/Libgcrypt/1.8.3/lib -lgcrypt
-L/Programs/Libgpgerror/1.32/lib -lgpg-error
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of gcry_error_t
-- Check size of gcry_error_t - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.2") 
-- Checking for one of the modules 'nss'
-- Found NSS:
-L/usr/lib64;-L/Programs/Nspr/4.20/lib;-L/Programs/Sqliteautoconf/3250200/lib;-lnss3;-lsmime3;-lssl3;-lsoftokn3;-lnssutil3;-lplds4;-lplc4;-lnspr4;-lsqlite3
-- Found OpenSSL: /usr/lib/libcrypto.so (found version "1.1.1")  
-- Looking for EVP_md2
-- Looking for EVP_md2 - not found
CMake Warning at plugins/qca-ossl/CMakeLists.txt:18 (message):
  qca-ossl will be compiled without MD2 digest algorithm support


-- Looking for EVP_aes_128_ctr
-- Looking for EVP_aes_128_ctr - found
-- Checking for one of the modules 'libpkcs11-helper-1'

Plugins:
  qca-botan off
  qca-cyrus-sasl on
  qca-gcrypt on
  qca-gnupg on
  qca-logger on
  qca-nss on
  qca-ossl on
  qca-pkcs11 off
  qca-softstore on

QCA prefix is /usr
Plugins will be installed to /usr/lib/qca-qt5
Binary will be installed to /usr/bin
Library will be installed to 

[okular] [Bug 399118] New: Small feature suggestion: ability to remove the most-left pane in okular

[shevegen]

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

Bug ID: 399118
   Summary: Small feature suggestion: ability to remove the
most-left pane in okular
   Product: okular
   Version: unspecified
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: wishlist
  Priority: NOR
 Component: PDF backend
  Assignee: okular-de...@kde.org
  Reporter: sheve...@gmail.com
  Target Milestone: ---

Hello okular devs,

I compiled the most recent okular from source and this time everything works
fine (in the past, okular had difficulty finding proper path to the theme or
the  code that handles opening .pdf, which had to do with me compiling okular
into a standalone directory rather than with the /usr/ prefix; the /usr/ prefix
gives me less problems in the long run, so I switched to using it again for
larger stacks, including KDE).

The tarball URL I used was:

https://download.kde.org/stable/applications/18.08.1/src/okular-18.08.1.tar.xz

(I mention this just in the event that it may be relevant to the report here.)


Okular works fine and opens .pdf files too but I would like a bit more control
over how much space the main .pdf file at hand receives.

For example if we are on the very left hand side with the mouse cursor; and
then click right mouse button for the context menu, we get a check button "Show
Text"; and we can Small Icons / Medium Icons / Large Icons.

I personally do not need this pane and I would like to have a simple option to
get rid of it.

Thus I would like to make two suggestions:

(1) Please consider adding another option in the small widget that pops up as
context menu, with an option to disable that side pane (or, if you want to, you
can minimize it to something like 2-4 pixel or so; that may work as well and
people could click on it again with the mouse cursor)

(2) Provide some additional option in the preferences to not show the side
pane(s).

Reason why I would like to have this:

- The .pdf viewer I often use to just look at documents, including university
documents. So to me the major part is the content on the .pdf; the presentation
aid in okular is not so important to me. Thus I would like to be able to tell
okular something like "please show me less non-pdf related widgets/content", so
as to maximize the area for the .pdf. Fullscreen is not a good option for me,
though, as I often have many more things open; I just want to have it fairly
big there, but not necessarily fullscreen. (I admittedly have a very strange
workflow).

Anyway, please do feel free to close this issue request at any moment in time,
for whatever reason.

Cheers!

-- 
You are receiving this mail because:
You are watching all bug changes.

[drkonqi] [Bug 398916] New: failed to create symbolic link 'backtraceparsertest_data' because existing path cannot be removed: Is a directory

[shevegen]

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

Bug ID: 398916
   Summary: failed to create symbolic link
'backtraceparsertest_data' because existing path
cannot be removed: Is a directory
   Product: drkonqi
   Version: 5.13.5
  Platform: Compiled Sources
OS: Linux
Status: REPORTED
  Severity: minor
  Priority: NOR
 Component: general
  Assignee: unassigned-b...@kde.org
  Reporter: sheve...@gmail.com
  Target Milestone: ---

I get a problem compiling drkonqi from source on Linux.

Before I describe the error, allow me to show you my OS and relevant software
versions, so that you can exclude some errors:

===
  Operating System:GNU/Linux
  Os Bit Type: x86_64   
  CPU Model:   AMD A8-7600 Radeon R7, 10 Compute Cores
4C+6G,  cores
  CFLAGS in use:   -O2 -fPIC -fno-strict-overflow -Wno-error
  Gcc Version: 8.2.0
  Glibc Version:   2.26 
  Kernel Version:  4.14.12
  Binutils Version:GNU gold (GNU Binutils 2.31.1) 1.16  
==

This was a slackware system but I compiled most everything from source myself,
excluding glibc and kernel (which are a bit old, but the rest is up to date,
including binutils).

I compiled most of the KDE stack recently, KDE apps and KDE foundation (well,
for the most part, up to the dependencies of drkonqi). This worked very well.

The source tarball I am using is this one here:

  https://download.kde.org/stable/plasma/5.13.5/drkonqi-5.13.5.tar.xz

drkonqi, however had, has a problem, which will be shown next:

---

[ 85%] Linking CXX executable ../../../bin/backtraceparsertest_manual
[ 85%] Built target backtraceparsertest_manual
Scanning dependencies of target backtraceparsertest_autogen
[ 86%] Automatic MOC for target backtraceparsertest
[ 86%] Built target backtraceparsertest_autogen
Scanning dependencies of target backtraceparsertest
[ 88%] Building CXX object
src/tests/backtraceparsertest/CMakeFiles/backtraceparsertest.dir/fakebacktracegenerator.cpp.o
[ 89%] Building CXX object
src/tests/backtraceparsertest/CMakeFiles/backtraceparsertest.dir/backtraceparsertest.cpp.o
[ 90%] Building CXX object
src/tests/backtraceparsertest/CMakeFiles/backtraceparsertest.dir/backtraceparsertest_autogen/mocs_compilation.cpp.o
[ 92%] Linking CXX executable ../../../bin/backtraceparsertest
failed to create symbolic link 'backtraceparsertest_data' because existing path
cannot be removed: Is a directory
make[2]: ***
[src/tests/backtraceparsertest/CMakeFiles/backtraceparsertest.dir/build.make:116:
bin/backtraceparsertest] Error 1
make[2]: *** Deleting file 'bin/backtraceparsertest'
make[1]: *** [CMakeFiles/Makefile2:619:
src/tests/backtraceparsertest/CMakeFiles/backtraceparsertest.dir/all] Error 2
make: *** [Makefile:141: all] Error 2

---

It seems to want to create a symlink; before so, it wants to remove an existing
path which is a directory. I am not sure why but I believe that there is some
error with the directory-path there.

I'll next display more of the error - perhaps it helps. (I am using some ruby
scripts to automate the compile-process; that is why the copy/pasted text
below has a few different messages perhaps. Oddly enough, drkonqi has some
ruby components too and these do not seem to work reliably right now and
do not seem to be rescued; I suggest a begin/rescue clause additionally,
and a meaningful error message if rescue fails. But this is not the reason 
for the cmake-problem shown above; just something I also wanted to mention.)

---

Next running cmake -DCMAKE_INSTALL_PREFIX=/usr/ .:
-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- Check for working C compiler: /System/Index/bin/cc
-- Check for working C compiler: /System/Index/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /System/Index/bin/c++
-- Check for working CXX compiler: /System/Index/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Installing in the same prefix as Qt, adopting their path scheme.
-- Looking for __GLIBC__
-- Looking for __GLIBC__ - found
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Success
-- Performing Test HAVE_DATE_TIME
-- Performing Test HAVE_DATE_TIME - Success
-- Found Gettext: /usr/bin/msgmerge (found version "0.19.8.1") 
-- Found KF5I18n: /usr/lib64/cmake/KF5I18n/KF5I18nConfig.cmake (found version
"5.50.0") 
-- Found 

[okular] [Bug 397553] New: Problem trying to start okular - compiled it from source, version 18.08.0

[shevegen]

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

Bug ID: 397553
   Summary: Problem trying to start okular - compiled it from
source, version 18.08.0
   Product: okular
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: okular-de...@kde.org
  Reporter: sheve...@gmail.com
  Target Milestone: ---

I was compiling:

https://download.kde.org/stable/applications/18.08.0/src/okular-18.08.0.tar.xz

Okular installed fine; no compile problem.

However had, it can not find something when I try to open a local .pdf file.
The error message shown is:

"Unable to find the Okular component: The shared library was not found."

Could you guys add to this error message WHICH particular shared library was
not found? It's hard to google for this if it does not tell me which shared
library is needed (or perhaps it is in a non-standard location, though I doubt
it). (I compiled everything from source, via prefix /usr/ - so if it is an
official tarball, it is simple for me to add it, but without okular telling me
more, there is no real way for me to find out)

Overall KDE is getting easier to compile and use though - I am confident that
okular will soon run too.

-- 
You are receiving this mail because:
You are watching all bug changes.

[drkonqi] [Bug 397030] drkonqi - version 5.13.4 - can not compile it because of a problem with backtraceparsertest

[shevegen]

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

--- Comment #2 from shevegen  ---
Well another try; guess this can not be edited once posted, sorry. :)

  Operating System:   GNU/Linux
  Os Bit Type:x86_64
  CPU Model:  AMD A8-7600 Radeon R7, 10 Compute Cores 4C+6G,  cores
  CFLAGS in use:  -O2 -fPIC -fno-strict-overflow -Wno-error
  Screen Resolution:  1920x1080
  Gcc Version:8.2.0
  Glibc Version:  2.26
  Kernel Version: 4.14.12

-- 
You are receiving this mail because:
You are watching all bug changes.

[drkonqi] [Bug 397030] drkonqi - version 5.13.4 - can not compile it because of a problem with backtraceparsertest

[shevegen]

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

--- Comment #1 from shevegen  ---
Oops - sorry for the weird line breaks, guess there were ' ' characters that I
did not see in the textfield (I just copy/pasted it from the output of a
terminal script; will look for stray ' ' and less of them next time when
pasting here into a textfield).

-- 
You are receiving this mail because:
You are watching all bug changes.

[drkonqi] [Bug 397030] New: drkonqi - version 5.13.4 - can not compile it because of a problem with backtraceparsertest

[shevegen]

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

Bug ID: 397030
   Summary: drkonqi - version 5.13.4 - can not compile it because
of a problem with backtraceparsertest
   Product: drkonqi
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: unassigned-b...@kde.org
  Reporter: sheve...@gmail.com
  Target Milestone: ---

[ 13%] Built target drkonqi_backtrace_parser
[ 14%] Automatic MOC for target drkonqi
[ 14%] Built target drkonqi_autogen
[ 73%] Built target drkonqi
[ 75%] Automatic MOC for target crashtest
[ 75%] Built target crashtest_autogen
[ 78%] Built target crashtest
[ 80%] Automatic MOC for target backtraceparsertest_manual
[ 80%] Built target backtraceparsertest_manual_autogen
[ 85%] Built target backtraceparsertest_manual
[ 86%] Automatic MOC for target backtraceparsertest
[ 86%] Built target backtraceparsertest_autogen
[ 88%] Linking CXX executable ../../../bin/backtraceparsertest
failed to create symbolic link 'backtraceparsertest_data' because existing path
cannot be removed: Is a directory
make[2]: ***
[src/tests/backtraceparsertest/CMakeFiles/backtraceparsertest.dir/build.make:116:
bin/backtraceparsertest] Fehler 1
make[2]: *** Datei ,,bin/backtraceparsertest" wird gelöscht
make[1]: *** [CMakeFiles/Makefile2:619:
src/tests/backtraceparsertest/CMakeFiles/backtraceparsertest.dir/all] Fehler 2
make: *** [Makefile:141: all] Fehler 2

^

fails to compile for me at the "Linking CXX executable". Not sure why it can
not link it. Most of the other kde-plasma things compile fine for me by the
way, in the 5.13.4 branch.

I guess the error may happen at the symlink part - weird that it wants to 
remove a directory.

PS: This should be filed under compile-related problem perhaps, but this
option was not available in the bug tracker.

If my environment is important, I copy/paste it next:


  Operating System:GNU/Linux
  Os Bit Type: x86_64   
  CPU Model:   AMD A8-7600 Radeon R7, 10 Compute Cores
4C+6G,  cores
  CFLAGS in use:   -O2 -fPIC -fno-strict-overflow -Wno-error
  Gcc Version: 8.2.0
  Glibc Version:   2.26 
  Kernel Version:  4.14.12  


-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kservice] [Bug 394711] New: fakeplugin.desktop can not be found

[shevegen]

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

Bug ID: 394711
   Summary: fakeplugin.desktop can not be found
   Product: frameworks-kservice
   Version: 5.46.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: fa...@kde.org
  Reporter: sheve...@gmail.com
CC: kdelibs-b...@kde.org
  Target Milestone: ---

I had luck compiling qt-5.11.0 and most of the KDE5 foundation
up until kservice. I think I reported the error before already
but I'll report it again, since this is now with
kservice-5.4.60.

The error is:

---

CMake Error at autotests/CMakeLists.txt:47 (file):
  file COPY cannot find
  "/Depot/Temp/kservice-5.46.0/autotests/fakeplugin.desktop".


CMake Error at autotests/CMakeLists.txt:48 (file):
  file RENAME failed to rename

/Depot/Temp/kservice-5.46.0/autotests/fakeplugin.desktop

  to

/Depot/Temp/kservice-5.46.0/autotests/fakeplugin_json_new.desktop

  because: No such file or directory

---

I do not know why it can not find/copy the fakeplugin.desktop
file. Would it be possible to try to continue even if it
can not find that file? Or does kservice really depend on
it.

I'd love to be able to compile the rest of KDE5 including KDE
Konsole but kservice stops me from doing so right now.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kservice] [Bug 388905] New: Can not compile kservice

[shevegen]

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

Bug ID: 388905
   Summary: Can not compile kservice
   Product: frameworks-kservice
   Version: 5.41.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: fa...@kde.org
  Reporter: sheve...@gmail.com
CC: kdelibs-b...@kde.org
  Target Milestone: ---

Error line:

















cmake -DCMAKE_INSTALL_PREFIX=/usr .
-- The C compiler identification is GNU 7.2.0
-- The CXX compiler identification is GNU 7.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- 

-- Installing in the same prefix as Qt, adopting their path scheme.
-- Looking for __GLIBC__
-- Looking for __GLIBC__ - found
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Success
-- Performing Test HAVE_DATE_TIME
-- Performing Test HAVE_DATE_TIME - Success
-- Could not set up the appstream test. appstreamcli is missing.
-- Found Gettext: /usr/bin/msgmerge (found version "0.19.8.1") 
-- Found PythonInterp: /usr/bin/python (found version "2.7.14") 
-- Found FLEX: /usr/bin/flex (found version "2.6.4") 
-- Found BISON: /usr/bin/bison (found version "3.0.4") 
-- Looking for mmap
-- Looking for mmap - found
-- Looking for posix_madvise
-- Looking for posix_madvise - found
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success
CMake Error at autotests/CMakeLists.txt:43 (file):
  file COPY cannot find
  "/Depot/Temp/kservice-5.41.0/autotests/fakeplugin.desktop".


CMake Error at autotests/CMakeLists.txt:44 (file):
  file RENAME failed to rename

/Depot/Temp/kservice-5.41.0/autotests/fakeplugin.desktop

  to

/Depot/Temp/kservice-5.41.0/autotests/fakeplugin_json_old.desktop

  because: No such file or directory



CMake Error at autotests/CMakeLists.txt:47 (file):
  file COPY cannot find
  "/Depot/Temp/kservice-5.41.0/autotests/fakeplugin.desktop".


CMake Error at autotests/CMakeLists.txt:48 (file):
  file RENAME failed to rename

/Depot/Temp/kservice-5.41.0/autotests/fakeplugin.desktop

  to

/Depot/Temp/kservice-5.41.0/autotests/fakeplugin_json_new.desktop

  because: No such file or directory



-- The following OPTIONAL packages have been found:

 * KF5DocTools (required version >= 5.41.0)

-- The following REQUIRED packages have been found:

 * ECM (required version >= 5.41.0), Extra CMake Modules.,

 * Qt5DBus
 * Qt5Xml
 * KF5Config (required version >= 5.41.0)
 * KF5CoreAddons (required version >= 5.41.0)
 * KF5Crash (required version >= 5.41.0)
 * KF5DBusAddons (required version >= 5.41.0)
 * Gettext
 * PythonInterp
 * KF5I18n (required version >= 5.41.0)
 * FLEX, Fast Lexical Analyzer, 
   Required for the Trader parser
 * BISON, general-purpose parser generator, 
   Required for the Trader parser
 * Qt5Concurrent
 * Qt5Test
 * Qt5 (required version >= 5.7.0)

-- The following features have been disabled:

 * QCH, API documentation in QCH format (for e.g. Qt Assistant, Qt Creator &
KDevelop)

-- Configuring incomplete, errors occurred!
See also "/Depot/Temp/kservice-5.41.0/CMakeFiles/CMakeOutput.log".

---


As can be seen, fakeplugin.desktop is not found or generated and thus the
whole compilation fails.

I have no idea what the error is about really but I have two suggestions:

(1) if fakeplugin.desktop is not totally important, perhaps continue with
the compile cycle.

(2) IF fakeplugin.desktop is important, it should be auto-generated or
perhaps a failsafe .desktop file bundled with kservice.

Right now I can not compile the rest of KDE5 but I am absolutely sure
that I was able to compile KDE5 up to including KDE Konsole a few months
ago. It seems as if the tests are run automatically? Perhaps that could
also become some documented commandline switch, since I don't need any
tests really - the C++ code should work just fine no?

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kconfig] [Bug 386170] Strange prefix change in cmake or compilation

[shevegen]

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

--- Comment #4 from shevegen <sheve...@gmail.com> ---
I think I finally solved this, so it can be closed.

A script that I used was doing an incomplete sed-operation; rather
than changing the prefix from lib64 to lib, there was an intermittant
/s/ applied resulting in prefix change from lib64 to s instead.

Not sure how to close this report; on github it's a lot easier 
to close :D *wink*

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kservice] [Bug 386745] New: kservice ails to compile due to missing file called "fakeplugin.desktop"

[shevegen]

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

Bug ID: 386745
   Summary: kservice ails to compile due to missing file called
"fakeplugin.desktop"
   Product: frameworks-kservice
   Version: 5.40.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: fa...@kde.org
  Reporter: sheve...@gmail.com
CC: kdelibs-b...@kde.org
  Target Milestone: ---

I am trying to compile kservice-5.40.0

The other KDE 5.40.0 packages compiled without a problem so far (I still have
that strange
/usr/s/cmake/ error I reported elsewhere, but I simply put a symlink from
/usr/s/ towards
/usr/lib/ and that seems to have worked for now; I investigate that error at a
later time,
for now, this is solely about kservice-5.40.0).

Now, in the extracted directory "/Depot/jj/kservice-5.40.0/" I do:

  cmake -DCMAKE_INSTALL_PREFIX=/usr .; make; make install

But I get an early error:


cmake -DCMAKE_INSTALL_PREFIX=/usr . 


-- The C compiler identification is GNU 7.2.0   
-- The CXX compiler identification is GNU 7.2.0 
-- Check for working C compiler: /System/Index/bin/cc   
-- Check for working C compiler: /System/Index/bin/cc -- works  
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done 
-- Detecting C compile features 
-- Detecting C compile features - done  
-- Check for working CXX compiler: /System/Index/bin/c++
-- Check for working CXX compiler: /System/Index/bin/c++ -- works   
-- Detecting CXX compiler ABI info  
-- Detecting CXX compiler ABI info - done   
-- Detecting CXX compile features   
-- Detecting CXX compile features - done
--  

-- Installing in the same prefix as Qt, adopting their path scheme. 
-- Looking for __GLIBC__
-- Looking for __GLIBC__ - found
-- Performing Test _OFFT_IS_64BIT   
-- Performing Test _OFFT_IS_64BIT - Success 
-- Performing Test HAVE_DATE_TIME   
-- Performing Test HAVE_DATE_TIME - Success 
-- Could not set up the appstream test. appstreamcli is missing.
-- Found Gettext: /System/Index/bin/msgmerge (found version "0.19.8.1") 
-- Found PythonInterp: /System/Index/bin/python (found version "2.7.14")
-- Found FLEX: /usr/bin/flex (found version "2.6.4")
-- Found BISON: /System/Index/bin/bison (found version "3.0.4") 
-- Looking for mmap 
-- Looking for mmap - found 
-- Looking for posix_madvise
-- Looking for posix_madvise - found
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY   
-- Performing Test COMPILER_HAS_HIDDEN_VISIBILITY - Success 
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY
-- Performing Test COMPILER_HAS_HIDDEN_INLINE_VISIBILITY - Success  
-- Performing Test COMPILER_HAS_DEPRECATED_ATTR 

-- Performing Test COMPILER_HAS_DEPRECATED_ATTR - Success   
CMake Error at autotests/CMakeLists.txt:47 (file):  
  file COPY cannot find 
  "/Depot/jj/kservice-5.40.0/autotests/fakeplugin.desktop".  


CMake Error at autotests/CMakeLists.txt:48 (file):  
  file RENAME failed to rename  

/Depot/jj/kservice-5.40.0/autotests/fakeplugin.desktop

  to

/Depot/jj/kservice-5.40.0/autotests/fakeplugin_json_new.desktop

  because: No such file or directory



-- The following OPTIONAL packages have been found:

 * KF5DocTools (required version >= 5.40.0)

-- The following REQUIRED packages have been found:

 * ECM (required version >= 5.40.0), Extra CMake Modules.,

 * Qt5DBus
 * Qt5Xml
 * KF5Config (required version >= 5.40.0)
 * KF5CoreAddons (required version >= 5.40.0)
 * KF5Crash (required version >= 5.40.0)
 * 

[klickety] [Bug 386403] New: Klickety is not listed at https://www.kde.org/applications/games/

[shevegen]

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

Bug ID: 386403
   Summary: Klickety is not listed at
https://www.kde.org/applications/games/
   Product: klickety
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: shuizhuyuan...@hotmail.com
  Reporter: sheve...@gmail.com
CC: kde-games-b...@kde.org
  Target Milestone: ---

https://www.kde.org/applications/games/

Klickety is not listed there.

Could it be added please?

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kconfig] [Bug 386170] Strange prefix change in cmake or compilation

[shevegen]

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

--- Comment #3 from shevegen <sheve...@gmail.com> ---
I wanted to add two more bits of information - not sure if they are
helpful, but additional information may be useful.

(1) My base system here on my main desktop machine, on which I also
reported the above situation, is slackware. But I compile the KDE
stack from source e. g. https://download.kde.org/stable/frameworks/5.39/
and https://download.kde.org/stable/applications/17.08.2/src/ and so
forth. I tend to use the /usr/ prefix normally but sometimes I also
use the GoboLinux versioned AppDir approach - so for example,
konsole would have the --prefix /Programs/Konsole/17.08.2, based on
the URL
 
https://download.kde.org/stable/applications/17.08.2/src/konsole-17.08.2.tar.xz

The latter approach requires of me to handle the cmake-modules of KDE
e. g. at /usr/lib/cmake/ (such as KF5 etc...) and I can not exclude
that I am doing everything right of course. But on the other hand, I
also was able to compile everything necessary up to (and including)
konsole from source, and konsole was even running fine. \o/

(2) I noticed that, the "s/" target, may have to do with "lib/". I
noticed this when I was compiling via versioned AppDir prefix, so
rather than a lib/ or lib64/ directory, I suddenly had a s/ directory.

I do not know if the latter observation is of any real help but I
just reported it in the event that it may be useful to others. I
could be wrong but some other KDE-related programs now seem to
use lib/ rather than lib64/, so I assume that perhaps this may be
related. But I am guessing here really.

I think that, either way, if it would be possible, it would be nice
to be able to understand the problem on the commandline since it
was unexpected to me via --prefix. I wrote a script for the latter
programs that replaces "s/" with "lib/" but this did not fix the 
issue, I still got error reports on a weird "lib/s/" prefix
instead.

I am not 100% sure but I can not remember this problem in the earlier
KDE releases from a few weeks ago, so I guess that there may have been
some changes. But I am really just guessing here mostly, sorry -
hopefully it may still be useful to someone out there. :)

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kconfig] [Bug 386170] Strange prefix change in cmake or compilation

[shevegen]

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

--- Comment #1 from shevegen <sheve...@gmail.com> ---
Btw the error message is also bogus.

I am the superuser, so I have no idea why the message tells me
"need administrative privileges". :)

I also created a file called s in "/usr/s" because I can not
explain the behaviour, so the above trigger is because of course
you can not create anything in the "directory" /usr/s - because
I made it a file. But this is not the issue anyway, the real
issue is why something in the build system assumes /usr/s/ as
the target prefix when /usr/ is used.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kconfig] [Bug 386170] New: Strange prefix change in cmake or compilation

[shevegen]

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

Bug ID: 386170
   Summary: Strange prefix change in cmake or compilation
   Product: frameworks-kconfig
   Version: 5.39.0
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: matt...@mjdsystems.ca
  Reporter: sheve...@gmail.com
CC: kdelibs-b...@kde.org
  Target Milestone: ---

Hello.

I downloaded the kconfig framework program from here:

  https://download.kde.org/stable/frameworks/5.39/kconfig-5.39.0.tar.xz

I extract it then do this:

  cmake -DCMAKE_INSTALL_PREFIX=/usr

The error I get is:

CMake Error at cmake_install.cmake:400 (file):
  file cannot create directory: /usr/s/cmake/KF5Config.  Maybe need
  administrative privileges.


make: *** [Makefile:129: install] Error 1

-

I have no idea why /usr/s/ is the prefix when I use /usr only as
prefix. It confuses me completely. I never had that with GNU 
autoconfigure either. Is there some stray prefix that gets inserted?

Because I can assure you to 100%, that I used manually this line:

  cmake -DCMAKE_INSTALL_PREFIX=/usr

so no idea why it suddenly becomes /usr/s/.

-- 
You are receiving this mail because:
You are watching all bug changes.

[cervisia] [Bug 385937] New: Please consider adding the names of other version control systems to cervisia's KDE-webpage

[shevegen]

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

Bug ID: 385937
   Summary: Please consider adding the names of other version
control systems to cervisia's KDE-webpage
   Product: cervisia
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: christian.lo...@hamburg.de
  Reporter: sheve...@gmail.com
  Target Milestone: ---

Hey folks,

If you look at: https://www.kde.org/applications/development/cervisia/

You see this text:

"Cervisia is a user friendly version control system front-end. The aim is to
support CVS and other version control system programs in a unified interface,
featuring conflict resolution, difference and history viewers, status for the
working copy files, and support for most version control functions."

-> Would it be possible to note down more version control systems on that above
page, in particular git and svn, if cervisia supports these? Right now I do not
know; I assume so but it is not listed on that page. Only cvs is listed, not
sure that many heroic people still use cvs ...

For instance, this page: https://www.kde.org/applications/development/

states "CVS Frontend", so right now visitors may assume that it supports ONLY
CVS. And CVS is a bit old, like used by the old dinosaurs before that nasty
meteorite had enough with CVS ...

-- 
You are receiving this mail because:
You are watching all bug changes.

[docs] [Bug 385569] New: KDE Plasma - no info page for plasma-5.11.php

[shevegen]

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

Bug ID: 385569
   Summary: KDE Plasma - no info page for plasma-5.11.php
   Product: docs
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: kde-doc-engl...@kde.org
  Reporter: sheve...@gmail.com
  Target Milestone: ---

Plasma 5.11 is announced but the link is incorrect at:

https://www.kde.org/announcements/plasma-5.11.0.php

If you scroll down, you can see a link towards:

https://www.kde.org/info/plasma-5.10.95.php

This is incorrect; it should point towards

https://www.kde.org/info/plasma-5.11.0.php

instead.

Not sure if this is appropriate to file here - there are so many 
entries, it's hard to know where to file what.

-- 
You are receiving this mail because:
You are watching all bug changes.

[frameworks-kio] [Bug 179678] KIO needs PolicyKit-kde integration

[shevegen]

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

shevegen <sheve...@gmail.com> changed:

   What|Removed |Added

 CC||sheve...@gmail.com

--- Comment #20 from shevegen <sheve...@gmail.com> ---
This is terrible news.

I used to complain about the Gnome devs treating users as being stupid, but now
this has leaked into KDE.

Just now I write this on my laptop where I run KDE Plasma.

I broke ncurses so nano does not work, so I need an editor.

I was thinking "hey, I can use kate". Ok installing kate worked.

Then I try to open it and kate REFUSES to obey, boring me with an
extremely irrelevant message aka 

"Executing Kate as root is not possible. To edit files as root use:
SUDO_EDITOR=kate sudoedit "

Now this is interesting.

Firstly, I have to say that I tried the above AND IT DOES NOT WORK,
so great job by those KDE devs who changed behaviour and did not
provide a work around.

Yes, I know a "work around" - I can change permission as superuser
anyway, edit it with kate, then change the permission again. I can
also use other editors too. I have tons of workaround BUT THE ISSUE
IS THAT SOME RANDOM KDE DEV SIMPLY CRIPPLED KATE HERE.

So firstly, please fire that dude. Second, please stop dumbing down
KDE everywhere. There is absolutely nothing wrong with the superuser
account. I am aware that you transitioned into a "we work for average
joe - and for red hat" but you used to be cool in the past, so what
happened with KDE?

There is some propaganda here:

https://blog.martin-graesslin.com/blog/2017/02/editing-files-as-root/

None of this applies or is relevant but the problem is that some random
dude dictated onto everyone else. BAD decision.

This Martin dude does not run software on MY machine. Why can he decide
how I should run it?

I can probably find the faulty code and remove it but that means I have
to invest time... which Martin doesn't pay me for.

I have to find out if he works for Red Hat, then this explains why he
crippled kate. It's not a big deal anyway since other editors will work
fine or I can find thousand other ways to modify text files, including
via scripts - but seriously KDE people, what happened to you? Did
Microsoft buy you in? KDE Plasma looks like a Win10 clone.

You used to be cool.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kstars] [Bug 385005] Kstars can not find the file TZrules.dat

[shevegen]

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

--- Comment #1 from shevegen <sheve...@gmail.com> ---
Oh I forgot to add which source - I was using the git download button, and then
repackaged it; 23.09.2017 is just middle europe dd.mm. notation - helps me
keep track when I checked out via git. I actually prefer tarball releases but
the homepage of kstars did not want to give a .tar.xz release there ... it only
said to use git, which I did. There used to be tarball source releases in the
past though such as
ftp://gd.tuwien.ac.at/kde/stable/4.14.3/src/kstars-4.14.3.tar.xz - I know that
because I keep track in my ruby programs of source files... but this is an
aside, this report is about TZrules.dat, not anything else really. :D

-- 
You are receiving this mail because:
You are watching all bug changes.

[kstars] [Bug 385005] New: Kstars can not find the file TZrules.dat

[shevegen]

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

Bug ID: 385005
   Summary: Kstars can not find the file TZrules.dat
   Product: kstars
   Version: git
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: mutla...@ikarustech.com
  Reporter: sheve...@gmail.com
  Target Milestone: ---

Hello kstars developers,

kstars can not find the file TZrules.dat

I compiled kstars with this "AppDir" prefix:

/Programs/Kstars/23.09.2017/

That means that this is similar to /usr/ as prefix,
just another prefix in use.

Upon starting kstars, a popup message shows up and says
that it could not find the file TZrules.dat. This widget
also showed where it was looking, aka the paths - this is
by the way, very helpful to me, because that way I could
instantly verify that the path is not there. And indeed,
it is not.

I was able to easily solve this by symlinking from:

/Programs/Kstars/23.09.2017/share/kstars/TZrules.dat

Into any of the directories that the widget told me (I
picked my home dir because that is the easiest for me
to memorize actually).

Anyway, I am not sure if you guys want to fix this because
from the 0.001% of the world population, I guess only 
0.001% may ever run into this. :D

HOWEVER had, it should also be trivial to fix, too, so
perhaps because it is so trivial to fix, it could be
fixed. Several ways are possible, I suggest a simple one,
to simply add the path that was picked via prefix (in
cmake this is DCMAKE_INSTALL_PREFIX=) to the paths that
kstars will check by default. This check can be omitted
perhaps if the prefix is /usr ... perhaps even /usr/local
but for any other paths, including /opt, I would recommend
to automatically include PREFIX_TARGET/share/kstars/ 
since that is where that .file will reside.

Thanks for reading anyway, please do feel free to close
this issue at any moment in time.

By the way, awesome application - I hope you guys can keep
on it. While I am not even a hobbyist dude in regards to,
well, the universe, I think it's kind of cool - a bit like
google map, of course except that mankind can not (yet) 
walk on the remote stars. I hope you can remain motivated
with kstars!

-- 
You are receiving this mail because:
You are watching all bug changes.

[docs] [Bug 384966] New: Please improve the docu for how to build qtwebkit from source - see content of this bug report

[shevegen]

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

Bug ID: 384966
   Summary: Please improve the docu for how to build qtwebkit from
source - see content of this bug report
   Product: docs
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: docs.kde.org
  Assignee: kde-doc-engl...@kde.org
  Reporter: sheve...@gmail.com
  Target Milestone: ---

Hi guys (and gals perhaps),

There is a docu ... problem? Hmm.

I came to this site:

https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source#Missing_Qt5WebKitWidgetsConfig.cmake

>From the source code aka "new plasma release". So I want to
compile it. I actually managed to compile most of kde KF and
plasma. But qtwebkit gives me issues. This issue is not about
the problem though - this is about the KDE wiki:

If you look at the above page:

https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source#Missing_Qt5WebKitWidgetsConfig.cmake

You can see this:

  It can be fixed by installing the dependeny

  sudo apt-get install libqt5webkit5-dev

That does not help me in any way. Firstly, I don't use
debian so I am not sure why the wiki is only for debian?
We can no longer use kde on non-debian or what?

But secondly and more importantly, it would be nice if
more information would be provided. I figured that the
webkit part probably has to do with ... chromium, which
is a bit weird if true since KDE would selectively favour
Google but this is an aside. My gripe is that the above
information is useless to me.

So my suggestion is:

- Please someone who has more information (did Gentoo
users die out or what), could more information be added
that explains a bit more and says as to what exactly is
needed? As far as I know, the webkit part isn't part of
the KF foundation nor plasma tarball releases, since I
compiled most of them and don't have the the webkit part;
and if it is part of qt 5.x then perhaps someone could
say so and show the commandline switch too. But I think
it may be somewhere else ... can it be integrated into
the whole kde stack? A few source packages require it,
I forgot which ones but I remember that I had the above
error and could not continue ... don't recall which
packages it were.

PS: Component entry only allowed me to pick docs.kde.org,
should perhaps also include community.kde.org - no idea
who runs community.kde.org? Not the KDE team? Honest 
question, I really have no idea right now.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kscreenlocker] [Bug 384865] New: Tarball archive extracts to wrong directory name at https://download.kde.org/stable/plasma/5.10.5/kscreenlocker-5.10.5.1.tar.xz

[shevegen]

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

Bug ID: 384865
   Summary: Tarball archive extracts to wrong directory name at
https://download.kde.org/stable/plasma/5.10.5/kscreenl
ocker-5.10.5.1.tar.xz
   Product: kscreenlocker
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: plasma-b...@kde.org
  Reporter: sheve...@gmail.com
CC: bhus...@gmail.com, mgraess...@kde.org
  Target Milestone: ---

Hey guys,

At the URL:

https://download.kde.org/stable/plasma/5.10.5/kscreenlocker-5.10.5.1.tar.xz

the archive extracts to "kscreenlocker-5.10.5" when it should instead extract
to "kscreenlocker-5.10.5.1".

I compared it to:

https://download.kde.org/stable/plasma/5.10.5/kscreenlocker-5.10.5.tar.xz

which also extracts (correctly so) to "kscreenlocker-5.10.5"

I assume that the .1 was a minor fix for something. Not sure if this is worth
for you to change but I report it just in any case - feel free to close this
issue here either way at any time!

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 384856] KDE Konsole crashes when I try to add a new profile, when I click on the "background" field

[shevegen]

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

--- Comment #1 from shevegen <sheve...@gmail.com> ---
Please excuse the typos ... in github issue trackers I can edit my typos... I
don't see an easy way here. :\

Perhaps email-send could be delayed for two minutes or so to allow people to
correct typos ... ah well. Github issue tracker for the win.

-- 
You are receiving this mail because:
You are watching all bug changes.

[konsole] [Bug 384856] New: KDE Konsole crashes when I try to add a new profile, when I click on the "background" field

[shevegen]

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

Bug ID: 384856
   Summary: KDE Konsole crashes when I try to add a new profile,
when I click on the "background" field
   Product: konsole
   Version: 17.08.1
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: konsole-de...@kde.org
  Reporter: sheve...@gmail.com
  Target Milestone: ---

Hello KDE people,

After years, with help from the LFS/BLFS team, I managed to compile quite a lot
of KDE - yay, go me! \o/

I even got konsole to work, or at the least, to start up, using this version:

https://download.kde.org/stable/applications/17.08.1/src/konsole-17.08.1.tar.xz

Konsole starts fine and I can use it. The default is white background and black
font but I prefer black background and white font. So I tried to change the
profiles ... well.

First thing, the profiles list is empty. I probably did something wrong but I
think it may be useful if, in the event that the profiles list is empty,
perhaps some widget or some other way, right button press, or whatever, can
inform a user a bit why this is the case. I understand that the KDE apps will
default casual users rather than people who compile from source but ... right
now I have ABSOLUTELY no idea as to why the profile list is empty. Anyway, I
guess I may figure out one day, but for now, this report is actually about
something afterwards.

I realized that the profile list was emtpy but one can create a new profile
list. So I tried this.

But when I clicked on the white rectangular box next to the "Background" slot,
konsole crashed.

The error dump on the commandline is:

QStandardPaths: wrong ownership on runtime directory /Depot/Temp, 1000 instead
of 0
QStandardPaths: wrong ownership on runtime directory /Depot/Temp, 1000 instead
of 0
QFSFileEngine::open: No file name specified
QFSFileEngine::open: No file name specified
QFSFileEngine::open: No file name specified
QFSFileEngine::open: No file name specified
GLib-GIO-Message: Using the 'memory' GSettings backend.  Your settings will not
be saved or shared with other applications.
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.

(konsole:15836): GdkPixbuf-WARNING **: Bug! loader 'png' didn't set an error on
failure

(konsole:15836): Gtk-WARNING **: Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.

(konsole:15836): GdkPixbuf-WARNING **: Bug! loader 'png' didn't set an error on
failure
**
Gtk:ERROR:gtkiconhelper.c:493:ensure_surface_for_gicon: assertion failed:
(destination)
Aborted

Now, I am pretty sure that the error is on my side ... I have some libpng and
gdk-pixbuf related problem... probably also via gtk (although actually, almost
all of the gnome-related programs, including evince, that I use from the
commandline, do work fine). So the error is not so much about a problem WITHIN
kde konsole. But I am still annoyed that kde konsole just crashes.

So here is my suggestion to change this:

- IF an error like the above happens, such as when someone can not find a
loader for
png, then rather than crash, konsole could notify about the error; on the
commandline
of course, but also perhaps within the konsole application. A simple pop-up
widget
that may be triggered could suffice or perhaps even better, some in-app
notification
within konsole. Either way, I think notification is better than flat-out crash.

Feel free to proceed with this bug report in any way that you wish to,
including to
close it at any moment in time.

PS: Being able to set background and foreground on the commandline would be
neat, then I could just start konsole like so:  "konsole --bg black --fg
white", or something like that. Right now it seems as if profiles are
mandatory. Not sure why but that wasn't my decision anyway. I su ppose that I
could probably create
some profile on the commandline via ruby scripts ... but being fairly lazy, I
am not sure
I'll go just through that part only to have black background and white colours
again... but
who knows.

PSS: I actually also use a second konsole, from kde4... that one is at /usr
prefix; the
new konsole is in /Programs/Konsole/17.08.1 - no idea if that matters or not, I
think
it should not, since the error is related to gdk/gtk rather than konsole. But I
mention
it just for sake of completion. I am also not entirely sure why konsole
attempts to use
a gtk-dialog, perhaps some kde-dialog is unavailable? I have no idea... I have
not 
finished compiling all of kde so far, neither plasma... but I'll have a look
how this
goes in the coming weeks.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdelibs] [Bug 384484] New: kdelibs-4.14.36 - please make docbookXML optional

[shevegen]

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

Bug ID: 384484
   Summary: kdelibs-4.14.36 - please make docbookXML optional
   Product: kdelibs
   Version: unspecified
  Platform: Other
OS: Linux
Status: UNCONFIRMED
  Severity: minor
  Priority: NOR
 Component: general
  Assignee: kdelibs-b...@kde.org
  Reporter: sheve...@gmail.com
  Target Milestone: ---

Hello,

I am trying to compile the latest kdelibs-4.14.36 from source.

Things work ok during configure stage except for one thing:

"-- The following REQUIRED packages have not been found:

 * DocBookXML, DocBook XML, 
   Required by the KDE help system to process DocBook XML"

It is possible to get DocBook XML to work but it's annoying on my slackware
system.

KDE help system wants it in order to process DocBook XML - but I already do not
use the KDE help system at all. So this is pointless for me. :)

If I need help, I use google, stackoverflow etc... - I never look for local
documentation and stuff anymore.

So my plea is - please make docbook XML an OPTIONAL dependency; or at the least
provide some specific hint how to disable it.

In the old GNU autoconfigure days, a switch switch as "--disable-docbook" or
"--disable-docbookxml" could be used. I have no idea how to do anything like
that via cmake; neither do I even know how to invoke the configure-options for
cmake either, so I would suggest to also add the cmake switch (it is probably
some all-upcased thingy there).

-- 
You are receiving this mail because:
You are watching all bug changes.