Additional mentors for GSOC project
Hi all, this was posted to a list I don't subscribe to, but Ralf is still needing some co-mentors, so am copy/pasting: Additional mentor for GSOC project searched > Ralf Habacker ralf.habacker at freenet.de > Wed Apr 8 11:40:42 BST 2020 > Hi, > for the appended GSOC project KDE organization wants to have additional > mentors. The task is to be a backup for the main mentor. > From https://google.github.io/gsocguides/mentor/: > Mentor: Mentors are people from the community who volunteer to work with > a student. Mentors provide guidance such as pointers to useful > documentation, code reviews, etc. In addition to providing students with > feedback and pointers, a mentor acts as an ambassador to help student > contributors integrate into their project’s community. Some > organizations choose to assign more than one mentor to each of their > students. Many members of the community provide guidance to their > project’s GSoC students without mentoring in an “official” capacity, > much as they would answer anyone’s questions on the project’s mailing > list or IRC channel. This isn't quite correct. If you want to help out, please subscribe to KDE-Soc-Mentor ML [1] Then write to kde-soc-managem...@kde.org and ask to be invited to the GSoC webapp. Accept the invitation to register as Ralf correctly says. If anyone has interest, please register at the Google GSOC site > (https://summerofcode.withgoogle.com/) as mentor and click on "Want to > mentor" at > > https://summerofcode.withgoogle.com/dashboard/organization/4610988642402304/proposal/6153080292245504/ > Regards > Ralf URL: < > http://mail.kde.org/pipermail/kde-finance-apps/attachments/20200408/001847f9/attachment-0001.pdf > > Thank you! GSoC would like us to have *two* backup mentors per student this year, given the tenuous health situation in the world right now. Valorie 1. https://mail.kde.org/mailman/listinfo/kde-soc-mentor -- http://about.me/valoriez - pronouns: she/her
Re: GSoC Project
Hi Luis, On Wed, Mar 18, 2020 at 6:51 AM luis salomao wrote: > Hi everyone, > My name is Luis Salomão, and i would like to apply to a project on ROCS, > so i can participate com GSoC. > I am currently talking with Caio Tonetti on how to apply and reguarding > the project as well. > Great! That is most important. Communication with your team along with the larger KDE developer group is absolutely crucial to your success. By subscribing to this list, you have cleared the first hurdle. :-) So welcome. > I would like to know how to introduce myself reguarding my programming > skills, so if any of you could answer this email. it would be of great help. > Thanks; > > LHFS > Discussing your skills with your possible mentor and team is great! This list is more about questions you might have as you decide how to tackle issues facing you in your proposal and as you begin coding. As you read the discussion here, you'll also notice developers wrestling with larger issues affecting all, such as refining the infrastructure, porting and deprecations, changes in Qt and other common tools, etc. My only advice: upload your proposal as soon as possible, and remember to turn on "suggesting" and then respond to comments and suggestions. Remember to link to commits you have made in your proposal. If they have not landed yet, link to the Phab or Invent discussion of your patches. All the best, Valorie -- http://about.me/valoriez - pronouns: she/her
GSoC Project
Hi everyone, My name is Luis Salomão, and i would like to apply to a project on ROCS, so i can participate com GSoC. I am currently talking with Caio Tonetti on how to apply and reguarding the project as well. I would like to know how to introduce myself reguarding my programming skills, so if any of you could answer this email. it would be of great help. Thanks; LHFS
Re: GSoC Project Proposal: Make High-DPI awesome
On Thu, Mar 23, 2017 at 5:16 AM, Lukas Hetzenecker wrote: > Hello, > > On 2017-03-22 08:03, Thiago Macieira wrote: > >> I have only one application left with problems and that's krdc: when I >> tell it >> to create a display (for example) 640x480, it does that in >> device-independent >> pixels, so it actually creates an area 1280x960, which is 4x bigger than >> the >> display it is going to get from the network and embed from vncviewer. >> >> All other applications are working fine now that I submitted this Qt >> patch: >> https://codereview.qt-project.org/188493 >> > > I've now applied this patch on top of the current Qt 5.8 branch and > unfortunately can > not confirm that all applications are working. > > Note that fractional scaling is not supported by Qt. You can do 1x or 2x, >> but >> nothing in-between. >> > > I know the Qt documentation mentions this, but when the "Scale Display" > slider > is set to e.g. 1.6 KDE sets the environment variable > QT_SCREEN_SCALE_FACTORS > to "DVI-I-0=1.6;DVI-I-1=1.6;HDMI-0=1.6;DP-0=1.6;DVI-D-0=1.6;DP-1=1.6;" > There are also noticable differences between 1.6 and 1.8, so the > fractional has > an actual effect. > > However I understand that this is an unsupported configuration. > Therefore I set it back to 2.0 and even than I could reproduce the > following bugs: > > * kdegraphics/gwenview > - https://bugs.kde.org/show_bug.cgi?id=373178 > - screenshot comparision: https://drive.google.com/file/ > d/0BwXqDXwyptm8LU9XcjdUOGZ1LWM/view > - (left is scale 1.0, right is scale 2.0) > > Pictures and thumbnails are blurred. > In lib/imagescaler.cpp ImageScaler::scaleRect are scaled to e.g. 500x500px, > because the devicePixelRatio is not taken into account when scaling the > image. As far as I've seen it, the right way would be to scale to > width() * devicePixelRatio, height() * devicePixelRatio, which results in > an > 1000x1000px image. After calling QPixmap->setDevicePixelRatio the QPainter > draw this correctly. > > * kdegraphics/okular > - https://bugs.kde.org/show_bug.cgi?id=362856 > - screenshot comparision: https://drive.google.com/file/ > d/0BwXqDXwyptm8cXBXZm1YSDBnNFk/view > - (left is scale 1.0, right is scale 2.0) > > Similar rendering problems happen in Okular. The document is blurry and > barely readable. > > * systemsettings > - https://bugs.kde.org/show_bug.cgi?id=366451 > - e.g. https://drive.google.com/open?id=0BwXqDXwyptm8Z3U3OW1nVzRIU2s > > Blurry fonts and other artefacts in systemsettings, although I suspect > the cause for this issue might be in another KDE framework/widget library. > Setting the scale factor to 2.0 improves the situation, but some issues > still persist. > > * plasmashell > - https://bugs.kde.org/show_bug.cgi?id=366451 > > There are still several issues in plasma, I can confirm the blurry > rendering > of the shutdown dialog. Again improvements with scale factor 2.0. > > > I can further reproduce the following bugs: > * kdepim/korganizer > - https://bugs.kde.org/show_bug.cgi?id=353240 > > Not only are the day labels cut off, but also icons appear blurry. > > * konsole > - https://bugs.kde.org/show_bug.cgi?id=373232 > > * systemsettings / Scale Display UI > > Even the scale display UI itself has rendering issues. > > This list should just highlight a few examples, there are still a few > other places where things are broken. > > So to summarize, applications still don't behave correctly on High-DPI > screens. > > It isn't clear if non-integer scale factors should be supported (at least > the > settings UI does not mention that this could cause problems). > > E.g. Java FX (starting from Java 9) Applications check the GDK_SCALE >>> environment variable, which by default isn't set. Also some applications >>> have in my experience problems if QT_SCREEN_SCALE_FACTORS is set (e.g. >>> VLC & JetBrains Toolbox) >>> >> >> VirtualBox has the same problem I described for krdc above. I didn't see a >> problem with VLC, but I suspect it would be the exact same issue. >> > > I can confirm problems with VLC and VirtualBox too. > > I especially like the following parts of your proposal: >>> * Polishing user interface for HiDPI settings. Extend it, so it allows >>> different scale factors for multiple screens. [my external 27" 4K >>> Monitor could need a smaller scaling factor than my 15" 4K Laptop Screen] >>> >> >> Not supported by Qt. Like I said, you can have 1 or 2, but not fractional. >> There's a patch for Qt by Morten that enables this, but you'll see plenty >> of >> problems because of rounding errors. So, don't. >> >> Supporting different scaling depending on monitors is possible with X, >> but not >> recommended. You're much better off having a single scaling factor for all >> monitors. Or switch to Wayland. >> > > We need to set the xrfb font dpi to make other toolkits vaguely usable on high DPI on X. That's global and there's no way round that. So it's sort of possible, but it breaks more stuff than it fixes. Is it already supported on
Re: GSoC Project Proposal: Make High-DPI awesome
On quinta-feira, 23 de março de 2017 09:26:26 PDT Jean-Baptiste Kempf wrote: > No, since I don't know who Morten is Morten Sørvig, the engineer who made the big changest o HiDPI support in 5.6. > (Also, to have proper HiDPi on Windows, you need to patch every Qt build > since 5.6 ) -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Re: GSoC Project Proposal: Make High-DPI awesome
Hello, On Thu, 23 Mar 2017, at 17:07, Thiago Macieira wrote: > > On Wed, 22 Mar 2017, at 08:03, Thiago Macieira wrote: > > > problem with VLC, but I suspect it would be the exact same issue. > > > > The issue with VLC is that you want to have native size (pixel-by-pixel) > > for the video player but scaled UI for the rest. > > And Qt is not making that simple for us... > > > > It's totally broken now, but it should be fixed in the current vlc.git > > (3.0). > > It's the same issue as VirtualBox and krdc then. Have you checked with > Morten > if we Qt can supply some API to make that clearer? No, since I don't know who Morten is :) (Also, to have proper HiDPi on Windows, you need to patch every Qt build since 5.6 :) ) -- Jean-Baptiste Kempf - President +33 672 704 734
Re: GSoC Project Proposal: Make High-DPI awesome
On quarta-feira, 22 de março de 2017 00:58:20 PDT Jean-Baptiste Kempf wrote: > Hello, > > On Wed, 22 Mar 2017, at 08:03, Thiago Macieira wrote: > > problem with VLC, but I suspect it would be the exact same issue. > > The issue with VLC is that you want to have native size (pixel-by-pixel) > for the video player but scaled UI for the rest. > And Qt is not making that simple for us... > > It's totally broken now, but it should be fixed in the current vlc.git > (3.0). It's the same issue as VirtualBox and krdc then. Have you checked with Morten if we Qt can supply some API to make that clearer? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Re: GSoC Project Proposal: Make High-DPI awesome
Hello, On 2017-03-22 08:03, Thiago Macieira wrote: I have only one application left with problems and that's krdc: when I tell it to create a display (for example) 640x480, it does that in device-independent pixels, so it actually creates an area 1280x960, which is 4x bigger than the display it is going to get from the network and embed from vncviewer. All other applications are working fine now that I submitted this Qt patch: https://codereview.qt-project.org/188493 I've now applied this patch on top of the current Qt 5.8 branch and unfortunately can not confirm that all applications are working. Note that fractional scaling is not supported by Qt. You can do 1x or 2x, but nothing in-between. I know the Qt documentation mentions this, but when the "Scale Display" slider is set to e.g. 1.6 KDE sets the environment variable QT_SCREEN_SCALE_FACTORS to "DVI-I-0=1.6;DVI-I-1=1.6;HDMI-0=1.6;DP-0=1.6;DVI-D-0=1.6;DP-1=1.6;" There are also noticable differences between 1.6 and 1.8, so the fractional has an actual effect. However I understand that this is an unsupported configuration. Therefore I set it back to 2.0 and even than I could reproduce the following bugs: * kdegraphics/gwenview - https://bugs.kde.org/show_bug.cgi?id=373178 - screenshot comparision: https://drive.google.com/file/d/0BwXqDXwyptm8LU9XcjdUOGZ1LWM/view - (left is scale 1.0, right is scale 2.0) Pictures and thumbnails are blurred. In lib/imagescaler.cpp ImageScaler::scaleRect are scaled to e.g. 500x500px, because the devicePixelRatio is not taken into account when scaling the image. As far as I've seen it, the right way would be to scale to width() * devicePixelRatio, height() * devicePixelRatio, which results in an 1000x1000px image. After calling QPixmap->setDevicePixelRatio the QPainter draw this correctly. * kdegraphics/okular - https://bugs.kde.org/show_bug.cgi?id=362856 - screenshot comparision: https://drive.google.com/file/d/0BwXqDXwyptm8cXBXZm1YSDBnNFk/view - (left is scale 1.0, right is scale 2.0) Similar rendering problems happen in Okular. The document is blurry and barely readable. * systemsettings - https://bugs.kde.org/show_bug.cgi?id=366451 - e.g. https://drive.google.com/open?id=0BwXqDXwyptm8Z3U3OW1nVzRIU2s Blurry fonts and other artefacts in systemsettings, although I suspect the cause for this issue might be in another KDE framework/widget library. Setting the scale factor to 2.0 improves the situation, but some issues still persist. * plasmashell - https://bugs.kde.org/show_bug.cgi?id=366451 There are still several issues in plasma, I can confirm the blurry rendering of the shutdown dialog. Again improvements with scale factor 2.0. I can further reproduce the following bugs: * kdepim/korganizer - https://bugs.kde.org/show_bug.cgi?id=353240 Not only are the day labels cut off, but also icons appear blurry. * konsole - https://bugs.kde.org/show_bug.cgi?id=373232 * systemsettings / Scale Display UI Even the scale display UI itself has rendering issues. This list should just highlight a few examples, there are still a few other places where things are broken. So to summarize, applications still don't behave correctly on High-DPI screens. It isn't clear if non-integer scale factors should be supported (at least the settings UI does not mention that this could cause problems). E.g. Java FX (starting from Java 9) Applications check the GDK_SCALE environment variable, which by default isn't set. Also some applications have in my experience problems if QT_SCREEN_SCALE_FACTORS is set (e.g. VLC & JetBrains Toolbox) VirtualBox has the same problem I described for krdc above. I didn't see a problem with VLC, but I suspect it would be the exact same issue. I can confirm problems with VLC and VirtualBox too. I especially like the following parts of your proposal: * Polishing user interface for HiDPI settings. Extend it, so it allows different scale factors for multiple screens. [my external 27" 4K Monitor could need a smaller scaling factor than my 15" 4K Laptop Screen] Not supported by Qt. Like I said, you can have 1 or 2, but not fractional. There's a patch for Qt by Morten that enables this, but you'll see plenty of problems because of rounding errors. So, don't. Supporting different scaling depending on monitors is possible with X, but not recommended. You're much better off having a single scaling factor for all monitors. Or switch to Wayland. Is it already supported on Wayland? If yes, we could enable this configuration only for Wayland users, to provide an incentive to finally ditch X. :) * If possible, try to also force other applications to use configured settings when starting a KDE workspace (Firefox? Google Chrome? GTK? Java?) Set GDK_SCALE and CLUTTER_SCALE, that's all. I don't know which of those controls Firefox and Chrome, but they are properly scaled up in my system. I run 3200x1800 in my laptop and 3840x2160 in the externa
Re: GSoC Project Proposal: Make High-DPI awesome
Hello, first of all - thanks to all for reading my proposal and your suggestions. I will apply this patch and test if it improves the situation. But as far as I see now, this only changes the positioning of windows. There seem to be other rendering issues in a variety of applications, mostly in kdegraphics related ones: - gwenview - https://bugs.kde.org/show_bug.cgi?id=373178 - Blurry scaling on HiDPI - okular - https://bugs.kde.org/show_bug.cgi?id=362856 - Wrong render resolution, possibly caused by Plasma 5 "Scale Display" - krita - https://bugs.kde.org/show_bug.cgi?id=360541 - HiDPI option in Qt also scales the canvas widget But also similar rendering issues exist in konsole, systemsettings and plasma (e.g. on the logout/shutdown and startup screen). Some of these seem to be caused by QPixmaps with no devicePixelRatio set, resulting in blurred or wrongly scaled images. I don't think there is a Qt- or KDE-wide approach that could simply fix this. Therefore my proposal to look into every problematic application and fix the issues there. I have a partly working patch for gwenview which does this (changes were the mentioned devicePixelRatios and taking those values into account in the paint method). -- Lukas On 2017-03-22 08:03, Thiago Macieira wrote: Em terça-feira, 21 de março de 2017, às 03:51:16 PDT, Stefan Derkits escreveu: On 2017-03-21 00:34, Lukas Hetzenecker wrote: > I’m looking also forward to any feedback you have about this proposal. I would really love to see the results of such a project. As I wrote you in a personal mail, for me HiDpi works already mostly well,but some Applications still have problems with it. I have only one application left with problems and that's krdc: when I tell it to create a display (for example) 640x480, it does that in device-independent pixels, so it actually creates an area 1280x960, which is 4x bigger than the display it is going to get from the network and embed from vncviewer. All other applications are working fine now that I submitted this Qt patch: https://codereview.qt-project.org/188493 Note that fractional scaling is not supported by Qt. You can do 1x or 2x, but nothing in-between. E.g. Java FX (starting from Java 9) Applications check the GDK_SCALE environment variable, which by default isn't set. Also some applications have in my experience problems if QT_SCREEN_SCALE_FACTORS is set (e.g. VLC & JetBrains Toolbox) VirtualBox has the same problem I described for krdc above. I didn't see a problem with VLC, but I suspect it would be the exact same issue. I especially like the following parts of your proposal: * Polishing user interface for HiDPI settings. Extend it, so it allows different scale factors for multiple screens. [my external 27" 4K Monitor could need a smaller scaling factor than my 15" 4K Laptop Screen] Not supported by Qt. Like I said, you can have 1 or 2, but not fractional. There's a patch for Qt by Morten that enables this, but you'll see plenty of problems because of rounding errors. So, don't. Supporting different scaling depending on monitors is possible with X, but not recommended. You're much better off having a single scaling factor for all monitors. Or switch to Wayland. * If possible, try to also force other applications to use configured settings when starting a KDE workspace (Firefox? Google Chrome? GTK? Java?) Set GDK_SCALE and CLUTTER_SCALE, that's all. I don't know which of those controls Firefox and Chrome, but they are properly scaled up in my system. I run 3200x1800 in my laptop and 3840x2160 in the external monitor.
Re: GSoC Project Proposal: Make High-DPI awesome
On Wed, 22 Mar 2017 11:19:17 +0100, Stefan Derkits wrote: On 2017-03-22 08:03, Thiago Macieira wrote: Note that fractional scaling is not supported by Qt. You can do 1x or 2x, but nothing in-between. KDE System Settings allow fractional scaling. So probably should be fixed in System Settings (except there are other Toolkits that support fractional scaling). Stefan Qt does support fractional scaling (and quite well, in my opinion). Try using QT_SCALE_FACTOR=1.35 for example. Meanwhile KDE System settings allows you to set some scaling that seems fractional, however it's not. In the range of 1.0-1.4 you're just making your fonts bigger and at 1.5 widgets are suddenly scaled 2x.
Re: GSoC Project Proposal: Make High-DPI awesome
Hi, On 2017-03-22 08:03, Thiago Macieira wrote: > I have only one application left with problems and that's krdc: when I tell > it > to create a display (for example) 640x480, it does that in device-independent > pixels, so it actually creates an area 1280x960, which is 4x bigger than the > display it is going to get from the network and embed from vncviewer. > > All other applications are working fine now that I submitted this Qt patch: > https://codereview.qt-project.org/188493 that sounds great, but that would mean for the proposal that Lukas probably can't find enough applications to fix and should look for another idea for his GSoC proposal ... or? > Note that fractional scaling is not supported by Qt. You can do 1x or 2x, but > nothing in-between. KDE System Settings allow fractional scaling. So probably should be fixed in System Settings (except there are other Toolkits that support fractional scaling). Stefan signature.asc Description: OpenPGP digital signature
Re: GSoC Project Proposal: Make High-DPI awesome
Hello, On Wed, 22 Mar 2017, at 08:03, Thiago Macieira wrote: > problem with VLC, but I suspect it would be the exact same issue. The issue with VLC is that you want to have native size (pixel-by-pixel) for the video player but scaled UI for the rest. And Qt is not making that simple for us... It's totally broken now, but it should be fixed in the current vlc.git (3.0). Best, -- Jean-Baptiste Kempf - President +33 672 704 734
Re: GSoC Project Proposal: Make High-DPI awesome
Em terça-feira, 21 de março de 2017, às 03:51:16 PDT, Stefan Derkits escreveu: > On 2017-03-21 00:34, Lukas Hetzenecker wrote: > > I’m looking also forward to any feedback you have about this proposal. > > I would really love to see the results of such a project. As I wrote you > in a personal mail, for me HiDpi works already mostly well,but some > Applications still have problems with it. I have only one application left with problems and that's krdc: when I tell it to create a display (for example) 640x480, it does that in device-independent pixels, so it actually creates an area 1280x960, which is 4x bigger than the display it is going to get from the network and embed from vncviewer. All other applications are working fine now that I submitted this Qt patch: https://codereview.qt-project.org/188493 Note that fractional scaling is not supported by Qt. You can do 1x or 2x, but nothing in-between. > E.g. Java FX (starting from Java 9) Applications check the GDK_SCALE > environment variable, which by default isn't set. Also some applications > have in my experience problems if QT_SCREEN_SCALE_FACTORS is set (e.g. > VLC & JetBrains Toolbox) VirtualBox has the same problem I described for krdc above. I didn't see a problem with VLC, but I suspect it would be the exact same issue. > I especially like the following parts of your proposal: > * Polishing user interface for HiDPI settings. Extend it, so it allows > different scale factors for multiple screens. [my external 27" 4K > Monitor could need a smaller scaling factor than my 15" 4K Laptop Screen] Not supported by Qt. Like I said, you can have 1 or 2, but not fractional. There's a patch for Qt by Morten that enables this, but you'll see plenty of problems because of rounding errors. So, don't. Supporting different scaling depending on monitors is possible with X, but not recommended. You're much better off having a single scaling factor for all monitors. Or switch to Wayland. > * If possible, try to also force other applications to use configured > settings when starting a KDE workspace (Firefox? Google Chrome? GTK? > Java?) Set GDK_SCALE and CLUTTER_SCALE, that's all. I don't know which of those controls Firefox and Chrome, but they are properly scaled up in my system. I run 3200x1800 in my laptop and 3840x2160 in the external monitor. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center
Re: GSoC Project Proposal: Make High-DPI awesome
Looks like a very strong proposal. Can you break the timeline down where you have "fix applications" into much more specific apps with timescale. Possibly even breaking down the different bits of apps. It doesn't matter if we deviate from it when GSOC starts, but it'll show that you have a realistic understanding of the problems involved. Other than that, can you try and get some other random patches into KDE fixing things that annoy you, it doesn't have to be anything to do with high DPI, just help us get to know you. David
Re: GSoC Project Proposal: Make High-DPI awesome
Hello, this proposal makes me happy, not only because I have a 4K Screen, but also because Lukas was a Student in a course at University about Software Engineering in C++/Qt of which I was part of the teaching team. And we need more people in Austria involved into KDE :) On 2017-03-21 00:34, Lukas Hetzenecker wrote: > I’m looking also forward to any feedback you have about this proposal. I would really love to see the results of such a project. As I wrote you in a personal mail, for me HiDpi works already mostly well,but some Applications still have problems with it. E.g. Java FX (starting from Java 9) Applications check the GDK_SCALE environment variable, which by default isn't set. Also some applications have in my experience problems if QT_SCREEN_SCALE_FACTORS is set (e.g. VLC & JetBrains Toolbox) I especially like the following parts of your proposal: * Polishing user interface for HiDPI settings. Extend it, so it allows different scale factors for multiple screens. [my external 27" 4K Monitor could need a smaller scaling factor than my 15" 4K Laptop Screen] * If possible, try to also force other applications to use configured settings when starting a KDE workspace (Firefox? Google Chrome? GTK? Java?) Greetings, Stefan signature.asc Description: OpenPGP digital signature
Re: GSoC Project Proposal: Make High-DPI awesome
I'm so sorry that sendgrid changed my plain-text version of the mail, here is the original: Hello fellow developers. I’m a student at the Technical University of Vienna in Austria and would love to participate in the upcoming Google Summer of Code. I have already talked about this proposal on IRC, but now I want to present the full document (continuously updated version at https://docs.google.com/document/d/1-SmazZh7Ut3dKppI-Q02SnezoNOL_tz0uVM_GGEDWEw/edit?usp=sharing): === Project title: Make High-DPI awesome Abstract As seen on Blog Posts on Planet KDE[1] support for High-DPI monitors has come a long way since Plasma 5.0. And thanks to the work by many dedicated people[2] the situation in Plasma is now almost ideal. But unfortunately, this is not the case for all KDE applications. Support for HiDPI seems to be more of a hit-and-miss for some of them, many crucial for day-to-day workflows (like Okular and Gwenview). Competing desktop environments have nowadays a nearly perfect HiDPI support, so I think it is time to face the remaining problems once and for all. Therefore I suggest the following approach: * My Google Summer of Code project will find HiDPI rendering issues in KDE applications and fix them in a coordinated approach. Proposal Timeline -- Before May 30 (Before official coding begin) * I will be active on IRC and the mailing lists and discuss with my mentor the planned steps in detail * Setting up KDE development environment for framework+workspace+apps using kdesrc-build (already done) * Submitting first patch, fixing gwenview (WIP) * Building list of HiDPI rendering problems from following sources: - Looking at bugs.kde.org (examples: #362856 okular, #373232 konsole, #373178 gwenview) - Writing about personal experience (and open bug reports decumeting the problems) - Writing a Blog Post aggregated on Planet KDE about upcoming plan and ask users to provide more examples * Publishing this list on a wiki (e.g. Techbase or the Community Wiki) and prioritizing issues May 30 - June 30 (Phase 1) * Fixing HiDPI rendering bugs in applications. This will not only require collaboration with my mentor, but also with the maintainer(s) of the application. The scope for this should be strictly inside the KDE ecosystem. If there are any bugs upstream - for example in the Qt Framework - I will open bug reports, but not try to fix them. Besides setting environment variables like QT_SCREEN_SCALE_FACTORS, I also have a 4K monitor I can test my patches with. June 30 - July 28 (Phase 2) * Further work on found issues. July 28 - August 29 (Final phase) * Further work on found issues. * Polishing user interface for HiDPI settings. Extend it, so it allows different scale factors for multiple screens. * Set-up sane defaults for new installations regarding HiDPI settings so that new KDE users have a good experience on the first boot * If possible, try to also force other applications to use configured settings when starting a KDE workspace (Firefox? Google Chrome? GTK? Java?) Outcome - After my project is finished, users will have a more polished user experience with HiDPI screens out of the box. Base KDE apps will no longer show any rendering problems when drawn on a 4K screen. About me -- I’m a 24 year old computer science student at the Technical University of Vienna. Besides previous tiny patches to KDE-related software (e.g. [3]) I gained experience with Qt while developing software for smart interactive displays (like the ones you see in museums) written in C++/Qt and QML. Further programming experience of mine is in Python and Java. My study term lasts until end of June, so it will overlap partly with the GSoC. I took fewer courses this semester, so there won’t be any time problems with coding. I also work part-time at an IT operating company which is specialized in Big Data and Cloud Services, but cleared time for the intended 30hrs/week I will spend on working for the project. I have no plan to write a proposal for any other organization. [1] http://www.lorenzobettini.it/2016/07/hidpi-in-kde-plasma/ [2] http://blog.davidedmundson.co.uk/blog/high_dpi_again [3] https://git.reviewboard.kde.org/r/101065/ === I have set up a complete KDE development environment using kdesrc-build and am currently in the process of writing a patch for #373178 - Blurry scaling on HiDPI for gwenview. I know this project covers many different parts of KDE - frameworks, applications and possibly the workspace too. Is there somebody who thinks this is a good idea and is willing to mentor it? I’m looking also forward to any feedback you have about this proposal. If you think that there is not a high chance that this project will get selected, please tell me and I will choose
GSoC Project Proposal: Make High-DPI awesome
Hello fellow developers. I’m a student at the Technical University of Vienna in Austria and would love to participate in the upcoming Google Summer of Code. I have already talked about this proposal on IRC, but now I want to present the full document (continuously updated version at https://u4060579.ct.sendgrid.net/wf/click?upn=O9eTlgqxXzWn1NMw0BaGZmBpi5949V-2F64iX6DVMiDuk-2FmhujSzqkX8U3MqXWcMYzlpe-2FbkHoSMIx4G1WV7inNC8PTWOrs4zQ2rvqyX13sIHugo7QEbzE7QWPmywv1adb-2BT-2Fk7mMbnjmlJWsRdyIYLQ-3D-3D_P1L0NV5fXQ-2Fk2ezJ7xYR3Ac8eQNE5mcZ3ZViRgxqmiWWddouDRu-2BMPLoGNOXAq5q4BZ-2Fz2AVWWe0c0qzLkBDpbkbwuNRuaBMiHUKXVpDR-2F9aQOXISrJW3BEx3DTHqHl5dmlxZnhPRDlvWdk6F42ZjrAWvmn6AjbBvgOIBhkXEpBdX0JQyUp6Ft4mHElPk0BUacbuiZ3As2jOII3DscZsnA-3D-3D === Project title: Make High-DPI awesome Abstract As seen on Blog Posts on Planet KDE[1] support for High-DPI monitors has come a long way since Plasma 5.0. And thanks to the work by many dedicated people[2] the situation in Plasma is now almost ideal. But unfortunately, this is not the case for all KDE applications. Support for HiDPI seems to be more of a hit-and-miss for some of them, many crucial for day-to-day workflows (like Okular and Gwenview). Competing desktop environments have nowadays a nearly perfect HiDPI support, so I think it is time to face the remaining problems once and for all. Therefore I suggest the following approach: * My Google Summer of Code project will find HiDPI rendering issues in KDE applications and fix them in a coordinated approach. Proposal Timeline -- Before May 30 (Before official coding begin) * I will be active on IRC and the mailing lists and discuss with my mentor the planned steps in detail * Setting up KDE development environment for framework+workspace+apps using kdesrc-build (already done) * Submitting first patch, fixing gwenview (WIP) * Building list of HiDPI rendering problems from following sources: - Looking at bugs.kde.org (examples: #362856 okular, #373232 konsole, #373178 gwenview) - Writing about personal experience (and open bug reports decumeting the problems) - Writing a Blog Post aggregated on Planet KDE about upcoming plan and ask users to provide more examples * Publishing this list on a wiki (e.g. Techbase or the Community Wiki) and prioritizing issues May 30 - June 30 (Phase 1) * Fixing HiDPI rendering bugs in applications. This will not only require collaboration with my mentor, but also with the maintainer(s) of the application. The scope for this should be strictly inside the KDE ecosystem. If there are any bugs upstream - for example in the Qt Framework - I will open bug reports, but not try to fix them. Besides setting environment variables like QT_SCREEN_SCALE_FACTORS, I also have a 4K monitor I can test my patches with. June 30 - July 28 (Phase 2) * Further work on found issues. July 28 - August 29 (Final phase) * Further work on found issues. * Polishing user interface for HiDPI settings. Extend it, so it allows different scale factors for multiple screens. * Set-up sane defaults for new installations regarding HiDPI settings so that new KDE users have a good experience on the first boot * If possible, try to also force other applications to use configured settings when starting a KDE workspace (Firefox? Google Chrome? GTK? Java?) Outcome - After my project is finished, users will have a more polished user experience with HiDPI screens out of the box. Base KDE apps will no longer show any rendering problems when drawn on a 4K screen. About me -- I’m a 24 year old computer science student at the Technical University of Vienna. Besides previous tiny patches to KDE-related software (e.g. [3]) I gained experience with Qt while developing software for smart interactive displays (like the ones you see in museums) written in C++/Qt and QML. Further programming experience of mine is in Python and Java. My study term lasts until end of June, so it will overlap partly with the GSoC. I took fewer courses this semester, so there won’t be any time problems with coding. I also work part-time at an IT operating company which is specialized in Big Data and Cloud Services, but cleared time for the intended 30hrs/week I will spend on working for the project. I have no plan to write a proposal for any other organization. [1] https://u4060579.ct.sendgrid.net/wf/click?upn=pWA8muICCr9ChFr-2B9lC2pbyJooR2Au4SWT8iMX7vaPaMWntq9wDdylREcvnP5pdR4Pgr6vOUcGlVdxAz0yVy6F-2B2GV8r83xnmTpDMPM8f5M-3D_P1L0NV5fXQ-2Fk2ezJ7xYR3Ac8eQNE5mcZ3ZViRgxqmiWWddouDRu-2BMPLoGNOXAq5qELO-2BTFil03oKYmdLzdT98E0S1HBYCCaAw4fsIpVj3f81FflWMEH2qnRyxYNWgIW9pCfomp2RdAoutR3e-2F85J-2BtAlATtOzP2AreuuTsF11mKMiqFWe0z2uqdOCJ1eb22BJLh3NNEYcD2wdfupNMwUdA-3D-3D [2] https://u4060579.ct.sendgrid.net/wf/click?upn=Ns3hUQ8zqyROw-2FUif9tAMxZgVAGHP3CdwVOnGNMb0pyBhVHiKA5bdQtixWff7YD8F7mKHHx0K1
Proposal for a GSoC project (KConfig/cloud/kdebase)
Hello KDE devs and GSoC mentors, I know its kind of last moment for GSoC ideas but I have had this one for quite some time in my mind and I would like to give it a shot. Since the deadline is approaching fast I will try to get to my point as quickly as possible so that you don't have to read much. I am sending this to devel and connect mailing lists with the hope of catching the interest of a mentor. If you are a mentor relevant to this area, please respond to my idea, even if you find it unacceptable. I would like to get all kind of feedback before submitting the formal proposal at GSoC. Thanks in advance :) *What problem am I trying to solve* Technology and how it is used has changed dramatically during the last 10 years. There are more people online in the internet, using a miltitude of heterogenous devices. Our wish, btw, is to see KDE everywhere. One of the problems that myself as well as my friends face is dealing with configuring multiple desktop systems we own in a consistent manner. I myself have two laptops and a desktop (in college) with KDE installed. I believe the case is not very different for most of you out there. Often whenever I make a change in one of these desktops, I have to go around on all the other systems to make the same changes myself. Consider a simple example. When I add a new feed to akregator, I need to ensure that I add the same in all my systems. Or take the case of adding a new bookmark to rekonq or konqueror. Consider the case when I changed a keyboard shortcut and having to make the same changes in all other systems. Wouldn't it be a lot simple if all the configuration changes get synchronized automagically over internet? Now consider the case where you plan to reinstall your OS. Or, change the distro from Kubuntu to Arch. Or maybe you just want to use a desktop at your in-laws for making an urgent fix to your project source code. Wouldn't it be a lot nicer if you could just login and synchronize your KDE session to get the same look and feel of your own system. This project aims to provide a seamless and consistent experience for any KDE user across many desktop installations. *Project Description* The project aims at providing a transparent mechanism for storing application configuration data in a cloud service with little or no modification to the existing KConfig module. The idea is to let a KDE user connect his/her KDE sessions (on multiple devices) to a cloud service using his/her identity.kde.org (or similar) credentials. Once the session is authenticated with identity.kde.org, user could configure the applications to be synced for storing their configuration data. A separate KDE service running in the background takes care of synchronization and any possible conflict resolution. A separate user interface would be used for manual conflict resolution. All configuration changes will be done through a kcm module. Service control and status monitoring would be shown using a system tray application. When an application uses KConfig module to store its configuration, the configuration is stored in local filesystem first. It's then scheduled to be updated to the cloud by the backend service at the earliest - we could use the Linux inotify interface or equivalent to monitor for changes in filesystem. Once updated in the cloud, the data is synchronized across all the desktop sessions using the same identity credentials both currently or any time in future. My current knowledge in KConfig is based on the tutorial given here: http://techbase.kde.org/Development/Tutorials/KConfig. I understand that there are multitude of ways an application might prefer to store its configuration data and it's my intention to take the most common apps on a case-by-case basis to provide the cloud support. I would currently like to target the following applications: a. akregator (for synchronizing feeds) b. rekonq (for bookmarks) Since this is a major feature, we should probably target KDE Framework 5. *Technologies & Tools* I prefer to use C++/Qt5/KF5 for all the modules except the server side. Server side could use PHP or Ruby. I'm not sure what runs behind the KDE servers currently, guessing it's PHP. I am familiar with HTML/Javascript but not an expert - so that might be an area where additional help will be required. *Deliverables & Timelines* I believe the project will have five deliverables: a. Have a cloud service running on a kde.org server (4 weeks) b. A KDE backend service that takes care of synchronization of configuration data (5 weeks) c. A kcm module to configure the service (1 week) d. A simple UI for manual conflict resolution (2 weeks) e. A simple system tray application for quick control and status monitoring of the synchronization process (1 week) *Concerns* Following are some concerns that some people have shown about the project: 1. Security and Privacy: As I understand, Privacy and Security are one of the main concerns with cloud storage. A few p
Re: GSoC project idea: Unlocking KWallet using PAM (I'm student)
Whether "make pam_exec call a dbus method" qualifies for GSoC i don't know, but with expose_authtok you can have the called exec read the login password from stdin - if it's used for kwallet encryption, you can this way also unlock the wallet. Otherwise you've to somewhere store the password/hash, pass it root access only, read it with a pam_exec call, pass the output to a seteuid pam_exec call for a process that waits for kwalletd to show up and does org.kde.KWallet.pamOpen The "tricky" part here is to make the user kwallet process store the password (requires a suid helper which must not be tricked into writing into the wrong file) Cheers, Thomas PS: no, i do not maintain nor even develop kwallet, just was pissed of being asked on each login and after learning that once a wallet is open, there's no further protection, I went for a generic "use cryptoloop" solution. Took me ~5 minutes to create an encrypted loop device, mount it via pam_mount, move the wallets there and (only "issue") trick kwallet into accepting a blank pasword. On Mittwoch, 1. Mai 2013 09:48:24 CEST, Alexander Mezin wrote: Hello. I think that fixing this bug: https://bugs.kde.org/show_bug.cgi?id=92845 could be a good GSoC project. It seems that KWallet can't be started from pam module (like gnome-keyring do), but some "unlock helper" can be started with pam_exec.so. Password (or hash) then can be passed to kwallet using local sockets. The only problem is that I'm not sure how to do this secure enough (and what is "secure enough") If I'll also add configuration options (unlock some wallet automatically or not, how long to keep it open, etc.), I think this will be enough for GSoC project. I didn't find any kwallet-related mailing list, so I'm posting here. Are there anyone interested in this project? Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
GSoC project idea: Unlocking KWallet using PAM (I'm student)
Hello. I think that fixing this bug: https://bugs.kde.org/show_bug.cgi?id=92845 could be a good GSoC project. It seems that KWallet can't be started from pam module (like gnome-keyring do), but some "unlock helper" can be started with pam_exec.so. Password (or hash) then can be passed to kwallet using local sockets. The only problem is that I'm not sure how to do this secure enough (and what is "secure enough") If I'll also add configuration options (unlock some wallet automatically or not, how long to keep it open, etc.), I think this will be enough for GSoC project. I didn't find any kwallet-related mailing list, so I'm posting here. Are there anyone interested in this project? >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Basic queries regarding GSOC project idea : Web based project report
I don't know how this mail could get into my spam folder. I am answering in a few hours. Sorry for the late reply. 2013/4/12 Lydia Pintscher > On Tue, Apr 9, 2013 at 3:21 AM, Lorefnon wrote: > > Hello, > > I wanted to inquire about the project idea for summer of code - Web based > > project report that aims to aggregate information from a multitude of > > sources (mentioned ones are - Git, Bugzilla and mailing lists) into a > > unified web-interface along with useful statistics. > > > > The project objective that I interpret from the description is to have a > > web-interface that can provide a quick overview of the activity and > current > > status of an open source project. In that retrospect will this be > similar to > > the popular site Ohloh (http://www.ohloh.net/) ? > > > > Given that ruby has been mentioned as the language of choice - Would > using > > Ruby on Rails framework be considered a good idea ? > > > > Also, while Git and Bugzilla provide structured sources of information, > I am > > not sure if I fully understand how mailing lists can be used to derive > > project statistics. I can think of using machine learning to infer which > > users are involved in development of which aspects of project to what > extent > > - but a bit of elaboration in this regard would certainly help. > > > > As far as my background is concerned, I am a final year undergraduate > > engineering student from IIT Kharagpur, India and have completed my prior > > summer of code project in 2011 which used Ruby on Rails. I have been > working > > off -and-on on projects involving ruby and c++ since. > > > > With regards, > > Gaurab Paul > > Rafael: Poke about this one as well. Please take some time a minute to > answer. > > > Cheers > Lydia > > -- > Lydia Pintscher - http://about.me/lydia.pintscher > KDE Community Working Group / KDE e.V. board member > http://kde.org - http://open-advice.org > -- Best regards, Rafael Fernández López >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: Basic queries regarding GSOC project idea : Web based project report
On Tue, Apr 9, 2013 at 3:21 AM, Lorefnon wrote: > Hello, > I wanted to inquire about the project idea for summer of code - Web based > project report that aims to aggregate information from a multitude of > sources (mentioned ones are - Git, Bugzilla and mailing lists) into a > unified web-interface along with useful statistics. > > The project objective that I interpret from the description is to have a > web-interface that can provide a quick overview of the activity and current > status of an open source project. In that retrospect will this be similar to > the popular site Ohloh (http://www.ohloh.net/) ? > > Given that ruby has been mentioned as the language of choice - Would using > Ruby on Rails framework be considered a good idea ? > > Also, while Git and Bugzilla provide structured sources of information, I am > not sure if I fully understand how mailing lists can be used to derive > project statistics. I can think of using machine learning to infer which > users are involved in development of which aspects of project to what extent > - but a bit of elaboration in this regard would certainly help. > > As far as my background is concerned, I am a final year undergraduate > engineering student from IIT Kharagpur, India and have completed my prior > summer of code project in 2011 which used Ruby on Rails. I have been working > off -and-on on projects involving ruby and c++ since. > > With regards, > Gaurab Paul Rafael: Poke about this one as well. Please take some time a minute to answer. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher KDE Community Working Group / KDE e.V. board member http://kde.org - http://open-advice.org >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Basic queries regarding GSOC project idea : Web based project report
Hello, I wanted to inquire about the project idea for summer of code - Web based project report that aims to aggregate information from a multitude of sources (mentioned ones are - Git, Bugzilla and mailing lists) into a unified web-interface along with useful statistics. The project objective that I interpret from the description is to have a web-interface that can provide a quick overview of the activity and current status of an open source project. In that retrospect will this be similar to the popular site Ohloh (http://www.ohloh.net/) ? Given that ruby has been mentioned as the language of choice - Would using Ruby on Rails framework be considered a good idea ? Also, while Git and Bugzilla provide structured sources of information, I am not sure if I fully understand how mailing lists can be used to derive project statistics. I can think of using machine learning to infer which users are involved in development of which aspects of project to what extent - but a bit of elaboration in this regard would certainly help. As far as my background is concerned, I am a final year undergraduate engineering student from IIT Kharagpur, India and have completed my prior summer of code project in 2011 which used Ruby on Rails. I have been working off -and-on on projects involving ruby and c++ since. With regards, Gaurab Paul >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Re: GSOC PROJECT
On Sun, Apr 29, 2012 at 08:59, Nishant Gupta wrote: > Sir, > > I am Nishant Gupta, a participant of GSOC 2012, wanted to contribute > something in open source software. So I applied for GSOC and had submitted > my proposals for companies which I applied but unfortunately couldn't be > selected due to limited slots given to them (as told by mentor whom I was in > touch with him and told your proposal was fine and we could have accommodate > if we have more slots available). I am still looking for open source > projects on which I could still work upon and I out your project list very > interesting and wanted to contribute something. Sir kindly guide me how > start about it. > Hello Nishant, thanks for contacting us. KDE hosts the Season of KDE program for students who have not been accepted into Google Summer of Code. To apply please follow the directions in this article [1]. I advise you to check the ideas page [2], see if there is something you would be interested in contributing to, and contact the relevant subproject to see if they have mentors available. [1] http://tinyurl.com/sok-faq [2] http://community.kde.org/GSoC/2012/Ideas Cheers, -- Teo >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
Anyone willing to mentor a KDE games GSoC project?
Hi all, I am planning to apply for GSoC this year with a project idea from the ideas list for KDE Games. The idea is to port a KDE game to QML. No one from KDE games has stepped up for mentoring it yet. Since QML/ QtQuick is well known among developers across KDE, I was wondering if any one from outside KDE games would be willing to mentor me on this. I myself am well acquainted with QML, all I need help with is writing the c++ parts that would be able to communicate with QML. I am really looking forward to doing this project (have a draft proposal already :p). Thanks, Viranch >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
