XSLT to convert Doxygen to MediaWiki
Hi all, I faced the problem of how to get the scripting documentation generated and most important up to date without manually editing the Wiki pages. As I am lazy I wrote an XSL Template to convert Doxygen generated XML into MediaWiki syntax. The template processes: * read-only properties * read-write properties * public slots * Q_SCRIPTABLE public methods The generated MediaWiki code matches the style used by Plasma's JavaScript documentation. An example for docu generated by the template can be found in [1]. To convert xsltproc cannot be used as I use XSLT 2.0 functionality. Best use saxon [2]. To generate use the following command: java -cp saxon9he.jar net.sf.saxon.Transform -t -s:/path/to/doxygen- generated.xml -xsl:/path/to/mediawiki.xslt I hope this can be useful to keep the Plasma JavaScript docu up to date :-) Cheers Martin [1] http://techbase.kde.org/Development/Tutorials/KWin/Scripting/API_4.9 [2] http://saxon.sourceforge.net mediawiki.xslt Description: application/xslt signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: OpenGL and Plasma::Wallpaper
On Saturday 31 December 2011 12:10:37 Shaun Reich wrote: On Sat, Dec 31, 2011 at 5:17 AM, Martin Gräßlin mgraess...@kde.org wrote: On Thursday 29 December 2011 11:21:36 Justin L. Boss wrote: Personally I am not a big fan of having animations which would require OpenGL in the background. Most of the time the background is not visible, it requires resources and puts load on the compositor which has to update the scene although nothing changes (full repaints are most expensive). May I ask why you want to use OpenGL? Probably because QPainter is dog slow. using OpenGL doesn't make it faster if you need QPainter to render to the background ;-) Also, I don't think you should be against OGL wallpapers, considering some really sweet/impressive things could be done with them which could really make KDE stand out. e.g. a wallpaper playing a moving OGL scene, movies, virus wallpaper (which is currently a large CPU drain, and has no HW accel afik). Take Win 7 for instance, how they have Dreamscene™ or whatever. I divide the world into two categories: good for KWin, bad for KWin. An animated wallpaper is bad for KWin as it needs to update everything all the time. In that sense it does not matter whether the wallpaper uses OpenGL or something else. If it is animated than it is bad. This is of course orthogonal to what it provides: being awesome. KWin has also the being awesome things which are in fact bad for KWin. But what's the difference? Nobody tries to use the desktop while the cube is spinning. It just doesn't matter that KWin is using lots of resources. In case of a wallpaper covered by windows it does matter whether the background makes everything slow or not. So here I just think we should not give users the tool to make the desktop unbearable slow. Yes it looks awesome, yes new users might love it. Yes new users will switch back to whatever they used, because everything is extremely slow. So unless our wallpapers learn to not redraw the areas which are not visible anyway (which is probably impossible to know for the wallpaper), I am not a fan of animated wallpapers in general. Just for the record: using always animated wallpapers should perform better thanks to optimizations in 4.8. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: OpenGL and Plasma::Wallpaper
On Sun, Jan 1, 2012 at 12:54 PM, Martin Gräßlin mgraess...@kde.org wrote: On Saturday 31 December 2011 12:10:37 Shaun Reich wrote: On Sat, Dec 31, 2011 at 5:17 AM, Martin Gräßlin mgraess...@kde.org wrote: On Thursday 29 December 2011 11:21:36 Justin L. Boss wrote: Personally I am not a big fan of having animations which would require OpenGL in the background. Most of the time the background is not visible, it requires resources and puts load on the compositor which has to update the scene although nothing changes (full repaints are most expensive). May I ask why you want to use OpenGL? Probably because QPainter is dog slow. using OpenGL doesn't make it faster if you need QPainter to render to the background ;-) Aaw, I was hoping using OGL/qml and what not would remove the need to go through QPainter at all. If only... So unless our wallpapers learn to not redraw the areas which are not visible anyway (which is probably impossible to know for the wallpaper), I am not a fan of animated wallpapers in general. Just for the record: using always animated wallpapers should perform better thanks to optimizations in 4.8. Cools. -- Shaun Reich, KDE Software Developer (kde.org) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: Re: OpenGL and Plasma::Wallpaper
On Sunday 01 January 2012 13:37:45 Shaun Reich wrote: On Sun, Jan 1, 2012 at 12:54 PM, Martin Gräßlin mgraess...@kde.org wrote: On Saturday 31 December 2011 12:10:37 Shaun Reich wrote: On Sat, Dec 31, 2011 at 5:17 AM, Martin Gräßlin mgraess...@kde.org wrote: On Thursday 29 December 2011 11:21:36 Justin L. Boss wrote: Personally I am not a big fan of having animations which would require OpenGL in the background. Most of the time the background is not visible, it requires resources and puts load on the compositor which has to update the scene although nothing changes (full repaints are most expensive). May I ask why you want to use OpenGL? Probably because QPainter is dog slow. using OpenGL doesn't make it faster if you need QPainter to render to the background ;-) Aaw, I was hoping using OGL/qml and what not would remove the need to go through QPainter at all. If only... it will with QML2 and the OpenGL SceneGraph :-) signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML widget explorer
On Saturday 31 December 2011, Marco Martin wrote: Hi all, After almost a year of stopped development, I think the qml rewrite of the widget explorer and activity manager are almost ready for merge :D Annuntio vobis gaudium magnum, the qml widget explorer and activity manager are merged, let the bitch fest begin :p Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML widget explorer
On Sun, Jan 1, 2012 at 2:51 PM, Marco Martin notm...@gmail.com wrote: the qml widget explorer and activity manager are merged, let the bitch fest begin :p So is this why you haven't/aren't on IRC? You think you can just hide from us and it'll all go away?! ;-p -- Shaun Reich, KDE Software Developer (kde.org) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
FolderView Overlay Incapsulation Question
Hello Plasma devs! I wanted to ask this question on IRC, but nobody's there at the moment. So I'm asking here instead. I'm implementing the option to hide the selection marker in FolderView as per the proposal from the NetRunner project. (netrunner-os.com). (I'm now working for that project, doing various KDE polish tasks. This is my first task. I will soon publish a review request for it.) I have located all the relevant code and implemented all the necessary bits but one. The Overlay buttons are in a QGraphicsGridLayout. The Click to view button (the lower one) uses the QWidget::hide() method in hoverEvent() and successfully hides itself. The Selection button, on the other hand, is located above the first button, and QWidget::hide() results in an **ugly gap**. Thus I have to use the QGraphicsGridLayout::removeItem() and ::addItem() instead of QWidget::hide(). Now these functions have to be called once on settings change, not every time on hoverEvent(). This means I have to implement a public method in ActionOverlay void ActionOverlay::setShowSelectionMarker(bool show); which would add / remove the button from the layout and hide it, resulting in a proper button alignment. Now if I implement this method, for consistency and symmetry, I will have to do the same for the ClickToView button: void ActionOverlay::setShowClickToViewButton(bool show); There are currently no such methods. It's done differently. Does this mean that my method is incorrect? Will my implementation break incapsulation or the existing class design? Please approve or disapprove of this proposal, as I have to finish coding this (dead simple) task soon and go forward. The other problem with FW is that following a recent commit from Aaron Seigo, the configAccepted() method no longer aplies settings, which is perfectly fine per se. But, now when we click Apply or OK, the settings are written to the disk, but are **not** applied. Tested in trunk. This needs some solution as well. Best regards, Ignat Semenov ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: QML widget explorer
On Sunday 01 January 2012 20:51:34 Marco Martin wrote: On Saturday 31 December 2011, Marco Martin wrote: Hi all, After almost a year of stopped development, I think the qml rewrite of the widget explorer and activity manager are almost ready for merge :D Annuntio vobis gaudium magnum, meh my Latin is not even good enough any more to translate that without Wikipedia :-( the qml widget explorer and activity manager are merged, let the bitch fest begin :p a little bit of feedback * \o/ yeah opening the widget explorer and typing works \o/ * the bottom of the activity mager looks a little bit crowded. I would say margin is missing (see [1]). If I are first in widget explorer it looks correct. * clicking on Create Activity opens the window on the left screen corner. If you don't have that I blame Qt and update (I saw 4.8 is in Debian experimental) * If I am first in Activies with bad bottom and go to widgets the scrollbar is missing * There should be a margin between widget title and right corner - see [2] * Widget name might need a text elide - see [3] * Too much empty space in tooltips * Yeah scrolling would be nice :-) Also the missing flickable behavior surprised me, though it is clear that it cannot work when there is a drag area. great work :-) Cheers Martin [1] http://wstaw.org/m/2012/01/01/bottom-of-activity-manager.png [2] http://wstaw.org/m/2012/01/01/kmail2f26845.jpg [3] http://wstaw.org/m/2012/01/01/kmail2W26845.jpg signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML widget explorer
On Sunday 01 January 2012, Martin Gräßlin wrote: On Sunday 01 January 2012 20:51:34 Marco Martin wrote: On Saturday 31 December 2011, Marco Martin wrote: Hi all, After almost a year of stopped development, I think the qml rewrite of the widget explorer and activity manager are almost ready for merge :D Annuntio vobis gaudium magnum, meh my Latin is not even good enough any more to translate that without Wikipedia :-( the qml widget explorer and activity manager are merged, let the bitch fest begin :p a little bit of feedback * \o/ yeah opening the widget explorer and typing works \o/ * the bottom of the activity mager looks a little bit crowded. I would say margin is missing (see [1]). If I are first in widget explorer it looks correct. uhm, seems the whole window gets behind the panel O.o * clicking on Create Activity opens the window on the left screen corner. If you don't have that I blame Qt and update (I saw 4.8 is in Debian experimental) duh, a thing i forgotten to fix, should be ok now * If I am first in Activies with bad bottom and go to widgets the scrollbar is missing * There should be a margin between widget title and right corner - see [2] * Widget name might need a text elide - see [3] * Too much empty space in tooltips there are probably a lot of little layout misbehaviours, that'll take a while indeed (and, slightly different behaviours with different fonts, fot sizes, etc - fun ;) * Yeah scrolling would be nice :-) Also the missing flickable behavior surprised me, though it is clear that it cannot work when there is a drag area. yep, the events are eaten by the drag area, the two things are pretty much mutually exclusive :/ great work :-) thx ;) -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QML widget explorer
On Sunday 01 January 2012 20:51:34 Marco Martin wrote: Annuntio vobis gaudium magnum, What? the qml widget explorer and activity manager are merged, let the bitch fest begin :p Ah, we have to smoke some QML in our pope ;-) -- Ruurd Pels, Boogerd 1, 1791 GW Den Burg - Texel, The Netherlands ru...@kde.nl http://about.me/ruurdpels +31612914545 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
