[Okular-devel] [Bug 217135] When i try open fb2 book okular crash
https://bugs.kde.org/show_bug.cgi?id=217135 --- Comment #12 from Albert Astals Cid tsdgeos terra es 2010-04-03 18:49:42 --- Tobias backported it -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 233084] New: Okular crashed after rotating a PDF
https://bugs.kde.org/show_bug.cgi?id=233084 Summary: Okular crashed after rotating a PDF Product: okular Version: 0.10.2 Platform: Ubuntu Packages OS/Version: Linux Status: UNCONFIRMED Severity: crash Priority: NOR Component: general AssignedTo: okular-devel@kde.org ReportedBy: stegma...@googlemail.com Application: okular (0.10.2) KDE Platform Version: 4.4.2 (KDE 4.4.2) Qt Version: 4.6.2 Operating System: Linux 2.6.32-18-generic x86_64 Distribution: Ubuntu lucid (development branch) -- Information about the crash: I was rotating a ~10 pages PDF file 90 degrees to the right, whereafter Okular suddenly crashed. This happend only once. -- Backtrace: Application: Okular (okular), signal: Segmentation fault [Current thread is 1 (Thread 0x7fad88048760 (LWP 2746))] Thread 6 (Thread 0x7fad7931c710 (LWP 2751)): #0 0x7fad819ffee3 in g_main_context_prepare () from /lib/libglib-2.0.so.0 #1 0x7fad81a00318 in ?? () from /lib/libglib-2.0.so.0 #2 0x7fad81a008fc in g_main_context_iteration () from /lib/libglib-2.0.so.0 #3 0x7fad866f9566 in QEventDispatcherGlib::processEvents (this=0x1c94880, flags=value optimized out) at kernel/qeventdispatcher_glib.cpp:414 #4 0x7fad866ce992 in QEventLoop::processEvents (this=value optimized out, flags=) at kernel/qeventloop.cpp:149 #5 0x7fad866ced6c in QEventLoop::exec (this=0x7fad7931bdb0, flags=) at kernel/qeventloop.cpp:201 #6 0x7fad865d8d59 in QThread::exec (this=value optimized out) at thread/qthread.cpp:487 #7 0x7fad866af178 in QInotifyFileSystemWatcherEngine::run (this=0x1c9f060) at io/qfilesystemwatcher_inotify.cpp:248 #8 0x7fad865db775 in QThreadPrivate::start (arg=0x1c9f060) at thread/qthread_unix.cpp:248 #9 0x7fad837da9ca in start_thread (arg=value optimized out) at pthread_create.c:300 #10 0x7fad8531b6dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #11 0x in ?? () Thread 5 (Thread 0x7fad6710 (LWP 2798)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x7fad865dc72b in QWaitConditionPrivate::wait (this=value optimized out, mutex=0x173d750, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:87 #2 QWaitCondition::wait (this=value optimized out, mutex=0x173d750, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:159 #3 0x7fad7c3ad026 in ThreadWeaver::WeaverImpl::blockThreadUntilJobsAreBeingAssigned (this=0x1d6faf0, th=0x1b5ddf0) at ../../../threadweaver/Weaver/WeaverImpl.cpp:365 #4 0x7fad7c3af6ab in ThreadWeaver::WorkingHardState::applyForWork (this=0x1b3a970, th=0x1b5ddf0) at ../../../threadweaver/Weaver/WorkingHardState.cpp:71 #5 0x7fad7c3af6c4 in ThreadWeaver::WorkingHardState::applyForWork (this=0x1b3a970, th=0x1b5ddf0) at ../../../threadweaver/Weaver/WorkingHardState.cpp:74 #6 0x7fad7c3af6c4 in ThreadWeaver::WorkingHardState::applyForWork (this=0x1b3a970, th=0x1b5ddf0) at ../../../threadweaver/Weaver/WorkingHardState.cpp:74 #7 0x7fad7c3adbff in ThreadWeaver::ThreadRunHelper::run (this=0x7fad6fffee00, parent=0x1d6faf0, th=0x1b5ddf0) at ../../../threadweaver/Weaver/Thread.cpp:87 #8 0x7fad7c3ae168 in ThreadWeaver::Thread::run (this=0x1b5ddf0) at ../../../threadweaver/Weaver/Thread.cpp:142 #9 0x7fad865db775 in QThreadPrivate::start (arg=0x1b5ddf0) at thread/qthread_unix.cpp:248 #10 0x7fad837da9ca in start_thread (arg=value optimized out) at pthread_create.c:300 #11 0x7fad8531b6dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #12 0x in ?? () Thread 4 (Thread 0x7fad6e0d7710 (LWP 2799)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x7fad865dc72b in QWaitConditionPrivate::wait (this=value optimized out, mutex=0x173d750, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:87 #2 QWaitCondition::wait (this=value optimized out, mutex=0x173d750, time=18446744073709551615) at thread/qwaitcondition_unix.cpp:159 #3 0x7fad7c3ad026 in ThreadWeaver::WeaverImpl::blockThreadUntilJobsAreBeingAssigned (this=0x1d6faf0, th=0x1ce8200) at ../../../threadweaver/Weaver/WeaverImpl.cpp:365 #4 0x7fad7c3af6ab in ThreadWeaver::WorkingHardState::applyForWork (this=0x1b3a970, th=0x1ce8200) at ../../../threadweaver/Weaver/WorkingHardState.cpp:71 #5 0x7fad7c3adbff in ThreadWeaver::ThreadRunHelper::run (this=0x7fad6e0d6e00, parent=0x1d6faf0, th=0x1ce8200) at ../../../threadweaver/Weaver/Thread.cpp:87 #6 0x7fad7c3ae168 in ThreadWeaver::Thread::run (this=0x1ce8200) at ../../../threadweaver/Weaver/Thread.cpp:142 #7 0x7fad865db775 in QThreadPrivate::start (arg=0x1ce8200) at thread/qthread_unix.cpp:248 #8 0x7fad837da9ca in start_thread (arg=value optimized out) at pthread_create.c:300 #9 0x7fad8531b6dd in clone () at
Re: [Okular-devel] Fwd: Re: Nepomuk MetaData in Okular
On Tuesday 26 January 2010 09:34:23 Peter Penz wrote: Hello Albert, From: Albert Astals Cid aa...@kde.org [...] Thanks for cleaning it up, unfortunately at the moment we are in feature freeze for the KDE 4.4 release (sorry i didn't anwer either, been very busy with real life lately), can you please put a reminder on your calendar for the beginning of february when trunk will be probably reopen for new features and we discuss about it again, ok? That's ok. Peter Penz is planing to move KMetaDataWidget to kdelibs to KDE 4.5. So it is a good idea to wait a little bit anyway. The widget is in kdelibs now: http://websvn.kde.org/trunk/KDE/kdelibs/kfile/kfilemetadatawidget.h?view=markup If you face any issues, please just let me know. Thanks! Peter [...] trunk is open for 4.5, can you tell(¿help?) Peter to move KMetaDataWidget to kdelibs asap? I need to do some interface cleanups in KMetaDataWidget before moving it to kdelibs, but I'm confident that it can be moved to kdelibs until the end of February. I'll send an e-mail to okular-devel@kde.org as soon as I've moved the class :-) Best regards, Peter PS: I'm not subscribed to okular-devel@kde.org, please keep me on CC when replying Albert Best regards, Oliver. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel --- ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 233182] New: Restore construct again the same annotation behaviour.
https://bugs.kde.org/show_bug.cgi?id=233182 Summary: Restore construct again the same annotation behaviour. Product: okular Version: 0.10.2 Platform: unspecified OS/Version: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: general AssignedTo: okular-devel@kde.org ReportedBy: razielm...@gmail.com Version: 0.10.2 (using 4.4.2 (KDE 4.4.2), Chakra) Compiler: gcc OS:Linux (i686) release 2.6.32-ARCH Lately I've been stying a lot of large PDF documents, and I found the current workflow that the annotator imposes very awkward: 1.- Select highlight tool 2.- Highlight text 3.- Select highlight tool 4.- Highlight text 5.- Select highlight tool 6.- Highlight text ... N.- Moonwalk away A more proper workflow would be: 1.- Select highlight tool 2.- Highlight text 3.- Highlight text 4.- Highlight text ... N.- Unselect highlight tool I'm aware this was the old beaviour and people complained because they needed to unselect the tool to edit an annotation (#155668). I think there are ways to solve both these problems. For example, I see no reason why we shouldn't allow the regular right-click context menu on annotation mode. AFAIK, the only place where right-click is used while on annotation mode is with the blue polygon tool, to close the shape, but I think it would be maybe more intuitive to close it with a double click (tools like inkscape support both right and double click to close the shape). Anyway, it would be okay to hijack the regular right-click operation *while* drawing the shape, but keep it *before* starting to draw it. For the rest of the annotation tools, maintaining the right-click context menu while not drawing would be OK IMHO. BTW, while we have selected an annotation tool, shouldn't we deselect the browse tool button? Mouse doesn't behave like on browse mode, so the button shouldn't be selected. I also would be awesome to change the cursor's shape depending on the annotation tool. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 233182] Restore construct again the same annotation behaviour.
https://bugs.kde.org/show_bug.cgi?id=233182 --- Comment #1 from Albert Astals Cid tsdgeos terra es 2010-04-03 19:07:10 --- Unless you want to work on a patch to fix this issue it's probably going to be not worked on since we are pretty short on workforce. If you want to help please join okular-devel mailing list. -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
[Okular-devel] [Bug 233182] Restore construct again the same annotation behaviour.
https://bugs.kde.org/show_bug.cgi?id=233182 --- Comment #2 from Ismael Barros razielmine gmail com 2010-04-03 19:49:24 --- Sounds about right, I'll take a look if I find some time :) -- Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Okular-devel mailing list Okular-devel@kde.org https://mail.kde.org/mailman/listinfo/okular-devel
