[ghostwriter] [Bug 467491] New: Segmentation fault at startup - directly after build from source
https://bugs.kde.org/show_bug.cgi?id=467491 Bug ID: 467491 Summary: Segmentation fault at startup - directly after build from source Classification: Applications Product: ghostwriter Version: unspecified Platform: Mint (Ubuntu based) OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: megan.con...@kdemail.net Reporter: christian.goe...@mailbox.org Target Milestone: --- SUMMARY *** I tried to build ghostwriter on Linux Mint (CE) from source (repositories). When I tried to start ghostwriter after building, I immediately got a segmentation fault. Feel free to ask for further information, but please keep in mind that I am just a user (not a programmer) Feel free to point out any mistakes or shortcoming in my building process. *** STEPS TO REPRODUCE 1. Download / install dependencies, mentioned on https://invent.kde.org/office/ghostwriter: sudo apt install g++ qtbase5-dev libqt5svg5-dev qtmultimedia5-dev qtwebengine5-dev pkg-config libqt5concurrent5 qttools5-dev-tools libkf5coreaddons-dev libkf5xmlgui-dev libkf5configwidgets-dev libkf5sonnet-dev libkf5doctools5 libkf5doctools-dev cmake extra-cmake-modules 2. I had to install two additional packages (as claimed by cmake): sudo apt install qttols5-dev libhunspell-dev 3. Get sources of ghostwriter: git clone https://invent.kde.org/office/ghostwriter 4. Build ghostwriter cd ghostwriter mkdir build cd build cmake .. make sudo make install 5. Start ghostwriter from the command line: $ ghostwriter OBSERVED RESULT $ ghostwriter Using pandoc version 2.9.2.1 Using multimarkdown version 1.35 Using cmark version 0.30.2 Segmentation fault (core dumped) EXPECTED RESULT Ghostwriter was expected to start (at least I hoped so) SOFTWARE/OS VERSIONS Linux/KDE Plasma: Linux Mint 21-1 - Cinnamon Edition ADDITIONAL INFORMATION cmake gave the following warning: CMake Deprecation Warning at /usr/share/cmake-3.22/Modules/GenerateExportHeader.cmake:427 (message): The add_compiler_export_flags function is obsolete. Use the CXX_VISIBILITY_PRESET and VISIBILITY_INLINES_HIDDEN target properties instead. Call Stack (most recent call first): 3rdparty/cmark-gfm/extensions/CMakeLists.txt:31 (add_compiler_export_flags) I tried to get debugging information: gdb) run Starting program: /usr/bin/ghostwriter [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffe1e0d640 (LWP 28852)] [New Thread 0x7fffe0ce2640 (LWP 28853)] [New Thread 0x7fffd3675640 (LWP 28854)] [New Thread 0x7fffd2e74640 (LWP 28855)] [New Thread 0x7fffd2673640 (LWP 28856)] [New Thread 0x7fffd1e72640 (LWP 28857)] [New Thread 0x7fffd11fa640 (LWP 28858)] [Thread 0x7fffd11fa640 (LWP 28858) exited] [New Thread 0x7fffd11fa640 (LWP 28859)] [New Thread 0x7fffd09f9640 (LWP 28860)] [Thread 0x7fffd11fa640 (LWP 28859) exited] [New Thread 0x7fffd11fa640 (LWP 28861)] [Thread 0x7fffd09f9640 (LWP 28860) exited] [New Thread 0x7fffd09f9640 (LWP 28862)] [Thread 0x7fffd11fa640 (LWP 28861) exited] [Thread 0x7fffd09f9640 (LWP 28862) exited] [Detaching after fork from child process 28863] Using pandoc version 2.9.2.1 [Detaching after fork from child process 28868] Using multimarkdown version 1.35 [Detaching after fork from child process 28869] Using cmark version 0.30.2 Thread 1 "ghostwriter" received signal SIGSEGV, Segmentation fault. 0x769932be in QString::operator=(QString const&) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 (gdb) exit Information about the dev-packages: -- The following OPTIONAL packages have been found: * KF5DocTools (required version >= 5.90), Tools to generate documentation * KF5Auth (required version >= 5.92.0) * KF5Codecs (required version >= 5.92.0) -- The following REQUIRED packages have been found: * ECM (required version >= 5.90) * Qt5LinguistTools * PkgConfig * Qt5Concurrent * Qt5Svg * Qt5Network (required version >= 5.15.3) * Qt5Qml (required version >= 5.15.3) * Qt5WebChannel * Qt5Gui * Qt5QmlModels (required version >= 5.15.3) * Qt5Quick (required version >= 5.15.3) * Qt5Positioning (required version >= 5.15.3) * Qt5WebEngineCore (required version >= 5.15.3) * Qt5PrintSupport (required version >= 5.15.3) * Qt5WebEngineWidgets * Qt5 (required version >= 5.15.2) * KF5Sonnet (required version >= 5.90) * KF5XmlGui (required version >= 5.90) * KF5CoreAddons (required version >= 5.92.0) * Qt5Core (required version >= 5.15.2) * KF5ConfigWidgets (required version >= 5.90) * Qt5Widgets (required version >= 5.15.2) * KF5WidgetsAddons (required version >= 5.90) * KF5 (required version >= 5.90) -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 467491] Segmentation fault at startup - directly after build from source
https://bugs.kde.org/show_bug.cgi?id=467491 goebbe changed: What|Removed |Added Resolution|WAITINGFORINFO |FIXED Status|NEEDSINFO |RESOLVED --- Comment #3 from goebbe --- Thanks for your comment! I just tried building from source, again. The build worked just fine! Since I reported the issue, I change the status to resolved and fixed! -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 461549] bold or italic markdown does not show consistently when text starts or ends with a composed letter
https://bugs.kde.org/show_bug.cgi?id=461549 --- Comment #3 from goebbe --- There seem to be a couple of bug reports for composed letters (e.g. German umlauts, or French composed letters). Since all the bug reports have been closed, I tried to test the fix. - build ghostwriter from source (as of 2023.04.20). - download and open the example file, attached to this bug Result: The issue seems not to be fixed - at least in my build. :-) (maybe the issue is caused by one of the dependencies, outside ghostwriter - but I didn't find a hint on what is responsible for the issue, in the closed reports) Should/ could the bug-report be reopened? For a very quick test, I paste a part of the example file, here: Issues when highlighting (bold/ italic) text that contains Umlauts or accents: *Überschrift* **Überschrift** <- first italic, second bold *ä* *ö* *ü* *ß* *á* *â* *à* <- all italic **ä** **ö** **ü** **ß** **á** **â** **à**<- all bold **aä** **aäa** **dö** should_be_normal **üadfafasd** <- mix bold and normal text **äa** **aäa** **äa** **öfö** **üadfafasd**<- all bold? **aäa** **äa** **aäa** **öfö** **üadfafasd** <- all bold, including the markup? **Whateverö** normal text **final word** <- the first word in the line should be bold **Whateverö** normal text **öfinal word**<- bold normal bold -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 461549] bold or italic markdown does not show consistently when text starts or ends with a composed letter
https://bugs.kde.org/show_bug.cgi?id=461549 --- Comment #4 from goebbe --- This bug is marked as duplicate. I guess this is the reason I cannot reopen, here. I will copy/paste my last comment and reopen the duplicate. -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 461547] Miss-placed markup rendering with composed letters
https://bugs.kde.org/show_bug.cgi?id=461547 goebbe changed: What|Removed |Added Status|RESOLVED|REOPENED Ever confirmed|0 |1 Resolution|FIXED |--- --- Comment #4 from goebbe --- There seem to be a couple of bug reports for composed letters (e.g. German umlauts, or French composed letters). Since all the bug reports have been closed, I tried to test again. - build ghostwriter from source (as of 2023.04.20). - download and open the example file, attached to this bug Result: The issue seems not to be fixed - at least in my build. :-/ (maybe the issue is caused by one of the dependencies, outside ghostwriter - but I didn't find a hint on what is responsible for the issue) Therefore, I reopen the issue. Please feel free to comment and close, if I miss something. For a very quick test, I paste a part of the example file, here: Issues when highlighting (bold/ italic) text that contains Umlauts or accents: *Überschrift* **Überschrift** <- first word should be italic, the second should be bold *ä* *ö* *ü* *ß* *á* *â* *à* <- all italic **ä** **ö** **ü** **ß** **á** **â** **à**<- all bold **aä** **aäa** **dö** should_be_normal **üadfafasd** <- mix bold and normal text **äa** **aäa** **äa** **öfö** **üadfafasd**<- all bold? **aäa** **äa** **aäa** **öfö** **üadfafasd** <- all bold, including the markup? **Whateverö** normal text **final word** <- the first word in the line should be bold **Whateverö** normal text **öfinal word**<- bold normal bold -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 461547] Miss-placed markup rendering with composed letters
https://bugs.kde.org/show_bug.cgi?id=461547 --- Comment #5 from goebbe --- There seem to be a couple of bug reports for composed letters (e.g. German umlauts, or French composed letters). Since all the bug reports have been closed, I tried to test again. - build ghostwriter from source (as of 2023.04.20). - download and open the example file, attached to this bug Result: The issue seems not to be fixed - at least in my build. :-/ (maybe the issue is caused by one of the dependencies, outside ghostwriter - but I didn't find a hint on what is responsible for the issue) Therefore, I reopen the issue. Please feel free to comment and close, if I miss something. For a very quick test, I paste a part of the example file, here: Issues when highlighting (bold/ italic) text that contains Umlauts or accents: *Überschrift* **Überschrift** <- first word should be italic, the second should be bold *ä* *ö* *ü* *ß* *á* *â* *à* <- all italic **ä** **ö** **ü** **ß** **á** **â** **à**<- all bold **aä** **aäa** **dö** should_be_normal **üadfafasd** <- mix bold and normal text **äa** **aäa** **äa** **öfö** **üadfafasd**<- all bold? **aäa** **äa** **aäa** **öfö** **üadfafasd** <- all bold, including the markup? **Whateverö** normal text **final word** <- the first word in the line should be bold **Whateverö** normal text **öfinal word**<- bold normal bold -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 460236] New: Import or clarify status of open issues from old project page
https://bugs.kde.org/show_bug.cgi?id=460236 Bug ID: 460236 Summary: Import or clarify status of open issues from old project page Classification: Applications Product: ghostwriter Version: unspecified Platform: Other OS: All Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: megan.con...@kdemail.net Reporter: christian.goe...@mailbox.org Target Milestone: --- At the old github page of ghostwriter http://wereturtle.github.io/ghostwriter/ ?? a couple of issues have been reported - most of them should still be valid. These issues should be transferred / imported into bugs.kde.org. At least the users should be informed about the status of the issues. Should open issues reported again in the KDE bug tracker? Thank you! -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 453904] New: The icon of Pop-up Notes should not cover text and make it unreadable
https://bugs.kde.org/show_bug.cgi?id=453904 Bug ID: 453904 Summary: The icon of Pop-up Notes should not cover text and make it unreadable Product: okular Version: 22.04.1 Platform: Flatpak OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: PDF backend Assignee: okular-de...@kde.org Reporter: christian.goe...@mailbox.org Target Milestone: --- Created attachment 148889 --> https://bugs.kde.org/attachment.cgi?id=148889&action=edit Pup-up note icon in Okular renders tex unreadable I just went through a big pdf-document, as I was asked to put my comments to an existing document. I was using the annotation tool of Okular. (Thank you, developers! I will donate for sure :-) ) Whenever I added a pop-up note and put my comment, the presence of the comment was made visible by an icon. The issue is, that the icon covers a lot of text, in my case. This made it really hard to continue proof reading the document, since the icon covers two and a half lines of text. STEPS TO REPRODUCE 1. Select the pop-up note in the annotation bar and left click to the place where you want to put the note 2. Write your text to the note and close the text window OBSERVED RESULT An icon is shown above the text. The icon is not transparent and covers several lines of text. This make it impossible to read the text behind the icon. (I will attach a screenshot) EXPECTED RESULT Either the icon should be much smaller - or maybe a semi transparent icon, that allows to read the text behind the icon. Other solution: Make the icon semitransparent (but still clickable) when hovering with the mouse over the icon? SOFTWARE/OS VERSIONS Okular 22.04.1 installed on Linux Mint 20.3 via flathub. PDF Backend Version 0.6.5 Using Poppler 22.05.0 Qt Version: Please let me know if you need additional information. Keep up the good work. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 453907] New: Provide a visual hint if annotations are combined with pup-up notes
https://bugs.kde.org/show_bug.cgi?id=453907 Bug ID: 453907 Summary: Provide a visual hint if annotations are combined with pup-up notes Product: okular Version: 22.04.1 Platform: Flatpak OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: PDF backend Assignee: okular-de...@kde.org Reporter: christian.goe...@mailbox.org Target Milestone: --- Created attachment 148892 --> https://bugs.kde.org/attachment.cgi?id=148892&action=edit Highlighted text annotations but impossible to guess which ones contain notes When proofreading pdf-files a very common pattern is the use of a combination of visual highlighting combined with a pup-up note. The issue is that once the pop-up note is closed - there is no visual clue, that the highlighted text is actually combined with a pop-up note. It would be great if the highlighting itself could contain a visual hint. E.g. in the form of a small semitransparent square or dot at the end of the highlighting. This applies to the following annotations: highlight, underline, squiggle and strike-out. Workaround: point your cursor above an annotation and wait, the note will be displayed as a hint, after a small amount of time. However, this is annoying in cases with many highlighted text pieces, when only some parts are combined with notes. In this case you have to put your cursor above each highlighted text to check for notes. STEPS TO REPRODUCE 1. Highlight text in a document. 2. Point to the highlight marker, right click, choose: "Open pop-up note" - to generate a combined "highlight with note" 3. Write your comment into the pop-up note and close the pop-up window. OBSERVED RESULT There is no visual clue, that the highlighting is combined with a pop-up note. EXPECTED RESULT There should be a visual clue, that the highlighting is combined with a pup-up note. SOFTWARE/OS VERSIONS Linux Mint 20.03 Okular installed via Flatpak (20.04.1) -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 453910] New: Allow the immediate combination of highlighting with pop-up notes
https://bugs.kde.org/show_bug.cgi?id=453910 Bug ID: 453910 Summary: Allow the immediate combination of highlighting with pop-up notes Product: okular Version: 22.04.1 Platform: Flatpak OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: PDF backend Assignee: okular-de...@kde.org Reporter: christian.goe...@mailbox.org Target Milestone: --- When proofreading pdf-files, a common pattern is the combination of highlighting with a pop-up note. In my use-case this applies to the majority of my own comments. (Obviously, use cases may be very different) :-) I believe it would be very useful to have an option (with an icon in the toolbar) for the combination of highlighting with a pop-up comment. Dream behaviour (of the future): 1. Select the (new) option "highlighting with pop-up note" in the annotation toolbar. 2. Select and highlight text (holding the left mouse key) - when releasing the mouse key, immediately open the combined pup-up note-window 3. let me type the text into the note (via keyboard) 4. bonus: the pop-up note window closes at the first left-click on the document (no close button involved) - Okular should stay in highlighting mode afterwards.Alternative: Use a much bigger close button in the pop-up note window. Currently, there are additional steps involved for combined highlight with pop-up notes: at step 2: currently one hast to select the highlighting marker, right click, choose pop-up note at step 4: close the pop-up window by clicking on the (very small) close button in the pop-up-window. Anyway, this would make the use of annotation easier. It's just a big point on my personal wishlist for Okular. :-D Keep up the great work and let me know it there is something I should ad to the description. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 443482] New: Could not enter shortcut AltGr+F to change to fullscreen on virtualbox
https://bugs.kde.org/show_bug.cgi?id=443482 Bug ID: 443482 Summary: Could not enter shortcut AltGr+F to change to fullscreen on virtualbox Product: krunner Version: unspecified Platform: Neon Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: alexander.loh...@gmx.de Reporter: christian.goe...@mailbox.org CC: plasma-b...@kde.org Target Milestone: --- SUMMARY Using KDE (Plasma,X11) in a VirtualBox, I was not able to switch the full-screen mode using the standard AltGr+f shortcut of VirtualBox. Background: Virtualbox uses AltGr+f as the default HOST shortcut. HOST+f is the standard shortcut to switch the screen mode (e.g. scaled to fullscreen) while using e.g. KDE Neon in VirtualBox. I am not a developer, I am not sure if "krunner" is the correct package for this report. This might be related to bug #295633 and #356773 STEPS TO REPRODUCE 1. Start KDE Neon in VirtualBox. Switch the view to "scaled view" via the GUI of VirtualBox. 2. Enter AltGr+F to switch to fullscreen mode 3. krunner opens showing the special glyph (if the cursor is over the desktop) OBSERVED RESULT The shortcut is not recognized by VirtualBox - instead, KDE handles the shortcut as the input of an alternative glyph/letter. EXPECTED RESULT Switch the screen mode to fullscreen. :-) MY LITTLE ODYSSEY: - First I thought that AltGr+F is a shortcut to open krunner. (This is a trap!) - Then I tried to disable krunner - Then I realised that krunner opens only if I have my cursor above the desktop - Then I tried to disable the opening of krunner when the cursor is - What makes this issue really ugly, is that there is no easy way in Virtualbox to go back to fullscreen without the shortcut - once you are in scaled model. I am not a computer expert! It seems that AltGr+f is always interpreted as typing a letter in the KDE/Plasma Environment. Virtualbox could "not seee" the shortcut. WORKARROUND: Change from default HOST key (i.e. AltGr) to a different key (e.g. Win+Alt) using File>Preference>Input>VirtualMachine>HostKeyKombination in VirtualBox. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neo (in Virtualbox) running on LinuxMint I hope this might be useful. I just spend half an hour understanding whats's going on. :-) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 428122] New: Broken scrolling behavior of KDE neon when installed in VirtualBox
https://bugs.kde.org/show_bug.cgi?id=428122 Bug ID: 428122 Summary: Broken scrolling behavior of KDE neon when installed in VirtualBox Product: kwin Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: libinput Assignee: kwin-bugs-n...@kde.org Reporter: christian.goe...@mailbox.org Target Milestone: --- SUMMARY When installed inside a VirtualBox, the scrolling behavior in the KDE-environment ist broken. Scrolling is interrupted as soon as the mouse pointer moves, which gives a very inconsistent an frustrating scrolling behavior. STEPS TO REPRODUCE 1. Install KDE-Neo inside a VirtualBox (e.g. on Ubuntu 20.04) 2. Open e.g. Discover and try to scroll down the list of updates OBSERVED RESULT Scrolling does not work as it should. Actually it is pretty hard to scroll without moving the mouse at all. EXPECTED RESULT Smooth scrolling - like an install outside of VirtualBox SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE neon 5.20 installed in VirtualBox on Ubuntu 20.04 (available in About System) KDE Plasma Version: 5.20.1 KDE Frameworks Version: 5.75.0 Qt Version: 5.15.0 Workaround: Disable the VirtualBox mouse integration via Xinput. The following worked for me: ~$ xinput ⎡ Virtual core pointer id=2[master pointer (3)] ⎜ ↳ Virtual core XTEST pointerid=4[slave pointer (2)] ⎜ ↳ VirtualBox mouse integration id=9[slave pointer (2)] ⎜ ↳ ImExPS/2 Generic Explorer Mouse id=11 [slave pointer (2)] ⎣ Virtual core keyboard id=3[master keyboard (2)] ↳ Virtual core XTEST keyboard id=5[slave keyboard (3)] ↳ Power Button id=6[slave keyboard (3)] ↳ Sleep Button id=7[slave keyboard (3)] ↳ Video Bus id=8[slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=10 [slave keyboard (3)] ~$ xinput disable 9 ADDITIONAL INFORMATION I had the same experience with older versions of KDE neon, VirtualBox and Ubuntu - so it seems that the problem is not due to a recent regression. Xfce offers a options in the mouse-setting that allows to disables VirtualBox mouse integration (permanently) - which offers an accessible way to fix the bad scrolling experience when installed inside a VirtualBox. The problem seems to be related to VirtualBox mouse integration, and should/could probably fixed there. :-( It would be great is there would be an (GUI) option to disable it. Please feel free to move the bug report to another component. I had a hard time to decide if this is the correct place (Kwin, libinput) to report the bug. Keep up the great work. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 428122] Broken scrolling behavior of KDE neon when installed in VirtualBox
https://bugs.kde.org/show_bug.cgi?id=428122 --- Comment #1 from goebbe --- Collecting addidional information on the issue: https://forums.virtualbox.org/viewtopic.php?f=3&t=83614#p431647 It seems libinput *ignores* scroll button events from one device while another device sends movement events, which is the case for mouse integration: the virtual touchpad sends (tons of) movement updates, while the virtual ps/2 mouse scrollwheel sends button events. With mouse integration disabled, both events are sent by the same virtual ps/2 mouse. Most notably, both libinput-debug-events and xev receive events correctly in all cases. This explains why the first workaround (disabling VirtualBox mouse integration) works. The following points to another workaround: https://superuser.com/questions/1270811/inconsistent-and-erratic-mouse-wheel-in-linux-while-moving-the-mouse-pointer Second workaround - as decribed on superuser.com: Replace libinput by xf86-input-evdev in combination with imwheel I hope this helps. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 428122] Broken scrolling behavior of KDE neon when installed in VirtualBox
https://bugs.kde.org/show_bug.cgi?id=428122 --- Comment #3 from goebbe --- This is a reference to the three year old bug report on Virtualbox: https://www.virtualbox.org/ticket/17270 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 428122] Broken scrolling behavior of KDE neon when installed in VirtualBox
https://bugs.kde.org/show_bug.cgi?id=428122 --- Comment #4 from goebbe --- ... and a two year old bug report for xf86-input-libinput: https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/issues/9 -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 461547] Incorrect markup rendering with diacritics such as accents and umlauts
https://bugs.kde.org/show_bug.cgi?id=461547 goebbe changed: What|Removed |Added Attachment #153552|0 |1 is obsolete|| --- Comment #8 from goebbe --- Created attachment 164798 --> https://bugs.kde.org/attachment.cgi?id=164798&action=edit Screenshot - illustration of issue - update Since some of the cases are fixed, I tried to gather more cases, where the issue still occurs. The new screenshot illustrates the remaining issues. -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 461547] Incorrect markup rendering with diacritics such as accents and umlauts
https://bugs.kde.org/show_bug.cgi?id=461547 --- Comment #9 from goebbe --- Here Is the text that has been used for the new screenshot: Examples of issues when highlighting (bold/ italic) text that contains Umlauts or accents: *Überschrift* **Überschrift**<- first italic, second bold? *ä* *ö* *ü* *ß* *á* *â* *à* ** <- all italic? **ä** **ö** **ü** **ß** **á** **â** **à**<- all bold? **aä** **aäa** **dö** should_be_normal **üadfafasd** <- mix bold and normal text **äa** **aäa** **äa** **öfö** **üadfafasd** <- all bold? **aäa** **äa** **aäa** **öfö** **üadfafasd** <- all bold, including the markup? **Whateverö** normal text **final word** <- the first word should be bold **Whateverö** normal text **öfinal word** <- bold normal bold *Whateverö* normal text *final word* <- italic, normal, italic? *Whateverö* normal text *öfinal word* <- italic, normal, italic? *Whateverö* normal text **öfinal word** <- italic, normal, bold? **Whateverö** normal text *öfinal word* <- bold, normal, italic? a o u *a* *o* *u* ä ö ü *ä* *ö* *ü*<- single umlauts do not work **a** **o** **u** **ä** **ö** **ü** aa oo uu uu *aa* *oo* *uu* *uu* <- issue with the markdown - no umlauts involved!! *äa* *oö* *uü* *uü* <- different rendering for first and last position> *aä* *öo* *üu* *üu* *aaa* *ooo* *uuu* *aäa* *oöo* *uüu*<- no issue when umlauts are in the middle of a word **aaa** aaa **aaa** **aaa** aaa **aaä** **aaä** aaa **aaä** **aaa** aaa **äaa** <- the aaa in the middle should be normal text **aaa**a**äaa** <- markdown is renderen differently, here -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 461547] Incorrect markup rendering with diacritics such as accents and umlauts
https://bugs.kde.org/show_bug.cgi?id=461547 --- Comment #7 from goebbe --- (In reply to megan.conkle from comment #6) > My apologies. I was indeed able to reproduce this. It appears the bug only > occurs when the umlaut is at the front or end of the marked up text (i.e., > just after the first '*' or before the last '*'). Thanks for the info! Thanks for looking into this! Yes, you are right. I realize only now, that some of the cases, that I have originally reported have indeed already been fixed. This is, why some of the problems, illustrated in my original screenshots, are not present any more! -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 476641] New: Just a big thank you!
https://bugs.kde.org/show_bug.cgi?id=476641 Bug ID: 476641 Summary: Just a big thank you! Classification: Applications Product: ghostwriter Version: 23.07.90 Platform: Mint (Ubuntu based) OS: Linux Status: REPORTED Severity: task Priority: NOR Component: general Assignee: megan.con...@kdemail.net Reporter: christian.goe...@mailbox.org Target Milestone: --- SUMMARY *** I just finished another small writing project using ghostwriter and I want to express my gratitude. Thank you for keeping this project alive and for all the effort you put into this! *** STEPS TO REPRODUCE 1. open ghostwriter 2. start writing 3. finish your project and be happy 4. donate 10€ to KDE e.V. since it is not possible to donate to ghostwriter directly OBSERVED RESULT There are some bugs, but is still just such a nice tool for writing. -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 461547] New: Miss-placed markup rendering with composed letters
https://bugs.kde.org/show_bug.cgi?id=461547 Bug ID: 461547 Summary: Miss-placed markup rendering with composed letters Classification: Applications Product: ghostwriter Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: megan.con...@kdemail.net Reporter: christian.goe...@mailbox.org Target Milestone: --- Created attachment 153552 --> https://bugs.kde.org/attachment.cgi?id=153552&action=edit Screenshot issue missplaced markdown with composed letters in gw SUMMARY In some cases, the markup rendering seems to be displaced, when using composed Letters (e.g. German Umlauts) in a paragraph. The issue seems only to appear in a paragraph that follows after a newline. STEPS TO REPRODUCE 1. Write a few letters/ word and hit enter to go to a new line 2. In the new line, write some words, using Markdown. e.g. in bold or in italic. 3. Type a composed letter, e.g. ä or é in this paragraph. OBSERVED RESULT The word in markdown (step 2) are not rendered correctly. It seems that the grey colour is applied one letter too late. EXPECTED RESULT Typing composed letters should not affect the rendering of Markdown. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Linux Mint 21 CE Ghostwriter Version: 2.2.0 (flatpak install) Qt Version: 5.15.3 -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 461547] Miss-placed markup rendering with composed letters
https://bugs.kde.org/show_bug.cgi?id=461547 --- Comment #1 from goebbe --- Created attachment 153553 --> https://bugs.kde.org/attachment.cgi?id=153553&action=edit Example md file for displaced markdown with composed letters -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 461549] New: bold or italic markdown does not show consistently when text starts or ends with a composed letter
https://bugs.kde.org/show_bug.cgi?id=461549 Bug ID: 461549 Summary: bold or italic markdown does not show consistently when text starts or ends with a composed letter Classification: Applications Product: ghostwriter Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: megan.con...@kdemail.net Reporter: christian.goe...@mailbox.org Target Milestone: --- Created attachment 153554 --> https://bugs.kde.org/attachment.cgi?id=153554&action=edit screenshot issue bold and italic with composed letters SUMMARY When using composed letters, depending on the position of the composed letter in a bold or italic text, the markdown shows/ does not show or spans between two bold/ italic words. STEPS TO REPRODUCE 1. Write words that contain composed letters, mark the word as bod or italic 2. Place composed letters at the start, in the middle or at the end of the words OBSERVED RESULT Word that contain composed letters are not always showing/ displaying the expected markdown. It seems to make a difference where the composed letter is located within a word. Composed letters at the start or at the end of a word seems to lead to issues, displaying the markdown. If the composed letter is at the end of a word, the "*" directly following the composed letter, seems to be ignored. It seems like the code "recognizing" the start and end of Markdown and the code which renders the markdown are treating composed letters differently. EXPECTED RESULT Markdown should consistently be recognized and rendered. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Linux Mint 21 CE Ghostwriter: 2.2 installed via flatpak Qt Version: 5.15.3 -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 461549] bold or italic markdown does not show consistently when text starts or ends with a composed letter
https://bugs.kde.org/show_bug.cgi?id=461549 --- Comment #1 from goebbe --- Created attachment 153555 --> https://bugs.kde.org/attachment.cgi?id=153555&action=edit Example md file for issue with bold italc and composed letters -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 462544] New: Please clarify where issues and bugs for ghostwriter should be reported
https://bugs.kde.org/show_bug.cgi?id=462544 Bug ID: 462544 Summary: Please clarify where issues and bugs for ghostwriter should be reported Classification: Applications Product: ghostwriter Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: megan.con...@kdemail.net Reporter: christian.goe...@mailbox.org Target Milestone: --- The webpage of ghostwriter https://ghostwriter.kde.org/ refers to the following repository: https://invent.kde.org/office/ghostwriter What I found confusing is that there seems to be another issue tracker attached to that repository. https://invent.kde.org/office/ghostwriter/-/issues There have been (different) issues reported there, during recent weeks. So currently there seem to be two places where issues can be reported? 1. https://invent.kde.org/office/ghostwriter/-/issues 2. bugzilla: https://bugs.kde.org/ Since, I suppose, that the pages refer to the very same project, it would be great if the official (if any) place for reporting bugs could be clarified. -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 462544] Please clarify where issues and bugs for ghostwriter should be reported
https://bugs.kde.org/show_bug.cgi?id=462544 --- Comment #2 from goebbe --- @Nate Graham: Thank you, for looking into this. A Banner would clearly solve this. :-) However, following your link, I cannot see any visible banner. Will attach a screenshot. Perhaps the missing banner is due to one of the following: - using Firefox on Linux Mint 21 - with uBlock Origin (Add blocker) - I am not logged in Update: Disabling the Add blocker and reload does not change anything. -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 462544] Please clarify where issues and bugs for ghostwriter should be reported
https://bugs.kde.org/show_bug.cgi?id=462544 --- Comment #3 from goebbe --- Created attachment 154269 --> https://bugs.kde.org/attachment.cgi?id=154269&action=edit gitlab page without the banner -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 462544] Please clarify where issues and bugs for ghostwriter should be reported
https://bugs.kde.org/show_bug.cgi?id=462544 --- Comment #5 from goebbe --- Thank you, after creating a KDE identity and login, it worked as advertised. :-) I guess, this works well from the developer's point of view. But it is a complicated process from a users point of view, who just wants to report a bug. Would it be helpful, if I open a new issue (on https://invent.kde.org/office/ghostwriter/-/issues) with title: "ATTENTION: Please use https://bugs.kde.org for reporting issues or suggestions" in addition? Not sure if bug reports can be pinned, though. Anyway, all the best. -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 461547] Incorrect markup rendering with diacritics such as accents and umlauts
https://bugs.kde.org/show_bug.cgi?id=461547 --- Comment #10 from goebbe --- @megan.con...@kdemail.net I just tested with the latest flatpak build of ghostwriter 24.12.0 - and I am happy to report that my reported issues, concerning diacritics such as accents and umlauts are basically resolved. I checked my examples, provided in my last post: Independent of diacritics the actual text is set in bold or italics correctly. Therefore, as the original reporter, I recommend closing this issue. Whoever fixed this, thank you very much. There are (related?) issues with lowlighting/greylighting the actual markup (e.g. **) in the md editor. The issues are different when diacritics are involved. I will search/open a new issue and add an example file. -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 497611] New: Rendering issues concerning highlight/lowlight of markdown in the md-editor
https://bugs.kde.org/show_bug.cgi?id=497611 Bug ID: 497611 Summary: Rendering issues concerning highlight/lowlight of markdown in the md-editor Classification: Applications Product: ghostwriter Version: 24.12.0 Platform: Mint (Ubuntu based) OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: megan.con...@kdemail.net Reporter: christian.goe...@mailbox.org Target Milestone: --- Created attachment 176711 --> https://bugs.kde.org/attachment.cgi?id=176711&action=edit Screenshot showing lowlighting issues for markdown in the md-editor SUMMARY When editing .md files in ghostwriter, sometimes I observe rendering issues concerning the lowlighting/ greylighting of the actual markdown. OBSERVED RESULT Sometimes the lowlighting seems to be some letters off - as a result, sometimes the markdown is not lowlighted and sometimes the actual text or parts of the actual text is lowlighted. EXPECTED RESULT Expected result: Only the markdown marks are actually lowlighted, but the very text of the document is rendered normally. STEPS TO REPRODUCE 1. Put text starting with markdown at the start of a new line **a** 2. The markup and only the markup "**" should be lowlighted 3. However, sometimes this does now work as expected (screenshot is attached) Text to reproduce the issues - for copy and pasting to ghostwriter: normal and italic: a o u ä ö ü *a* *o* *u*<- highlighting in md seems reversed *t* *s* *w* *ä* *ö* *ü*<- different rendering with single umlauts (diacritics) aa oo uu uu *aa* *oo* *uu* *uu* <- issue with the markdown - no umlauts involved!! *äa* *oö* *uü* *uü* <- different rendering for first and last position> *aä* *öo* *üu* *üu* *aaa* *ooo* *uuu* *aäa* *oöo* *uüu*<- no issue when umlauts are in the middle of a word *aaa* *ooo* *uuu*<- after an empty line nomal and bold: a o u ä ö ü **a** **o** **u** **ä** **ö** **ü** **aa** **oo** **uu** **äa** **öo** **üu** **aä** **oö** **uü** **aaa** **ooo** **uuu** **äaa** **öoo** **üuu** **äaä** **öoö** **üuü** **aäa** **oöo** **üuü** -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 453907] Provide a visual hint if annotations are combined with pop-up notes
https://bugs.kde.org/show_bug.cgi?id=453907 --- Comment #6 from goebbe --- (In reply to Grósz Dániel from comment #5) > This is a duplicate of Bug 440248, isn't it? I guess you are right - both reports are about the same issue and suggest/ request similar solutions. This one is perhaps a tiny bit more explicit, talking about "Pop up Notes" and also naming the different types of highlighting that can be combined with pop-up-notes. -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 497611] Rendering issues concerning highlight/lowlight of markdown in the md-editor
https://bugs.kde.org/show_bug.cgi?id=497611 --- Comment #3 from goebbe --- Reproduce rendering issues with leading asterix (*), when typing text (no copy/paste involved): 1. Open a new file and type the following text (two lines): *a* * a 2. Now go back to the first line and delete the last asterix using the DEL key Another one: 1. Open a new file and type the following text (two lines) - there are 4 leading white spaces in the first line: *a* a 2. Now go back to the first line and delete the leading 4 white spaces -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 497611] Rendering issues concerning highlight/lowlight of markdown in the md-editor
https://bugs.kde.org/show_bug.cgi?id=497611 --- Comment #4 from goebbe --- Another interesting one: 1. Open a new file and type the following text (three lines) - it is important to start with a whitespace " " in the first line, followed by an umlaut e.g. "ä" (note the two points above the "a" - the same issue appears when using e.g. a French accented "é" instead). Important: There is NO whitespace in the second and third line: ä **a** **ä** 2. The rendering issues are immediately visible. -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 497611] Rendering issues concerning highlight/lowlight of markdown in the md-editor
https://bugs.kde.org/show_bug.cgi?id=497611 --- Comment #2 from goebbe --- @John Kitzer Thanks for looking into this. You are right: When typing my example text (not copy/paste), most of the rendering is fine, directly after typing. - However, some rendering issues appear, as soon as the newly typed text is copied/ pasted - even though, in this case, the rendering issues are different and only concern the first asterix on a line. - Sometimes these type of rendering issues appear even without copying pasting - however I will try to come up with reproducible examples and add another comment. - Just copying my example text from my first post to ghostwriter - I am still able to reproduce the rendering issues from the attached screenshot. - The rendering issues seem to re-appear when save/ restart ghostwriter / reopen the file. -- You are receiving this mail because: You are watching all bug changes.
