> On Feb. 23, 2011, 5:29 p.m., Martin Gräßlin wrote:
> > The GLApplet seems to be unmaintained and is nowhere used in KDE (see 
> > http://lxr.kde.org/ident?i=GLApplet ). There was once one demo applet using 
> > it, but it has vanished.
> > 
> > GLApplet uses OpenGL only for glClear before passing the QPainter to the 
> > Plasmoid. I think we could just remove the background clearing and require 
> > it from the applet and drop the link to OpenGL completely.
> > 
> > Another thing is that given that it is just not used adding the complete 
> > GLES detection and building to Plasma does not make sense. It's probably 
> > better just to add a cmake option to disable building of the plasma applet 
> > (maybe using the mobile profile for that?).
> > 
> > The CMake stuff to find GLES is unfortunately not in a state to be included 
> > in kdelibs. I contacted build system some time ago and they gave me a nice 
> > list of things which need to be improved and it's still on my TODO stack :-(
> > 
> > It would be nice to have some input from Plasma devs here. Could you please 
> > add the Plasma group to the review?
> 
> Jammy Zhou wrote:
>     I'm a newbie for KDE development, what's GLApplet originally used for? 
> And if GLApplet is really obsolete, maybe we'd better retire it to remove the 
> dependency of libplasma on libGL. :)
>     
>     I also considered to remove glClear in GLApplet, but I'm not sure if it 
> will cause some regressions, so I prepared this change.
>     
>     Anyway, waiting for inputs from plasma-devs to make final decision.
> 
> Martin Gräßlin wrote:
>     > what's GLApplet originally used for?
>     It allows to write a Plasmoid which can use OpenGL. Apparently there is 
> no interest in doing so
>     > And if GLApplet is really obsolete, maybe we'd better retire it to 
> remove the dependency of libplasma on libGL. :)
>     Yeah that would be nice. We cannot remove the class altogether, as that 
> would break the ABI, but what should be done is deprecate it and add it to 
> the list for removal in libplasma2. To get it free of OpenGL removing the 
> glClear should be enough.
>     
>     > I also considered to remove glClear in GLApplet, but I'm not sure if it 
> will cause some regressions, so I prepared this change.
>     As there is nothing using it at least in KDE repositories it probably 
> won't cause regressions. Therefore I would give a +1 to remove it. Notmart or 
> aseigo what do you think?
>     
>     Technical background for the non OpenGL devs in Plasma: the GLApplet has 
> two lines of OpenGL code: it sets the clear color and clears the background. 
> In normal speak, it repaints the background completely black. Afterwards the 
> paint implementation of the applet is called which does the actual OpenGL 
> rendering. Now the normal way in doing a paint process, is to first clear the 
> background. If I would write an applet that's what I would have done in my 
> code as I would not have expected the framework to clear already. It is also 
> not documented that it does that and you do not always want to clear the 
> background but want to continue to render on the previous frame.
>     
>     So the chances are that even if there exists an applet, which we do not 
> know about, it would do the clearing itself.

Thanks for the detailed answers, Martin. I will prepare a new patch to remove 
the direct OpenGL dependency of libplasma as you suggested. I think if OpenGL 
rendering is really needed in libplasma, it can be done through QtOpenGL 
module, which can handle desktop OpenGL and OpenGL ES2.0 in Qt.


- Jammy


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100705/#review1612
-----------------------------------------------------------


On Feb. 24, 2011, 2:07 a.m., Jammy Zhou wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/100705/
> -----------------------------------------------------------
> 
> (Updated Feb. 24, 2011, 2:07 a.m.)
> 
> 
> Review request for kdelibs and Plasma.
> 
> 
> Summary
> -------
> 
> After build kwin with GLES2 code path, the kwin binary still has dependency 
> on libGL.so, which is introduced by libplasma.so. Then we also need to add 
> GLES2 support to libplasma, so that kwin/plasma only has dependency on 
> libGLESv2.so in this case. 
> 
> The new option "BUILD_PLASMA_WITH_OPENGLES" added in attached patch is 
> disabled by default, and distributions can turn it on when do packaging for 
> OpenGL ES2.0 support.
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt 2dcc5ec 
>   cmake/modules/FindOpenGLES.cmake PRE-CREATION 
>   includes/CMakeLists.txt 9954c37 
>   plasma/CMakeLists.txt 8e6b0d7 
> 
> Diff: http://git.reviewboard.kde.org/r/100705/diff
> 
> 
> Testing
> -------
> 
> After turn the "BUILD_PLASMA_WITH_OPENGLES" option on, kwin-gles has no 
> dependency on libGL.so now. And by default, libplasma still depends on 
> libGL.so when run ldd.
> 
> 
> Thanks,
> 
> Jammy
> 
>

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Reply via email to