[okular] [Bug 478141] Height of the window decrease after changing tabs
https://bugs.kde.org/show_bug.cgi?id=478141 --- Comment #16 from Henry Zhang --- (In reply to Albert Astals Cid from comment #15) > FWIW i still can not reproduce such an issue with a very similar setup, > except i don't have hidpi, are you running some hidpi zoom that is not an > integer number? Yes. I could reproduce on 150% scaling but not 100%. -- You are receiving this mail because: You are the assignee for the bug.
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
[okular] [Bug 480260] Okular has problems displaying check boxes in lists and tables
https://bugs.kde.org/show_bug.cgi?id=480260 Albert Astals Cid changed: What|Removed |Added Resolution|WAITINGFORINFO |UPSTREAM Status|NEEDSINFO |RESOLVED --- Comment #3 from Albert Astals Cid --- We are using discount for markdown rendering, you can see that the same rendering happens when doing in a terminal mkd2html list.md and opening the resulting list.html in a web browser. Please file a bug in https://github.com/Orc/discount once it is fixed there (and your distribution updates the discount version) it will be automatically fixed in okular. -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 478141] Height of the window decrease after changing tabs
https://bugs.kde.org/show_bug.cgi?id=478141 --- Comment #15 from Albert Astals Cid --- FWIW i still can not reproduce such an issue with a very similar setup, except i don't have hidpi, are you running some hidpi zoom that is not an integer number? -- You are receiving this mail because: You are the assignee for the bug.
[okular] [Bug 480501] "facing pages option" without a gap in a middle and from screen's top to bottom.
https://bugs.kde.org/show_bug.cgi?id=480501 Albert Astals Cid changed: What|Removed |Added Severity|normal |wishlist -- You are receiving this mail because: You are the assignee for the bug.
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 > > > > >