[kdelibs] [Bug 193337] multipage option doesn't work with pdf printer

[Andrea via KDE Bugzilla]

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

Andrea  changed:

   What|Removed |Added

 CC||andry.d...@gmail.com

--- Comment #23 from Andrea  ---
I also confirm this bug. KDE 5.7.2 using  Okular

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

[digikam] [Bug 367853] Digikam hangs on 'Reading database' when stumbling across MacOS' Photos Library of a huge size (>20GB)

[Andrea via KDE Bugzilla]

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

--- Comment #4 from Andrea  ---
Gilles,

 thank you very much for the new pre installer. I tried it. Unfortunately, the
problem remains. For the time being a hint like you proposed in the
releasenotes.html, a readme and the FAQ might suffice.

"The best way to store images on Mac Book Pro is to host them in dedicated
directory hierarchies, outside the extra data for other applications: Avoid
having e.g. iPhoto' or Photos' library in the same directory in which your
images are stored and scanned by digikam. "

Andrea

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

[digikam] [Bug 367853] Digikam hangs on 'Reading database' when stumbling across MacOS' Photos Library.photoslibrary of a huge size (>20GB)

[Andrea via KDE Bugzilla]

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

Andrea  changed:

   What|Removed |Added

 CC||and...@renderland.de

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

[digikam] [Bug 367853] New: Digikam hangs on 'Reading database' when stumbling across MacOS' Photos Library.photoslibrary of a huge size (>20GB)

[Andrea via KDE Bugzilla]

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

Bug ID: 367853
   Summary: Digikam hangs on 'Reading database' when stumbling
across MacOS' Photos Library.photoslibrary of a huge
size (>20GB)
   Product: digikam
   Version: 5.1.0
  Platform: Mac OS X Disk Images
OS: OS X
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Database-Scan
  Assignee: digikam-de...@kde.org
  Reporter: and...@renderland.de

If installed on MacOSX (10.11.6 El Capitan) digikam seemed to freeze in the
process of reading the database after starting it for the first time with
default settings. This happens if digikam scans the default user's Pictures
folder AND in case one already has used the Apple application Photos before
that created a huge Photos Library.photoslibrary in the very same folder.
Photos Library.photoslibrary is a packaged db in itself. The size of this file
is in my  case 26 GB as I managed almost 10,000 photos with it. 

One has to wait a looong time (about half an hour) to see digikam finish
reading the content of Photos Library.photoslibrary in its own database and
later on it seems to have some performance problems with so many photos or
maybe with this file that it represents as a folder structure. 

It took me a long time to figure out that this is the reason for the apparent
freeze – at the beginning I just thought that digikam 5.0.1 is simply not
working on MacOSX El Capitan.

Reproducible: Always

Steps to Reproduce:
1. (for testing purpose one might) create a huge  Photos Library.photoslibrary
file in Pictures-folder (default) for many fotos (in my case almost 10.000)
with the Photos app of Apple MacOSX El Capitan  (it's done automatically if you
start it) 
2. Install pre-compiled digikam app 
3. Start digikam with default settings and let it scan the Pictures folder
(happens automatically)  with huge  Photos Library.photoslibrary in it

Actual Results:  
Digikam hangs on 'Reading database' during startup

Expected Results:  
At least the software should warn the user that it is going to take a very long
time to read a file of a certain size or package files like Photos
Library.photoslibrary and that it might cause performance problems later on and
give the opportunity to skip this file from being written to the databas/to
delete it/to move it elsewhere.

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

[KScreen] [Bug 346795] touchscreen offset when using multiple displays

[Andrea via KDE Bugzilla]

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

--- Comment #14 from Andrea  ---
@Martin, the argument "I am not payed to do this and I don't want to, so stop
bothering me" is, at last, a very convincing one :) 

Much more convicing than "we know what's good for the users stop complaining
and be happy instead"

Since we apparently agree that this has nothing to do with providing a usable
DE to your users, I am also happy to close the discussion here.

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

[KScreen] [Bug 346795] touchscreen offset when using multiple displays

[Andrea via KDE Bugzilla]

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

--- Comment #12 from Andrea  ---
@Martin because other DE do not have this problem. If this were really
something inherently missing upstream and impossible to solve, as you say,
everybody would have the same problem.

So, setting aside the discussions on whose design is flawed and where the
missing functionality should be implemented, I see this apparent impossibility
of KDE to implement a workaround as a limitation. YMMV of course, but don't
expect me to agree with you as long as plugging a second screen keeps screwing
up a perfectly working touch device, because there is no argument you can
possibly build that can make this appear as a feature.

And I am sorry, but asking users to report bugs or missing functionalities
upstream is not a good practice, imvho. When one of my clients reports a bug on
my code due to some upstream dependencies, what I do is  1) implement a
workaround ASAP and 2) report the bug upstream myself. I believe this is a much
more effective development model, but again, YMMV.

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

[KScreen] [Bug 346795] touchscreen offset when using multiple displays

[Andrea via KDE Bugzilla]

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

--- Comment #10 from Andrea  ---
Hi Martin, thanks for the explanation, I finally understand the problem, and I
agree that having kde guessing is not optimal.

Still, in the case we are discussing here, there is a configuration with one
output screen and one touch input. All works smoothly until, at some point, a
second screen is added. The only correct behavior here (regardless of whether a
new touch device appears together with the new screen) is clearly to properly
offset all inputs from the "old" touch according to the positioning of the new
screen. I don't think one needs any sophisticated heuristics here.

I guess things get more complicated if, after hot-plugging, I reboot with the
second monitor connected, since then the system sees two screens and one touch
and has no robust way to pair them.

But then, if the system does not provide the info itself, why not asking the
user? If given the opportunity, I would be happy to touch "HDMI1" and help KDE
determine that it needs to be connected to "/dev/input/event7". I expect most
people to use a limited number of screen configurations, so the results of
these manual calibrations could very likely be saved and reused.

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

[KScreen] [Bug 346795] touchscreen offset when using multiple displays

[Andrea via KDE Bugzilla]

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

--- Comment #8 from Andrea  ---
Thanks for the clarifications, but there is still something I just don't
understand. You say kde has not enough information to solve the issue, but
isn't all you need already available in the "Display and Monitor" panel in the
system settings? Once the relative position of the multiple monitors is set, it
seems to me all the offsets are also fully known.

I also don't see why the touch capability of the screens is an issue here. If I
have a touch screen, and I attach a second screen to the left of it, all the
touches on the first screen must receive an offset, regardless of whether the
new screen is touch-capable or not.

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

[plasmashell] [Bug 359855] Crash when I hover over the tab "History"

[Andrea via KDE Bugzilla]

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

Andrea  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

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

[plasmashell] [Bug 359855] New: Crash when I hover over the tab "History"

[Andrea via KDE Bugzilla]

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

Bug ID: 359855
   Summary: Crash when I hover over the tab "History"
   Product: plasmashell
   Version: 5.5.4
  Platform: Kubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: crash
  Priority: NOR
 Component: Application Launcher (Kickoff)
  Assignee: k...@davidedmundson.co.uk
  Reporter: andry.d...@gmail.com
CC: plasma-b...@kde.org

Every time I hover over on the history tab the application crashes .

Reproducible: Always

Steps to Reproduce:
1.Open kickoff
2.go to the tab History

Actual Results:  
Kickoff not not responding


Kubuntu 15.10
KDE Plasma 5.5.4
Kernel: 4.4.1

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

[frameworks-kded] [Bug 359616] Total crash of X server configuration after the close screen laptop (standby) with a external monitor via HDMI

[Andrea via KDE Bugzilla]

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

--- Comment #2 from Andrea  ---
Created attachment 97353
  --> https://bugs.kde.org/attachment.cgi?id=97353=edit
errorLog

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

[frameworks-kded] [Bug 359616] Total crash of X server configuration after the close screen laptop (standby) with a external monitor via HDMI

[Andrea via KDE Bugzilla]

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

--- Comment #1 from Andrea  ---
Application: krunner (krunner), signal: Aborted
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f178507d800 (LWP 1560))]

Thread 11 (Thread 0x7f17714cd700 (LWP 1565)):
#0  0x7f1781b3988d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7f178102bbd2 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x7f178102d74f in xcb_wait_for_event () from
/usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x7f1773817a39 in ?? () from
/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so
#4  0x7f178222c2be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7f177fd986aa in start_thread (arg=0x7f17714cd700) at
pthread_create.c:333
#6  0x7f1781b44e9d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 10 (Thread 0x7f1766d8d700 (LWP 1591)):
#0  0x7f1782462b6a in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#1  0x7f177f21877d in g_main_context_prepare () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f177f21911b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f177f2192fc in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f178246329b in
QEventDispatcherGlib::processEvents(QFlags) ()
from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x7f178240975a in
QEventLoop::exec(QFlags) () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x7f17822273d4 in QThread::exec() () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#7  0x7f178402ef85 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#8  0x7f178222c2be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x7f177fd986aa in start_thread (arg=0x7f1766d8d700) at
pthread_create.c:333
#10 0x7f1781b44e9d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 9 (Thread 0x7f1757823700 (LWP 2258)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7f178222d55b in QWaitCondition::wait(QMutex*, unsigned long) () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#2  0x7f175fbc729f in
ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*,
bool, bool, bool) () from /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#3  0x7f175fbcb4c8 in ?? () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#4  0x7f175fbc644d in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#5  0x7f175fbcb522 in ?? () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#6  0x7f175fbc644d in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#7  0x7f175fbc9423 in ThreadWeaver::Thread::run() () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#8  0x7f178222c2be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x7f177fd986aa in start_thread (arg=0x7f1757823700) at
pthread_create.c:333
#10 0x7f1781b44e9d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 8 (Thread 0x7f1757022700 (LWP 2259)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7f178222d55b in QWaitCondition::wait(QMutex*, unsigned long) () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#2  0x7f175fbc729f in
ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*,
bool, bool, bool) () from /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#3  0x7f175fbcb4c8 in ?? () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#4  0x7f175fbc644d in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#5  0x7f175fbcb522 in ?? () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#6  0x7f175fbc644d in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#7  0x7f175fbc9423 in ThreadWeaver::Thread::run() () from
/usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#8  0x7f178222c2be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x7f177fd986aa in start_thread (arg=0x7f1757022700) at
pthread_create.c:333
#10 0x7f1781b44e9d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Thread 7 (Thread 0x7f1756821700 (LWP 2260)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7f178222d55b in QWaitCondition::wait(QMutex*, unsigned long) () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#2  0x7f175fbc729f in
ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*,
bool, bool, bool) () from /usr/lib/x86_64-linux-gnu/libKF5ThreadWeaver.so.5
#3  0x7f175fbcb4c8 in ?? () from

[frameworks-kded] [Bug 359616] New: Total crash of X server configuration after the close screen laptop (standby) with a external monitor via HDMI

[Andrea via KDE Bugzilla]

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

Bug ID: 359616
   Summary: Total crash of X server configuration after the close
screen laptop (standby)  with a external monitor via
HDMI
   Product: frameworks-kded
   Version: 5.1.0
  Platform: Kubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: critical
  Priority: NOR
 Component: general
  Assignee: afies...@kde.org
  Reporter: fosch...@gmail.com
CC: kdelibs-b...@kde.org

A laptop with a external monitor via HDMI. If you close the screen laptop with
the cable inserted, X11 configuration crashes and after also with the external
monitor plugged you can use the laptop.

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

[kio] [Bug 351913] since version 15.08 some file types previews no longer available (pdf for instance)

[Andrea via KDE Bugzilla]

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

Andrea  changed:

   What|Removed |Added

 CC||andry.d...@gmail.com

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

[muon] [Bug 358359] HIgh cpu consumption and apt-check process infinte fork

[Andrea via KDE Bugzilla]

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

Andrea  changed:

   What|Removed |Added

 CC||andry.d...@gmail.com

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