Re: Moving Baloo forward
On Wed, Jan 29, 2014 at 8:49 AM, Todd wrote: > > What about something like what Dolphin has now, where when you drop a file > on a removable filesystem or remote drive it pops up the current > copy/move/link option, but also has a checkbox (disabled by default buy > configurable) to "copy metadata" or "copy tags" or something along those > lines? > Well it's a menu, once you select an action, the menu goes away, checkbox or not. I imagine there are some ways (hacks?) howto make menu a small sort of modal dialog, but then imho it would be better to have "Copy" and "Copy with metadata". Oh and the visual clutter it would bring to that simple menu...dunno, sounds too complicated imo. What we could do with regards to educating users, is what Google does these days - when there's a new feature in any Google product, it shows a little bubble shortly explaining what is it about with two buttons - "Okay, got it" and "Show me more". I can imagine something similar first time you copy a file/open dolphin/some other action. Shown once and never more. Too bad if the users misses it though :) Cheers -- Martin Klapetek | KDE Developer
Re: Moving Baloo forward
On Wednesday, 2014-01-29, 00:06:11, Ingo Klöcker wrote: > I don't think it makes sense to work around a social problem (uneducated > users) by using an inferior and much more complex technical solution > (some database instead of xattrs). IMHO the advantages of using xattrs > (e.g. we get easy synchronization and backup of metadata for free) > outweigh the possibility that some people might inadvertently publish > private metadata. People need to be educated that they have to use their > brains when they share stuff. And we need to make sharing stuff (with > built-in privacy protection) as easy as possible. As you pointed out below, most sharing technologies automatically discard xattrs anyway. The only sharing option that would not that I can come up with is having a shared directory on a filesystem with xattrs support. The question for that is whether it is not the administrator responsibility to set it up without xattrs support if privacy between sharing parties is a concern. > Moreover, the risk for privacy is significantly lower than with metadata > that is stored in the file itself (as in your MS Word document example). > In contrast to metadata stored in MS Word documents, metadata stored in > xattrs will not be leaked if you share the file via mail or by uploading > it to Facebook or by copying it on a (FAT32-formatted) USB-stick. > Apparently, Dropbox supports xattrs, but IMHO it's Dropbox's > responsibility to provide a setting to disable synchronization of file > metadata. My guess would be that DropBox or any other synchronisation service only does that for sync clients, not when enabling "outside" access to the same data. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Moving Baloo forward
On Wednesday, 2014-01-29, 09:09:50, Martin Klapetek wrote: > On Wed, Jan 29, 2014 at 8:49 AM, Todd wrote: > > What about something like what Dolphin has now, where when you drop a file > > on a removable filesystem or remote drive it pops up the current > > copy/move/link option, but also has a checkbox (disabled by default buy > > configurable) to "copy metadata" or "copy tags" or something along those > > lines? > > Well it's a menu, once you select an action, the menu goes away, checkbox > or not. I imagine there are some ways (hacks?) howto make menu a small sort > of modal dialog, but then imho it would be better to have "Copy" and "Copy > with metadata". Oh and the visual clutter it would bring to that simple > menu...dunno, sounds too complicated imo. On each copy/move sounds too annoying IMHO. An alternative approach could be to allow removable media or their volumes to be marked as "trusted" and only copy metadata onto such media. For example I have a USB disk sitting on my desk and use it as my main "big" storage for this laptop (which only has SSD). It is an external drive, so potentially something that might be connected to a different computer, but I wouldn't want to be asked for metadata copy permission everytime I copy something to it. Actually in this case the "trusted" could even be automatic or opt-out because the volumes themselves are encrypted. > What we could do with regards to educating users, is what Google does these > days - when there's a new feature in any Google product, it shows a little > bubble shortly explaining what is it about with two buttons - "Okay, got > it" and "Show me more". I can imagine something similar first time you copy > a file/open dolphin/some other action. Shown once and never more. Too bad > if the users misses it though :) Such hints sound like a very good idea in any case. Discoverability of new features is something we are not very good at yet. As an old KDE user I am often amazed what new features are available in programs I have been using for over a decade because I was never aware when they got added. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: kqmlgraphplugin -- a QML plugin to render beautiful and interactive graphs
On Tuesday, January 28, 2014 23:26:58 Albert Astals Cid wrote: > El Dissabte, 25 de gener de 2014, a les 12:17:05, Sebastian Gottfried va > > escriure: > > Hi everyone, > > Hi > > > 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 > > Came here to say this :D > > > * 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? > > Good, question, at this stage i'd either put it inside the kde-edu "virtual > module" and get it released if with 4.13 and on or put it in extragear-libs > and you care of releasing it yourself. 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. 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. -Inge > > 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. > > Makes sense to me, you probably want to discuss that in the frameworks > mailing list. > > > 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. > > Agreed. > > Cheers, > Albert > > > Best regards, > > > > Sebastian
Re: kqmlgraphplugin -- a QML plugin to render beautiful and interactive graphs
Hi Sebastian, On 28/01/14 05:51, Sebastian Gottfried wrote: 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? +1 for the use of chart instead of graph (for ambiguity with Graph Theory [1]) and instead of plot, since I think the word plot is used when a math expression is involved (function, inequality, etc.) and kqmlgraphplugin is more suitable when one needs to render results from statistical/financial analysis. Percy [1] http://planetmath.org/node/33701 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: Moving Baloo forward
Am Dienstag, 28. Januar 2014, 22:06:45 schrieb Rolf Eike Beer: > Am Dienstag, 28. Januar 2014, 20:10:13 schrieb Ivan Čukić: > > > To move a file to another machine and have the metadata be copied and > > > re- > > > indexed on that new machine as well. The copy process just needs to take > > > care of transfering the xattr. This can even work when using a USB stick > > > or so as interim medium. > > > > I'm all for xattrs, but this thread really raises a nice question of which > > annotations/tags/whatever should be public and which should not. > > IMHO the default should be "privacy first". Probably everyone of us has > laughed about someone who accidentially published either metadata or > deleted text (remember MS Word document history or something)? I'm > absolutely fine if you want this that you do this. But most people will not > be aware of it, even less of the implications. So it should be deactivated > by default and only activated explicitely. Hmmm, right, didn´t actually think of the privacy implications. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
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). 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? 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 ;) Greetings, Sven
Re: Review Request 115371: Remove strigi usages from kde-runtime
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115371/#review48573 --- If you're removing it from the CMakeLists then please remove the kde-runtime/kioslave/trash/trashthroughanalyzer.* files as well. You may want to grep through kde-runtime for all uses of strigi. (Ignore the nepomuk ones, that's just an old variable name) - Vishesh Handa On Jan. 28, 2014, 11:04 p.m., Hrvoje Senjan wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115371/ > --- > > (Updated Jan. 28, 2014, 11:04 p.m.) > > > Review request for KDE Runtime and Vishesh Handa. > > > Repository: kde-runtime > > > Description > --- > > Strigi is used only for trashanalyzer, which isn't installed since 2007 ;-) > so i removed it also. > > > Diffs > - > > CMakeLists.txt 312f42f > kioslave/trash/CMakeLists.txt ddf0ae0 > kioslave/trash/tests/CMakeLists.txt 651f25d > kioslave/trash/trashthroughanalyzer.cpp df0eb87 > > Diff: https://git.reviewboard.kde.org/r/115371/diff/ > > > Testing > --- > > Builds. > > > Thanks, > > Hrvoje Senjan > >
Re: Review Request 115371: Remove strigi usages from kde-runtime
> On Jan. 29, 2014, 10:45 p.m., Vishesh Handa wrote: > > If you're removing it from the CMakeLists then please remove the > > kde-runtime/kioslave/trash/trashthroughanalyzer.* files as well. > > > > You may want to grep through kde-runtime for all uses of strigi. (Ignore > > the nepomuk ones, that's just an old variable name) >If you're removing it from the CMakeLists then please remove the >kde-runtime/kioslave/trash/trashthroughanalyzer.* files as well. Already done in the patch ;-) >You may want to grep through kde-runtime for all uses of strigi. Nothing else was using it =) - Hrvoje --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115371/#review48573 --- On Jan. 28, 2014, 11:04 p.m., Hrvoje Senjan wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115371/ > --- > > (Updated Jan. 28, 2014, 11:04 p.m.) > > > Review request for KDE Runtime and Vishesh Handa. > > > Repository: kde-runtime > > > Description > --- > > Strigi is used only for trashanalyzer, which isn't installed since 2007 ;-) > so i removed it also. > > > Diffs > - > > CMakeLists.txt 312f42f > kioslave/trash/CMakeLists.txt ddf0ae0 > kioslave/trash/tests/CMakeLists.txt 651f25d > kioslave/trash/trashthroughanalyzer.cpp df0eb87 > > Diff: https://git.reviewboard.kde.org/r/115371/diff/ > > > Testing > --- > > Builds. > > > Thanks, > > Hrvoje Senjan > >
Re: Review Request 115371: Remove strigi usages from kde-runtime
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115371/#review48578 --- Ship it! Ship It! - Vishesh Handa On Jan. 28, 2014, 11:04 p.m., Hrvoje Senjan wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115371/ > --- > > (Updated Jan. 28, 2014, 11:04 p.m.) > > > Review request for KDE Runtime and Vishesh Handa. > > > Repository: kde-runtime > > > Description > --- > > Strigi is used only for trashanalyzer, which isn't installed since 2007 ;-) > so i removed it also. > > > Diffs > - > > CMakeLists.txt 312f42f > kioslave/trash/CMakeLists.txt ddf0ae0 > kioslave/trash/tests/CMakeLists.txt 651f25d > kioslave/trash/trashthroughanalyzer.cpp df0eb87 > > Diff: https://git.reviewboard.kde.org/r/115371/diff/ > > > Testing > --- > > Builds. > > > Thanks, > > Hrvoje Senjan > >
Re: Review Request 115371: Remove strigi usages from kde-runtime
> On Jan. 29, 2014, 10:45 p.m., Vishesh Handa wrote: > > If you're removing it from the CMakeLists then please remove the > > kde-runtime/kioslave/trash/trashthroughanalyzer.* files as well. > > > > You may want to grep through kde-runtime for all uses of strigi. (Ignore > > the nepomuk ones, that's just an old variable name) > > Hrvoje Senjan wrote: > >If you're removing it from the CMakeLists then please remove the > kde-runtime/kioslave/trash/trashthroughanalyzer.* files as well. > Already done in the patch ;-) > > >You may want to grep through kde-runtime for all uses of strigi. > Nothing else was using it =) Sorry. I'm blind :) Ship it! - Vishesh --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115371/#review48573 --- On Jan. 28, 2014, 11:04 p.m., Hrvoje Senjan wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115371/ > --- > > (Updated Jan. 28, 2014, 11:04 p.m.) > > > Review request for KDE Runtime and Vishesh Handa. > > > Repository: kde-runtime > > > Description > --- > > Strigi is used only for trashanalyzer, which isn't installed since 2007 ;-) > so i removed it also. > > > Diffs > - > > CMakeLists.txt 312f42f > kioslave/trash/CMakeLists.txt ddf0ae0 > kioslave/trash/tests/CMakeLists.txt 651f25d > kioslave/trash/trashthroughanalyzer.cpp df0eb87 > > Diff: https://git.reviewboard.kde.org/r/115371/diff/ > > > Testing > --- > > Builds. > > > Thanks, > > Hrvoje Senjan > >
Re: Review Request 115371: Remove strigi usages from kde-runtime
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115371/ --- (Updated Jan. 29, 2014, 11:35 p.m.) Status -- This change has been marked as submitted. Review request for KDE Runtime and Vishesh Handa. Repository: kde-runtime Description --- Strigi is used only for trashanalyzer, which isn't installed since 2007 ;-) so i removed it also. Diffs - CMakeLists.txt 312f42f kioslave/trash/CMakeLists.txt ddf0ae0 kioslave/trash/tests/CMakeLists.txt 651f25d kioslave/trash/trashthroughanalyzer.cpp df0eb87 Diff: https://git.reviewboard.kde.org/r/115371/diff/ Testing --- Builds. Thanks, Hrvoje Senjan
Re: Review Request 115371: Remove strigi usages from kde-runtime
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115371/#review48582 --- This review has been submitted with commit 6cd3063bd5b60420228d7dbd9935060c68eb491c by Hrvoje Senjan to branch master. - Commit Hook On Jan. 28, 2014, 11:04 p.m., Hrvoje Senjan wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/115371/ > --- > > (Updated Jan. 28, 2014, 11:04 p.m.) > > > Review request for KDE Runtime and Vishesh Handa. > > > Repository: kde-runtime > > > Description > --- > > Strigi is used only for trashanalyzer, which isn't installed since 2007 ;-) > so i removed it also. > > > Diffs > - > > CMakeLists.txt 312f42f > kioslave/trash/CMakeLists.txt ddf0ae0 > kioslave/trash/tests/CMakeLists.txt 651f25d > kioslave/trash/trashthroughanalyzer.cpp df0eb87 > > Diff: https://git.reviewboard.kde.org/r/115371/diff/ > > > Testing > --- > > Builds. > > > Thanks, > > Hrvoje Senjan > >
Re: kqmlgraphplugin -- a QML plugin to render beautiful and interactive graphs
El Dimecres, 29 de gener de 2014, a les 08:55:01, Sebastian Gottfried va escriure: > 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? kqtquickcharts? Cheers, Albert > > 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
El Dimecres, 29 de gener de 2014, a les 09:03:17, Sebastian Gottfried va escriure: > Hi, > > > > 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? > > > > Good, question, at this stage i'd either put it inside the kde-edu > > "virtual > > module" and get it released if with 4.13 and on or put it in > > extragear-libs > > and you care of releasing it yourself. > > I think releasing it with kde-edu with 4.13 is the best solution for me. If > possible I would prefer this way. Works for me. > What steps need to be taken to achieve this strategy? Move to review, warn the edu guys, get reviewed, done. Cheers, Albert > > > > 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. > > > > Makes sense to me, you probably want to discuss that in the frameworks > > mailing list. > > Okay. > > Best regards
