kqmlgraphplugin -- a QML plugin to render beautiful and interactive graphs

2014-01-27 Thread Sebastian Gottfried
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

2014-01-28 Thread Sebastian Gottfried
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

2014-01-29 Thread Sebastian Gottfried
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

2014-01-29 Thread Sebastian Gottfried
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

2014-01-30 Thread Sebastian Gottfried
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

2014-01-30 Thread Sebastian Gottfried
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

2014-02-02 Thread Sebastian Gottfried
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

2014-02-06 Thread Sebastian Gottfried
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

2014-02-19 Thread Sebastian Gottfried
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

2012-05-09 Thread Sebastian Gottfried

---
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

2012-05-10 Thread Sebastian Gottfried


> 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

2012-12-07 Thread Sebastian Gottfried

---
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

2012-12-19 Thread Sebastian Gottfried

---
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

2012-12-19 Thread Sebastian Gottfried

---
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

2012-12-19 Thread Sebastian Gottfried

---
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

2013-02-08 Thread Sebastian Gottfried

---
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

2013-02-08 Thread Sebastian Gottfried

---
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

2017-02-08 Thread Sebastian Gottfried

---
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