[plasmashell] [Bug 353975] Black screen on second display.

2016-10-06 Thread Vangelis via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=353975

--- Comment #84 from Vangelis  ---
I had this issue, and indeed, upgrading to Plasma 5.8 (on KDE Neon) solved the
problem for me.

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


[konsole] [Bug 369496] KPart doesn't respect Scrollback File Location for "Unlimited Scrollback"

2016-09-28 Thread Vangelis via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=369496

Vangelis  changed:

   What|Removed |Added

Version|3.0.2   |16.08.1

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


[yakuake] [Bug 369496] New: Yakuake doesn't respect Scrollback File Location for "Unlimited Scrollback"

2016-09-28 Thread Vangelis via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=369496

Bug ID: 369496
   Summary: Yakuake doesn't respect Scrollback File Location for
"Unlimited Scrollback"
   Product: yakuake
   Version: 3.0.2
  Platform: Neon Packages
OS: Linux
Status: UNCONFIRMED
  Severity: major
  Priority: NOR
 Component: general
  Assignee: h...@kde.org
  Reporter: cyberan...@gmail.com

I am not sure if this is a yakuake or a konsole-part bug, but I will describe
it here since I only experience the issue in Yakuake (I guess the same will be
happening in other applications that use the konsole-part).

In a dropped-down Yakuake window I do a "right click -> Scrollback -> Adjust
Scrollback..." and I choose the "Unlimited scrollback" option, where it gives
me the following notification:


When using this option, the scrollback data will be written unencrypted to
temporary files. Those temporary files will be deleted automatically when
Konsole is closed in a normal manner.
Use Settings->Configure Konsole->File Location to select the location of the
temporary files.


Then I open the konsole and I choose "Settings -> Configure Konsole -> File
Location -> Use user specific location". I kill and restart yakuake. Now
yakuake should save the scrollback files in /home/user/.cache/konsole
directory, but the global /tmp is still used instead.

I tried to debug the konsole (not yakuake) code since the konsole-part is
involved here, and I found that the choice of path is happening in the
History.cpp file issue and in the HistoryFile::HistoryFile() constructor.

I added the following qDebug lines in the code:

HistoryFile::HistoryFile()
: _fd(-1),
  _length(0),
  _fileMap(0),
  _readWriteBalance(0)
{
// Determine the temp directory once
// This class is called 3 times for each "unlimited" scrollback.
// This has the down-side that users must restart to
// load changes (currently only 2 choices).

if (!historyFileLocation.exists()) {
KConfigGroup configGroup(KSharedConfig::openConfig(), "FileLocation");
KSharedConfig::Ptr k = KSharedConfig::openConfig();
qDebug() << "KConfig::mainConfigName() = " << k->name();
qDebug() << "configGroup.readEntry(\"scrollbackUseCacheLocation\",
false) = " << configGroup.readEntry("scrollbackUseCacheLocation", false);
qDebug() << "configGroup.name() = " << configGroup.name();
qDebug() << "configGroup.exists() = " << configGroup.exists();
if (configGroup.readEntry("scrollbackUseCacheLocation", false)) {
*historyFileLocation() =
QStandardPaths::writableLocation(QStandardPaths::CacheLocation);
} else {
*historyFileLocation() = QDir::tempPath();
}
QDir().mkpath(*historyFileLocation());
}
const QString tmpDir = *historyFileLocation();
const QString tmpFormat = tmpDir + QLatin1Char('/') +
"konsole-XX.history";
_tmpFile.setFileTemplate(tmpFormat);
if (_tmpFile.open()) {
_tmpFile.setAutoRemove(true);
_fd = _tmpFile.handle();
}
}

And what I realized is that yakuake doesn't respect the scrollback file
location because the config file yakuakerc doesn't contain a config group
"FileLocation".

This is a sample debug output for when I run "konsole":
~$ konsole
KConfig::mainConfigName() =  "konsolerc"
configGroup.readEntry("scrollbackUseCacheLocation", false) =  true
configGroup.name() =  "FileLocation"
configGroup.exists() =  true

And this is a sample debug output when I run "yakuake":
~$ yakuake
KConfig::mainConfigName() =  "yakuakerc"
configGroup.readEntry("scrollbackUseCacheLocation", false) =  false
configGroup.name() =  "FileLocation"
configGroup.exists() =  false

What is happening here is that in the line "KConfigGroup
configGroup(KSharedConfig::openConfig(), "FileLocation");" the config file is
loaded and we try to read the config group "FileLocation". Since there is no
filename provided to the function KSharedConfig::openConfig(), the default
KConfig::mainConfigName() is used as the configuration file. Eventually, when
one uses "konsole" the default configuration file is "konsolerc", that contains
the config group "FileLocation", and the scrollback file location works as
expected, while when konsole-part is loaded from yakuake the default
configuration file is "yakuakerc". Of course, yakuakerc doesn't contain the
config group "FileLocation" and the scrollback files are saved to the default
/tmp location.

When I added in ~/.config/yakuakerc the following lines (that are the lines
added by konsole to the konsolerc when the user chooses the option "Use user
specific location" for storing the scrollback files), the problem is solved.

[FileLocation]
scrollbackUseCacheLocation=true
scrollbackUseSystemLocation=false

Reproducible: Always




I would choose the bug severity as "Normal", but I chose "Major" because 

[plasmashell] [Bug 353975] Black screen on second display.

2016-09-27 Thread Vangelis via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=353975

Vangelis  changed:

   What|Removed |Added

 CC||cyberan...@gmail.com

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


[neon] [Bug 365301] QtCreator installation fails

2016-09-27 Thread Vangelis via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=365301

Vangelis  changed:

   What|Removed |Added

 CC||cyberan...@gmail.com

--- Comment #4 from Vangelis  ---
@Roman, is there a deb file in the link you provided?
I only found QT Creator binary files with a .run extension. They install and
work fine, but do not integrate with the package management in the system (as
expected).

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