kqmlgraphplugin -- a QML plugin to render beautiful and interactive graphs
Hi everyone, some time ago I was in need for a graphing component for my application (KTouch). As the applications UI is done entirely in QML, I was looking for an QML component to do so. Since there was no satisfactory of-the-shelf solution I decided to implement my own graphs. Currently, the code for these graphs lives in the KTouch repository in is distributed alongside KTouch. More recently, at the last Edu sprint Andreas Cord-Landwehr approached me, because he would like to use the same graphs in his new application, artikulate. So we decided to split the graphing code out of KTouch and develop it in an independent project. This was pretty simple, since technically the code was already a plugin, only bundled with KTouch. That way kqmlgraphplugin was born. The goal: Provide a set of simple components to enable applications with a QML user interface to embed clear and visually pleasing graphs for tabular data. The current state: * we have components to display line and bar graphs * data comes from a QTableModel provided by the client * all code is currently Qt4 / QML 1.1 * project is hosted as a KDE Playground Project * GIT-URL: g...@git.kde.org:kqmlgraphplugin, kqmlgraphplugin on bugs.kde.org That's missing: * API documentation * a small demo app More information on the usage of the components can be found on my blog from an old but still accurate entry: > http://blog.sebasgo.net/blog/2012/09/26/line-graphs-for-qt-quick/ Andreas and me want to release this project as soon as possible to the public, since artikulate depends on this plugin already and can't be released before this. I think the code is pretty stable. It's used inside KTouch without any problems since KDE 4.10. I'm less sure about how the release should be done and there these components fits in. Should this plugin be distributed on its own or as part of something bigger? And what happens after the Qt5 / QML 2 transistion, should this be part the Frameworks 5? I think a lot of applications could be interested in such a plugin. Also interesting is the question of the wanted dependencies. Currently it uses Qt (obviously) and also imports some Plasma components for theme integration. I thinks that's no issue for a Qt4-based release, since all the QML using KDE applications already depend on Plasma components anyway, but for QML 2 it's probably better to get rid of this dependency. Best regards, Sebastian
Re: kqmlgraphplugin -- a QML plugin to render beautiful and interactive graphs
Hi David, > I don't want to start a naming bikeshed so if it is already too late > to consider renaming, just dismiss these comments: No, that's still okay. Nothing is set in stone yet. > > The first thing I thought of when I read the name of the plugin is > that it did graph rendering, like OGDF QML[0], and I was in desperate > need for such a library a couple of months ago. I think graph is > confusing for a couple of reasons: > > * There is already a concept of graphs associated to QML, as in QML > Graph Scene (which is apparently the most common result I get from > searching "QML Graph") Never thought about that. > * In KDE, Rocs deals with Graphs and KmPlot deals with these kinds of > graphs. * There is a Qt Charts[1] thing that does something similar. > > So I would consider renaming this to something with plot/chart. I like charts better and would consider renaming it to kqmlchartsplugin. The QML import would be 'org.kde.charts' then. Are there any more opinions on the naming issue? > > David E. Narvaez > > [0] https://github.com/schulzch/qml-ogdf > [1] http://blog.qt.digia.com/blog/2013/06/19/qt-charts-1-3-0-released-2/
Re: kqmlgraphplugin -- a QML plugin to render beautiful and interactive graphs
Hi, > > If this uses QtQuick I would suggest that it be part of the name. > > > > QML is a more generic term, used for thing that can be used by a QML > > engine. Usually components without UI, like data sources, sensors, > > models, timers etc. Things that can be used outside a UI context or with > > any UI component set (QtQuick, Cascasdes, Widgets and so on). > > +1 QML is the language, QtQuick is the "toolkit" So maybe "KDE QtQuick Charts" as the official name and "kdeqtquickcharts" for the repository? I'm undecided whether KDE should be part of the name or not, but I thinks it's better so as long it has a dependency on kderuntime for the Plasma Components. Best regards, Sebastian
Re: kqmlgraphplugin -- a QML plugin to render beautiful and interactive graphs
Hi Inge, > What's your long term plan for this module? I have been looking for a > better chart module for the calligra charts for some time. The current one > is good bug strictly 2D only. If you are interested in adding more chart > types then we are interested in using it. > > But for that to be feasible we need at least: > - More 2D planar types: bar charts, area charts, line charts (you have this > already) > - 2D polar types: Ring charts > - Pie types: Pie charts, Ring charts > - 3D charts: This is what is lacking now. > > Now, I understand that this will take a long time but I'm just wondering if > you are interested in working towards this at all. I can't promise anything with regards to large feature additions. My focus will be releasing this software at all and the port to Qt Quick 2. Which will be, if done thoroughly, quite a big task. There is lot of QPainter use in the components, which isn't exactly encouraged in Qt Quick 2. I would avoid large feature additions before the Qt Quick 2 port and before the related technical decisions are made. It would be certainly great to have such a large user like Calligra, but for that the project's scope has to be extended significantly. So far I have designed the components for the "casual" chart user, like visualizing the training progress in KTouch or artikulate. It is unlikely that will be able to achieve that on my own. > Regarding 3D charts, I have no idea if this is even possible using QML alone > or if you need to do something else for that. This is certainly possible in Qt Quick 2. Maybe not entirely with QML but one can extend the scene graph with new 3D node types in C++. But I personally have exactly zero experience with 3D programming. Best regards, Sebastian
Re: kqmlgraphplugin -- a QML plugin to render beautiful and interactive graphs
Hi, > > Cool project, I really missed such a component a while back (I actually > wrote my own back then, which was less nice than yours). The code looks > sane too from a quick look, so I'm all for moving it to extragear (although > I'm not exactly an expert for sane code). Thanks! > > It doesn't seem to be designed for lots of data (since each point is an > object, etc.), which is understandable; but eventually it would be a nice > feature to add API designed towards such data in the future? The line chart isn't suited at all for big data sets right now. Not only it use multiple QML items per data point but the line connecting the data points is drawn into one huge buffer, even for the parts of the line clipped by the viewport. The bar chart behaves better. It is based on a ListView item, so only the items actually visible on screen (which is a fairly limited number) are created at a given time. I think API-wise both chart types are fine. There is no inherent problem with QTableModels for large data sets I know of. But the line chart definitely needs a more efficient implementation. This is one of the points I hope I can resolve when porting to Qt Quick 2. > > On Wednesday 29 January 2014 12:41:22 Inge Wallin wrote: > > Regarding 3D charts, I have no idea if this is even possible using QML > > alone or if you need to do something else for that. > > I assume you're talking about the "usual" 3D charts, such as 3D-looking pie > charts and bar graphs? For drawing those, I would not use any kind of 3D API > at all. Just drawing some rectangles and ellipses clipping each other will > be way easier for that purpose, which is very easy even with QtQuick 1. > (Apart from that, those 3D effects are bad for a chart's readability > anyways ;) This is no near-future stuff anyways. Best regards, Sebastian
Re: kqmlgraphplugin -- a QML plugin to render beautiful and interactive graphs
Hi, > > So maybe "KDE QtQuick Charts" as the official name and "kdeqtquickcharts" > > for the repository? > > kqtquickcharts? That's better. More concise. So be it. Best regards, Sebastian
Re: Using kqmlgraphplugin in Plasma Next
Hi > Currently I am working on a QML Canvas based SignalPlotter, to replace > the old Plasma1SignalPlotter which is KSignalPlotter and > QGraphicWidget based. My SignalPlotter is in bshah/plotter-qml branch > of plasma-framework > (src/declarativeimports/plasmaextracomponents/SignalPlotter.qml) Conceptually charts and signal plotters are pretty different. A plotter tracks a value of a fixed amount of time (set by the available horizontal space) and cuts earlier values off. Charts on the contrary display whatever they are told to do. Both are useful and should IMO coexist. > > Meanwhile I was notified by apol that something like this already > exist, which is QML, So basically my plan is to port kqmlgraphplugin > to KDE Frameworks 5 and use it to plot data in Plasma Next. > > I am interested in porting it to KDE Frameworks 5. Is someone already > working on that? If yes can I help with that? Otherwise I will start > to port it. :) Sure, go for it. It needs to be investigated what the best porting strategy is. Three ways come to mind. The easy way: use QPaintedItem. Very straightforward, but virtually no gain in comparison to the Qt Quick 1 version since the continued use of software rendering. Canvas based: I have no experience with that but I guess performance is should be better than with QPaintedItem, since it directly renders to a GPU framebuffer and painting can be done in an separate thread. Shader based: Perform the actual rendering in a fragment shader. Definitely the most ambitious and complicated solution, but also the only with pure GPU rendering. I don't know if it's really worth the effort. Best regards, Sebastian
KDE Review: Move kqtquickcharts to KDE Edu
Hi everyone, kqtquickcharts (formerly known as kqmlgraphs) provides components for line and bar charts for QtQuick applications. As discussed earlier, I want to release the project as soon as possible (read: 4.13) so KTouch and artikulate can use it. The release of artikulate depends on this, KTouch will drop its own copy of the charts code as soon as the review progress is over. Ideally I want to release the project in the current state with as little changes possible. Large new features and refactorings are reserved for the inevitable port to QtQuick 2. With that, I may try to get project into Frameworks 5, depending on interest. For now, I stick with KDE Edu. The repository for the review is located at: https://projects.kde.org/projects/kdereview/kqtquickcharts/repository Best regards, Sebastian
Re: KDE Review: Move kqtquickcharts to KDE Edu
Hi everyone, > kqtquickcharts (formerly known as kqmlgraphs) provides components for line > and bar charts for QtQuick applications. > As discussed earlier, I want to release the project as soon as possible > (read: 4.13) so KTouch and artikulate can use it. The release of artikulate > depends on this, KTouch will drop its own copy of the charts code as soon > as the review progress is over. The two weeks of the review period are almost over. Has anyone still objections / suggestions? Otherwise I will proceed further after the deadline has passed so the artikulate release with 4.13 may actually happen. Best regards, Sebastian
Review Request: Plasma Components: TextField and TextArea: Show placeholders even if item has the focus
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104895/ --- Review request for KDE Runtime. Description --- Rationale: This allows the application to pre-focus a text field with a placeholder text for the user. In the version before this would have hidden the placeholder text and it may not have been obvious for user what he was expected to enter in the text field. Diffs - plasma/declarativeimports/plasmacomponents/qml/TextArea.qml 2d9e89f plasma/declarativeimports/plasmacomponents/qml/TextField.qml 4ed15d9 Diff: http://git.reviewboard.kde.org/r/104895/diff/ Testing --- Used it in ktouch/next, works fine. Screenshots --- Form in KTouch http://git.reviewboard.kde.org/r/104895/s/562/ Thanks, Sebastian Gottfried
Re: Review Request: Plasma Components: TextField and TextArea: Show placeholders even if item has the focus
> On May 9, 2012, 6:30 p.m., Mark Gaiser wrote: > > Ehh optional perhaps? > > I've seen forms behave like this before and back then when i first saw it i > > tried to delete the text.. Which obviously didn't happen. The text just > > disappears as soon as i start typing. I kinda dislike that behavior. I > > mean, there is a big fat blue focus border that has the purpose of telling > > the user that the one with the blue border (style dependent) is the one > > that currently has focus. The blinking cursor is yet another indication > > that the field has focus. I think that is enough. > > > > Perhaps optional, but please not by default. This is just my opinion and i > > don't maintain plasma components (nor anything in KDE for that matter). > > You'd have to wait for a reply from some of the plasma component > > maintainers to get a final word on this. > > Sebastian Kügler wrote: > This just fixes a race condition, I don't quite understand your > reservation, Mark? > > David Edmundson wrote: > No it doesn't. Currently if you give an item focus you hide the > placeholder text. In this patch it only hides placeholder text after you > start typing. > > David Edmundson wrote: > ^ That reply was at Sebastian where he says it's a fix, where it's > actually a large visual change. (reviewboard doesn't really show that very > well) > > Sebastian Kügler wrote: > Funny, because I ran into this exact behaviour last night, and to make it > work well, I had to resort to using a Timer which calls forceActiveFocus() on > the TextArea, not quite intuitive either. > > Does anyone have a suggestion which satisfies both usecase without hacks? Using a timer to give a text field the focus sounds really strange in my ears. We could obviously extend the API of the text fields with a boolean property "showPlaceholderWhileFocused" and give the responsibility to decide on the wanted behaviour to the application developer. But at least me would prefer a consistent behaviour for all text fields. - Sebastian --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104895/#review13617 --- On May 9, 2012, 4:53 p.m., Sebastian Gottfried wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/104895/ > --- > > (Updated May 9, 2012, 4:53 p.m.) > > > Review request for KDE Runtime. > > > Description > --- > > Rationale: This allows the application to pre-focus a text field with a > placeholder text for the user. In the version before this would have > hidden the placeholder text and it may not have been obvious for user > what he was expected to enter in the text field. > > > Diffs > - > > plasma/declarativeimports/plasmacomponents/qml/TextArea.qml 2d9e89f > plasma/declarativeimports/plasmacomponents/qml/TextField.qml 4ed15d9 > > Diff: http://git.reviewboard.kde.org/r/104895/diff/ > > > Testing > --- > > Used it in ktouch/next, works fine. > > > Screenshots > --- > > Form in KTouch > http://git.reviewboard.kde.org/r/104895/s/562/ > > > Thanks, > > Sebastian Gottfried > >
Review Request: QML Plasma Components - fix for bug in ScrollBar anchoring
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107622/ --- Review request for KDE Runtime, Burkhard Lück and Marco Martin. Description --- Regarding the QML Plasma components: The recent commit by Bernhard Lück checking whether anchoring of a ScrollBar is possible contains a subtle logic error. I think the intended behavior is to check whether the ScrollBar item's parent is the associated flickable itself or its parent. But because the check is done in "internalLoader", a child of the actual ScrollBar item on directly on this item's parent property, it checks whether the ScrollBar item is the flickable or its parent. The patch fixes this by doing the checks on 'scrollBar.parent'. Feel free to discard that request if I'm mistaken. Diffs - plasma/declarativeimports/plasmacomponents/qml/ScrollBar.qml 7464645 Diff: http://git.reviewboard.kde.org/r/107622/diff/ Testing --- The checking logic broke some of the scroll bars in KTouch, now they work again. Thanks, Sebastian Gottfried
Review Request: Plasma QML Components: fix internal anchoring in ToolButton
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107813/ --- Review request for KDE Runtime and Marco Martin. Description --- There is a bug in the tool button component resulting in layout breakage if one clears and sets the text property of the component when not visible, see the attached screenshot. I have tried to solve the issue without changing the existing anchoring system, but without success. The only working solution was to put the icon and the label item into Column item. That way I was able to fix the bug and even get rid of the ugly explicit non-declarative anchor assignments. I have also removed the preferredWidth property of the label item, that one always evaluated to paintedWidth, anyway. For consistency the button component should get the same treatment, I will do so once I get positive feedback here. Diffs - plasma/declarativeimports/plasmacomponents/qml/ToolButton.qml 594067d Diff: http://git.reviewboard.kde.org/r/107813/diff/ Testing --- Work as expected. No behavioral changes apart from the bugfix. Screenshots --- Broken tool button layout http://git.reviewboard.kde.org/r/107813/s/921/ Thanks, Sebastian Gottfried
Re: Review Request: Plasma QML Components: fix internal anchoring in ToolButton
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107813/ --- (Updated Dec. 19, 2012, 1:46 p.m.) Review request for KDE Runtime and Marco Martin. Changes --- fix label position when icon invalid, now it is properly centered Description --- There is a bug in the tool button component resulting in layout breakage if one clears and sets the text property of the component when not visible, see the attached screenshot. I have tried to solve the issue without changing the existing anchoring system, but without success. The only working solution was to put the icon and the label item into Column item. That way I was able to fix the bug and even get rid of the ugly explicit non-declarative anchor assignments. I have also removed the preferredWidth property of the label item, that one always evaluated to paintedWidth, anyway. For consistency the button component should get the same treatment, I will do so once I get positive feedback here. Diffs (updated) - plasma/declarativeimports/plasmacomponents/qml/ToolButton.qml 594067d Diff: http://git.reviewboard.kde.org/r/107813/diff/ Testing --- Work as expected. No behavioral changes apart from the bugfix. Screenshots --- Broken tool button layout http://git.reviewboard.kde.org/r/107813/s/921/ Thanks, Sebastian Gottfried
Re: Review Request: Plasma QML Components: fix internal anchoring in ToolButton
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107813/ --- (Updated Dec. 19, 2012, 2:35 p.m.) Review request for KDE Runtime and Marco Martin. Changes --- Extend patch to cover PlasmaComponents.Button as well. Description (updated) --- There is a bug in the tool button and button components resulting in layout breakage if one clears and sets the text property of the component when not visible, see the attached screenshot. I have tried to solve the issue without changing the existing anchoring system, but without success. The only working solution was to put the icon and the label item into Row item. That way I was able to fix the bug and even get rid of the ugly explicit non-declarative anchor assignments. I have also removed the preferredWidth property of the label item, that one always evaluated to paintedWidth, anyway. Diffs (updated) - plasma/declarativeimports/plasmacomponents/qml/Button.qml 5bfb8d7 plasma/declarativeimports/plasmacomponents/qml/ToolButton.qml 594067d Diff: http://git.reviewboard.kde.org/r/107813/diff/ Testing --- Work as expected. No behavioral changes apart from the bugfix. Screenshots --- Broken tool button layout http://git.reviewboard.kde.org/r/107813/s/921/ Thanks, Sebastian Gottfried
Review Request 108860: Plasma QML Components: trigger appearAnimation in InlineDialog properly
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108860/ --- Review request for KDE Runtime and Marco Martin. Description --- Use `appearAnimation.restart()` instead of `appearAnimation.running = true` to trigger the open/close animation. In the old version it is impossible to open or close the dialog while it is still appearing or disappearing since the old animation simply continues to run. Diffs - plasma/declarativeimports/plasmacomponents/qml/private/InlineDialog.qml 2b7b832 Diff: http://git.reviewboard.kde.org/r/108860/diff/ Testing --- Tested within KTouch. Works as expected. Thanks, Sebastian Gottfried
Review Request 108862: QML Plasma Components: improve positioning strategy for inline dialog
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108862/ --- Review request for KDE Runtime and Marco Martin. Description --- This changes the positioning of the inline dialog in two ways: 1) Offset the dialog vertically so the balloon tip won't poke into the visual parent. 2) Make sure the dialog won't leave the view port in the horizontal dimension. This useful for dialogs with parents near the viewport border. The position of the tip is adjusted appropriately. I'm not sure whether this still a bugfix or not and should also go into KDE/4.10. Please comment. Diffs - plasma/declarativeimports/plasmacomponents/qml/private/InlineDialog.qml 2b7b832 Diff: http://git.reviewboard.kde.org/r/108862/diff/ Testing --- Tested within KTouch. Works as expected. File Attachments Improved positioning http://git.reviewboard.kde.org/media/uploaded/files/2013/02/08/improved-inline-dialog-positioning.png Thanks, Sebastian Gottfried
Re: Review Request 108862: QML Plasma Components: improve positioning strategy for inline dialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/108862/ --- (Updated Feb. 8, 2017, 12:42 p.m.) Status -- This change has been discarded. Review request for KDE Runtime and Marco Martin. Repository: kde-runtime Description --- This changes the positioning of the inline dialog in two ways: 1) Offset the dialog vertically so the balloon tip won't poke into the visual parent. 2) Make sure the dialog won't leave the view port in the horizontal dimension. This useful for dialogs with parents near the viewport border. The position of the tip is adjusted appropriately. I'm not sure whether this still a bugfix or not and should also go into KDE/4.10. Please comment. Diffs - plasma/declarativeimports/plasmacomponents/qml/private/InlineDialog.qml 2b7b832 Diff: https://git.reviewboard.kde.org/r/108862/diff/ Testing --- Tested within KTouch. Works as expected. File Attachments Improved positioning https://git.reviewboard.kde.org/media/uploaded/files/2013/02/08/improved-inline-dialog-positioning.png Thanks, Sebastian Gottfried
