Re: Problem with digitaly sign
El dissabte, 7 de setembre del 2024, a les 16:15:46 (CEST), kvstjepan va escriure: > Dear Sir, > > I would use Ocular for digital signing. Everything works normally under > Linux Mint, except that the last letter of my last name is not visible > in the digital signature field. Looks like Ocular is limited to 15 > characters, and my first and last name including spaces takes up 16 > characters. Is it possible for you to correct this in the code or write > me exactly where the problem is so that I can correct it myself. Thanks. Can you just "drag" a bigger rectangle when "drawing" the rectangle where the signature is going to be? Cheers, Albert > Kind regards > > Stjepan Blažević >
Re: Add autosave function to Okular
El dimecres, 24 de juliol del 2024, a les 15:04:42 (CEST), Wen Chang va escriure: > > As Laura described yes, as you described it no. > > > > Okular is not a file management system, you use git or whatever other > > tool for > > > that, keeping N old copies of the same file makes no sense. > > > > Cheers, > > > > Albert > > I agree with your decision and can implement Laura's idea. > > Could you please let me know how to contribute to this feature? https://okular.kde.org/build-it/ https://community.kde.org/Get_Involved/development But in short, just create a Merge Request in https://invent.kde.org/graphics/okular Cheers, Albert > > I am not familiar with KDE policies. > > Thank you. > > Best, > Wen > 於 2024年7月24日 週三 下午5:07寫道： > > > Send Okular-devel mailing list submissions to > > > > okular-devel@kde.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > > https://mail.kde.org/mailman/listinfo/okular-devel > > > > or, via email, send a message with subject or body 'help' to > > > > okular-devel-requ...@kde.org > > > > You can reach the person managing the list at > > > > okular-devel-ow...@kde.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Okular-devel digest..." > > > > Today's Topics: > >1. Re: Add autosave function to Okular (Albert Astals Cid) > >2. Re: Add possibility to adjust the font size for PDF form > > > > filling (Albert Astals Cid) > > > >3. [okular] [Bug 490714] The program is not restored from a > > > > saved session after another update. (Albert Astals Cid) > > > >4. Re: Add possibility to adjust the font size for PDF form > > > > filling (Andy Sardina) > > > >5. [okular] [Bug 490714] The program is not restored from a > > > > saved session after another update. (Adrian Carver) > > > > -- > > > > Message: 1 > > Date: Tue, 23 Jul 2024 23:50:13 +0200 > > From: Albert Astals Cid > > To: okular-devel@kde.org > > Subject: Re: Add autosave function to Okular > > Message-ID: <15943638.68RGZT8oEa@xps15> > > Content-Type: text/plain; charset="utf-8" > > > > El dilluns, 22 de juliol del 2024, a les 7:28:12 (CEST), Wen Chang va > > > > escriure: > > > > Exactly, auto save is just not how desktop software generally works. > > > > > > > > Cheers, > > > > > > > > Albert > > > > > > Could we implement the backup method for Okular? > > > > As Laura described yes, as you described it no. > > > > Okular is not a file management system, you use git or whatever other tool > > for > > that, keeping N old copies of the same file makes no sense. > > > > Cheers, > > > > Albert > > > > > Best, > > > Wen > > > 於 2024年7月18日 週四 下午7:00寫道： > > > > > > > Send Okular-devel mailing list submissions to > > > > > > > > okular-devel@kde.org > > > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > > > > > > https://mail.kde.org/mailman/listinfo/okular-devel > > > > > > > > or, via email, send a message with subject or body 'help' to > > > > > > > > okular-devel-requ...@kde.org > > > > > > > > You can reach the person managing the list at > > > > > > > > okular-devel-ow...@kde.org > > > > > > > > When replying, please edit your Subject line so it is more specific > > > > than "Re: Contents of Okular-devel digest..." > > > > > > > > Today's Topics: > > > >1. [okular] [Bug 490337] Allow to get PDF passwords from a > > > > > > > > org.freedesktop.secrets service (yan12125) > > > > > > > >2. [okular] [Bug 490337] Allow to get PDF passwords from a > > > > > > > > org.freedesktop.secrets service (Albert Astals Cid) > > > > > > > >3. Re: Add autosave function to Okular (Albert Astals Cid) > > > >4. Re: Add autosave function to Okular (Wen C
Re: Add possibility to adjust the font size for PDF form filling
Aha!! If you are already working on it, please just go ahead! On Wed, 24 Jul 2024 at 12:09 PM Pratham Gandhi wrote: > Hey Andy, > I am already working on this. Will try to raise an MR for this by this or > next weekend. If you'd still like to take this up, I can share my progress > with you. > The same issue exists with combo box, list box, etc. Not sure, but some > change could be required on poppler end as well. > > Cheers, > Pratham > > On Wed, 24 Jul, 2024, 1:05 pm Andy Sardina, > wrote: > >> Cool! >> >> I’ll work on a PR and avoid sharing pointers between the two levels. >> >> On Wed, 24 Jul 2024 at 1:11 AM Albert Astals Cid wrote: >> >>> El dimarts, 23 de juliol del 2024, a les 12:46:59 (CEST), Andy Sardina >>> va >>> escriure: >>> > Hi, >>> > >>> >I have used Okular recently to fill a PDF form and I haven't found >>> a way >>> > (in the UI) to adjust the font size for text fields. This is a problem >>> > because for some text fields, specially the ones where one has to >>> write an >>> > address, even if the text fits perfectly in the Okular::FormLineEdit, >>> when >>> > it gets rendered, the text could be cut. >>> > >>> > For example: >>> > >>> > [image: form-show.png] >>> > >>> > but when the form is hidden: >>> > >>> > [image: form-hidden.png] >>> > >>> > The problem seems to be that the font (and font size) for the >>> > Okular::FormLineEdit is different from the one in the Default >>> Appearance >>> > (DA) in the PDF. >>> > >>> > My proposal is to take advantage of the method >>> > Poppler::FormFieldText::setTextFontSize to adjust the font size in >>> > the PopplerFormFieldText (Poppler Generator). >>> > >>> > Ideally, Poppler::FormFieldText could have a member function that >>> returns a >>> > pointer (to avoid duplicating the same object if many text files share >>> the >>> > same font) to >>> > the font defined in the DA (implies changes in Poppler itself). This >>> font >>> > can then be used on the constructor of Okular::FormLineEdit to "sync" >>> both >>> > fonts. >>> > >>> > What do you think? Is this a change that could be accepted? >>> >>> Setting the font & font size is possibly a valid feature, we do that >>> already >>> for annotations so i don't see why we would not do it for Forms. >>> >>> What you suggest of sharing pointers between poppler and okular, that's >>> possibly a bad idea. >>> >>> Cheers, >>> Albert >>> >>> >>>
Re: Add autosave function to Okular
> As Laura described yes, as you described it no. > > Okular is not a file management system, you use git or whatever other tool for > that, keeping N old copies of the same file makes no sense. > > Cheers, > Albert I agree with your decision and can implement Laura's idea. Could you please let me know how to contribute to this feature? I am not familiar with KDE policies. Thank you. Best, Wen 於 2024年7月24日 週三 下午5:07寫道： > Send Okular-devel mailing list submissions to > okular-devel@kde.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.kde.org/mailman/listinfo/okular-devel > or, via email, send a message with subject or body 'help' to > okular-devel-requ...@kde.org > > You can reach the person managing the list at > okular-devel-ow...@kde.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Okular-devel digest..." > > > Today's Topics: > >1. Re: Add autosave function to Okular (Albert Astals Cid) >2. Re: Add possibility to adjust the font size for PDF form > filling (Albert Astals Cid) >3. [okular] [Bug 490714] The program is not restored from a > saved session after another update. (Albert Astals Cid) >4. Re: Add possibility to adjust the font size for PDF form > filling (Andy Sardina) >5. [okular] [Bug 490714] The program is not restored from a > saved session after another update. (Adrian Carver) > > > ------ > > Message: 1 > Date: Tue, 23 Jul 2024 23:50:13 +0200 > From: Albert Astals Cid > To: okular-devel@kde.org > Subject: Re: Add autosave function to Okular > Message-ID: <15943638.68RGZT8oEa@xps15> > Content-Type: text/plain; charset="utf-8" > > El dilluns, 22 de juliol del 2024, a les 7:28:12 (CEST), Wen Chang va > escriure: > > > Exactly, auto save is just not how desktop software generally works. > > > > > > Cheers, > > > > > > Albert > > > > Could we implement the backup method for Okular? > > As Laura described yes, as you described it no. > > Okular is not a file management system, you use git or whatever other tool > for > that, keeping N old copies of the same file makes no sense. > > Cheers, > Albert > > > > > Best, > > Wen > > 於 2024年7月18日 週四 下午7:00寫道： > > > > > Send Okular-devel mailing list submissions to > > > > > > okular-devel@kde.org > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > > > > https://mail.kde.org/mailman/listinfo/okular-devel > > > > > > or, via email, send a message with subject or body 'help' to > > > > > > okular-devel-requ...@kde.org > > > > > > You can reach the person managing the list at > > > > > > okular-devel-ow...@kde.org > > > > > > When replying, please edit your Subject line so it is more specific > > > than "Re: Contents of Okular-devel digest..." > > > > > > Today's Topics: > > >1. [okular] [Bug 490337] Allow to get PDF passwords from a > > > > > > org.freedesktop.secrets service (yan12125) > > > > > >2. [okular] [Bug 490337] Allow to get PDF passwords from a > > > > > > org.freedesktop.secrets service (Albert Astals Cid) > > > > > >3. Re: Add autosave function to Okular (Albert Astals Cid) > > >4. Re: Add autosave function to Okular (Wen Chang) > > >5. [okular] [Bug 490435] New: printing from the selected range > > > > > > of pages does not work correctly (Nazar) > > > > > > -- > > > > > > Message: 1 > > > Date: Wed, 17 Jul 2024 13:59:53 + > > > From: yan12125 > > > To: okular-devel@kde.org > > > Subject: [okular] [Bug 490337] Allow to get PDF passwords from a > > > > > > org.freedesktop.secrets service > > > > > > Message-ID: > > > Content-Type: text/plain; charset=UTF-8 > > > > > > https://bugs.kde.org/show_bug.cgi?id=490337 > > > > > > --- Comment #2 from yan12125 --- > > > Ah, I forgot the main point: I use neither KDE nor kwalletd. Instead, I > > > use > > > KeePassXC as a cross-platform solution to manage all my secrets. That > > > program >
Re: Add possibility to adjust the font size for PDF form filling
Hey Andy, I am already working on this. Will try to raise an MR for this by this or next weekend. If you'd still like to take this up, I can share my progress with you. The same issue exists with combo box, list box, etc. Not sure, but some change could be required on poppler end as well. Cheers, Pratham On Wed, 24 Jul, 2024, 1:05 pm Andy Sardina, wrote: > Cool! > > I’ll work on a PR and avoid sharing pointers between the two levels. > > On Wed, 24 Jul 2024 at 1:11 AM Albert Astals Cid wrote: > >> El dimarts, 23 de juliol del 2024, a les 12:46:59 (CEST), Andy Sardina va >> escriure: >> > Hi, >> > >> >I have used Okular recently to fill a PDF form and I haven't found a >> way >> > (in the UI) to adjust the font size for text fields. This is a problem >> > because for some text fields, specially the ones where one has to write >> an >> > address, even if the text fits perfectly in the Okular::FormLineEdit, >> when >> > it gets rendered, the text could be cut. >> > >> > For example: >> > >> > [image: form-show.png] >> > >> > but when the form is hidden: >> > >> > [image: form-hidden.png] >> > >> > The problem seems to be that the font (and font size) for the >> > Okular::FormLineEdit is different from the one in the Default Appearance >> > (DA) in the PDF. >> > >> > My proposal is to take advantage of the method >> > Poppler::FormFieldText::setTextFontSize to adjust the font size in >> > the PopplerFormFieldText (Poppler Generator). >> > >> > Ideally, Poppler::FormFieldText could have a member function that >> returns a >> > pointer (to avoid duplicating the same object if many text files share >> the >> > same font) to >> > the font defined in the DA (implies changes in Poppler itself). This >> font >> > can then be used on the constructor of Okular::FormLineEdit to "sync" >> both >> > fonts. >> > >> > What do you think? Is this a change that could be accepted? >> >> Setting the font & font size is possibly a valid feature, we do that >> already >> for annotations so i don't see why we would not do it for Forms. >> >> What you suggest of sharing pointers between poppler and okular, that's >> possibly a bad idea. >> >> Cheers, >> Albert >> >> >>
Re: Add possibility to adjust the font size for PDF form filling
Cool! I’ll work on a PR and avoid sharing pointers between the two levels. On Wed, 24 Jul 2024 at 1:11 AM Albert Astals Cid wrote: > El dimarts, 23 de juliol del 2024, a les 12:46:59 (CEST), Andy Sardina va > escriure: > > Hi, > > > >I have used Okular recently to fill a PDF form and I haven't found a > way > > (in the UI) to adjust the font size for text fields. This is a problem > > because for some text fields, specially the ones where one has to write > an > > address, even if the text fits perfectly in the Okular::FormLineEdit, > when > > it gets rendered, the text could be cut. > > > > For example: > > > > [image: form-show.png] > > > > but when the form is hidden: > > > > [image: form-hidden.png] > > > > The problem seems to be that the font (and font size) for the > > Okular::FormLineEdit is different from the one in the Default Appearance > > (DA) in the PDF. > > > > My proposal is to take advantage of the method > > Poppler::FormFieldText::setTextFontSize to adjust the font size in > > the PopplerFormFieldText (Poppler Generator). > > > > Ideally, Poppler::FormFieldText could have a member function that > returns a > > pointer (to avoid duplicating the same object if many text files share > the > > same font) to > > the font defined in the DA (implies changes in Poppler itself). This font > > can then be used on the constructor of Okular::FormLineEdit to "sync" > both > > fonts. > > > > What do you think? Is this a change that could be accepted? > > Setting the font & font size is possibly a valid feature, we do that > already > for annotations so i don't see why we would not do it for Forms. > > What you suggest of sharing pointers between poppler and okular, that's > possibly a bad idea. > > Cheers, > Albert > > >
Re: Add possibility to adjust the font size for PDF form filling
El dimarts, 23 de juliol del 2024, a les 12:46:59 (CEST), Andy Sardina va escriure: > Hi, > >I have used Okular recently to fill a PDF form and I haven't found a way > (in the UI) to adjust the font size for text fields. This is a problem > because for some text fields, specially the ones where one has to write an > address, even if the text fits perfectly in the Okular::FormLineEdit, when > it gets rendered, the text could be cut. > > For example: > > [image: form-show.png] > > but when the form is hidden: > > [image: form-hidden.png] > > The problem seems to be that the font (and font size) for the > Okular::FormLineEdit is different from the one in the Default Appearance > (DA) in the PDF. > > My proposal is to take advantage of the method > Poppler::FormFieldText::setTextFontSize to adjust the font size in > the PopplerFormFieldText (Poppler Generator). > > Ideally, Poppler::FormFieldText could have a member function that returns a > pointer (to avoid duplicating the same object if many text files share the > same font) to > the font defined in the DA (implies changes in Poppler itself). This font > can then be used on the constructor of Okular::FormLineEdit to "sync" both > fonts. > > What do you think? Is this a change that could be accepted? Setting the font & font size is possibly a valid feature, we do that already for annotations so i don't see why we would not do it for Forms. What you suggest of sharing pointers between poppler and okular, that's possibly a bad idea. Cheers, Albert
Re: Add autosave function to Okular
El dilluns, 22 de juliol del 2024, a les 7:28:12 (CEST), Wen Chang va escriure: > > Exactly, auto save is just not how desktop software generally works. > > > > Cheers, > > > > Albert > > Could we implement the backup method for Okular? As Laura described yes, as you described it no. Okular is not a file management system, you use git or whatever other tool for that, keeping N old copies of the same file makes no sense. Cheers, Albert > > Best, > Wen > 於 2024年7月18日 週四 下午7:00寫道： > > > Send Okular-devel mailing list submissions to > > > > okular-devel@kde.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > > https://mail.kde.org/mailman/listinfo/okular-devel > > > > or, via email, send a message with subject or body 'help' to > > > > okular-devel-requ...@kde.org > > > > You can reach the person managing the list at > > > > okular-devel-ow...@kde.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Okular-devel digest..." > > > > Today's Topics: > >1. [okular] [Bug 490337] Allow to get PDF passwords from a > > > > org.freedesktop.secrets service (yan12125) > > > >2. [okular] [Bug 490337] Allow to get PDF passwords from a > > > > org.freedesktop.secrets service (Albert Astals Cid) > > > >3. Re: Add autosave function to Okular (Albert Astals Cid) > >4. Re: Add autosave function to Okular (Wen Chang) > >5. [okular] [Bug 490435] New: printing from the selected range > > > > of pages does not work correctly (Nazar) > > > > -- > > > > Message: 1 > > Date: Wed, 17 Jul 2024 13:59:53 + > > From: yan12125 > > To: okular-devel@kde.org > > Subject: [okular] [Bug 490337] Allow to get PDF passwords from a > > > > org.freedesktop.secrets service > > > > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > > https://bugs.kde.org/show_bug.cgi?id=490337 > > > > --- Comment #2 from yan12125 --- > > Ah, I forgot the main point: I use neither KDE nor kwalletd. Instead, I > > use > > KeePassXC as a cross-platform solution to manage all my secrets. That > > program > > also provides org.freedesktop.secrets service like kwalletd. If Okular > > supports > > org.freedesktop.secrets, I can just use KeePassXC instead of setting up > > another > > secrets service for PDF passwords. > > > > -- > > You are receiving this mail because: > > You are the assignee for the bug. > > > > -- > > > > Message: 2 > > Date: Wed, 17 Jul 2024 20:19:56 + > > From: "Albert Astals Cid" > > To: okular-devel@kde.org > > Subject: [okular] [Bug 490337] Allow to get PDF passwords from a > > > > org.freedesktop.secrets service > > > > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > > https://bugs.kde.org/show_bug.cgi?id=490337 > > > > --- Comment #3 from Albert Astals Cid --- > > Ok, i guess that makes some sense, I wouldnt' be against such feature. > > > > -- > > You are receiving this mail because: > > You are the assignee for the bug. > > > > -- > > > > Message: 3 > > Date: Wed, 17 Jul 2024 23:22:41 +0200 > > From: Albert Astals Cid > > To: okular-devel@kde.org > > Subject: Re: Add autosave function to Okular > > Message-ID: <2416547.6LXrqp22Eu@xps15> > > Content-Type: text/plain; charset="utf-8" > > > > El dimecres, 17 de juliol del 2024, a les 7:26:20 (CEST), Laura David > > Hurka va > > > > escriure: > > > On Wed, 17 Jul 2024 11:01:53 +0800 Wen Chang wrote: > > > > I can do it that way by saving the changes in a backup file. > > > > > > > > I would like to know why modifying the file on disk without user > > > > interaction is a bad idea based on your experience. > > > > > > > > Also, I noticed that VSCode automatically saves changes once they are > > > > made. > > > > To my knowledge, only the file that the user is working on will be > > > > modified. > > > > > > > > What drawbacks would there be if a file is directly modified without >
Re: Add autosave function to Okular
> Exactly, auto save is just not how desktop software generally works. > > Cheers, > Albert Could we implement the backup method for Okular? Best, Wen 於 2024年7月18日 週四 下午7:00寫道： > Send Okular-devel mailing list submissions to > okular-devel@kde.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.kde.org/mailman/listinfo/okular-devel > or, via email, send a message with subject or body 'help' to > okular-devel-requ...@kde.org > > You can reach the person managing the list at > okular-devel-ow...@kde.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Okular-devel digest..." > > > Today's Topics: > >1. [okular] [Bug 490337] Allow to get PDF passwords from a > org.freedesktop.secrets service (yan12125) >2. [okular] [Bug 490337] Allow to get PDF passwords from a > org.freedesktop.secrets service (Albert Astals Cid) >3. Re: Add autosave function to Okular (Albert Astals Cid) >4. Re: Add autosave function to Okular (Wen Chang) >5. [okular] [Bug 490435] New: printing from the selected range > of pages does not work correctly (Nazar) > > > -- > > Message: 1 > Date: Wed, 17 Jul 2024 13:59:53 + > From: yan12125 > To: okular-devel@kde.org > Subject: [okular] [Bug 490337] Allow to get PDF passwords from a > org.freedesktop.secrets service > Message-ID: > Content-Type: text/plain; charset=UTF-8 > > https://bugs.kde.org/show_bug.cgi?id=490337 > > --- Comment #2 from yan12125 --- > Ah, I forgot the main point: I use neither KDE nor kwalletd. Instead, I use > KeePassXC as a cross-platform solution to manage all my secrets. That > program > also provides org.freedesktop.secrets service like kwalletd. If Okular > supports > org.freedesktop.secrets, I can just use KeePassXC instead of setting up > another > secrets service for PDF passwords. > > -- > You are receiving this mail because: > You are the assignee for the bug. > > -- > > Message: 2 > Date: Wed, 17 Jul 2024 20:19:56 + > From: "Albert Astals Cid" > To: okular-devel@kde.org > Subject: [okular] [Bug 490337] Allow to get PDF passwords from a > org.freedesktop.secrets service > Message-ID: > Content-Type: text/plain; charset=UTF-8 > > https://bugs.kde.org/show_bug.cgi?id=490337 > > --- Comment #3 from Albert Astals Cid --- > Ok, i guess that makes some sense, I wouldnt' be against such feature. > > -- > You are receiving this mail because: > You are the assignee for the bug. > > -- > > Message: 3 > Date: Wed, 17 Jul 2024 23:22:41 +0200 > From: Albert Astals Cid > To: okular-devel@kde.org > Subject: Re: Add autosave function to Okular > Message-ID: <2416547.6LXrqp22Eu@xps15> > Content-Type: text/plain; charset="utf-8" > > El dimecres, 17 de juliol del 2024, a les 7:26:20 (CEST), Laura David > Hurka va > escriure: > > On Wed, 17 Jul 2024 11:01:53 +0800 Wen Chang wrote: > > > I can do it that way by saving the changes in a backup file. > > > > > > I would like to know why modifying the file on disk without user > > > interaction is a bad idea based on your experience. > > > > > > Also, I noticed that VSCode automatically saves changes once they are > > > made. > > > To my knowledge, only the file that the user is working on will be > > > modified. > > > > > > What drawbacks would there be if a file is directly modified without > user > > > interaction? > > > > Drawback would be that it is unusual and unexpected for many users > (unless > > the user explicitly configured it that way). > > > > Imagine you have a form that you need to fill out often, and then just > print > > once. > > If changes are saved automatically, you can’t use the file the next time > > anymore, because it is already filled. > > > > It would also not make much sense with “Open...”, “Save”, and “Save > As...”. > > Exactly, auto save is just not how desktop software generally works. > > Cheers, > Albert > > > > > Laura > > > > > > > -- > > Message: 4 > Date: Thu, 18 Jul 2024 11:28:31 +0800 > From: Wen Chang > To: okular-devel@kde.org > Subject: Re: Add autosave function to Okular > Message-ID: > < > cakpy6qvptjeynft6v_qb0pb1tjepkue8gprohn-mrgxez_r...@mail.gmail.com> > Con
Re: Add autosave function to Okular
That's indeed the concern of the autosave method. Thanks for letting me know. About your concern, I provide my suggestion as follows: > Drawback would be that it is unusual and unexpected for many users (unless the > user explicitly configured it that way). The autosave function is disabled by default. Once the user clicks the button to turn it on, changes will be saved automatically. This ensures that users are aware they are in autosave mode. Additionally, autosave will remain enabled the next time the user opens Okular. Does implementing the method this way make more sense? Feel free to let me know. > If changes are saved automatically, you can’t use the file the next time > anymore, because it is already filled. In this situation, I suggest saving a backup file whenever the user closes Okular. This would create a list of backup files in a folder located in the same directory as the document. Users would then be able to roll back by checking different versions of the backup files. To my understanding, the current policy in Okular does not allow users to revert to the original version of a file once they have saved it manually, right? Please correct me if I am mistaken. Thanks. Best, Wen 於 2024年7月17日 週三 下午7:00寫道： > Send Okular-devel mailing list submissions to > okular-devel@kde.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.kde.org/mailman/listinfo/okular-devel > or, via email, send a message with subject or body 'help' to > okular-devel-requ...@kde.org > > You can reach the person managing the list at > okular-devel-ow...@kde.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Okular-devel digest..." > > > Today's Topics: > >1. Re: Add autosave function to Okular (Laura David Hurka) > > > -- > > Message: 1 > Date: Wed, 17 Jul 2024 07:26:20 +0200 > From: Laura David Hurka > To: okular-devel@kde.org > Subject: Re: Add autosave function to Okular > Message-ID: <6009722.DvuYhMxLoT@doro> > Content-Type: text/plain; charset="utf-8" > > On Wed, 17 Jul 2024 11:01:53 +0800 Wen Chang wrote: > > I can do it that way by saving the changes in a backup file. > > > > I would like to know why modifying the file on disk without user > > interaction is a bad idea based on your experience. > > > > Also, I noticed that VSCode automatically saves changes once they are > made. > > To my knowledge, only the file that the user is working on will be > modified. > > > > What drawbacks would there be if a file is directly modified without user > > interaction? > > Drawback would be that it is unusual and unexpected for many users (unless > the > user explicitly configured it that way). > > Imagine you have a form that you need to fill out often, and then just > print > once. > If changes are saved automatically, you can’t use the file the next time > anymore, because it is already filled. > > It would also not make much sense with “Open...”, “Save”, and “Save As...”. > > Laura > > > > > -- > > Subject: Digest Footer > > ___ > Okular-devel mailing list > Okular-devel@kde.org > https://mail.kde.org/mailman/listinfo/okular-devel > > > -- > > End of Okular-devel Digest, Vol 214, Issue 22 > * >
Re: Add autosave function to Okular
El dimecres, 17 de juliol del 2024, a les 7:26:20 (CEST), Laura David Hurka va escriure: > On Wed, 17 Jul 2024 11:01:53 +0800 Wen Chang wrote: > > I can do it that way by saving the changes in a backup file. > > > > I would like to know why modifying the file on disk without user > > interaction is a bad idea based on your experience. > > > > Also, I noticed that VSCode automatically saves changes once they are > > made. > > To my knowledge, only the file that the user is working on will be > > modified. > > > > What drawbacks would there be if a file is directly modified without user > > interaction? > > Drawback would be that it is unusual and unexpected for many users (unless > the user explicitly configured it that way). > > Imagine you have a form that you need to fill out often, and then just print > once. > If changes are saved automatically, you can’t use the file the next time > anymore, because it is already filled. > > It would also not make much sense with “Open...”, “Save”, and “Save As...”. Exactly, auto save is just not how desktop software generally works. Cheers, Albert > > Laura
Re: Add autosave function to Okular
On Wed, 17 Jul 2024 11:01:53 +0800 Wen Chang wrote: > I can do it that way by saving the changes in a backup file. > > I would like to know why modifying the file on disk without user > interaction is a bad idea based on your experience. > > Also, I noticed that VSCode automatically saves changes once they are made. > To my knowledge, only the file that the user is working on will be modified. > > What drawbacks would there be if a file is directly modified without user > interaction? Drawback would be that it is unusual and unexpected for many users (unless the user explicitly configured it that way). Imagine you have a form that you need to fill out often, and then just print once. If changes are saved automatically, you can’t use the file the next time anymore, because it is already filled. It would also not make much sense with “Open...”, “Save”, and “Save As...”. Laura
Re: Add autosave function to Okular
I can do it that way by saving the changes in a backup file. I would like to know why modifying the file on disk without user interaction is a bad idea based on your experience. Also, I noticed that VSCode automatically saves changes once they are made. To my knowledge, only the file that the user is working on will be modified. What drawbacks would there be if a file is directly modified without user interaction? Best, Wen 於 2024年7月16日 週二 下午1:51寫道： > Send Okular-devel mailing list submissions to > okular-devel@kde.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.kde.org/mailman/listinfo/okular-devel > or, via email, send a message with subject or body 'help' to > okular-devel-requ...@kde.org > > You can reach the person managing the list at > okular-devel-ow...@kde.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Okular-devel digest..." > > > Today's Topics: > >1. [okular] [Bug 401268] Freehand lines rendered ugly as you > write and look good only after you finish (Fahad Al-Saidi) >2. Re: Add autosave function to Okular (Albert Astals Cid) >3. [okular] [Bug 489490] Saving of externally modified PDF fails > (Bug Janitor Service) >4. [okular] [Bug 401067] Fillable form fields in Okular may show > up as "undefined" (Bug Janitor Service) >5. [okular] [Bug 484557] crash digitally signing a document > (Bug Janitor Service) >6. [okular] [Bug 490337] New: Allow to get PDF passwords from a > org.freedesktop.secrets service (yan12125) > > > -- > > Message: 1 > Date: Mon, 15 Jul 2024 13:18:10 + > From: "Fahad Al-Saidi" > To: okular-devel@kde.org > Subject: [okular] [Bug 401268] Freehand lines rendered ugly as you > write and look good only after you finish > Message-ID: > Content-Type: text/plain; charset=UTF-8 > > https://bugs.kde.org/show_bug.cgi?id=401268 > > Fahad Al-Saidi changed: > >What|Removed |Added > > > CC||fahad.alsa...@gmail.com > > -- > You are receiving this mail because: > You are the assignee for the bug. > > -- > > Message: 2 > Date: Mon, 15 Jul 2024 23:44:51 +0200 > From: Albert Astals Cid > To: okular-devel@kde.org > Subject: Re: Add autosave function to Okular > Message-ID: <10066030.lSEfBjtcgG@xps15> > Content-Type: text/plain; charset="utf-8" > > El dissabte, 13 de juliol del 2024, a les 7:05:54 (CEST), Wen Chang va > escriure: > > > I not asking you about your problem. > > > > > > You are suggesting a solution that you call "Add autosave function". > > > > > > I am asking you how would your suggestion behave in this scenario > > > > > > * Open Okular > > > * Open file > > > * Make annotation > > > * Close Okular > > > > > > Would the annotation be saved to file without any user interaction? > > > > > > Best Regards, > > > > > > Albert > > > > I see. The annotation will be saved automatically without any user > > interaction once autosave mode is enabled. > > I don't think that's acceptable. Modifying the file on disk without user > interaction is bad. > > What Laura suggests would be much more acceptable. > > Best Regards, > Albert > > > > > Best, > > Wen > > > > 於 2024年7月12日 週五 下午7:00寫道： > > > > > Send Okular-devel mailing list submissions to > > > > > > okular-devel@kde.org > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > > > > https://mail.kde.org/mailman/listinfo/okular-devel > > > > > > or, via email, send a message with subject or body 'help' to > > > > > > okular-devel-requ...@kde.org > > > > > > You can reach the person managing the list at > > > > > > okular-devel-ow...@kde.org > > > > > > When replying, please edit your Subject line so it is more specific > > > than "Re: Contents of Okular-devel digest..." > > > > > > Today's Topics: > > >1. Re: Add autosave function to Okular (Albert Astals Cid) > > > > > >
Re: Add autosave function to Okular
El dissabte, 13 de juliol del 2024, a les 7:05:54 (CEST), Wen Chang va escriure: > > I not asking you about your problem. > > > > You are suggesting a solution that you call "Add autosave function". > > > > I am asking you how would your suggestion behave in this scenario > > > > * Open Okular > > * Open file > > * Make annotation > > * Close Okular > > > > Would the annotation be saved to file without any user interaction? > > > > Best Regards, > > > > Albert > > I see. The annotation will be saved automatically without any user > interaction once autosave mode is enabled. I don't think that's acceptable. Modifying the file on disk without user interaction is bad. What Laura suggests would be much more acceptable. Best Regards, Albert > > Best, > Wen > > 於 2024年7月12日 週五 下午7:00寫道： > > > Send Okular-devel mailing list submissions to > > > > okular-devel@kde.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > > https://mail.kde.org/mailman/listinfo/okular-devel > > > > or, via email, send a message with subject or body 'help' to > > > > okular-devel-requ...@kde.org > > > > You can reach the person managing the list at > > > > okular-devel-ow...@kde.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Okular-devel digest..." > > > > Today's Topics: > >1. Re: Add autosave function to Okular (Albert Astals Cid) > > > > -- > > > > Message: 1 > > Date: Fri, 12 Jul 2024 11:31:47 +0200 > > From: Albert Astals Cid > > To: okular-devel@kde.org > > Subject: Re: Add autosave function to Okular > > Message-ID: <8354510.Qug9gx46Qj@xps15> > > Content-Type: text/plain; charset="utf-8" > > > > El divendres, 12 de juliol del 2024, a les 6:11:35 (CEST), Wen Chang va > > > > escriure: > > > Not quite understand what you mean. > > > To reproduce the issue, the user: > > > * Open Okular > > > * Make some changes (annotation) > > > * reboot or turn off their PC > > > > > > The update will disappear. > > > I have tested this on my laptop. > > > > I not asking you about your problem. > > > > You are suggesting a solution that you call "Add autosave function". > > > > I am asking you how would your suggestion behave in this scenario > > > > * Open Okular > > * Open file > > * Make annotation > > * Close Okular > > > > Would the annotation be saved to file without any user interaction? > > > > Best Regards, > > > > Albert > > > > > Best, > > > Wen > > > > > > Albert Astals Cid 於 2024年7月12日 週五 上午5:31寫道： > > > > > > > El dijous, 11 de juliol del 2024, a les 19:30:07 (CEST), Wen Chang va > > > > > > > > escriure: > > > > > >How can the user forget to save their update? > > > > > > > > > > > >We show them a dialog when closing the application. > > > > > > > > > > > >Best Regards, > > > > > > > > > > > > Albert > > > > > > > > > > I noticed that function. > > > > > When the users restart or turn off their laptop, > > > > > the update without being saved will not be available. > > > > > > > > > > Also, the function provides a better user experience, since the user > > > > > would not need to save their change frequently. > > > > > > > > Just to make sure, are you suggesting that: > > > > > > > > * Open Okular > > > > * Open file > > > > * Make annotation > > > > * Close Okular > > > > > > > > Should save the annotation to the file? > > > > > > > > Best Regards, > > > > > > > > Albert > > > > > > > > > Best, > > > > > Wen > > > > > > > > > > 於 2024年7月11日 週四 下午7:00寫道： > > > > > > > > > > > Send Okular-devel mailing list submissions to > > > > > > > > > > > > okular-devel@kde.org > > > > > >
Re: Add autosave function to Okular
> I not asking you about your problem. > > You are suggesting a solution that you call "Add autosave function". > > I am asking you how would your suggestion behave in this scenario > > * Open Okular > * Open file > * Make annotation > * Close Okular > > Would the annotation be saved to file without any user interaction? > > Best Regards, > Albert I see. The annotation will be saved automatically without any user interaction once autosave mode is enabled. Best, Wen 於 2024年7月12日 週五 下午7:00寫道： > Send Okular-devel mailing list submissions to > okular-devel@kde.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.kde.org/mailman/listinfo/okular-devel > or, via email, send a message with subject or body 'help' to > okular-devel-requ...@kde.org > > You can reach the person managing the list at > okular-devel-ow...@kde.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Okular-devel digest..." > > > Today's Topics: > >1. Re: Add autosave function to Okular (Albert Astals Cid) > > > -- > > Message: 1 > Date: Fri, 12 Jul 2024 11:31:47 +0200 > From: Albert Astals Cid > To: okular-devel@kde.org > Subject: Re: Add autosave function to Okular > Message-ID: <8354510.Qug9gx46Qj@xps15> > Content-Type: text/plain; charset="utf-8" > > El divendres, 12 de juliol del 2024, a les 6:11:35 (CEST), Wen Chang va > escriure: > > Not quite understand what you mean. > > To reproduce the issue, the user: > > * Open Okular > > * Make some changes (annotation) > > * reboot or turn off their PC > > > > The update will disappear. > > I have tested this on my laptop. > > I not asking you about your problem. > > You are suggesting a solution that you call "Add autosave function". > > I am asking you how would your suggestion behave in this scenario > > * Open Okular > * Open file > * Make annotation > * Close Okular > > Would the annotation be saved to file without any user interaction? > > Best Regards, > Albert > > > Best, > > Wen > > > > Albert Astals Cid 於 2024年7月12日 週五 上午5:31寫道： > > > > > El dijous, 11 de juliol del 2024, a les 19:30:07 (CEST), Wen Chang va > > > > > > escriure: > > > > >How can the user forget to save their update? > > > > > > > > > >We show them a dialog when closing the application. > > > > > > > > > >Best Regards, > > > > > > > > > > Albert > > > > > > > > I noticed that function. > > > > When the users restart or turn off their laptop, > > > > the update without being saved will not be available. > > > > > > > > Also, the function provides a better user experience, since the user > > > > would not need to save their change frequently. > > > > > > Just to make sure, are you suggesting that: > > > > > > * Open Okular > > > * Open file > > > * Make annotation > > > * Close Okular > > > > > > Should save the annotation to the file? > > > > > > Best Regards, > > > > > > Albert > > > > > > > Best, > > > > Wen > > > > > > > > 於 2024年7月11日 週四 下午7:00寫道： > > > > > > > > > Send Okular-devel mailing list submissions to > > > > > > > > > > okular-devel@kde.org > > > > > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > > > > > > > > https://mail.kde.org/mailman/listinfo/okular-devel > > > > > > > > > > or, via email, send a message with subject or body 'help' to > > > > > > > > > > okular-devel-requ...@kde.org > > > > > > > > > > You can reach the person managing the list at > > > > > > > > > > okular-devel-ow...@kde.org > > > > > > > > > > When replying, please edit your Subject line so it is more specific > > > > > than "Re: Contents of Okular-devel digest..." > > > > > > > > > > Today's Topics: > > > > >1. Re: Add autosave function to Okular (Albert Astals Cid) > > > > >2. [okular] [Bug 443882] popup m
Re: Add autosave function to Okular
> [...] Nitpicking about a word? What Wen would like to add is probably almost the same as Kate does. When the user starts editing a document, Kate creates a backup of the document file, which contains all changes made by the user (with a delay of a few seconds). When the user saves the document, the backup is not needed. But when Kate crashes (or is killed), and is then restarted again, Kate can offer to load the changes from the backup file, so the user looses at most a few seconds worth of work. I can very well imagine having this in Okular. Cheers, Laura
Re: Add autosave function to Okular
El divendres, 12 de juliol del 2024, a les 6:11:35 (CEST), Wen Chang va escriure: > Not quite understand what you mean. > To reproduce the issue, the user: > * Open Okular > * Make some changes (annotation) > * reboot or turn off their PC > > The update will disappear. > I have tested this on my laptop. I not asking you about your problem. You are suggesting a solution that you call "Add autosave function". I am asking you how would your suggestion behave in this scenario * Open Okular * Open file * Make annotation * Close Okular Would the annotation be saved to file without any user interaction? Best Regards, Albert > Best, > Wen > > Albert Astals Cid 於 2024年7月12日 週五 上午5:31寫道： > > > El dijous, 11 de juliol del 2024, a les 19:30:07 (CEST), Wen Chang va > > > > escriure: > > > >How can the user forget to save their update? > > > > > > > >We show them a dialog when closing the application. > > > > > > > >Best Regards, > > > > > > > > Albert > > > > > > I noticed that function. > > > When the users restart or turn off their laptop, > > > the update without being saved will not be available. > > > > > > Also, the function provides a better user experience, since the user > > > would not need to save their change frequently. > > > > Just to make sure, are you suggesting that: > > > > * Open Okular > > * Open file > > * Make annotation > > * Close Okular > > > > Should save the annotation to the file? > > > > Best Regards, > > > > Albert > > > > > Best, > > > Wen > > > > > > 於 2024年7月11日 週四 下午7:00寫道： > > > > > > > Send Okular-devel mailing list submissions to > > > > > > > > okular-devel@kde.org > > > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > > > > > > https://mail.kde.org/mailman/listinfo/okular-devel > > > > > > > > or, via email, send a message with subject or body 'help' to > > > > > > > > okular-devel-requ...@kde.org > > > > > > > > You can reach the person managing the list at > > > > > > > > okular-devel-ow...@kde.org > > > > > > > > When replying, please edit your Subject line so it is more specific > > > > than "Re: Contents of Okular-devel digest..." > > > > > > > > Today's Topics: > > > >1. Re: Add autosave function to Okular (Albert Astals Cid) > > > >2. [okular] [Bug 443882] popup menu of highlighted text does not > > > > > > > > appear on right click in text selection mode (Stan) > > > > > > > >3. [okular] [Bug 485676] Double-sided printing 'long side > > > > > > > > binding' not working correctly (Peter) > > > > > > > > -- > > > > > > > > Message: 1 > > > > Date: Wed, 10 Jul 2024 23:57:09 +0200 > > > > From: Albert Astals Cid > > > > To: okular-devel@kde.org > > > > Subject: Re: Add autosave function to Okular > > > > Message-ID: <2016002.J8XNHHvg0a@xps15> > > > > Content-Type: text/plain; charset="utf-8" > > > > > > > > El dimecres, 10 de juliol del 2024, a les 9:48:16 (CEST), Wen Chang va > > > > > > > > escriure: > > > > > Dear KDE maintainers, > > > > > > > > > > I have used the Okular for a while. > > > > > I wonder whether it would be good to have > > > > > the autosave option similar to the function in vscode. > > > > > This way, the annotation will not disappear if the users > > > > > forgot to save their update. > > > > > > > > How can the user forget to save their update? > > > > > > > > We show them a dialog when closing the application. > > > > > > > > Best Regards, > > > > > > > > Albert > > > > > > > > > I am willing to responsible for this update. > > > > > Feel free to let me know. > > > > > This is my first time working with KDE. > > > > > Please let me know the contribution policy, thank you. > > >
Re: Add autosave function to Okular
Not quite understand what you mean. To reproduce the issue, the user: * Open Okular * Make some changes (annotation) * reboot or turn off their PC The update will disappear. I have tested this on my laptop. Best, Wen Albert Astals Cid 於 2024年7月12日 週五 上午5:31寫道： > El dijous, 11 de juliol del 2024, a les 19:30:07 (CEST), Wen Chang va > escriure: > > >How can the user forget to save their update? > > > > > >We show them a dialog when closing the application. > > > > > >Best Regards, > > > > > > Albert > > > > I noticed that function. > > When the users restart or turn off their laptop, > > the update without being saved will not be available. > > > > Also, the function provides a better user experience, since the user > > would not need to save their change frequently. > > Just to make sure, are you suggesting that: > > * Open Okular > * Open file > * Make annotation > * Close Okular > > Should save the annotation to the file? > > Best Regards, > Albert > > > > > Best, > > Wen > > > > 於 2024年7月11日 週四 下午7:00寫道： > > > > > Send Okular-devel mailing list submissions to > > > > > > okular-devel@kde.org > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > > > > https://mail.kde.org/mailman/listinfo/okular-devel > > > > > > or, via email, send a message with subject or body 'help' to > > > > > > okular-devel-requ...@kde.org > > > > > > You can reach the person managing the list at > > > > > > okular-devel-ow...@kde.org > > > > > > When replying, please edit your Subject line so it is more specific > > > than "Re: Contents of Okular-devel digest..." > > > > > > Today's Topics: > > >1. Re: Add autosave function to Okular (Albert Astals Cid) > > >2. [okular] [Bug 443882] popup menu of highlighted text does not > > > > > > appear on right click in text selection mode (Stan) > > > > > >3. [okular] [Bug 485676] Double-sided printing 'long side > > > > > > binding' not working correctly (Peter) > > > > > > -- > > > > > > Message: 1 > > > Date: Wed, 10 Jul 2024 23:57:09 +0200 > > > From: Albert Astals Cid > > > To: okular-devel@kde.org > > > Subject: Re: Add autosave function to Okular > > > Message-ID: <2016002.J8XNHHvg0a@xps15> > > > Content-Type: text/plain; charset="utf-8" > > > > > > El dimecres, 10 de juliol del 2024, a les 9:48:16 (CEST), Wen Chang va > > > > > > escriure: > > > > Dear KDE maintainers, > > > > > > > > I have used the Okular for a while. > > > > I wonder whether it would be good to have > > > > the autosave option similar to the function in vscode. > > > > This way, the annotation will not disappear if the users > > > > forgot to save their update. > > > > > > How can the user forget to save their update? > > > > > > We show them a dialog when closing the application. > > > > > > Best Regards, > > > > > > Albert > > > > > > > I am willing to responsible for this update. > > > > Feel free to let me know. > > > > This is my first time working with KDE. > > > > Please let me know the contribution policy, thank you. > > > > > > > > Best, > > > > Wen > > > > > > -- > > > > > > Message: 2 > > > Date: Thu, 11 Jul 2024 08:21:12 + > > > From: Stan > > > To: okular-devel@kde.org > > > Subject: [okular] [Bug 443882] popup menu of highlighted text does not > > > > > > appear on right click in text selection mode > > > > > > Message-ID: > > > Content-Type: text/plain; charset=UTF-8 > > > > > > https://bugs.kde.org/show_bug.cgi?id=443882 > > > > > > Stan changed: > > >What|Removed |Added > > > > > > > -- > > > --> > > > CC||schym...@gmail.com > > > > > > --- Comment #18 from Stan --
Re: Add autosave function to Okular
El dijous, 11 de juliol del 2024, a les 19:30:07 (CEST), Wen Chang va escriure: > >How can the user forget to save their update? > > > >We show them a dialog when closing the application. > > > >Best Regards, > > > > Albert > > I noticed that function. > When the users restart or turn off their laptop, > the update without being saved will not be available. > > Also, the function provides a better user experience, since the user > would not need to save their change frequently. Just to make sure, are you suggesting that: * Open Okular * Open file * Make annotation * Close Okular Should save the annotation to the file? Best Regards, Albert > > Best, > Wen > > 於 2024年7月11日 週四 下午7:00寫道： > > > Send Okular-devel mailing list submissions to > > > > okular-devel@kde.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > > https://mail.kde.org/mailman/listinfo/okular-devel > > > > or, via email, send a message with subject or body 'help' to > > > > okular-devel-requ...@kde.org > > > > You can reach the person managing the list at > > > > okular-devel-ow...@kde.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of Okular-devel digest..." > > > > Today's Topics: > >1. Re: Add autosave function to Okular (Albert Astals Cid) > >2. [okular] [Bug 443882] popup menu of highlighted text does not > > > > appear on right click in text selection mode (Stan) > > > >3. [okular] [Bug 485676] Double-sided printing 'long side > > > > binding' not working correctly (Peter) > > > > -- > > > > Message: 1 > > Date: Wed, 10 Jul 2024 23:57:09 +0200 > > From: Albert Astals Cid > > To: okular-devel@kde.org > > Subject: Re: Add autosave function to Okular > > Message-ID: <2016002.J8XNHHvg0a@xps15> > > Content-Type: text/plain; charset="utf-8" > > > > El dimecres, 10 de juliol del 2024, a les 9:48:16 (CEST), Wen Chang va > > > > escriure: > > > Dear KDE maintainers, > > > > > > I have used the Okular for a while. > > > I wonder whether it would be good to have > > > the autosave option similar to the function in vscode. > > > This way, the annotation will not disappear if the users > > > forgot to save their update. > > > > How can the user forget to save their update? > > > > We show them a dialog when closing the application. > > > > Best Regards, > > > > Albert > > > > > I am willing to responsible for this update. > > > Feel free to let me know. > > > This is my first time working with KDE. > > > Please let me know the contribution policy, thank you. > > > > > > Best, > > > Wen > > > > -- > > > > Message: 2 > > Date: Thu, 11 Jul 2024 08:21:12 + > > From: Stan > > To: okular-devel@kde.org > > Subject: [okular] [Bug 443882] popup menu of highlighted text does not > > > > appear on right click in text selection mode > > > > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > > > https://bugs.kde.org/show_bug.cgi?id=443882 > > > > Stan changed: > >What|Removed |Added > > > > -- > > --> > > CC||schym...@gmail.com > > > > --- Comment #18 from Stan --- > > I think it is important that the right-click + delete works in all > > annotation > > modes (highlighting, pop-up, etc.), as this is when it is most needed, > > e.g. > > after highlighting the wrong part of text or placing a note in the wrong > > place. > > It is very tedious to have to switch out of the annotation mode in order > > to > > delete the wrong annotation and then switch back into it again to add the > > annotation in the right place. Therefore, I would consider this missing > > functionality a bug. > > > > -- > > You are receiving this mail because: > > You are the assignee for the bug. > > > > -- > > > > Message: 3 > > Date: Thu, 11 Jul 2024 10:19:25 + > > F
Re: Add autosave function to Okular
>How can the user forget to save their update? > >We show them a dialog when closing the application. > >Best Regards, > Albert I noticed that function. When the users restart or turn off their laptop, the update without being saved will not be available. Also, the function provides a better user experience, since the user would not need to save their change frequently. Best, Wen 於 2024年7月11日 週四 下午7:00寫道： > Send Okular-devel mailing list submissions to > okular-devel@kde.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.kde.org/mailman/listinfo/okular-devel > or, via email, send a message with subject or body 'help' to > okular-devel-requ...@kde.org > > You can reach the person managing the list at > okular-devel-ow...@kde.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Okular-devel digest..." > > > Today's Topics: > >1. Re: Add autosave function to Okular (Albert Astals Cid) >2. [okular] [Bug 443882] popup menu of highlighted text does not > appear on right click in text selection mode (Stan) >3. [okular] [Bug 485676] Double-sided printing 'long side > binding' not working correctly (Peter) > > > ------ > > Message: 1 > Date: Wed, 10 Jul 2024 23:57:09 +0200 > From: Albert Astals Cid > To: okular-devel@kde.org > Subject: Re: Add autosave function to Okular > Message-ID: <2016002.J8XNHHvg0a@xps15> > Content-Type: text/plain; charset="utf-8" > > El dimecres, 10 de juliol del 2024, a les 9:48:16 (CEST), Wen Chang va > escriure: > > Dear KDE maintainers, > > > > I have used the Okular for a while. > > I wonder whether it would be good to have > > the autosave option similar to the function in vscode. > > This way, the annotation will not disappear if the users > > forgot to save their update. > > How can the user forget to save their update? > > We show them a dialog when closing the application. > > Best Regards, > Albert > > > I am willing to responsible for this update. > > Feel free to let me know. > > This is my first time working with KDE. > > Please let me know the contribution policy, thank you. > > > > Best, > > Wen > > > > > > > -- > > Message: 2 > Date: Thu, 11 Jul 2024 08:21:12 + > From: Stan > To: okular-devel@kde.org > Subject: [okular] [Bug 443882] popup menu of highlighted text does not > appear on right click in text selection mode > Message-ID: > Content-Type: text/plain; charset=UTF-8 > > https://bugs.kde.org/show_bug.cgi?id=443882 > > Stan changed: > >What|Removed |Added > > > CC||schym...@gmail.com > > --- Comment #18 from Stan --- > I think it is important that the right-click + delete works in all > annotation > modes (highlighting, pop-up, etc.), as this is when it is most needed, e.g. > after highlighting the wrong part of text or placing a note in the wrong > place. > It is very tedious to have to switch out of the annotation mode in order to > delete the wrong annotation and then switch back into it again to add the > annotation in the right place. Therefore, I would consider this missing > functionality a bug. > > -- > You are receiving this mail because: > You are the assignee for the bug. > > -- > > Message: 3 > Date: Thu, 11 Jul 2024 10:19:25 + > From: Peter > To: okular-devel@kde.org > Subject: [okular] [Bug 485676] Double-sided printing 'long side > binding' not working correctly > Message-ID: > Content-Type: text/plain; charset=UTF-8 > > https://bugs.kde.org/show_bug.cgi?id=485676 > > Peter changed: > >What|Removed |Added > > >Platform|Other |Neon > Version|24.02.2 |24.05.2 > > -- > You are receiving this mail because: > You are the assignee for the bug. > > -- > > Subject: Digest Footer > > ___ > Okular-devel mailing list > Okular-devel@kde.org > https://mail.kde.org/mailman/listinfo/okular-devel > > > -- > > End of Okular-devel Digest, Vol 214, Issue 13 > * >
Re: Add autosave function to Okular
El dimecres, 10 de juliol del 2024, a les 9:48:16 (CEST), Wen Chang va escriure: > Dear KDE maintainers, > > I have used the Okular for a while. > I wonder whether it would be good to have > the autosave option similar to the function in vscode. > This way, the annotation will not disappear if the users > forgot to save their update. How can the user forget to save their update? We show them a dialog when closing the application. Best Regards, Albert > I am willing to responsible for this update. > Feel free to let me know. > This is my first time working with KDE. > Please let me know the contribution policy, thank you. > > Best, > Wen
Re: Usage of okular on windows
El dijous, 14 de març de 2024, a les 20:17:44 (CET), Lionel Bruno va escriure: > Dear Okular developers, > > We are a french institution that adopted Okular on our computers ( tired of > Acrobat advertising in their GUI ). > > We used to download the windows version from binary-factory.kde.org ( the > windows store is not allowed on our machines ). The replacement for unstable releases is https://cdn.kde.org/ci-builds/graphics/okular/master/ but we don't have windows build yet. > > Is there an alternative way to get the recent version and future updates > outside the windows store ? For the official build you can always download it from download.kde.org i.e. https://download.kde.org/Attic/release-service/23.08.1/windows/ But it's a bit tricky because you have to know which of the releases had a windows release. > > Thanks for your great work and thanks in advance you for your response. We do not provide an auto-updater besides Windows Store. choco seems to have okular https://community.chocolatey.org/packages/okular But i have no idea how much you can trust those packages or if choco would be allowed on your computers. Cheers, Albert > > > regards > > --- > Lionel Bruno > > Service des systèmes d'information > +33 1 47 03 89 12 > lionel.br...@inha.fr
[okular] [Bug 353389] REQUEST: Obvious overlap position indicator to prevent re-reading overlap
https://bugs.kde.org/show_bug.cgi?id=353389 --- Comment #2 from El Oton --- When I made this request 9 years ago, it was at the bottom of the "General" settings tab. I'm not presently using KDE so I don't know. -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 353389] REQUEST: Obvious overlap position indicator to prevent re-reading overlap
https://bugs.kde.org/show_bug.cgi?id=353389 Joe Breuer changed: What|Removed |Added CC||k...@jmbreuer.net --- Comment #1 from Joe Breuer --- What... overlap? Did you turn that on at some place? (Where?) I came here with the feature request to have (some, ideally configurable) overlap when using PgUp/PgDn in Continuous Mode. In the PDF document I'm currently reading, Okular will skip by _exactly_ the whole page, even when that means splitting a line of text in half. ... -- You are receiving this mail because: You are the assignee for the bug.
Re: Question for OKULAR stamps
El diumenge, 18 de febrer de 2024, a les 10:24:05 (CET), Alain LAPIERE va escriure: > Hello > 2 questions In the future please use https://kde.org/support/ to find support channels, do not email the Okular development mailing list about how to use Okular. > How resize a stamp when it is put on a pdf ? Be in Browse mode, select the stamp with the mouse, drag the square markers that appear around the stamp. > Hox resize a stamp when we create it ? When adding the stamp (and most annotations) press the mouse button, hold and drag to the size of the stamp you want to create, then release the mouse button. Cheers, Albert > Best regards
Re: Removing plucker generator ?
El dijous, 25 de gener de 2024, a les 0:33:58 (CET), Albert Astals Cid va escriure: > El dimecres, 17 de gener de 2024, a les 13:45:03 (CET), Sune Stolborg > Vuorela > va escriure: > > Hi > > > > While doing changes for KF6, I also touched the plucker generator code a > > bit. And I'm not confident in the code. > > > > It's c-code originating in 2003. > > It seems to be trusting the input is good. > > I found potential crasher bugs in it by looking at it > > It has no tests > > It doesn't look like the code has met some fuzzy-tester > > > > If it requires a owner key, it needs to be provided in a configuration > > file > > somewhere on disk, and trying that ends up with out of bounds writes and > > crashes. The configuration file it tries to open is btw called: > > PLUCKER_CONFIG_DIRFILE_SEPARATOR_CHAR_SSYS_CONFIG_FILE_NAME > > (and stored in a char* malloc'ed to be 40 chars long). > > > > It has foo = realloc(foo,...); foo[n].bar = ...; Realloc returns null on > > failure. > > > > It's hard to find test data for it. Any data. > > The homepage of the format seems to have been repurposed many years ago to > > something else. > > > > I think we should either find someone to take ownership over this and > > promise to invest a significant amount of time into it. Or just remove it. > > CC'in Tobias (if that address still works) in case he has some input. > > I've never seen any plucker document myself. No answer from anyone so this was actioned. https://invent.kde.org/graphics/okular/-/merge_requests/921 Cheers, Albert > > Cheers, > Albert > > > /Sune
Re: KEcoLab's integration into Okular
Hi Albert, Once again sorry for the delay in response me and karan were attending Conf KDE India so were a bit preoccupied with that >Try following the steps, you will see that you can't do step 1 because that is >not something we have in KDE (I guess one could bother sysadmin about it, but >that's not scalable). Yes you are correct we'll have to ask sysadmins for this. For this we would create a template to make this easy to achieve where we can have a comma seperated list of email addresses to notify when the pipeline breaks. Although this would be the last step for integration In regards to concern around scalability at present we were only looking to work with select projects owing to limited availability of hardware and also bearing in mind measuring too many projects can overload the system under test. Also on 14 February we would be having our monthly KDE Eco meetup and from what I have been told joseph will contact you in regards to this so maybe we can go into more details over this which would help in a smoother conversation. Sincerely, Aakarsh MJ On Thu, Feb 1, 2024 at 3:18 AM Albert Astals Cid wrote: > El dimecres, 31 de gener de 2024, a les 4:48:04 (CET), DrQuark va escriure: > > Hi Albert, > > I am Karanjot Singh, one of the developers from the KEcolab Team. > > > > > > You can configure a list of people that would receive an email when the > > pipeline status changes. > > See > https://docs.gitlab.com/ee/user/project/integrations/pipeline_status_em > > ails.html > > Try following the steps, you will see that you can't do step 1 because > that is > not something we have in KDE (I guess one could bother sysadmin about it, > but > that's not scalable). > > Cheers, > Albert > > > > > > > Cheers, > > Karanjot > > > > > > > > > > > > On Wed, Jan 31, 2024 at 04:39, Albert Astals Cid wrote: > > > > El dilluns, 29 de gener de 2024, a les 20:11:20 (CET), Aakarsh MJ va > escriure: > > > Sorry for the late reply, > > > > > > > > Please remember to keep the list in copy :) > > > > > > My mistake, I made sure to include all in this reply > > > > > > > Doing the testing on the tag creation may be a bit too late since we > > > > only > > > > > > > > create the tag when the application is released, which means if the > test > > > > finds > > > > > > > > a regression, it's too late since we've already released. > > > > > > > > > > > > But I guess as a start is not a bad thing, at least we'd know a > > > > regression > > > > > > > > happened :D > > > > > > Great! > > > > > > > Speaking of which, how would we know a regression happened? I > understand > > > > the > > > > > > > > pipeline would fail, but since "noone" is specifically looking at > that > > > > > > > > pipeline it would possibly be "lost"? Maybe we can get an email on > the > > > > mailing > > > > > > > > list? But I guess that's step #2. > > > > > > Yes, iirc whenever a pipeline fails the maintainers do receive an email > > > > > similar to the following image: > > Are you sure this is how it works? > > > > For Okular I only get emails when I break it, not when someone else does. > > > > Cheers, > > Albert > > > > > [image: image.png] > > > and even if the deploy stage fails we would still have artefacts from > the > > > energy measurement stage. > > > > > > Sincerely, > > > Aakarsh MJ > > > > > > On Fri, Jan 26, 2024 at 4:32 AM Albert Astals Cid > wrote: > > > > El dijous, 25 de gener de 2024, a les 23:37:59 (CET), Aakarsh MJ va > > > > > > > > escriure: > > > > > Hi Albert, > > > > > > > > Please remember to keep the list in copy :) > > > > > > > > > So we are planning to integrate this in the gitlab pipeline and are > > > > > > > > looking > > > > > > > > > to leverage `release-tags` (eg tag v 1.0) to identify the release > > > > > KEcoLab > > > > > runner would automatically run on and additionally the measurement > > > > > > > > process > > > > > > > > > can also be run manually at any time. > > > > > > > > Doing the testing on the tag creation may be a bit too late since we > > > > only > > > > create the tag when the application is released, which means if the > test > > > > finds > > > > a regression, it's too late since we've already released. > > > > > > > > But I guess as a start is not a bad thing, at least we'd know a > > > > regression > > > > happened :D > > > > > > > > Speaking of which, how would we know a regression happened? I > understand > > > > the > > > > pipeline would fail, but since "noone" is specifically looking at > that > > > > pipeline it would possibly be "lost"? Maybe we can get an email on > the > > > > mailing > > > > list? But I guess that's step #2. > > > > > > > > Cheers, > > > > > > > > Albert > > > > > > > > > Sincerely, > > > > > Aakarsh MJ > > > > > > > > > > On Tue, Jan 23, 2024 at 4:07 AM Albert Astals Cid > wrote: > > > > > > El dijous, 18 de gener de 2024, a les 18:17:10 (CET), Aakarsh MJ > va > > > > > > > > > > > > escriure: > > > > > > > request "reply all" > > > > > > > > > > > > > >
Re: KEcoLab's integration into Okular
<<< text/html; charset=utf-8: Unrecognized >>> publicKey - thestrangequarks@protonmail.com - 0xA1F859C9.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: KEcoLab's integration into Okular
El dimecres, 31 de gener de 2024, a les 4:48:04 (CET), DrQuark va escriure: > Hi Albert, > I am Karanjot Singh, one of the developers from the KEcolab Team. > > > You can configure a list of people that would receive an email when the > pipeline status changes. > See https://docs.gitlab.com/ee/user/project/integrations/pipeline_status_em > ails.html Try following the steps, you will see that you can't do step 1 because that is not something we have in KDE (I guess one could bother sysadmin about it, but that's not scalable). Cheers, Albert > > > Cheers, > Karanjot > > > > > > On Wed, Jan 31, 2024 at 04:39, Albert Astals Cid wrote: > > El dilluns, 29 de gener de 2024, a les 20:11:20 (CET), Aakarsh MJ va escriure: > > Sorry for the late reply, > > > > > > Please remember to keep the list in copy :) > > > > My mistake, I made sure to include all in this reply > > > > > Doing the testing on the tag creation may be a bit too late since we > > > only > > > > > > create the tag when the application is released, which means if the test > > > finds > > > > > > a regression, it's too late since we've already released. > > > > > > > > > But I guess as a start is not a bad thing, at least we'd know a > > > regression > > > > > > happened :D > > > > Great! > > > > > Speaking of which, how would we know a regression happened? I understand > > > the > > > > > > pipeline would fail, but since "noone" is specifically looking at that > > > > > > pipeline it would possibly be "lost"? Maybe we can get an email on the > > > mailing > > > > > > list? But I guess that's step #2. > > > > Yes, iirc whenever a pipeline fails the maintainers do receive an email > > > similar to the following image: > Are you sure this is how it works? > > For Okular I only get emails when I break it, not when someone else does. > > Cheers, > Albert > > > [image: image.png] > > and even if the deploy stage fails we would still have artefacts from the > > energy measurement stage. > > > > Sincerely, > > Aakarsh MJ > > > > On Fri, Jan 26, 2024 at 4:32 AM Albert Astals Cid wrote: > > > El dijous, 25 de gener de 2024, a les 23:37:59 (CET), Aakarsh MJ va > > > > > > escriure: > > > > Hi Albert, > > > > > > Please remember to keep the list in copy :) > > > > > > > So we are planning to integrate this in the gitlab pipeline and are > > > > > > looking > > > > > > > to leverage `release-tags` (eg tag v 1.0) to identify the release > > > > KEcoLab > > > > runner would automatically run on and additionally the measurement > > > > > > process > > > > > > > can also be run manually at any time. > > > > > > Doing the testing on the tag creation may be a bit too late since we > > > only > > > create the tag when the application is released, which means if the test > > > finds > > > a regression, it's too late since we've already released. > > > > > > But I guess as a start is not a bad thing, at least we'd know a > > > regression > > > happened :D > > > > > > Speaking of which, how would we know a regression happened? I understand > > > the > > > pipeline would fail, but since "noone" is specifically looking at that > > > pipeline it would possibly be "lost"? Maybe we can get an email on the > > > mailing > > > list? But I guess that's step #2. > > > > > > Cheers, > > > > > > Albert > > > > > > > Sincerely, > > > > Aakarsh MJ > > > > > > > > On Tue, Jan 23, 2024 at 4:07 AM Albert Astals Cid wrote: > > > > > El dijous, 18 de gener de 2024, a les 18:17:10 (CET), Aakarsh MJ va > > > > > > > > > > escriure: > > > > > > request "reply all" > > > > > > > > > > > > Hello everyone, My name is Aakarsh MJ, I’m contacting you on > > > > > > behalf > > > > > > of > > > > > > > > the > > > > > > > > > > > KDE Eco’s KEcoLab team for proposing the integration of KEcoLab > > > > > > into > > > > > > Okular’s pipeline. There are 2 proposed models (you can also > > > > > > suggest > > > > > > your > > > > > > own) which are as follows: > > > > > > > > > > > > 1) Pre-release Testing: > > > > > > * Every release candidate would be tested for energy consumption. > > > > > > * Provide information about energy change with the previous > > > > > > versions > > > > > > to > > > > > > > > > maintain the Blue Angel’s recommended less than 10% increase from > > > > > > the > > > > > > > > > > time > > > > > > > > > > > of certification requirement. > > > > > > > > > > > > 2) Optional Merge Request Testing (MRT) > > > > > > * Maintainers can opt to run KEcoLab on specific merge requests > > > > > > based on > > > > > > > > > their potential impact on energy consumption. > > > > > > * Smaller changes or bug fixes may not require MRT, while large > > > > > > feature > > > > > > > > > additions could benefit from energy analysis > > > > > > * This approach allows for targeted testing, while at the same > > > > > > time > > > > > > ensuring we are not consuming unnecessary energy. > > > > > > > > > > > > If approved me and
Re: KEcoLab's integration into Okular
El dilluns, 29 de gener de 2024, a les 20:11:20 (CET), Aakarsh MJ va escriure: > Sorry for the late reply, > > > > Please remember to keep the list in copy :) > > My mistake, I made sure to include all in this reply > > > Doing the testing on the tag creation may be a bit too late since we only > > > > create the tag when the application is released, which means if the test > > finds > > > > a regression, it's too late since we've already released. > > > > > > But I guess as a start is not a bad thing, at least we'd know a > > regression > > > > happened :D > > Great! > > > Speaking of which, how would we know a regression happened? I understand > > the > > > > pipeline would fail, but since "noone" is specifically looking at that > > > > pipeline it would possibly be "lost"? Maybe we can get an email on the > > mailing > > > > list? But I guess that's step #2. > > Yes, iirc whenever a pipeline fails the maintainers do receive an email > similar to the following image: Are you sure this is how it works? For Okular I only get emails when I break it, not when someone else does. Cheers, Albert > [image: image.png] > and even if the deploy stage fails we would still have artefacts from the > energy measurement stage. > > Sincerely, > Aakarsh MJ > > On Fri, Jan 26, 2024 at 4:32 AM Albert Astals Cid wrote: > > El dijous, 25 de gener de 2024, a les 23:37:59 (CET), Aakarsh MJ va > > > > escriure: > > > Hi Albert, > > > > Please remember to keep the list in copy :) > > > > > So we are planning to integrate this in the gitlab pipeline and are > > > > looking > > > > > to leverage `release-tags` (eg tag v 1.0) to identify the release > > > KEcoLab > > > runner would automatically run on and additionally the measurement > > > > process > > > > > can also be run manually at any time. > > > > Doing the testing on the tag creation may be a bit too late since we only > > create the tag when the application is released, which means if the test > > finds > > a regression, it's too late since we've already released. > > > > But I guess as a start is not a bad thing, at least we'd know a regression > > happened :D > > > > Speaking of which, how would we know a regression happened? I understand > > the > > pipeline would fail, but since "noone" is specifically looking at that > > pipeline it would possibly be "lost"? Maybe we can get an email on the > > mailing > > list? But I guess that's step #2. > > > > Cheers, > > > > Albert > > > > > Sincerely, > > > Aakarsh MJ > > > > > > On Tue, Jan 23, 2024 at 4:07 AM Albert Astals Cid wrote: > > > > El dijous, 18 de gener de 2024, a les 18:17:10 (CET), Aakarsh MJ va > > > > > > > > escriure: > > > > > request "reply all" > > > > > > > > > > Hello everyone, My name is Aakarsh MJ, I’m contacting you on behalf > > > > of > > > > > > the > > > > > > > > > KDE Eco’s KEcoLab team for proposing the integration of KEcoLab into > > > > > Okular’s pipeline. There are 2 proposed models (you can also suggest > > > > > your > > > > > own) which are as follows: > > > > > > > > > > 1) Pre-release Testing: > > > > > * Every release candidate would be tested for energy consumption. > > > > > * Provide information about energy change with the previous versions > > > > to > > > > > > > maintain the Blue Angel’s recommended less than 10% increase from > > > > > the > > > > > > > > time > > > > > > > > > of certification requirement. > > > > > > > > > > 2) Optional Merge Request Testing (MRT) > > > > > * Maintainers can opt to run KEcoLab on specific merge requests > > > > based on > > > > > > > their potential impact on energy consumption. > > > > > * Smaller changes or bug fixes may not require MRT, while large > > > > feature > > > > > > > additions could benefit from energy analysis > > > > > * This approach allows for targeted testing, while at the same time > > > > > ensuring we are not consuming unnecessary energy. > > > > > > > > > > If approved me and sarthak negi will be working on it as part of KDE > > > > SoK > > > > > > > 24. You can also check my proposal( > > > > > https://invent.kde.org/teams/season-of-kde/2024/-/issues/24) and > > > > > > > > sarthak's > > > > > > > > > proposal(https://invent.kde.org/teams/season-of-kde/2024/-/issues/19 > > > > ) > > > > > > > I am eager to hear your feedback, answer any questions and discuss > > > > the > > > > > > most > > > > > > > > > effective implementation approach. Thanks for your time and > > > > > > > > consideration. > > > > > > > > Would this be a gitlab thing or be in a separate service? > > > > > > > > How would you implement 1) i.e. how do you know what/when a > > > > "pre-release" > > > > > > exactly is? > > > > > > > > Cheers, > > > > > > > > Albert
Re: KEcoLab's integration into Okular
Sorry for the late reply, > > Please remember to keep the list in copy :) > My mistake, I made sure to include all in this reply > Doing the testing on the tag creation may be a bit too late since we only > create the tag when the application is released, which means if the test > finds > a regression, it's too late since we've already released. > But I guess as a start is not a bad thing, at least we'd know a > regression > happened :D > Great! > Speaking of which, how would we know a regression happened? I understand > the > pipeline would fail, but since "noone" is specifically looking at that > pipeline it would possibly be "lost"? Maybe we can get an email on the > mailing > list? But I guess that's step #2. Yes, iirc whenever a pipeline fails the maintainers do receive an email similar to the following image: [image: image.png] and even if the deploy stage fails we would still have artefacts from the energy measurement stage. Sincerely, Aakarsh MJ On Fri, Jan 26, 2024 at 4:32 AM Albert Astals Cid wrote: > El dijous, 25 de gener de 2024, a les 23:37:59 (CET), Aakarsh MJ va > escriure: > > Hi Albert, > > Please remember to keep the list in copy :) > > > So we are planning to integrate this in the gitlab pipeline and are > looking > > to leverage `release-tags` (eg tag v 1.0) to identify the release KEcoLab > > runner would automatically run on and additionally the measurement > process > > can also be run manually at any time. > > Doing the testing on the tag creation may be a bit too late since we only > create the tag when the application is released, which means if the test > finds > a regression, it's too late since we've already released. > > But I guess as a start is not a bad thing, at least we'd know a regression > happened :D > > Speaking of which, how would we know a regression happened? I understand > the > pipeline would fail, but since "noone" is specifically looking at that > pipeline it would possibly be "lost"? Maybe we can get an email on the > mailing > list? But I guess that's step #2. > > Cheers, > Albert > > > > > Sincerely, > > Aakarsh MJ > > > > On Tue, Jan 23, 2024 at 4:07 AM Albert Astals Cid wrote: > > > El dijous, 18 de gener de 2024, a les 18:17:10 (CET), Aakarsh MJ va > > > > > > escriure: > > > > request "reply all" > > > > > > > > Hello everyone, My name is Aakarsh MJ, I’m contacting you on behalf > of > > > > > > the > > > > > > > KDE Eco’s KEcoLab team for proposing the integration of KEcoLab into > > > > Okular’s pipeline. There are 2 proposed models (you can also suggest > > > > your > > > > own) which are as follows: > > > > > > > > 1) Pre-release Testing: > > > > * Every release candidate would be tested for energy consumption. > > > > * Provide information about energy change with the previous versions > to > > > > maintain the Blue Angel’s recommended less than 10% increase from the > > > > > > time > > > > > > > of certification requirement. > > > > > > > > 2) Optional Merge Request Testing (MRT) > > > > * Maintainers can opt to run KEcoLab on specific merge requests > based on > > > > their potential impact on energy consumption. > > > > * Smaller changes or bug fixes may not require MRT, while large > feature > > > > additions could benefit from energy analysis > > > > * This approach allows for targeted testing, while at the same time > > > > ensuring we are not consuming unnecessary energy. > > > > > > > > If approved me and sarthak negi will be working on it as part of KDE > SoK > > > > 24. You can also check my proposal( > > > > https://invent.kde.org/teams/season-of-kde/2024/-/issues/24) and > > > > > > sarthak's > > > > > > > proposal(https://invent.kde.org/teams/season-of-kde/2024/-/issues/19 > ) > > > > > > > > I am eager to hear your feedback, answer any questions and discuss > the > > > > > > most > > > > > > > effective implementation approach. Thanks for your time and > > > > > > consideration. > > > > > > Would this be a gitlab thing or be in a separate service? > > > > > > How would you implement 1) i.e. how do you know what/when a > "pre-release" > > > exactly is? > > > > > > Cheers, > > > > > > Albert > > > > >
Re: KEcoLab's integration into Okular
El dijous, 25 de gener de 2024, a les 23:37:59 (CET), Aakarsh MJ va escriure: > Hi Albert, Please remember to keep the list in copy :) > So we are planning to integrate this in the gitlab pipeline and are looking > to leverage `release-tags` (eg tag v 1.0) to identify the release KEcoLab > runner would automatically run on and additionally the measurement process > can also be run manually at any time. Doing the testing on the tag creation may be a bit too late since we only create the tag when the application is released, which means if the test finds a regression, it's too late since we've already released. But I guess as a start is not a bad thing, at least we'd know a regression happened :D Speaking of which, how would we know a regression happened? I understand the pipeline would fail, but since "noone" is specifically looking at that pipeline it would possibly be "lost"? Maybe we can get an email on the mailing list? But I guess that's step #2. Cheers, Albert > > Sincerely, > Aakarsh MJ > > On Tue, Jan 23, 2024 at 4:07 AM Albert Astals Cid wrote: > > El dijous, 18 de gener de 2024, a les 18:17:10 (CET), Aakarsh MJ va > > > > escriure: > > > request "reply all" > > > > > > Hello everyone, My name is Aakarsh MJ, I’m contacting you on behalf of > > > > the > > > > > KDE Eco’s KEcoLab team for proposing the integration of KEcoLab into > > > Okular’s pipeline. There are 2 proposed models (you can also suggest > > > your > > > own) which are as follows: > > > > > > 1) Pre-release Testing: > > > * Every release candidate would be tested for energy consumption. > > > * Provide information about energy change with the previous versions to > > > maintain the Blue Angel’s recommended less than 10% increase from the > > > > time > > > > > of certification requirement. > > > > > > 2) Optional Merge Request Testing (MRT) > > > * Maintainers can opt to run KEcoLab on specific merge requests based on > > > their potential impact on energy consumption. > > > * Smaller changes or bug fixes may not require MRT, while large feature > > > additions could benefit from energy analysis > > > * This approach allows for targeted testing, while at the same time > > > ensuring we are not consuming unnecessary energy. > > > > > > If approved me and sarthak negi will be working on it as part of KDE SoK > > > 24. You can also check my proposal( > > > https://invent.kde.org/teams/season-of-kde/2024/-/issues/24) and > > > > sarthak's > > > > > proposal(https://invent.kde.org/teams/season-of-kde/2024/-/issues/19) > > > > > > I am eager to hear your feedback, answer any questions and discuss the > > > > most > > > > > effective implementation approach. Thanks for your time and > > > > consideration. > > > > Would this be a gitlab thing or be in a separate service? > > > > How would you implement 1) i.e. how do you know what/when a "pre-release" > > exactly is? > > > > Cheers, > > > > Albert
Re: Removing plucker generator ?
El dimecres, 17 de gener de 2024, a les 13:45:03 (CET), Sune Stolborg Vuorela va escriure: > Hi > > While doing changes for KF6, I also touched the plucker generator code a > bit. And I'm not confident in the code. > > It's c-code originating in 2003. > It seems to be trusting the input is good. > I found potential crasher bugs in it by looking at it > It has no tests > It doesn't look like the code has met some fuzzy-tester > > If it requires a owner key, it needs to be provided in a configuration file > somewhere on disk, and trying that ends up with out of bounds writes and > crashes. The configuration file it tries to open is btw called: > PLUCKER_CONFIG_DIRFILE_SEPARATOR_CHAR_SSYS_CONFIG_FILE_NAME > (and stored in a char* malloc'ed to be 40 chars long). > > It has foo = realloc(foo,...); foo[n].bar = ...; Realloc returns null on > failure. > > It's hard to find test data for it. Any data. > The homepage of the format seems to have been repurposed many years ago to > something else. > > I think we should either find someone to take ownership over this and > promise to invest a significant amount of time into it. Or just remove it. CC'in Tobias (if that address still works) in case he has some input. I've never seen any plucker document myself. Cheers, Albert > > /Sune
Re: KEcoLab's integration into Okular
El dijous, 18 de gener de 2024, a les 18:17:10 (CET), Aakarsh MJ va escriure: > request "reply all" > > Hello everyone, My name is Aakarsh MJ, I’m contacting you on behalf of the > KDE Eco’s KEcoLab team for proposing the integration of KEcoLab into > Okular’s pipeline. There are 2 proposed models (you can also suggest your > own) which are as follows: > > 1) Pre-release Testing: > * Every release candidate would be tested for energy consumption. > * Provide information about energy change with the previous versions to > maintain the Blue Angel’s recommended less than 10% increase from the time > of certification requirement. > > 2) Optional Merge Request Testing (MRT) > * Maintainers can opt to run KEcoLab on specific merge requests based on > their potential impact on energy consumption. > * Smaller changes or bug fixes may not require MRT, while large feature > additions could benefit from energy analysis > * This approach allows for targeted testing, while at the same time > ensuring we are not consuming unnecessary energy. > > If approved me and sarthak negi will be working on it as part of KDE SoK > 24. You can also check my proposal( > https://invent.kde.org/teams/season-of-kde/2024/-/issues/24) and sarthak's > proposal(https://invent.kde.org/teams/season-of-kde/2024/-/issues/19) > > I am eager to hear your feedback, answer any questions and discuss the most > effective implementation approach. Thanks for your time and consideration. Would this be a gitlab thing or be in a separate service? How would you implement 1) i.e. how do you know what/when a "pre-release" exactly is? Cheers, Albert
Re: how to unsubscribe this mailing list ?
thanks :) Le dim. 10 déc. 2023 à 23:36, Albert Astals Cid a écrit : > See https://mail.kde.org/mailman/listinfo/okular-devel > > >
Re: how to unsubscribe this mailing list ?
See https://mail.kde.org/mailman/listinfo/okular-devel
Re: Removing import Postscript as PDF feature?
El divendres, 24 de novembre de 2023, a les 10:29:22 (CET), Oliver Sander va escriure: > > I'm also trying to flip it around a bit. If this was proposed today where > > we have a postscript generator in okular, would we accept this feature? > Also, don't you get the same functionality by loading the postscript as > postscript, and then printing it to a file (at least in principle)? I'd > consider that way of converting postscript to pdf more natural. This is a good point, if loading the PS directly gives a similar experience than converting the PS to PDF on the fly, then my argument about people being sad doesn't apply. To be honest I have no idea if the functionality is similar, i don't think i've ever used the feature. Cheers, Albert > > Best, > Oliver
Re: Removing import Postscript as PDF feature?
El divendres, 24 de novembre de 2023, a les 9:49:15 (CET), Sune Stolborg Vuorela va escriure: > On Friday, November 24, 2023 12:53:31 AM CET Albert Astals Cid wrote: > > What do we win by removing the code? It's like 10 lines of code i guess? > > it is just 2 digits lines of code, yes. But there is some bugs in it. > - Paper size > - memory leaks on conversion failure > - no user feedback on conversion failure > - Not that good user experience if ps2pdf not available > > I'm also trying to flip it around a bit. If this was proposed today where > we have a postscript generator in okular, would we accept this feature? No, would probably not be accepted, but that's not a fair question, because the feature is here, potentially used by people (we should add kuserfeeddback to have actual data about this) that will be sad that the feature is removed. The fact that it can be done using the command line doesn't matter, we can't ask regular users to use the command line, if we do that, we've lost. > > All of this can be fixed, but I'd rather just remove it because I don't yet > see the value in it. There's also no need to fix it, the code has existed for 2 decades and AFAIK there's no bug about any of those things you mention. Cheers, Albert > > /Sune
Re: Removing import Postscript as PDF feature?
I'm also trying to flip it around a bit. If this was proposed today where we have a postscript generator in okular, would we accept this feature? Also, don't you get the same functionality by loading the postscript as postscript, and then printing it to a file (at least in principle)? I'd consider that way of converting postscript to pdf more natural. Best, Oliver smime.p7s Description: S/MIME Cryptographic Signature
Re: Removing import Postscript as PDF feature?
On Friday, November 24, 2023 12:53:31 AM CET Albert Astals Cid wrote: > What do we win by removing the code? It's like 10 lines of code i guess? it is just 2 digits lines of code, yes. But there is some bugs in it. - Paper size - memory leaks on conversion failure - no user feedback on conversion failure - Not that good user experience if ps2pdf not available I'm also trying to flip it around a bit. If this was proposed today where we have a postscript generator in okular, would we accept this feature? All of this can be fixed, but I'd rather just remove it because I don't yet see the value in it. /Sune -- I didn’t stop pretending when I became an adult, it’s just that when I was a kid I was pretending that I fit into the rules and structures of this world. And now that I’m an adult, I pretend that those rules and structures exist. - zefrank
Re: Removing import Postscript as PDF feature?
El dimecres, 22 de novembre de 2023, a les 14:01:03 (CET), Sune Stolborg Vuorela va escriure: > Hi > I was just reading over bits of okular source code and suddenly discovered > "Import postscript as PDF" in the main menu. > > I'm considering removing it, but before I propose a patch doing it, I would > love to have some feedback first. > > Reasons to remove: > - Okular can open postcript by itself > - It clutters up the menu > - There is a open bug report that it always uses US Letter as papersize > when importing, and no gentle way of fixing it without exposing a > complicated dialog - It is implented by running an external command > (ps2pdf) to do the heavy lifting > - If your platform doesn't have libspectre&libgs, it likely also doesn't > have ps2pdf > - if ps2pdf is not found, it is not immediately clear to the user how to > solve > - Error handling in case of ps2pdf failing is nonexisting > > Reasons to keep: > - If you have a okular compiled in a nonstandard configuration, but with > pdf support, you can later install ps2pdf and be able to view postscript > files anyway > > The feature in question was added back in 2005; that was back when okular > was kpdf and has not been touched much since then. > > Any one for? > Any one against? What do we win by removing the code? It's like 10 lines of code i guess? Cheers, Albert > > /Sune
Re: Removing import Postscript as PDF feature?
On Wed, 22 Nov 2023 at 13:01, Sune Stolborg Vuorela wrote: > > Any one for? > Any one against? > As far as I'm concerned, you can remove it. My main reason for that stance is that, as you wrote, the feature is implemented by calling an external program (ps2pdf), meaning you might as well use that program in the first place. However, I'm comfortable using the command line, and some people who are not might appreciate the feature being part of okular. Regards, Albert Wik.
Re: Okular font selection
El divendres, 10 de novembre de 2023, a les 17:15:57 (CET), A. Wik va escriure: > Hi all, > > It seems I may have come across a bug in Okular, with regard to font > selection. Here is a screenshot: > https://drive.google.com/file/d/178nuOFvWiBOoqmSIs7spAqDrGt2YHAqQ/view?usp=s > haring > > As you can see from the picture, one of the CourierNew fonts gets > substituted with > NimbusMonoPS, and one of the TimesNewRoman fonts does not get mapped > to Times New Roman but to Times Roman. Meanwhile, there is no problem > with Garamond. > > I've tried to debug this with fc-match, but everthing seems correct > according to it: > aw@aw-thinkpad:~$ fc-match 'CourierNew' > cour.ttf: "Courier New" "Regular" > aw@aw-thinkpad:~$ fc-match 'TimesNewRoman' > times.ttf: "Times New Roman" "Regular" > > Can anyone shed some light on this? You had to go and open a bug and now there's two places to talk about this. Don't do that. Cheers, Albert > > Regards, > Albert Wik.
Re: [okular] [Bug 477127] review tool settings get lost after reload
Hello All, Is there a way for me to unsubscribe from this email list? I subscribed in the first place because I thought it was the newsletter of Okular (and I didn't get it was the list for developers). Thanks for your help, Cheers, Ari Le ven. 17 nov. 2023 à 11:53, peter josvai a écrit : > https://bugs.kde.org/show_bug.cgi?id=477127 > > --- Comment #3 from peter josvai --- > it functions good now > I don't now what happened, but the problem had produced itself twice... > > I now have checked whether it is just the last modification that gets > lost... > I did one modification, saved and reloaded the document (and Okular), and > it > didn't get forgotten... > > > so, at this point I cannot reproduce it anymore... > Sorry for taking your time!!! > > -- > You are receiving this mail because: > You are the assignee for the bug.
Re: Feature request/enquiry: Overprint support
Hi all, Following this up to close the loop - Kevin Ottens from Enioka has completed the work involved to get this feature request functional. At the time of writing the patches/PRs are awaiting upstream review: - Okular: https://invent.kde.org/graphics/okular/-/merge_requests/764 - Poppler: https://gitlab.freedesktop.org/poppler/poppler/-/merge_requests/1411 If anyone is interested in testing, I have backported the patches for ubuntu 22.04/jammy in this ppa: - https://launchpad.net/~bernard-gray/+archive/ubuntu/okular-poppler Thanks for all the assistance, I'm very glad to report a happy (near) ending :) Regards, Bernie On Fri, 2 Jun 2023 at 15:51, Bernard Gray wrote: > > Hi Oliver, > > > to be honest I think you need professional support for this. > > Overprint support is a bit exotic, and you are very unlikely to find > > a volunteer with the motivation, the time and the skills to implement this. > > In a previous email you mentioned that you write on behalf > > of a company. I strongly suggest that you ask them for money to hire > > one of the companies that offers professional Okular support. > > No problems, I've reached out to a company we've previously had > discussions with - if that's not fruitful, do you have any specific > recommendations? (Happy if you'd prefer to email me directly/off list) > > Thanks again for all the assistance btw, this has been valuable in > honing the scope of work required. > > Regards, > Bernie
Re: Feature request/enquiry: Overprint support
Hi Michael, Thanks for the introduction, we are moving ahead with our previous contact for now, but will certainly look to get in touch for any future requirements! Regards, Bernie On Mon, 5 Jun 2023 at 18:46, Michael freer wrote: > > @Oliver - thank you for the introduction and for the endorsement, both are > much appreciated. > —- > > Hello Bernard > > It is a pleasure to meet you, albeit virtually, for the time being anyway. > > It would be a pleasure to determine how KDAB can potentially assist you as > and when you feel it is appropriate to do so. When you are ready, please make > contact via email or phone. > > Kind regards > > Michael > > — > Michael Freer | michael.fr...@kdab.com | Director of Sales > KDAB (UK) Ltd., a KDAB Group company > Mob: +44 (0)7990 065259 > Office: +44 (0)1625 809908 > KDAB - Trusted Software Excellence > > > > On 2 Jun 2023, at 11:20, Oliver Sander wrote: > > > > > >> > >> No problems, I've reached out to a company we've previously had > >> discussions with - if that's not fruitful, do you have any specific > >> recommendations? (Happy if you'd prefer to email me directly/off list) > > > > My employer has hired KDAB [CCed] several times for Okular/Poppler work, > > and we have always been very satisfied with the results.
Re: Feature request/enquiry: Overprint support
@Oliver - thank you for the introduction and for the endorsement, both are much appreciated. —- Hello Bernard It is a pleasure to meet you, albeit virtually, for the time being anyway. It would be a pleasure to determine how KDAB can potentially assist you as and when you feel it is appropriate to do so. When you are ready, please make contact via email or phone. Kind regards Michael — Michael Freer | michael.fr...@kdab.com | Director of Sales KDAB (UK) Ltd., a KDAB Group company Mob: +44 (0)7990 065259 Office: +44 (0)1625 809908 KDAB - Trusted Software Excellence > On 2 Jun 2023, at 11:20, Oliver Sander wrote: > > >> >> No problems, I've reached out to a company we've previously had >> discussions with - if that's not fruitful, do you have any specific >> recommendations? (Happy if you'd prefer to email me directly/off list) > > My employer has hired KDAB [CCed] several times for Okular/Poppler work, > and we have always been very satisfied with the results.
Re: Feature request/enquiry: Overprint support
Hi Oliver, > to be honest I think you need professional support for this. > Overprint support is a bit exotic, and you are very unlikely to find > a volunteer with the motivation, the time and the skills to implement this. > In a previous email you mentioned that you write on behalf > of a company. I strongly suggest that you ask them for money to hire > one of the companies that offers professional Okular support. No problems, I've reached out to a company we've previously had discussions with - if that's not fruitful, do you have any specific recommendations? (Happy if you'd prefer to email me directly/off list) Thanks again for all the assistance btw, this has been valuable in honing the scope of work required. Regards, Bernie
Re: Feature request/enquiry: Overprint support
> poppler does have overprinting support (to a certain extent). See for example > the manpage of pdftops. Thanks Oliver, that's great information - On Wed, 31 May 2023 at 02:10, Oliver Sander wrote: > ... > > Maybe open a feature request at bugs.kde.org -- that's more easily kept > > track of. > > That I think is still a good idea. Turns out, there was already a bug raised in 2006(!): https://bugs.kde.org/show_bug.cgi?id=126942 I've added links back to this mailing list thread - is there any way I am able to raise the profile of this ticket to get it looked at (beyond having this discussion)? Regards, Bernie > > Best, > Oliver > > > > > Cheers, > > Oliver > > > > > > On 29.05.23 21:49, Laura David Hurka wrote: > >> Hi Bernard, > >> > >> I don’t know exactly what overprinting is, or what your requirements are. > >> I understand it as a feature similar to PDF layers. > >> Okular has a side panel for layers, you can try it with the last page of > >> what > >> a quick internet search gave me: > >> > >> https://www.edcfiresafe.org/wp-content/uploads/2015/12/Using-Layerd-PDFs-with-Sample-Map.pdf > >> > >> I assume your requirement is to display the document correctly, only on > >> your > >> screen of your local desktop computer. > >> > >> My conclusion is that Poppler (the PDF library normally used by Okular) > >> will > >> need to support “overprinting”. > >> If a user interface is necessary, that should be a sensible addition to > >> Okular, similar to how layers already have a user interface. > >> > >> Cheers, David > >> > >>> Hi everyone, > >>> > >>> We are currently supporting a very old version of 32 bit adobe reader on > >>> our ubuntu 22.04/kde desktops, due to the requirement for support for a > >>> PDF > >>> feature called "Overprint" which is used by our label printing supplier (I > >>> work for an Australian winery) > >>> > >>> [...] > >>> > >>> Is this feature something Okular would be interested in developing? > >> > >> > >> On Wed, 31 May 2023 at 02:10, Oliver Sander wrote: > > > Bernard, can you explain more precisely what it is that you need? > > Without it I don't think you will get a better answer. > > Sorry for this: I just found your last email which gives more information. > Let me digest those first. > > > Maybe open a feature request at bugs.kde.org -- that's more easily kept > > track of. > > That I think is still a good idea. > > Best, > Oliver > > > > > Cheers, > > Oliver > > > > > > On 29.05.23 21:49, Laura David Hurka wrote: > >> Hi Bernard, > >> > >> I don’t know exactly what overprinting is, or what your requirements are. > >> I understand it as a feature similar to PDF layers. > >> Okular has a side panel for layers, you can try it with the last page of > >> what > >> a quick internet search gave me: > >> > >> https://www.edcfiresafe.org/wp-content/uploads/2015/12/Using-Layerd-PDFs-with-Sample-Map.pdf > >> > >> I assume your requirement is to display the document correctly, only on > >> your > >> screen of your local desktop computer. > >> > >> My conclusion is that Poppler (the PDF library normally used by Okular) > >> will > >> need to support “overprinting”. > >> If a user interface is necessary, that should be a sensible addition to > >> Okular, similar to how layers already have a user interface. > >> > >> Cheers, David > >> > >>> Hi everyone, > >>> > >>> We are currently supporting a very old version of 32 bit adobe reader on > >>> our ubuntu 22.04/kde desktops, due to the requirement for support for a > >>> PDF > >>> feature called "Overprint" which is used by our label printing supplier (I > >>> work for an Australian winery) > >>> > >>> [...] > >>> > >>> Is this feature something Okular would be interested in developing? > >> > >> > >>
Re: Feature request/enquiry: Overprint support
No problems, I've reached out to a company we've previously had discussions with - if that's not fruitful, do you have any specific recommendations? (Happy if you'd prefer to email me directly/off list) My employer has hired KDAB [CCed] several times for Okular/Poppler work, and we have always been very satisfied with the results. smime.p7s Description: S/MIME Cryptographic Signature
Re: Feature request/enquiry: Overprint support
Hi Bernard, Turns out, there was already a bug raised in 2006(!): https://bugs.kde.org/show_bug.cgi?id=126942 thanks for finding this. I've added links back to this mailing list thread - is there any way I am able to raise the profile of this ticket to get it looked at (beyond having this discussion)? to be honest I think you need professional support for this. Overprint support is a bit exotic, and you are very unlikely to find a volunteer with the motivation, the time and the skills to implement this. In a previous email you mentioned that you write on behalf of a company. I strongly suggest that you ask them for money to hire one of the companies that offers professional Okular support. Best, Oliver smime.p7s Description: S/MIME Cryptographic Signature
Re: Feature request/enquiry: Overprint support
Bernard, can you explain more precisely what it is that you need? Without it I don't think you will get a better answer. Sorry for this: I just found your last email which gives more information. Let me digest those first. Maybe open a feature request at bugs.kde.org -- that's more easily kept track of. That I think is still a good idea. Best, Oliver Cheers, Oliver On 29.05.23 21:49, Laura David Hurka wrote: Hi Bernard, I don’t know exactly what overprinting is, or what your requirements are. I understand it as a feature similar to PDF layers. Okular has a side panel for layers, you can try it with the last page of what a quick internet search gave me: https://www.edcfiresafe.org/wp-content/uploads/2015/12/Using-Layerd-PDFs-with-Sample-Map.pdf I assume your requirement is to display the document correctly, only on your screen of your local desktop computer. My conclusion is that Poppler (the PDF library normally used by Okular) will need to support “overprinting”. If a user interface is necessary, that should be a sensible addition to Okular, similar to how layers already have a user interface. Cheers, David Hi everyone, We are currently supporting a very old version of 32 bit adobe reader on our ubuntu 22.04/kde desktops, due to the requirement for support for a PDF feature called "Overprint" which is used by our label printing supplier (I work for an Australian winery) [...] Is this feature something Okular would be interested in developing? smime.p7s Description: S/MIME Cryptographic Signature
Re: Feature request/enquiry: Overprint support
Hi David, Thankyou for your informative reply! On Tue, 30 May 2023 at 05:49, Laura David Hurka wrote: > > Hi Bernard, > > I don’t know exactly what overprinting is, or what your requirements are. > I understand it as a feature similar to PDF layers. I'm afraid I don't exactly understand it either, but from the link I posted in the original email[1] it seems to be tied to (some) physical printers and the way the PDF defines the separation of CMYK toners for certain elements. The problem is that the screen viewers (okular, et al) don't render this to the screen correctly, creating the multi-layered, unclear font in the example I sent > Okular has a side panel for layers, you can try it with the last page of what > a quick internet search gave me: > > https://www.edcfiresafe.org/wp-content/uploads/2015/12/Using-Layerd-PDFs-with-Sample-Map.pdf Great, that was useful to see how okular implements layers, however it does not recognise the Overprint features in the PDF as layers (there was no layers tab appearing in the sidebar of okular in my example PDF[2]) > I assume your requirement is to display the document correctly, only on your > screen of your local desktop computer. Correct > My conclusion is that Poppler (the PDF library normally used by Okular) will > need to support “overprinting”. I don't really understand how the library would interact with the viewer in this case, but I am happy to pose the question to the poppler team separately Do you have any recommendation on how best to contact them/frame the request? > If a user interface is necessary, that should be a sensible addition to > Okular, similar to how layers already have a user interface. This is the user interface implemented in AdobeReader 9 - Via the program preferences, setting "Use Overprint Preview: [Always | Automatic]" displays the PDF correctly https://drive.google.com/file/d/1ix9ZPtq8LD4EosaKZXFF5aRCVnEQv_bM/view?usp=sharing > Cheers, David [1]: https://pdfa.org/understanding-overprint/ [2]: https://drive.google.com/file/d/1WGlly-EvzQl1Jhj39R9hvJ16CIgVZD5j/view?usp=share_link > > > Hi everyone, > > > > We are currently supporting a very old version of 32 bit adobe reader on > > our ubuntu 22.04/kde desktops, due to the requirement for support for a PDF > > feature called "Overprint" which is used by our label printing supplier (I > > work for an Australian winery) > > > > [...] > > > > Is this feature something Okular would be interested in developing?
Re: Feature request/enquiry: Overprint support
Hi, poppler does have overprinting support (to a certain extent). See for example the manpage of pdftops. Bernard, can you explain more precisely what it is that you need? Without it I don't think you will get a better answer. Maybe open a feature request at bugs.kde.org -- that's more easily kept track of. Cheers, Oliver On 29.05.23 21:49, Laura David Hurka wrote: Hi Bernard, I don’t know exactly what overprinting is, or what your requirements are. I understand it as a feature similar to PDF layers. Okular has a side panel for layers, you can try it with the last page of what a quick internet search gave me: https://www.edcfiresafe.org/wp-content/uploads/2015/12/Using-Layerd-PDFs-with-Sample-Map.pdf I assume your requirement is to display the document correctly, only on your screen of your local desktop computer. My conclusion is that Poppler (the PDF library normally used by Okular) will need to support “overprinting”. If a user interface is necessary, that should be a sensible addition to Okular, similar to how layers already have a user interface. Cheers, David Hi everyone, We are currently supporting a very old version of 32 bit adobe reader on our ubuntu 22.04/kde desktops, due to the requirement for support for a PDF feature called "Overprint" which is used by our label printing supplier (I work for an Australian winery) [...] Is this feature something Okular would be interested in developing? smime.p7s Description: S/MIME Cryptographic Signature
Re: Feature request/enquiry: Overprint support
Hi Bernard, I don’t know exactly what overprinting is, or what your requirements are. I understand it as a feature similar to PDF layers. Okular has a side panel for layers, you can try it with the last page of what a quick internet search gave me: https://www.edcfiresafe.org/wp-content/uploads/2015/12/Using-Layerd-PDFs-with-Sample-Map.pdf I assume your requirement is to display the document correctly, only on your screen of your local desktop computer. My conclusion is that Poppler (the PDF library normally used by Okular) will need to support “overprinting”. If a user interface is necessary, that should be a sensible addition to Okular, similar to how layers already have a user interface. Cheers, David > Hi everyone, > > We are currently supporting a very old version of 32 bit adobe reader on > our ubuntu 22.04/kde desktops, due to the requirement for support for a PDF > feature called "Overprint" which is used by our label printing supplier (I > work for an Australian winery) > > [...] > > Is this feature something Okular would be interested in developing?
Re: Okular with GnuPG / Gpg4win
El dimecres, 17 de maig de 2023, a les 10:56:38 (CEST), Andre Heinecke va escriure: > Hi, > > On Tuesday 16 May 2023 23:55:00 CEST Albert Astals Cid wrote: > > The text looks reasonable to me, but i guess we'd definitely want some > > input from the KDE Promo folks. Want me to involve them or will you? > > I already did start on that yesterday. > https://marc.info/?l=kde-promo&m=168423425626159&w=2 > > Btw. my second mail in the thread gives some additional rationale why the > GnuPG integration is useful for us so it might be worth a read. > > > I can see that how that would make sense for translation but i don't see > > how this particular wording makes sense to be in the Okular repository. > > > > Imagine we get 10 different downstreams like you, we would need 10 > > different strings. > > > > One thing that comes to mind is we could come up with some kind of "these > > functionalities have been disabled" based on > > FORCE_NOT_REQUIRED_DEPENDENCIES have been set. (Or maybe just a generic > > one if any has been set?) > > I understand your point In Kleopatra we try to avoid that, too. > > What do you think about two options: > > option(OKULAR_UI_TITLE "Use an alternative title for the Okular UI. Please > consider when using FORCE_NOT_REQUIRED_DEPENDENCIES" "Okular") > option(SHOW_REDUCED_FUNCTIONALITY_WARNING "Show a warning on first run and > in the about dialog that this Okular comes with a reduced functionality > set." ((NOT FORCE_NOT_REQUIRED_DEPENDENCIES) AND (NOT > FORCE_NOT_REQUIRED_DEPENDENCIES STREQUAL ""))) > > That way we could have a generic warning because I don't think > our users will understand what the libraries mean and explaining that would > be too much. And a distro that might want to make only a minor change like > not shipping CHM support for some reason can set this option to "OFF" to > avoid such a warning. > > The reference to the Windows store should also be added with a > Q_OS_WIN ifdef and maybe for Linux with an "obtain from your Distribution". > > OKULAR_UI_TITLE we can then use to bring in "Okular (GnuPG Edition)". > > Probably best if I create an MR and we can discuss this there. Yes. Cheers, Albert > > Best Regards, > Andre
Re: Okular with GnuPG / Gpg4win
Hi, On Tuesday 16 May 2023 23:55:00 CEST Albert Astals Cid wrote: > The text looks reasonable to me, but i guess we'd definitely want some input > from the KDE Promo folks. Want me to involve them or will you? I already did start on that yesterday. https://marc.info/?l=kde-promo&m=168423425626159&w=2 Btw. my second mail in the thread gives some additional rationale why the GnuPG integration is useful for us so it might be worth a read. > I can see that how that would make sense for translation but i don't see how > this particular wording makes sense to be in the Okular repository. > > Imagine we get 10 different downstreams like you, we would need 10 different > strings. > > One thing that comes to mind is we could come up with some kind of "these > functionalities have been disabled" based on FORCE_NOT_REQUIRED_DEPENDENCIES > have been set. (Or maybe just a generic one if any has been set?) I understand your point In Kleopatra we try to avoid that, too. What do you think about two options: option(OKULAR_UI_TITLE "Use an alternative title for the Okular UI. Please consider when using FORCE_NOT_REQUIRED_DEPENDENCIES" "Okular") option(SHOW_REDUCED_FUNCTIONALITY_WARNING "Show a warning on first run and in the about dialog that this Okular comes with a reduced functionality set." ((NOT FORCE_NOT_REQUIRED_DEPENDENCIES) AND (NOT FORCE_NOT_REQUIRED_DEPENDENCIES STREQUAL ""))) That way we could have a generic warning because I don't think our users will understand what the libraries mean and explaining that would be too much. And a distro that might want to make only a minor change like not shipping CHM support for some reason can set this option to "OFF" to avoid such a warning. The reference to the Windows store should also be added with a Q_OS_WIN ifdef and maybe for Linux with an "obtain from your Distribution". OKULAR_UI_TITLE we can then use to bring in "Okular (GnuPG Edition)". Probably best if I create an MR and we can discuss this there. Best Regards, Andre -- GnuPG.com - a brand of g10 Code, the GnuPG experts. g10 Code GmbH, Erkrath/Germany, AG Wuppertal HRB14459 GF Werner Koch, USt-Id DE215605608, www.g10code.com. GnuPG e.V., Rochusstr. 44, D-40479 Düsseldorf. VR 11482 Düsseldorf Vorstand: W.Koch, B.Reiter, A.HeineckeMail: bo...@gnupg.org Finanzamt D-Altstadt, St-Nr: 103/5923/1779. Tel: +49-211-28010702 signature.asc Description: This is a digitally signed message part.
Re: Okular with GnuPG / Gpg4win
El divendres, 12 de maig de 2023, a les 12:40:23 (CEST), Andre Heinecke va escriure: > Hi, > > our integration of Okular anxd GnuPG (and later on GnuPG VS-Desktop) is > nearly finished. Not everything is upstream yet but we see no roadblocks on > the way that might cause us to abort so we would like to go ahead and > announce this a bit more. > > Attached is a first draft of a statement about why we started to work on > this. The text looks reasonable to me, but i guess we'd definitely want some input from the KDE Promo folks. Want me to involve them or will you? > First of I want to say a big thank you to everyone who helped with reviewing > etc. and for the excellent design of Okular which allowed a very modular > build. > > But, this is a slight problem because we are targeting a high security > environment we want to limit the attack surface as much as possible. This > means that we have stripped down Okular quite a lot. > > - It will have only the poppler generator. > - Basically no optional dependencies. (No JavaScript) > - No Phonon for Media (patches to cleanly make that optional are incoming, I > have hacked it for now). > > Additionally we carry some patches which allow us to strip down framework > inter dependencies and brutally hack some parts like KIO to come for example > without DBus support. > > As such I think it would be unfair of us to call this just "Okular" and give > you a possibly bad name. > > My suggestion is the following: > - Use the name "Okular (GnuPG Edition)" in user visible strings, like the > start Menu, Window Title, About Dialog etc. > - Change the bug tracker URL to dev.gnupg.org for us (should be obvious). That seems reasonable to me. > > And finally to add a Message Box on the first launch and add a Text in the > about dialog to promote the full featured Okular which I draft as > following: > > -- > Okular in general is a lightweight and highly secure document viewer for > many document formats. > > To reduce the attack surface even further the GnuPG Edition is stripped > down to only support PDF documents without any active content. > > For the best User Experience you can safely install the fully featured > Okular from the https://apps.microsoft.com/store/detail/okular/ > 9N41MSQ1WNM8">Microsoft Store > -- > > If this seems agreeable to you I would open a merge request regarding > something like this as a build switch. I would like to have the text > included upstream instead of patching it in for translation / wording > support etc. I can see that how that would make sense for translation but i don't see how this particular wording makes sense to be in the Okular repository. Imagine we get 10 different downstreams like you, we would need 10 different strings. One thing that comes to mind is we could come up with some kind of "these functionalities have been disabled" based on FORCE_NOT_REQUIRED_DEPENDENCIES have been set. (Or maybe just a generic one if any has been set?) Cheers, Albert > > I don't think that a parallel installation of two Okulars will make much > sense except in very specific use cases (e.g. If you use Okular (GnuPG > Edition) to open PDF's from Mails and the regular Okular as default). But > it is possible and no Problem. > > > Best Regards, > Andre
Re: GSoC proposal submitted
Thanks for the feedback! Hoping everything goes smoothly. :) Thanks, Shivodit On 4/4/23 02:31, Albert Astals Cid wrote: > El dilluns, 3 d’abril de 2023, a les 22:08:45 (CEST), Shivodit Gill va > escriure: >> Hello, >> >> I have submitted my GSoC proposal on the online portal, please take a >> look at it. > > I've had a look at it, seems reasonable :) > > Best Regards, > Albert > >> >> Thanks, >> Shivodit > > > >
Re: GSoC proposal submitted
El dilluns, 3 d’abril de 2023, a les 22:08:45 (CEST), Shivodit Gill va escriure: > Hello, > > I have submitted my GSoC proposal on the online portal, please take a > look at it. I've had a look at it, seems reasonable :) Best Regards, Albert > > Thanks, > Shivodit
Re: Okular PlantUML Support
El dijous, 30 de març de 2023, a les 8:39:28 (CEST), Signal Kirigami va escriure: > Recently I'm trying to add PlantUML support on okular part. PlantUML is a > component to generate diagrams, and many markdown editors, such as QOwnNote > and VSCode, support it. > > The code is here: https://invent.kde.org/prcups/okular/-/tree/master. > > Current version have slow speed and will freeze when generating, because > markdown generator can't be dynamically update. I think I can do more on > this field, like creating a plugin platform, or change backend of > generator. We already have a plugin platform, generators are plugins. > I need some advice. You need to be more precise in which advice you need :) Cheers, Albert
Re:
Thanks for the info, I'll look into the GlobalParams code. As a side note, I'm having trouble figuring out why the icon rendering isn't working, as I haven't gotten to setting up a debug environment fully. Do you have any tips? Thanks, Shivodit On 3/27/23 13:25, Albert Astals Cid wrote: > El dilluns, 20 de març de 2023, a les 21:56:13 (CEST), Shivodit Gill va > escriure: >> Hello, >> >> Sorry about the ambiguous wording, what I meant to say was - after >> obtaining the correct font, how does the font API for desktop Poppler >> send the font for rendering to the correct backend (Cairo/Splash)? >> >> In short, I'm trying to understand the implementation of the current >> font API on desktop Poppler. This is to get an idea of how the Android >> font API based on FontMatcher would be designed - how it would get >> details of fonts that are unembedded in the pdf, and other such things. >> >> After looking through the Poppler repo, I think poppler/GfxFont.h and >> poppler/GfxFont.cc are the files which contain the implementation of the >> desktop font API. If I'm mistaken or if there are more files which >> provide the desktop font API, please point it out. > > You want to look at GlobalParams. > > Cheers, > Albert > >> >> Thanks, >> Shivodit >> >> On 3/20/23 03:31, Albert Astals Cid wrote: >>> El dissabte, 18 de març de 2023, a les 22:27:38 (CET), Shivodit Gill va >>> >>> escriure: Hello, Thanks for clearing that up! Also, while I was writing my proposal, I started wondering - how do we pass the font object to Poppler so it can use it? >>> >>> Who is we? There's nothing that needs to be passed to poppler, the change >>> needs to happen in poppler as mentioned in the gsoc description. >>> >>> Cheers, >>> >>> Albert AFontMatcher can take a string of text, and return the best matching font as a pointer to an AFont object. How will this AFont object be used to render the text in Poppler? I tried doing some research of my own in the Poppler repository but ended up getting confused. I couldn't find any documentation for how to render some text with a given font in Poppler. I couldn't find much info about the AFont datatype either. Using the AFont object, we can find the path of the returned font, which can be used to open said font file in O_RDONLY mode. Maybe we can pass that to Poppler? Thanks, Shivodit On 3/16/23 04:35, Albert Astals Cid wrote: > El dimecres, 15 de març de 2023, a les 22:23:19 (CET), Shivodit Gill va > > escriure: >> On 3/15/23 05:07, Albert Astals Cid wrote: >>> El dimarts, 14 de març de 2023, a les 22:30:38 (CET), Shivodit va > > escriure: Hello, >>> >>> Hello, please write a Subject to your emails. >> >> Sorry about that, I forgot to add a subject line and only realized it >> after I had sent the mail, since GMail doesn't warn about missing >> subject lines. I'll make sure to not repeat this in the future. >> I am a college student planning to contribute to KDE for GSoC '23, by taking on the task of improving Okular on Android. I have the following questions: 1. What will be the use case of implementing the Android AFontMatcher font API? Initially I had tested a .pdf file in Okular for Android, and the text in that file did not load at all. So I assumed that this API would help to find the correct fonts in such situations, so that text content could be properly shown. >>> >>> Exactly. >>> However, now I am not sure - I tried some other pdfs with text, and all of them rendered the text correctly. The issue with font rendering only occurs when viewing the earlier mentioned pdf file. If I use the "Print to file" option to create a duplicate of the problematic pdf, the duplicated pdf loads correctly on Okular for Android. Weirdly enough, the same problematic pdf renders correctly when opened in desktop Okular. 2. Since the AFontMatcher API will be implemented in the Poppler backend, I was wondering in which files/directories the programming work would be done. Initially I assumed work would be done in the generator/poppler directory of the Okular repo, but that turned out to be incorrect. After some digging, I stumbled upon the freedesktop Poppler repo, (https://gitlab.freedesktop.org/poppler/poppler and it contains) the code files for the Qt5 Poppler interface. I'm guessing the work will be done here? >>> >>> No, the code wil
Re:
El dilluns, 20 de març de 2023, a les 21:56:13 (CEST), Shivodit Gill va escriure: > Hello, > > Sorry about the ambiguous wording, what I meant to say was - after > obtaining the correct font, how does the font API for desktop Poppler > send the font for rendering to the correct backend (Cairo/Splash)? > > In short, I'm trying to understand the implementation of the current > font API on desktop Poppler. This is to get an idea of how the Android > font API based on FontMatcher would be designed - how it would get > details of fonts that are unembedded in the pdf, and other such things. > > After looking through the Poppler repo, I think poppler/GfxFont.h and > poppler/GfxFont.cc are the files which contain the implementation of the > desktop font API. If I'm mistaken or if there are more files which > provide the desktop font API, please point it out. You want to look at GlobalParams. Cheers, Albert > > Thanks, > Shivodit > > On 3/20/23 03:31, Albert Astals Cid wrote: > > El dissabte, 18 de març de 2023, a les 22:27:38 (CET), Shivodit Gill va > > > > escriure: > >> Hello, > >> > >> Thanks for clearing that up! > >> > >> Also, while I was writing my proposal, I started wondering - how do we > >> pass the font object to Poppler so it can use it? > > > > Who is we? There's nothing that needs to be passed to poppler, the change > > needs to happen in poppler as mentioned in the gsoc description. > > > > Cheers, > > > > Albert > >> > >> AFontMatcher can take a string of text, and return the best matching > >> font as a pointer to an AFont object. > >> > >> How will this AFont object be used to render the text in Poppler? > >> > >> I tried doing some research of my own in the Poppler repository but > >> ended up getting confused. I couldn't find any documentation for how to > >> render some text with a given font in Poppler. I couldn't find much info > >> about the AFont datatype either. > >> > >> Using the AFont object, we can find the path of the returned font, which > >> can be used to open said font file in O_RDONLY mode. Maybe we can pass > >> that to Poppler? > >> > >> Thanks, > >> Shivodit > >> > >> On 3/16/23 04:35, Albert Astals Cid wrote: > >>> El dimecres, 15 de març de 2023, a les 22:23:19 (CET), Shivodit Gill va > >>> > >>> escriure: > On 3/15/23 05:07, Albert Astals Cid wrote: > > El dimarts, 14 de març de 2023, a les 22:30:38 (CET), Shivodit va > >>> > >>> escriure: > >> Hello, > > > > Hello, please write a Subject to your emails. > > Sorry about that, I forgot to add a subject line and only realized it > after I had sent the mail, since GMail doesn't warn about missing > subject lines. I'll make sure to not repeat this in the future. > > >> I am a college student planning to contribute to KDE for GSoC '23, by > >> taking on the task of improving Okular on Android. I have the > >> following > >> questions: > >> > >> 1. What will be the use case of implementing the Android > >> AFontMatcher > >> > >> font API? > >> > >> Initially I had tested a .pdf file in Okular for Android, and the > >> text in that file did not load at all. So I assumed that this API > >> would help to find the correct fonts in such situations, so that > >> text content could be properly shown. > > > > Exactly. > > > >> However, now I am not sure - I tried some other pdfs with text, > >> and all of them rendered the text correctly. The issue with font > >> rendering only occurs when viewing the earlier mentioned pdf > >> file. > >> If I use the "Print to file" option to create a duplicate of the > >> problematic pdf, the duplicated pdf loads correctly on Okular for > >> Android. Weirdly enough, the same problematic pdf renders > >> correctly > >> when opened in desktop Okular. > >> > >> 2. Since the AFontMatcher API will be implemented in the Poppler > >> backend, > >> > >> I was wondering in which files/directories the programming work > >> would be done. > >> > >> Initially I assumed work would be done in the generator/poppler > >> directory of the Okular repo, but that turned out to be > >> incorrect. > >> > >> After some digging, I stumbled upon the freedesktop Poppler repo, > >> (https://gitlab.freedesktop.org/poppler/poppler and it contains) > >> the code files for the Qt5 Poppler interface. I'm guessing the > >> work > >> will be done here? > > > > No, the code will not be in the Qt5 Poppler interface, keep digging > > your > > almost there. > > I see, me being close probably means I'm in the correct repo, right? If > yes, then my guess is that the work will be happening in the poppler > directory of the Poppler repo. Reasoning
Re:
Hello, Sorry about the ambiguous wording, what I meant to say was - after obtaining the correct font, how does the font API for desktop Poppler send the font for rendering to the correct backend (Cairo/Splash)? In short, I'm trying to understand the implementation of the current font API on desktop Poppler. This is to get an idea of how the Android font API based on FontMatcher would be designed - how it would get details of fonts that are unembedded in the pdf, and other such things. After looking through the Poppler repo, I think poppler/GfxFont.h and poppler/GfxFont.cc are the files which contain the implementation of the desktop font API. If I'm mistaken or if there are more files which provide the desktop font API, please point it out. Thanks, Shivodit On 3/20/23 03:31, Albert Astals Cid wrote: > El dissabte, 18 de març de 2023, a les 22:27:38 (CET), Shivodit Gill va > escriure: >> Hello, >> >> Thanks for clearing that up! >> >> Also, while I was writing my proposal, I started wondering - how do we >> pass the font object to Poppler so it can use it? > > Who is we? There's nothing that needs to be passed to poppler, the change > needs to happen in poppler as mentioned in the gsoc description. > > Cheers, > Albert > >> >> AFontMatcher can take a string of text, and return the best matching >> font as a pointer to an AFont object. >> >> How will this AFont object be used to render the text in Poppler? >> >> I tried doing some research of my own in the Poppler repository but >> ended up getting confused. I couldn't find any documentation for how to >> render some text with a given font in Poppler. I couldn't find much info >> about the AFont datatype either. >> >> Using the AFont object, we can find the path of the returned font, which >> can be used to open said font file in O_RDONLY mode. Maybe we can pass >> that to Poppler? >> >> Thanks, >> Shivodit >> >> On 3/16/23 04:35, Albert Astals Cid wrote: >>> El dimecres, 15 de març de 2023, a les 22:23:19 (CET), Shivodit Gill va >>> >>> escriure: On 3/15/23 05:07, Albert Astals Cid wrote: > El dimarts, 14 de març de 2023, a les 22:30:38 (CET), Shivodit va >>> >>> escriure: >> Hello, > > Hello, please write a Subject to your emails. Sorry about that, I forgot to add a subject line and only realized it after I had sent the mail, since GMail doesn't warn about missing subject lines. I'll make sure to not repeat this in the future. >> I am a college student planning to contribute to KDE for GSoC '23, by >> taking on the task of improving Okular on Android. I have the following >> questions: >> >> 1. What will be the use case of implementing the Android AFontMatcher >> >> font API? >> >> Initially I had tested a .pdf file in Okular for Android, and the >> text in that file did not load at all. So I assumed that this API >> would help to find the correct fonts in such situations, so that >> text content could be properly shown. > > Exactly. > >> However, now I am not sure - I tried some other pdfs with text, >> and all of them rendered the text correctly. The issue with font >> rendering only occurs when viewing the earlier mentioned pdf file. >> If I use the "Print to file" option to create a duplicate of the >> problematic pdf, the duplicated pdf loads correctly on Okular for >> Android. Weirdly enough, the same problematic pdf renders correctly >> when opened in desktop Okular. >> >> 2. Since the AFontMatcher API will be implemented in the Poppler >> backend, >> >> I was wondering in which files/directories the programming work >> would be done. >> >> Initially I assumed work would be done in the generator/poppler >> directory of the Okular repo, but that turned out to be incorrect. >> >> After some digging, I stumbled upon the freedesktop Poppler repo, >> (https://gitlab.freedesktop.org/poppler/poppler and it contains) >> the code files for the Qt5 Poppler interface. I'm guessing the work >> will be done here? > > No, the code will not be in the Qt5 Poppler interface, keep digging your > almost there. I see, me being close probably means I'm in the correct repo, right? If yes, then my guess is that the work will be happening in the poppler directory of the Poppler repo. Reasoning being that it contains some .cc/.cpp files which deal with some information related to fonts.. >>> >>> Yes, that is the proper folder. >>> >> 3. This is a bit off-topic, but why is the pdf mentioned above having >> >> trouble with text rendering? All other pdfs with text content >> render >> correctly, but only this specific file has trouble with loading on >> Android Okular but it gets shown correctly everywher
Re: segmentation fault 22.04.3
Thank you Albert. The pdf file is not relevant here though. Not when other viewers such as xpdf handle the file without a problem. The pdf file is certainly relevant. It is very difficult to fix a crash in a particular file without having the file. Please open an issue on bugs.kde.org and attach the file. Best, Oliver smime.p7s Description: S/MIME Cryptographic Signature
Re:
El dissabte, 18 de març de 2023, a les 22:27:38 (CET), Shivodit Gill va escriure: > Hello, > > Thanks for clearing that up! > > Also, while I was writing my proposal, I started wondering - how do we > pass the font object to Poppler so it can use it? Who is we? There's nothing that needs to be passed to poppler, the change needs to happen in poppler as mentioned in the gsoc description. Cheers, Albert > > AFontMatcher can take a string of text, and return the best matching > font as a pointer to an AFont object. > > How will this AFont object be used to render the text in Poppler? > > I tried doing some research of my own in the Poppler repository but > ended up getting confused. I couldn't find any documentation for how to > render some text with a given font in Poppler. I couldn't find much info > about the AFont datatype either. > > Using the AFont object, we can find the path of the returned font, which > can be used to open said font file in O_RDONLY mode. Maybe we can pass > that to Poppler? > > Thanks, > Shivodit > > On 3/16/23 04:35, Albert Astals Cid wrote: > > El dimecres, 15 de març de 2023, a les 22:23:19 (CET), Shivodit Gill va > > > > escriure: > >> On 3/15/23 05:07, Albert Astals Cid wrote: > >>> El dimarts, 14 de març de 2023, a les 22:30:38 (CET), Shivodit va > > > > escriure: > Hello, > >>> > >>> Hello, please write a Subject to your emails. > >> > >> Sorry about that, I forgot to add a subject line and only realized it > >> after I had sent the mail, since GMail doesn't warn about missing > >> subject lines. I'll make sure to not repeat this in the future. > >> > I am a college student planning to contribute to KDE for GSoC '23, by > taking on the task of improving Okular on Android. I have the following > questions: > > 1. What will be the use case of implementing the Android AFontMatcher > > font API? > > Initially I had tested a .pdf file in Okular for Android, and the > text in that file did not load at all. So I assumed that this API > would help to find the correct fonts in such situations, so that > text content could be properly shown. > >>> > >>> Exactly. > >>> > However, now I am not sure - I tried some other pdfs with text, > and all of them rendered the text correctly. The issue with font > rendering only occurs when viewing the earlier mentioned pdf file. > If I use the "Print to file" option to create a duplicate of the > problematic pdf, the duplicated pdf loads correctly on Okular for > Android. Weirdly enough, the same problematic pdf renders correctly > when opened in desktop Okular. > > 2. Since the AFontMatcher API will be implemented in the Poppler > backend, > > I was wondering in which files/directories the programming work > would be done. > > Initially I assumed work would be done in the generator/poppler > directory of the Okular repo, but that turned out to be incorrect. > > After some digging, I stumbled upon the freedesktop Poppler repo, > (https://gitlab.freedesktop.org/poppler/poppler and it contains) > the code files for the Qt5 Poppler interface. I'm guessing the work > will be done here? > >>> > >>> No, the code will not be in the Qt5 Poppler interface, keep digging your > >>> almost there. > >> > >> I see, me being close probably means I'm in the correct repo, right? If > >> yes, then my guess is that the work will be happening in the poppler > >> directory of the Poppler repo. Reasoning being that it contains some > >> .cc/.cpp files which deal with some information related to fonts.. > > > > Yes, that is the proper folder. > > > 3. This is a bit off-topic, but why is the pdf mentioned above having > > trouble with text rendering? All other pdfs with text content > render > correctly, but only this specific file has trouble with loading on > Android Okular but it gets shown correctly everywhere else, > including > other pdf viewers on Android. I can send the pdf if someone > would like to take a look at it. > >>> > >>> Without the PDF I can only guess is because the PDF doesn't embed its > >>> fonts. > >> > >> I see, so maybe duplicating the entire pdf using the 'Print to File' > >> functionality causes the proper fonts/their substitutes to get embedded? > >> > >> I've also uploaded the faulty pdf I mentioned to this google drive link, > >> please check it out when you get the chance. > >> > >> Faulty pdf: > >> https://drive.google.com/file/d/1oid-cZwady9jaCpdZb4wShflDId-RHFu/view?us > >> p=s haring > > > > There's nothing faulty about that pdf, having non embedded fonts is > > perfectly ok, and that's why we need poppler+Android to support that > > scenario. > > > > Cheers, > >
Re:
Hello, Thanks for clearing that up! Also, while I was writing my proposal, I started wondering - how do we pass the font object to Poppler so it can use it? AFontMatcher can take a string of text, and return the best matching font as a pointer to an AFont object. How will this AFont object be used to render the text in Poppler? I tried doing some research of my own in the Poppler repository but ended up getting confused. I couldn't find any documentation for how to render some text with a given font in Poppler. I couldn't find much info about the AFont datatype either. Using the AFont object, we can find the path of the returned font, which can be used to open said font file in O_RDONLY mode. Maybe we can pass that to Poppler? Thanks, Shivodit On 3/16/23 04:35, Albert Astals Cid wrote: > El dimecres, 15 de març de 2023, a les 22:23:19 (CET), Shivodit Gill va > escriure: >> On 3/15/23 05:07, Albert Astals Cid wrote: >>> El dimarts, 14 de març de 2023, a les 22:30:38 (CET), Shivodit va > escriure: Hello, >>> >>> Hello, please write a Subject to your emails. >> >> Sorry about that, I forgot to add a subject line and only realized it >> after I had sent the mail, since GMail doesn't warn about missing >> subject lines. I'll make sure to not repeat this in the future. >> I am a college student planning to contribute to KDE for GSoC '23, by taking on the task of improving Okular on Android. I have the following questions: 1. What will be the use case of implementing the Android AFontMatcher font API? Initially I had tested a .pdf file in Okular for Android, and the text in that file did not load at all. So I assumed that this API would help to find the correct fonts in such situations, so that text content could be properly shown. >>> >>> Exactly. >>> However, now I am not sure - I tried some other pdfs with text, and all of them rendered the text correctly. The issue with font rendering only occurs when viewing the earlier mentioned pdf file. If I use the "Print to file" option to create a duplicate of the problematic pdf, the duplicated pdf loads correctly on Okular for Android. Weirdly enough, the same problematic pdf renders correctly when opened in desktop Okular. 2. Since the AFontMatcher API will be implemented in the Poppler backend, I was wondering in which files/directories the programming work would be done. Initially I assumed work would be done in the generator/poppler directory of the Okular repo, but that turned out to be incorrect. After some digging, I stumbled upon the freedesktop Poppler repo, (https://gitlab.freedesktop.org/poppler/poppler and it contains) the code files for the Qt5 Poppler interface. I'm guessing the work will be done here? >>> >>> No, the code will not be in the Qt5 Poppler interface, keep digging your >>> almost there. >> >> I see, me being close probably means I'm in the correct repo, right? If >> yes, then my guess is that the work will be happening in the poppler >> directory of the Poppler repo. Reasoning being that it contains some >> .cc/.cpp files which deal with some information related to fonts.. > > Yes, that is the proper folder. > >> 3. This is a bit off-topic, but why is the pdf mentioned above having trouble with text rendering? All other pdfs with text content render correctly, but only this specific file has trouble with loading on Android Okular but it gets shown correctly everywhere else, including other pdf viewers on Android. I can send the pdf if someone would like to take a look at it. >>> >>> Without the PDF I can only guess is because the PDF doesn't embed its >>> fonts. >> I see, so maybe duplicating the entire pdf using the 'Print to File' >> functionality causes the proper fonts/their substitutes to get embedded? >> >> I've also uploaded the faulty pdf I mentioned to this google drive link, >> please check it out when you get the chance. >> >> Faulty pdf: >> https://drive.google.com/file/d/1oid-cZwady9jaCpdZb4wShflDId-RHFu/view?usp=s >> haring > > There's nothing faulty about that pdf, having non embedded fonts is perfectly > ok, and that's why we need poppler+Android to support that scenario. > > Cheers, > Albert > >> >> Thanks, >> Shivodit >> >>> Cheers, >>> >>> Albert Thanks, Shivodit > > > >
Re: segmentation fault 22.04.3
On Sat, Mar 18, 2023 at 11:46:21AM +0100, Albert Astals Cid wrote: > El dissabte, 18 de març de 2023, a les 6:34:56 (CET), Carlos va escriure: > > Hello list: > > > > I just came across a segmentation fault. I didn't check for similar errors, > > but I thought of posting it either way. Okular crashes every time with the > > same file. > > > > Starting program: /usr/bin/okular > > [New LWP 22049] > > [New LWP 22050] > > [New LWP 22051] > > [LWP 22051 exited] > > [New LWP 22055] > > [New LWP 22056] > > [LWP 22055 exited] > > [LWP 22056 exited] > > [New LWP 22057] > > [New LWP 22058] > > [LWP 22057 exited] > > [New LWP 22059] > > > > Thread 8 "Okular::TextPag" received signal SIGSEGV, Segmentation fault. > > [Switching to LWP 22058] > > 0x7fffe76b5e4a in ?? () from /usr/lib/libpoppler.so.121 > > Please file bug in bugs.kde.org add a longer backtrace (ideally with > symbols) I'll do that. I don't know about the «symbols» part, as there are only ?? and () on the backtrace. > and attach the file that is causing the crash. > > Cheers, > Albert Thank you Albert. The pdf file is not relevant here though. Not when other viewers such as xpdf handle the file without a problem. -- Overflow on /dev/null, please empty the bit bucket.
Re: segmentation fault 22.04.3
El dissabte, 18 de març de 2023, a les 6:34:56 (CET), Carlos va escriure: > Hello list: > > I just came across a segmentation fault. I didn't check for similar errors, > but I thought of posting it either way. Okular crashes every time with the > same file. > > Starting program: /usr/bin/okular > [New LWP 22049] > [New LWP 22050] > [New LWP 22051] > [LWP 22051 exited] > [New LWP 22055] > [New LWP 22056] > [LWP 22055 exited] > [LWP 22056 exited] > [New LWP 22057] > [New LWP 22058] > [LWP 22057 exited] > [New LWP 22059] > > Thread 8 "Okular::TextPag" received signal SIGSEGV, Segmentation fault. > [Switching to LWP 22058] > 0x7fffe76b5e4a in ?? () from /usr/lib/libpoppler.so.121 Please file bug in bugs.kde.org add a longer backtrace (ideally with symbols) and attach the file that is causing the crash. Cheers, Albert
Re: Digital signature: font & content of the rectangle
Hi Guillaume, most of what is missing has been implemented in https://invent.kde.org/graphics/okular/-/merge_requests/537 Best, Oliver On 15.03.23 18:31, Guillaume Gheysen wrote: Dear Okular developers, I am using Okular to e-sign documents (using Belgian Eid) and I really appreciate your work. However, I don't find the options to configure the signature drawn on the pdf (font, content, etc.) and I need to make a huge rectangle to have a visible signature (which is not often possible). It is possible to have information about this configuration or do you know when this feature will be available ? Thank you. Best regards, Guillaume Gheysen smime.p7s Description: S/MIME Cryptographic Signature
Re:
El dimecres, 15 de març de 2023, a les 22:23:19 (CET), Shivodit Gill va escriure: > On 3/15/23 05:07, Albert Astals Cid wrote: > > El dimarts, 14 de març de 2023, a les 22:30:38 (CET), Shivodit va escriure: > >> Hello, > > > > Hello, please write a Subject to your emails. > > Sorry about that, I forgot to add a subject line and only realized it > after I had sent the mail, since GMail doesn't warn about missing > subject lines. I'll make sure to not repeat this in the future. > > >> I am a college student planning to contribute to KDE for GSoC '23, by > >> taking on the task of improving Okular on Android. I have the following > >> questions: > >> > >> 1. What will be the use case of implementing the Android AFontMatcher > >> > >> font API? > >> > >> Initially I had tested a .pdf file in Okular for Android, and the > >> text in that file did not load at all. So I assumed that this API > >> would help to find the correct fonts in such situations, so that > >> text content could be properly shown. > > > > Exactly. > > > >> However, now I am not sure - I tried some other pdfs with text, > >> and all of them rendered the text correctly. The issue with font > >> rendering only occurs when viewing the earlier mentioned pdf file. > >> If I use the "Print to file" option to create a duplicate of the > >> problematic pdf, the duplicated pdf loads correctly on Okular for > >> Android. Weirdly enough, the same problematic pdf renders correctly > >> when opened in desktop Okular. > >> > >> 2. Since the AFontMatcher API will be implemented in the Poppler > >> backend, > >> > >> I was wondering in which files/directories the programming work > >> would be done. > >> > >> Initially I assumed work would be done in the generator/poppler > >> directory of the Okular repo, but that turned out to be incorrect. > >> > >> After some digging, I stumbled upon the freedesktop Poppler repo, > >> (https://gitlab.freedesktop.org/poppler/poppler and it contains) > >> the code files for the Qt5 Poppler interface. I'm guessing the work > >> will be done here? > > > > No, the code will not be in the Qt5 Poppler interface, keep digging your > > almost there. > > I see, me being close probably means I'm in the correct repo, right? If > yes, then my guess is that the work will be happening in the poppler > directory of the Poppler repo. Reasoning being that it contains some > .cc/.cpp files which deal with some information related to fonts.. Yes, that is the proper folder. > > >> 3. This is a bit off-topic, but why is the pdf mentioned above having > >> > >> trouble with text rendering? All other pdfs with text content render > >> correctly, but only this specific file has trouble with loading on > >> Android Okular but it gets shown correctly everywhere else, including > >> other pdf viewers on Android. I can send the pdf if someone > >> would like to take a look at it. > > > > Without the PDF I can only guess is because the PDF doesn't embed its > > fonts. > I see, so maybe duplicating the entire pdf using the 'Print to File' > functionality causes the proper fonts/their substitutes to get embedded? > > I've also uploaded the faulty pdf I mentioned to this google drive link, > please check it out when you get the chance. > > Faulty pdf: > https://drive.google.com/file/d/1oid-cZwady9jaCpdZb4wShflDId-RHFu/view?usp=s > haring There's nothing faulty about that pdf, having non embedded fonts is perfectly ok, and that's why we need poppler+Android to support that scenario. Cheers, Albert > > Thanks, > Shivodit > > > Cheers, > > > > Albert > >> > >> Thanks, > >> Shivodit
Re:
On 3/15/23 05:07, Albert Astals Cid wrote: > El dimarts, 14 de març de 2023, a les 22:30:38 (CET), Shivodit va escriure: >> Hello, > > Hello, please write a Subject to your emails. Sorry about that, I forgot to add a subject line and only realized it after I had sent the mail, since GMail doesn't warn about missing subject lines. I'll make sure to not repeat this in the future. > >> >> I am a college student planning to contribute to KDE for GSoC '23, by >> taking on the task of improving Okular on Android. I have the following >> questions: >> >> 1. What will be the use case of implementing the Android AFontMatcher >> font API? >> >> Initially I had tested a .pdf file in Okular for Android, and the >> text in that file did not load at all. So I assumed that this API >> would help to find the correct fonts in such situations, so that >> text content could be properly shown. > > Exactly. > >> >> However, now I am not sure - I tried some other pdfs with text, >> and all of them rendered the text correctly. The issue with font >> rendering only occurs when viewing the earlier mentioned pdf file. >> If I use the "Print to file" option to create a duplicate of the >> problematic pdf, the duplicated pdf loads correctly on Okular for >> Android. Weirdly enough, the same problematic pdf renders correctly >> when opened in desktop Okular. >> >> 2. Since the AFontMatcher API will be implemented in the Poppler backend, >> I was wondering in which files/directories the programming work >> would be done. >> >> Initially I assumed work would be done in the generator/poppler >> directory of the Okular repo, but that turned out to be incorrect. >> >> After some digging, I stumbled upon the freedesktop Poppler repo, >> (https://gitlab.freedesktop.org/poppler/poppler and it contains) >> the code files for the Qt5 Poppler interface. I'm guessing the work >> will be done here? > > No, the code will not be in the Qt5 Poppler interface, keep digging your > almost there. I see, me being close probably means I'm in the correct repo, right? If yes, then my guess is that the work will be happening in the poppler directory of the Poppler repo. Reasoning being that it contains some .cc/.cpp files which deal with some information related to fonts.. >> >> 3. This is a bit off-topic, but why is the pdf mentioned above having >> trouble with text rendering? All other pdfs with text content render >> correctly, but only this specific file has trouble with loading on >> Android Okular but it gets shown correctly everywhere else, including >> other pdf viewers on Android. I can send the pdf if someone >> would like to take a look at it. > > Without the PDF I can only guess is because the PDF doesn't embed its fonts. > I see, so maybe duplicating the entire pdf using the 'Print to File' functionality causes the proper fonts/their substitutes to get embedded? I've also uploaded the faulty pdf I mentioned to this google drive link, please check it out when you get the chance. Faulty pdf: https://drive.google.com/file/d/1oid-cZwady9jaCpdZb4wShflDId-RHFu/view?usp=sharing Thanks, Shivodit > Cheers, > Albert > >> >> Thanks, >> Shivodit > > > >
Re:
El dimarts, 14 de març de 2023, a les 22:30:38 (CET), Shivodit va escriure: > Hello, Hello, please write a Subject to your emails. > > I am a college student planning to contribute to KDE for GSoC '23, by > taking on the task of improving Okular on Android. I have the following > questions: > > 1. What will be the use case of implementing the Android AFontMatcher > font API? > > Initially I had tested a .pdf file in Okular for Android, and the > text in that file did not load at all. So I assumed that this API > would help to find the correct fonts in such situations, so that > text content could be properly shown. Exactly. > > However, now I am not sure - I tried some other pdfs with text, > and all of them rendered the text correctly. The issue with font > rendering only occurs when viewing the earlier mentioned pdf file. > If I use the "Print to file" option to create a duplicate of the > problematic pdf, the duplicated pdf loads correctly on Okular for > Android. Weirdly enough, the same problematic pdf renders correctly > when opened in desktop Okular. > > 2. Since the AFontMatcher API will be implemented in the Poppler backend, > I was wondering in which files/directories the programming work > would be done. > > Initially I assumed work would be done in the generator/poppler > directory of the Okular repo, but that turned out to be incorrect. > > After some digging, I stumbled upon the freedesktop Poppler repo, > (https://gitlab.freedesktop.org/poppler/poppler and it contains) > the code files for the Qt5 Poppler interface. I'm guessing the work > will be done here? No, the code will not be in the Qt5 Poppler interface, keep digging your almost there. > > 3. This is a bit off-topic, but why is the pdf mentioned above having > trouble with text rendering? All other pdfs with text content render > correctly, but only this specific file has trouble with loading on > Android Okular but it gets shown correctly everywhere else, including > other pdf viewers on Android. I can send the pdf if someone > would like to take a look at it. Without the PDF I can only guess is because the PDF doesn't embed its fonts. Cheers, Albert > > Thanks, > Shivodit
Re: Runtime error "you need to call Settings::instance before using"
Am Samstag, 25. Februar 2023, 11:41:42 CET schrieb Albert Astals Cid: > Why are you adding PDF only options to the general config file and general > config dialog instead of to the PDF generator config file and PDF generator > config dialog/page? Moved the configuration to the Backend Configuration, looks now like this: https://invent.kde.org/martin-de/okular/uploads/82757d49a7fe7daa4ffa872f5f6ca4b6/Screenshot_20230225_144426.png It seems to work now: the configuration is saved and can be retrieved and set as default before printing, and the print dialog no longer crashes after invoking it. Should I create a merge request now? Cheers, Martin
Re: Runtime error "you need to call Settings::instance before using"
El divendres, 24 de febrer de 2023, a les 12:34:59 (CET), Martin Schnitkemper va escriure: > Am Donnerstag, 23. Februar 2023, 23:32:15 CET schrieben Sie: > > Hello Albert, > > > Please push your code as a Merge Request so we can see it, much easier to > > comment on code when we can see it :) > > Thank you for your response. Please keep the list on copy :) > > I forked the project and created a branch: > https://invent.kde.org/martin-de/okular/-/tree/wish%23463732 > > There you are able to review the code, these are the changes: > https://invent.kde.org/martin-de/okular/-/commit/1df9d5a500241b0cfae860b1e1b > d1d604dde7439 Why are you adding PDF only options to the general config file and general config dialog instead of to the PDF generator config file and PDF generator config dialog/page? > > I opend also an issue where I described the problem more detailed: > https://invent.kde.org/martin-de/okular/-/issues/1 > > You can leave your comments there, since I dropped myself from the > mailinglist due to the traffic. Which trafic? the bug emails? You need to learn about email filtering :) Cheers, Albert > > Cheers, > Martin
Re: Runtime error "you need to call Settings::instance before using"
El dijous, 19 de gener de 2023, a les 9:43:30 (CET), Martin Schnitkemper va escriure: > Hello, > > I tried to extend okular to save PDF-Print-Options (wish #463732). All > works well so far, I added a new item in the configuration dialog and the > new variable "PageScaleMode" is written to and read from "okularpartrc", > but I am not able to assign the value of "Okular::Settings::pageScaleMode" > to "m_scaleMode->setCurrentIndex" in module "generator_pdf.cpp". > > Compilation is successful, but it crashes on runtime after opening the print > dialog. Message on terminal is "you need to call Settings::instance before > using". > > I am not too familiar with C++ coding and it is my first try to extend an > application. I inspected already the other modules of the project where the > developers used "Okular::Settings::" in a similar & working way, but I > could not find out so far, where the instance has been set for a proper > usage. > > Can anyone tell me what I missed, or guide me to a code example of the > okular project where I can see how to get right access to the > "Okular::Settings::"? Please push your code as a Merge Request so we can see it, much easier to comment on code when we can see it :) Cheers, Albert > > Thank you in advance for your support, > Martin
Re: Publish Okular for Windows using new script
El dilluns, 6 de febrer de 2023, a les 17:32:58 (CET), Ingo Klöcker va escriure: > On Donnerstag, 2. Februar 2023 23:31:29 CET Albert Astals Cid wrote: > > El dimarts, 31 de gener de 2023, a les 16:23:43 (CET), Ingo Klöcker va > > > > escriure: > > > * There are 5 screenshots in Microsoft Store which are different from > > > the > > > screenshots referenced in the AppStream data. On one hand this allows > > > using > > > Windows-specific screenshots for the Microsoft Store. On the other hand > > > you > > > miss the opportunity for translated captions which are provided by the > > > AppStream data. Maybe consider using the same screenshots because I > > > guess > > > that the look of Okular on Windows shouldn't be that different than the > > > one > > > on Linux except for different windows decorations. > > > > I think this is a big deal for Windows users, they are already scared > > enough installing some weird app, worst if we show them the wrong window > > decoration in the screenshots. > > > > Maybe we can use custom tags for the windows screenshots? > > > > https://community.kde.org/Guidelines_and_HOWTOs/AppStream#KDE_customs_tags > > Custom tags seem to be limited to key-value pairs. :/ > An alternative would be > to add the Windows screenshots to the screenshots tag, but without > type="default" (or any other type) and instead with platform="windows" > (Harald opened an issue for this some time ago: > https://github.com/ximion/appstream/issues/390). > > We will have to change the generator for apps.kde.org to skip screenshots > without default type if we don't want to see Windows screenshots on > apps.kde.org. But that will just work for apps.kde.org there's "infinite" other consumers of appstream files out there (discover, flathub, gnome software), we can't "fix" those > > BTW, I don't see the Windows screenshots in > https://cdn.kde.org/screenshots/okular/ > Where are they "hidden"? I guess in the Windows Store :D Cheers, Albert > > Regards, > Ingo
Re: Publish Okular for Windows using new script
On Donnerstag, 2. Februar 2023 23:31:29 CET Albert Astals Cid wrote: > El dimarts, 31 de gener de 2023, a les 16:23:43 (CET), Ingo Klöcker va > escriure: > > * There are 5 screenshots in Microsoft Store which are different from the > > screenshots referenced in the AppStream data. On one hand this allows > > using > > Windows-specific screenshots for the Microsoft Store. On the other hand > > you > > miss the opportunity for translated captions which are provided by the > > AppStream data. Maybe consider using the same screenshots because I guess > > that the look of Okular on Windows shouldn't be that different than the > > one > > on Linux except for different windows decorations. > > I think this is a big deal for Windows users, they are already scared enough > installing some weird app, worst if we show them the wrong window > decoration in the screenshots. > > Maybe we can use custom tags for the windows screenshots? > > https://community.kde.org/Guidelines_and_HOWTOs/AppStream#KDE_customs_tags Custom tags seem to be limited to key-value pairs. An alternative would be to add the Windows screenshots to the screenshots tag, but without type="default" (or any other type) and instead with platform="windows" (Harald opened an issue for this some time ago: https://github.com/ximion/appstream/issues/390). We will have to change the generator for apps.kde.org to skip screenshots without default type if we don't want to see Windows screenshots on apps.kde.org. BTW, I don't see the Windows screenshots in https://cdn.kde.org/screenshots/okular/ Where are they "hidden"? Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Publish Okular for Windows using new script
El dimarts, 31 de gener de 2023, a les 16:23:43 (CET), Ingo Klöcker va escriure: > Hi Okular devs, > > as you may have seen there is now a way to publish your application semi- > automatically on the Microsoft Store: > https://blogs.kde.org/2023/01/16/neochat-published-microsoft-store > > Aleix suggested that you could give it a try, so that I can get feedback > what should be improved. > > The idea of the script is to use the information from the AppStream data > additionally to the .appxupload package so that one does not have to fill in > the information manually. > > Comparing the AppStream data for Okular with the information published in > the Microsoft Store I'm seeing the following: > > * The Microsoft Store contains only a listing in English. The script would > create listings for all languages (supported by Microsoft Store) for which > there is a translation of the description in the AppStream data. > > * The description in Microsoft Store seems to be identical to the > description in the AppStream data, but without the list of Features. > > * The list of Features in Microsoft Store seems to be identical to the list > of Features in the description in the AppStream data. > > * What's New? in Microsoft Store contains "Updated to ". In the > AppStream data the first (newest) release entry has no description. Quite > frankly, "Update to " isn't really very helpful information for the > users. Listing new features would be much more interesting (for all > consumers of the AppStream data). I used to add links to the changelog (i.e. https://kde.org/announcements/ changelogs/gear/22.12.0/#okular), if the last one doesn't is because i got bored > > * There are 5 screenshots in Microsoft Store which are different from the > screenshots referenced in the AppStream data. On one hand this allows using > Windows-specific screenshots for the Microsoft Store. On the other hand you > miss the opportunity for translated captions which are provided by the > AppStream data. Maybe consider using the same screenshots because I guess > that the look of Okular on Windows shouldn't be that different than the one > on Linux except for different windows decorations. I think this is a big deal for Windows users, they are already scared enough installing some weird app, worst if we show them the wrong window decoration in the screenshots. Maybe we can use custom tags for the windows screenshots? https://community.kde.org/Guidelines_and_HOWTOs/AppStream#KDE_customs_tags Cheers, Albert > > * The entry in the Microsoft Store lists Search terms. AppStream supports > (and the script uses those), but Okular's AppStream data doesn't > list any keywords. > > For a first try you may want to run the script as follows: > > python3 submit-to-microsoft-store.py -vv --skip-commit \ > --keep description,images org.kde.okular > > so that the description (for the English listing) and the images are not > overwritten by the information found in the AppStream data. Moreover, the > --skip-commit option will allow you to check the submission in Partner > Center before it is actually submitted for publication. > > Note that you need special credentials to actually use this script (as > mentioned in the documentation). You need to ask Ben for them. (Of course, I > could also give them to you, but it's better to keep Ben in the loop.) In > the future, the script is supposed to be run on invent so that we do not > have to hand out credentials to anyone/everyone. > > Regards, > Ingo
Re: Possible to change scroll refresh rate to match monitor
Interesting .. I suspected as much, but thank you for confirming. I do have one monitor, but yes for whatever reason the display manager starts up at 60, and the Xsession runs at 120 Hz. Nonetheless, can confirm that kile scrolls a pdf smoothly at 120Hz in the preview pane. What you said makes sense regarding line scrolling in kate -- also smooth / instantaneous. Could it be a performance issue? Seems unlikely as Okular is not saturating the CPU (a Ryzen 9 5950x...), and scrolling should be pretty straightforward (unsure how much rendering is batched internally, though). Cheers, Tim Date: Sat, 07 Jan 2023 10:47:51 +0100 From: David Hurka To: okular-devel@kde.org Subject: Re: Possible to change scroll refresh rate to match monitor (e.g. 120Hz, 144Hz) Message-ID: <2285352.ElGaqSPkdT@doro> Content-Type: text/plain; charset="UTF-8" > Is there some way to get okular to refresh the page faster? > It seems fixed at 60hz. Its not possible from within Okular. According to QScroller documentation, there is a global animation timer which sets the update rate. This timer should match the frame rate of the screen, but apparently that doesn’t work. (Maybe you have more than one monitor, or the monitor changes framerate after startup, or Qt fails to detect it correctly.) > Of note other KDE / qt apps refresh at the monitor rate > (konsole, kate, kile) It surprises me, because they use either line-wise scrolling, which happens instantly, or Okular. If it works in the Kile document preview, that means Kile is better than the Okular shell in detecting the framerate.
Re: Possible to change scroll refresh rate to match monitor (e.g. 120Hz, 144Hz)
> Is there some way to get okular to refresh the page faster? > It seems fixed at 60hz. Its not possible from within Okular. According to QScroller documentation, there is a global animation timer which sets the update rate. This timer should match the frame rate of the screen, but apparently that doesn’t work. (Maybe you have more than one monitor, or the monitor changes framerate after startup, or Qt fails to detect it correctly.) > Of note other KDE / qt apps refresh at the monitor rate > (konsole, kate, kile) It surprises me, because they use either line-wise scrolling, which happens instantly, or Okular. If it works in the Kile document preview, that means Kile is better than the Okular shell in detecting the framerate.
Re: Blue Angel info | include in manual or "About" info-box?
El dimecres, 7 de desembre de 2022, a les 10:36:29 (CET), Joseph P. De Veaugh- Geiss va escriure: > Hello, > > On 12/4/22 23:47, Albert Astals Cid wrote: > > I don't see how to make it fit in the About dialog though. The About > > dialog is not very customizable (on purpose, so that all apps show the > > same). > > > > One option is to add it as "Other" text, but IMHO it's a bit too > > prominent, > > before the copyright and okular webpage link > > https://i.imgur.com/ZkRIoTr.png > > > > The other option is have it in the "Thanks" section, which is semantically > > wrong (e.g. the web link tooltip says "Visit the contributors page") > > https://i.imgur.com/VbkajK2.png > > > > Maybe we should just go for the manual? > > I noticed that different applications have different tabs in the Help > > About X info box. For instance: Dolphin has "About", "Components, > "Authors", while Kate has those plus "Thanks To". > > Could it be worth adding a "Sustainabaility" / "Eco" tab? This would be > a place to include information about Blue Angel eco-certification and > other energy measurements, or aspects of the software which make it more > sustainable (runs on older hardware, freedom from advertising, etc.)? > > I think this idea fits well with the sustainability goal, in particular > "highlighting where our software is already sustainably designed". > > https://community.kde.org/Goals/Sustainable_Software > > What do you think? The only thing applications can add is what i told you. Adding new tabs is outside the applications scope and would need changes in kcoreaddons and kxmlgui (which are out of scope to discuss here). Cheers, Albert > > Cheers, > Joseph
Re: Blue Angel info | include in manual or "About" info-box?
Hello, On 12/4/22 23:47, Albert Astals Cid wrote: I don't see how to make it fit in the About dialog though. The About dialog is not very customizable (on purpose, so that all apps show the same). One option is to add it as "Other" text, but IMHO it's a bit too prominent, before the copyright and okular webpage link https://i.imgur.com/ZkRIoTr.png The other option is have it in the "Thanks" section, which is semantically wrong (e.g. the web link tooltip says "Visit the contributors page") https://i.imgur.com/VbkajK2.png Maybe we should just go for the manual? I noticed that different applications have different tabs in the Help > About X info box. For instance: Dolphin has "About", "Components, "Authors", while Kate has those plus "Thanks To". Could it be worth adding a "Sustainabaility" / "Eco" tab? This would be a place to include information about Blue Angel eco-certification and other energy measurements, or aspects of the software which make it more sustainable (runs on older hardware, freedom from advertising, etc.)? I think this idea fits well with the sustainability goal, in particular "highlighting where our software is already sustainably designed". https://community.kde.org/Goals/Sustainable_Software What do you think? Cheers, Joseph -- Joseph P. De Veaugh-Geiss BE4FOSS Project and Community Manager (KDE Eco) OpenPGP: 8FC5 4178 DC44 AD55 08E7 DF57 453E 5746 59A6 C06F --- KDE Eco: Building Energy-Efficient Free Software! Website: https://eco.kde.org Mastodon: @be4foss@floss.social Mailing list: https://mail.kde.org/cgi-bin/mailman/listinfo/energy-efficiency Matrix: https://webchat.kde.org/#/room/#energy-efficiency:kde.org Forum: https://forum.kde.org/viewforum.php?f=334
RE: [okular] [Bug 434777] [Snap] Okular does not open in new tab but window
To me, that looks like you are using different okular versions with different settings. Maybe one is snap and one from the system?Von meinem/meiner Galaxy gesendet Ursprüngliche Nachricht Von: bugzilla_nore...@kde.org Datum: 07.12.22 09:50 (GMT+01:00) An: okular-devel@kde.org Betreff: [okular] [Bug 434777] [Snap] Okular does not open in new tab but window https://bugs.kde.org/show_bug.cgi?id=434777--- Comment #3 from giamm...@hotmail.com ---I have just noticed that if a pdf is opened via right click -> open withanother application -> Okular, instead of double-clicking, the file is actuallyopened in a tab of the already opened Okular. How is it possible to code thisas default behaviour?-- You are receiving this mail because:You are the assignee for the bug.
Re: Blue Angel info | include in manual or "About" info-box?
El divendres, 2 de desembre de 2022, a les 8:11:50 (CET), Joseph P. De Veaugh- Geiss va escriure: > Hi! > > On 12/2/22 00:05, Albert Astals Cid wrote: > > I'm not against it, but what's the actual benefit of having that mention? > > > > I can see it's appeal on the webpage, it tells people we're serious, a > > good > > app, etc etc so it's a "selling point" > > > > But on the manual/about box, the person is already using the app, so they > > don't need to be sold on it. > > I can see at least two reasons to include it there: > > - Many users may be using Okular and not know it has been eco-certified. > This would be a way to inform them about certification if they do not go > to the main website. > > - As more KDE aps are certified or the energy consumption of more > programs is made available (via badges?), it may be beneficial to have > an easy and consistent way for users to find the relevant information. Fair enough. I don't see how to make it fit in the About dialog though. The About dialog is not very customizable (on purpose, so that all apps show the same). One option is to add it as "Other" text, but IMHO it's a bit too prominent, before the copyright and okular webpage link https://i.imgur.com/ZkRIoTr.png The other option is have it in the "Thanks" section, which is semantically wrong (e.g. the web link tooltip says "Visit the contributors page") https://i.imgur.com/VbkajK2.png Maybe we should just go for the manual? Cheers, Albert > Cheers, > Joseph
Re: Blue Angel info | include in manual or "About" info-box?
Hi! On 12/2/22 00:05, Albert Astals Cid wrote: I'm not against it, but what's the actual benefit of having that mention? I can see it's appeal on the webpage, it tells people we're serious, a good app, etc etc so it's a "selling point" But on the manual/about box, the person is already using the app, so they don't need to be sold on it. I can see at least two reasons to include it there: - Many users may be using Okular and not know it has been eco-certified. This would be a way to inform them about certification if they do not go to the main website. - As more KDE aps are certified or the energy consumption of more programs is made available (via badges?), it may be beneficial to have an easy and consistent way for users to find the relevant information. Cheers, Joseph -- Joseph P. De Veaugh-Geiss BE4FOSS Project and Community Manager (KDE Eco) OpenPGP: 8FC5 4178 DC44 AD55 08E7 DF57 453E 5746 59A6 C06F
Re: Help Navigating Source Code
El dijous, 1 de desembre de 2022, a les 18:35:49 (CET), Hank Greenburg va escriure: > Hello, > I am looking at contributing to Okular but am having a hard time navigating > the source code. I was wondering if anyone could point me in the direction > of the code for the highlighters, and popup notes? What do you mean "the code for the highlighters, and popup notes"? The UI dialogs? the toolbar? how UI to add them? How they are painted on page? > Also, is there a Matrix chat room for Okular https://matrix.to/#/#okular:kde.org > or is the mailing list the only place to ask this question or any other questions one might have? Though it's possible the mailing list will give you more answers (please subscribe) Cheers, Albert > > Thank you for your time!
Re: Blue Angel info | include in manual or "About" info-box?
El dimarts, 29 de novembre de 2022, a les 16:23:28 (CET), Joseph P. De Veaugh- Geiss va escriure: > Hello, > > I was talking with Cornelius and we thought it might be worth including > information about Okular receiving the Blue Angel in Okular's manual or > the "About" info-box in the application itself. (I looked but didn't > find one, though.) > > Would this be something Okular developers would be interested in? I'm not against it, but what's the actual benefit of having that mention? I can see it's appeal on the webpage, it tells people we're serious, a good app, etc etc so it's a "selling point" But on the manual/about box, the person is already using the app, so they don't need to be sold on it. Cheers, Albert > > I have prepared two texts that may be used for this; see below. > > If you agree this is a good idea, please let me know if I can help in > any way. > > Cheers, > Joseph > > == short text == > > In February 2022, Okular was awarded the Blue Angel environmental label > award by the German government for sustainable software design. > > == long text == > > In February 2022, Okular was awarded the Blue Angel environmental label > award by the German government for sustainable software design. To > obtain the ecolabel, Okular demonstrated it meets a list of requirements > considered critical for the environment over the product's life cycle. > These included transparency in energy and resource consumption when > using Okular and the ability to run the application on hardware at least > five years old, as well as compliance with a list of user autonomy > requirements which reduce the environmental impact of software.
Re: Blue Angel info | include in manual or "About" info-box?
Hi, On 11/29/22 17:53, Ingo Klöcker wrote: I like this idea. "About Okular" is in the Help menu and the manual can also be opened from the Help menu. Excellent! Alternatively to adding some text to the About dialog, we could (could we?) add the Blue Angel certification logo and link it to some page giving details (e.g. the manual). With respect to the guidelines of the Blue Angel, adding the following logo is permitted: https://okular.kde.org/images/rees-en.svg There is also this site with information to link to: https://www.blauer-engel.de/en/products/kde-okular Cheers, Joseph -- Joseph P. De Veaugh-Geiss BE4FOSS Project and Community Manager (KDE Eco) OpenPGP: 8FC5 4178 DC44 AD55 08E7 DF57 453E 5746 59A6 C06F --- KDE Eco: Building Energy-Efficient Free Software! Website: https://eco.kde.org Mastodon: @be4foss@floss.social Mailing list: https://mail.kde.org/cgi-bin/mailman/listinfo/energy-efficiency Matrix: https://webchat.kde.org/#/room/#energy-efficiency:kde.org Forum: https://forum.kde.org/viewforum.php?f=334
Re: Blue Angel info | include in manual or "About" info-box?
On Dienstag, 29. November 2022 16:23:28 CET Joseph P. De Veaugh-Geiss wrote: > I was talking with Cornelius and we thought it might be worth including > information about Okular receiving the Blue Angel in Okular's manual or > the "About" info-box in the application itself. (I looked but didn't > find one, though.) I like this idea. "About Okular" is in the Help menu and the manual can also be opened from the Help menu. Alternatively to adding some text to the About dialog, we could (could we?) add the Blue Angel certification logo and link it to some page giving details (e.g. the manual). Regards, Ingo signature.asc Description: This is a digitally signed message part.
[okular] [Bug 402397] Okular crashes while trying to re-open already deleted document at startup
https://bugs.kde.org/show_bug.cgi?id=402397 Bug Janitor Service changed: What|Removed |Added Resolution|WAITINGFORINFO |WORKSFORME Status|NEEDSINFO |RESOLVED --- Comment #4 from Bug Janitor Service --- This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 402397] Okular crashes while trying to re-open already deleted document at startup
https://bugs.kde.org/show_bug.cgi?id=402397 --- Comment #3 from Bug Janitor Service --- Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! -- You are receiving this mail because: You are the assignee for the bug.
Re: [okular] [Bug 458723] PDF document isn't shown - "Please wait ..." message is shown instead
On Mittwoch, 19. Oktober 2022 23:43:47 CEST Albert Astals Cid wrote: > --- Comment #10 from Albert Astals Cid --- > (In reply to johnathan from comment #9) > > > so now firefox can edit xfa forms, allow users to type in a name or tick a > > checkbox but okular cannot even display the file? yeah Toxic bug reports like this one made me stop reading bug reports for kmail to protect my mental health. > Firefox has a like 700 employees, Okular has 0. I don't see why it is > surprising to you. Also XFA is basically a webpage so adding support for it > in Firefox is defenitely easier than in Okular. > > But yes please be an asshole to us developers, that will for sure make us > work for free for ungrateful people like you You could have worded it a bit more politely. Or, even better, you could have ignored it. I know from own experience that ignoring such reports is hard, but I think it's the best option for everyone. Simply delete such toxic bug report emails and try to forget about them. You have no obligation to justify the decisions and actions of the Okular team (or any other Free Software team) to anybody. Take care, Albert and all other KDE contributors! ❤️ Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: [okular] [Bug 459333] Errors with media files
El dimecres, 12 d’octubre de 2022, a les 16:15:37 (CEST), Ingo Klöcker va escriure: > On Montag, 19. September 2022 19:23:44 CEST Ingo Klöcker wrote: > > The Craft recipe for Okular includes phonon, but no backend. KStars > > includes phonon-vlc (to be able to play .ogg notification files). After > > copying the simpleplayer demo of phonon to the bin folder of KStars I > > could play the sound of a video with simpleplayer, but the video display > > stayed black. Maybe the video codec is missing. > > > > So, the first thing to do would be to add phonon-vlc as dependency of > > okular in craft. > > I have now added phonon-vlc as dependency of okular in the craft blueprint. > > Do you have some test PDFs with embedded multimedia files that I could test > the next Windows build of okular with? I'd say ask the reporter in https://bugs.kde.org/show_bug.cgi?id=459333 If you make the ones i have but not theirs it's not great for them :D Cheers, Albert > > Regards, > Ingo
Re: [okular] [Bug 459333] Errors with media files
On Montag, 19. September 2022 19:23:44 CEST Ingo Klöcker wrote: > The Craft recipe for Okular includes phonon, but no backend. KStars includes > phonon-vlc (to be able to play .ogg notification files). After copying the > simpleplayer demo of phonon to the bin folder of KStars I could play the > sound of a video with simpleplayer, but the video display stayed black. > Maybe the video codec is missing. > > So, the first thing to do would be to add phonon-vlc as dependency of okular > in craft. I have now added phonon-vlc as dependency of okular in the craft blueprint. Do you have some test PDFs with embedded multimedia files that I could test the next Windows build of okular with? Regards, Ingo signature.asc Description: This is a digitally signed message part.
[okular] [Bug 402397] Okular crashes while trying to re-open already deleted document at startup
https://bugs.kde.org/show_bug.cgi?id=402397 Justin Zobel changed: What|Removed |Added Resolution|--- |WAITINGFORINFO Status|REPORTED|NEEDSINFO --- Comment #2 from Justin Zobel --- Thank you for reporting this crash in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the crash with a recent software version? If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you! -- You are receiving this mail because: You are the assignee for the bug.
Re: [okular] [Bug 459333] Errors with media files
On Sonntag, 18. September 2022 19:19:00 CEST you wrote: > https://bugs.kde.org/show_bug.cgi?id=459333 > > Albert Astals Cid changed: > >What|Removed |Added > > CC||aa...@kde.org, >||kloec...@kde.org > > --- Comment #1 from Albert Astals Cid --- > Ingo would you please try to figure out if Phonon has support for Windows > nowadays? The Craft recipe for Okular includes phonon, but no backend. KStars includes phonon-vlc (to be able to play .ogg notification files). After copying the simpleplayer demo of phonon to the bin folder of KStars I could play the sound of a video with simpleplayer, but the video display stayed black. Maybe the video codec is missing. So, the first thing to do would be to add phonon-vlc as dependency of okular in craft. Or some other backend. There seems to be an outdated phonon-ds9 (for DirectShow), but it does already fail at cmake. There doesn't seem to be a Craft recipe for gstreamer and therefore also none for phonon-gstreamer. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: [okular] [Bug 458516] Spaces in content filenames causes a second copy of the book's content to be shown; TOC points to the second copy.
On 2022-09-13 15:57, Albert Astals Cid wrote: https://bugs.kde.org/show_bug.cgi?id=458516 --- Comment #3 from Albert Astals Cid --- I don't see any problem with the attached file. What is wrong with it? The file itself is OK. The problem is in Okular's displaying of the file. I've added a screenshot of Okular illustrating the problem to the bug report [ https://bugsfiles.kde.org/attachment.cgi?id=152038 ]. Note that the TOC shows chapters 1-3 pointing to pages 4-6. This is the second copy of the content. The first copy of chapters 1-3 is on pages 1-3. Page through the document and you'll see it displayed as: page 1 Chapter 1 page 2 Chapter 2 page 3 Chapter 3 page 4 Chapter 1 (pointed to by TOC) page 5 Chapter 2 (pointed to by TOC) page 6 Chapter 3 (pointed to by TOC) page 7 (blank) Yet, the epub contains only (chapter) files: te st_split_000.html te st_split_001.html te st_split_002.html Rename the epub files to "test_split_000.html", "test_split_001.html", and "test_split_002.html", and edit "content.opf" and "toc.ncx" to contain the new names and Okular stops displaying the first copy of the chapters. Pages in the TOC are corrected as well.
Re: Hi, I'm the App Stores Support Engineer guy
El dimecres, 7 de setembre de 2022, a les 11:12:46 (CEST), Ingo Klöcker va escriure: > Hi Okular people, Hello :) > > as you may have read on the community mailing list [1], I'm taking on the > role of App Stores Support Engineer for KDE. > > Aleix Pol wrote: > "Ingo will be working with the different teams in KDE towards our > infrastructure getting prepared to have their software delivered to > the platforms they are targetting. With this, we hope to improve the > reach of our products to end users and hopefully enable them also to > make a living with their KDE products." > > You do already publish Okular in the Windows Store and it has got a few nice > reviews. That's great! > > Here are a few questions I'm interested in: > > a) Where can I find more information about your building and publishing > process? Who should I talk to in your team? For Windows It's build by binary-factory via Craft. The publishing process is the same as the rest of KDE Windows Store app, done via the webui. After putting it there you also but the corresponding exe in https://download.kde.org/stable/release-service/x.y.x/windows/ i.e. https://download.kde.org/stable/release-service/22.08.0/windows/ for posterity. Nico Fella and me have been the ones doing the updates lately. For Android i don't really remember what i did last time, but as far as i remember same-ish, get the build from the binary factory, upload it to the android web ui. Of course some testing applies before uploading ;) > b) Are there things you wish the KDE infrastructure would better support > with regard to building for different platforms and publishing in different > app stores? > > c) Are there things in the KDE Frameworks that should be improved to ease > building for different platforms, e.g. do you patch some KDE Frameworks when > you create builds for Windows or macOS? There's no patches in Craft for KF5 as far as i know. One of the Craft blueprints shortcomings is that it does not use the KDE Qt5 Patch collection > d) Do you want to target more platforms and/or app stores? If yes, which and > in which order? Getting this fixed wouldn't hurt i guess https://binary-factory.kde.org/job/Okular_Nightly_macos/ My guess is that Windows should be one of the main focuses, there must be a sizeable chunk of users out there because when we break something (we broke saving in 22.08.0) we get bug reports in bugs.kde.org which is somewhat alien for a regular windows user i'd say :D > > e) Are there tasks/issues on some task board or issue tracker that I should > look at? I don't think there's any particular task other than the bugs in https://bugs.kde.org/ Main thing i can think of being broken on Windows that would be nice to fix is that tabs don't work because one needs dbus for that which we don't ship/have on Windows. I think kate fixed it by using some other framework instead of dbus. > > f) Is this mailing list the right place to talk about this? Sure :) Cheers, Albert > > Regards, > Ingo > > [1] https://mail.kde.org/pipermail/kde-community/2022q3/007274.html
Re: user interface for attach & detach
Am 04.05.22 um 00:48 schrieb Albert Astals Cid: El dissabte, 30 d’abril de 2022, a les 21:28:09 (CEST), Andreas Naumann va escriure: I am working on the detach and re-attach of a tab in okular. The current implementation in MR 616 (https://invent.kde.org/graphics/okular/-/merge_requests/616) allows to detach a tab into a new okular instance. If tabs are enabled, an existing tab can be moved to another instance. However, if exactly one file is open, then we do not see the tab bar, but only one window. That raises the question, how can a user move that instance/file to another instance? Until now I have the following workflows / user interfaces in mind: (1) Drag the window (at the title) with the single file above another instance: From my perspective, this feels most intuitive. (2) Drag the "page" (click with the mouse somewhere next to the text) and move into another window: This feels also intuitive, but is in conflict with the page movement of a zoomed page. (3) Insert some button/icon in the toolbar: How should that button look like and intuitively like "attach some where else". (4) Use a shortcut, to show other okular instances in a dialog: That feels less intuitive. In particular, it is inconsistent with the detaching from a multi-tab. I implemented the interface (1), but have some trouble with Qt. The basic idea was to overload the member function "Shell::moveEvent", check if the main window was moved on top of another okular window and if so, than open the file in the other instance and close the single-file-window. This approach has one big drawback: the function moveEvent is also called, when the new window starts. Thus, if one detaches, or creates a new okular instance, which (by possibility or accident) starts above another window, it will be closed and attached to that. Finally I have two questions: 1. Which interface/workflow would you prefer? Alternative suggestion: * Add a sub-option to "Always show tabs" [even if there's only one document open] in the configuration. It's what konsole and firefox do. And then people that like dragging tabs around can enable that and be happy dragging the tags. What do you think? That is the way, I implemented the feature now. If the option "Keep tab" is enabled, we keep the tab box even if there is only one open file. The user interface works two fold now: 1. simple drag and drop: If the mouse leaves the window, a "drag" action is started. Thus a user can simply drop the file in any other application (which supports drag'n drop). This is like a "copy operation". Even if you drop the file onto another okular instance, we keep it open at the source. 2. drag while pressing "shift". That detaches the file from the current okular instance and removes. This is like a "move operation". I chose the shift key, because it is similar to the behavior of dolphin. There "shift & drag" means move the file to the destination. Regards, Andreas Cheers, Albert 2. Do you have any other suggestion for the implementation of (1)? All best, Andreas
