Re: Review Request 113139: Try to export include targets for Plasma as well
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113139/#review41324
---
Which kde-workspace branch should I use to test this?
src/plasma/CMakeLists.txt
http://git.reviewboard.kde.org/r/113139/#comment30269
The if-else shouldn't be needed. INSTALL_INTERFACE should already check if
${INCLUDE_INSTALL_DIR} is absolute.
- Stephen Kelly
On Oct. 7, 2013, 8:13 a.m., Ben Cooksley wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113139/
---
(Updated Oct. 7, 2013, 8:13 a.m.)
Review request for kdelibs, Plasma and Stephen Kelly.
Repository: plasma-framework
Description
---
Add include targets for KF5::plasma, which will hopefully contribute towards
fixing the kde-workspace[master] build on build.kde.org.
Unfortunately it isn't entirely successful as it seems camelcase headers are
installed by KF5::plasma into include/KDE/Plasma/ but it should be a start...
Diffs
-
src/plasma/CMakeLists.txt b21fd7b
Diff: http://git.reviewboard.kde.org/r/113139/diff/
Testing
---
In place on CI build system. Proper include path now given to compiler.
Thanks,
Ben Cooksley
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 113139: Try to export include targets for Plasma as well
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113139/#review41331 --- Ship it! Unfortunately it isn't entirely successful as it seems camelcase headers are installed by KF5::plasma into include/KDE/Plasma/ Odd. I tried to add this dir, but seem to have hit a bug I'll look into. Patch looks good for now I think, thanks! - Stephen Kelly On Oct. 7, 2013, 8:13 a.m., Ben Cooksley wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113139/ --- (Updated Oct. 7, 2013, 8:13 a.m.) Review request for kdelibs, Plasma and Stephen Kelly. Repository: plasma-framework Description --- Add include targets for KF5::plasma, which will hopefully contribute towards fixing the kde-workspace[master] build on build.kde.org. Unfortunately it isn't entirely successful as it seems camelcase headers are installed by KF5::plasma into include/KDE/Plasma/ but it should be a start... Diffs - src/plasma/CMakeLists.txt b21fd7b Diff: http://git.reviewboard.kde.org/r/113139/diff/ Testing --- In place on CI build system. Proper include path now given to compiler. Thanks, Ben Cooksley ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request 113139: Try to export include targets for Plasma as well
On Oct. 7, 2013, 9:35 a.m., Stephen Kelly wrote:
src/plasma/CMakeLists.txt, line 173
http://git.reviewboard.kde.org/r/113139/diff/1/?file=199605#file199605line173
The if-else shouldn't be needed. INSTALL_INTERFACE should already check
if ${INCLUDE_INSTALL_DIR} is absolute.
Ben Cooksley wrote:
I copied this code from KCoreAddons in kdelibs[frameworks]. Shall I
correct it there as well?
It appears in several other frameworks too. Actually your snippet is needed
until CMake 2.8.12. I'll remove it from them all when kde requires that version.
- Stephen
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113139/#review41324
---
On Oct. 7, 2013, 10:48 a.m., Ben Cooksley wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113139/
---
(Updated Oct. 7, 2013, 10:48 a.m.)
Review request for kdelibs, Plasma and Stephen Kelly.
Repository: plasma-framework
Description
---
Add include targets for KF5::plasma, which will hopefully contribute towards
fixing the kde-workspace[master] build on build.kde.org.
Unfortunately it isn't entirely successful as it seems camelcase headers are
installed by KF5::plasma into include/KDE/Plasma/ but it should be a start...
Diffs
-
src/plasma/CMakeLists.txt b21fd7b
Diff: http://git.reviewboard.kde.org/r/113139/diff/
Testing
---
In place on CI build system. Proper include path now given to compiler.
Thanks,
Ben Cooksley
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
Sebastian Kügler wrote: CMake-gods, can you confirm the below? (It's inconsistent with my understanding, and how we've done it in the past months, I'd like to have a specialist opinion before going around and changing every single CMakeLists.txt in Plasma.) Running git log -S KI18n_LIBRARIES shows that I made a mistake and redefined the variable. Fixed now. Thanks, Steve. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: repository changes for plasma2/frameworks5
Marco Martin wrote: Most important, what is the less messy git way to do it? As we discussed on IRC, it may be better to split plasma out into its own repo now already, like we did with nepomuk. As the frameworks branch has a 'use-by' date, I'd prefer not to import more things into it from kde-runtime. Thanks, Steve. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Workflow Idea for 4.10
Alexander Neundorf wrote: On Friday 16 March 2012, Kevin Ottens wrote: Hello, On Wednesday 14 March 2012 14:38:19 Aaron J. Seigo wrote: [...] this is what really piques my interest: merge based workflow. an integration branch would be fantastic. that branch should rebase periodically off of master and only be used to merge feature branches. this branch would largely take the place of current master: where development happens. feature branches should be merged into integration on a regular basis and developers and testers should track this integration branch in their day-to-day usage integration should always be open to feature branch merging. master should only be open for feature merge when not in freeze, however. when in freeze, either a stabilization branch could be made off of master for this purpose (probably a very good idea for larger fixes) which is then merged down in master at known good points .. or .. master is opened for bug fixes directly in those periods. the latter is probably not as good from a stability POV, but may be more reasonable and less of a workload for people doing the actual work. so what i'm interested in hearing is what sort of branch management scheme would work for people. i'm happy to maintain either an integration or the master branch (but not both). [...] note that the methods being (slowly) adopted for frameworks devel are also moving in the direction noted above. I'd just like to add my 0.02€ here. I've been thinking about the git workflow to be used in KDE Frameworks in the future. Based on observations and discussions with current and future frameworks maintainer, I think that it would be a mistake to force a single workflow for all the frameworks. I'm not 100% sure what the final solution will be but it's likely to end up being a short list of blessed workflows: 1) Full game, one branch per feature with review time in an integration/testing branch before hitting master; 2) Intermediate, one branch per feature with merge in master after reviewers/maintainer validation; 3) Easy, features directly developped in master[1]. Sounds good. But OTOH, having one workflow for KDE frameworks (i.e. not even all of KDE SC) would be also a really good thing to have. It will make contributing easier. Would 2) be an option for KDE frameworks ? :/ Am I the only person who values browsable history? Repositories where you can run gitk and see something useful. What Aaron proposed is exactly what CMake does. The result is that if you run gitk, you can't see the actual patches. If you run gitk --first-parent on master you *only* see merges, so the only information you can see is the name of the branch that got merged (which is in the git commit message), not the actual patch, and to see the patches in a topic you have to know the name of the topic. You can't just browse the commits, so you can't practically do post-commit review with gitk, as I do. Using email for that really doesn't work for me for one thing. If I want to look at commits that I vaguely know exist but I don't know which topic branch it came from, I should be able to browse fot that. I have the git repo in front of me, so I should be able to use it without jumping through too many hoops. We're going to have small repos after splitting, not large ones. Having a branch and a merge per patch commit in small repos is way overkill. Let's have readable history instead please. My vote is for 3 (for frameworks in general at least), and if people want to create branches like the actions or colors ones we currently have, lets do that in scratch or personal repos. They can be rebased/squashed to readable patches when the learning about how to create a framework by a contributor is done (that's not useful history). The actions branch should all be squashed into one commit because originally the contributor didn't realize the steps that are needed to make a split (move the files, update some include_directories, give the new framework a name which doesn't have kdeui in it, rename the deprecated and export macros). Currently none of those commits actually build because they don't do all of the necessary steps and even the tip of the branch isn't complete because the export macros haven't been changed. Once the branch is fixed to build, I will squash and rebase it to origin/frameworks to commit. The colors branch also contains lots of commits with typos, fixes for typos, adding missing files, removing stuff from CMake files which should have been removed in previous commits, etc, so I will also fix/squash/rebase that one when it's ready, but likely into more commits. Note that I say I'll do the rebase. I'm not expecting anyone else to have to know how to do it. (In CMake, despite using a new branch for everything they do sometimes request rebases to that the commits are clean). I think people think that if
Plasma does not build without kdepimlibs
Hi, 9edc8d34b3b0f9983f0eb014f8fbf4bcfcffc3f1 introduced a dependency in plasma on kdepimlibs for gpgme++. The cmake check in kdelibs for kdepimlibs claims it is optional, but the build fails later. The stuff that uses gpgme++ should be compiled conditionally based on whether kdepimlibs was found. Thanks, Steve. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QtQuick 2.0?
FYI QtQuick 2 will not be compatible with QtQuick 1.x. Something to keep in mind, that there may be a migration step. context: http://thread.gmane.org/gmane.comp.lib.qt.qml/2499 Alan Alpert wrote: On Wed, 4 May 2011 03:39:22 ext Jason H wrote: I thought with modularization, that what is in qt 4.8 should matter less and less. For instance, there is a QML2 plugin that will work with QML1 http://labs.qt.nokia.com/2011/05/03/qml-shadereffectitem-on- qgraphicsview/ If everything except the core is a plug in, then what is in 4.8 should be less relevant. That plugin is a QML1 plugin designed to emulate a QML2 element. As far as I'm aware, it is a completely different element (C++-wise). But it does aim for QML source compatibility, like the QML2 elements designed to act like the QML1 elements we all know and love. Modularization doesn't do anything to solve this problem, alas, as QtQuick 1 and QtQuick 2 will still be incompatible. Plugins may contain just QML1 or QML2 items, and while they can contain both it is likely that you'd have to implement each one semi-separately in C++. So this is not the most graceful version bump. On the plus side, it's still a ways away (still a 'research' stage project and so not tied to any release). I don't know when 4.8 is being released, so I can't say it won't end up in 4.8, but right now it's not in any release. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: QtQuick 2.0?
FYI QtQuick 2 will not be compatible with QtQuick 1.x. Something to keep in mind, that there may be a migration step. context: http://thread.gmane.org/gmane.comp.lib.qt.qml/2499 Alan Alpert wrote: On Wed, 4 May 2011 03:39:22 ext Jason H wrote: I thought with modularization, that what is in qt 4.8 should matter less and less. For instance, there is a QML2 plugin that will work with QML1 http://labs.qt.nokia.com/2011/05/03/qml-shadereffectitem-on- qgraphicsview/ If everything except the core is a plug in, then what is in 4.8 should be less relevant. That plugin is a QML1 plugin designed to emulate a QML2 element. As far as I'm aware, it is a completely different element (C++-wise). But it does aim for QML source compatibility, like the QML2 elements designed to act like the QML1 elements we all know and love. Modularization doesn't do anything to solve this problem, alas, as QtQuick 1 and QtQuick 2 will still be incompatible. Plugins may contain just QML1 or QML2 items, and while they can contain both it is likely that you'd have to implement each one semi-separately in C++. So this is not the most graceful version bump. On the plus side, it's still a ways away (still a 'research' stage project and so not tied to any release). I don't know when 4.8 is being released, so I can't say it won't end up in 4.8, but right now it's not in any release. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Notes widget: Working bold/italic/underline/strike out even when the note text is empty
On 2010-11-30 01:04:03, Davide Bettio wrote: Should we apply this patch while waiting someone who fix this bug in Qt? Aaron Seigo wrote: sure (if only because the bug has been closed as out of scope), but annotate the code with a comment explaining the situation and a link to the bug report on the qt bug tracker. Just for clarity, I think it's similar to the bug I filed with Qt before, but maybe not the same. I think you should file a new Qt bug and link to that. - Stephen --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6005/#review9050 --- On 2010-11-28 20:23:45, Davide Bettio wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6005/ --- (Updated 2010-11-28 20:23:45) Review request for Plasma and Stephen Kelly. Summary --- Text format of the note can't be changed while the note is empty, so I add a space and I change the text format. This work around is rather stupid but I don't have any nicer idea. Anyway this might be a bug in KRichTextEdit so I add to this review request also steveire. Diffs - trunk/KDE/kdeplasma-addons/applets/notes/notes.h 1201054 trunk/KDE/kdeplasma-addons/applets/notes/notes.cpp 1201054 Diff: http://svn.reviewboard.kde.org/r/6005/diff Testing --- Thanks, Davide ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Notes widget: Working bold/italic/underline/strike out even when the note text is empty
On 2010-11-30 01:04:03, Davide Bettio wrote: Should we apply this patch while waiting someone who fix this bug in Qt? Aaron Seigo wrote: sure (if only because the bug has been closed as out of scope), but annotate the code with a comment explaining the situation and a link to the bug report on the qt bug tracker. Stephen Kelly wrote: Just for clarity, I think it's similar to the bug I filed with Qt before, but maybe not the same. I think you should file a new Qt bug and link to that. Anne-Marie Mahfouf wrote: Stephen did you investigate further? I can't reproduce on a test case i.e. if I have an empty QTextEdit and set bold then the first char is bold. Same if I use the example TextEdit and click NEw and set Bold then the first char is bold. Is there a reason why you point to Qt and can you explain it so I can make a test case? Nope I didn't investigate further yet. I pointed to Qt because of of previous bugs, and because of something similar a kopete developer asked me about QTextDocument before. If you can't create a test case I may be wrong. Do we have a KRichTextEdit based test case? I'm currently rebuilding my development environment, so I probably won't have a chance until tomorrow. - Stephen --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6005/#review9050 --- On 2010-11-28 20:23:45, Davide Bettio wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6005/ --- (Updated 2010-11-28 20:23:45) Review request for Plasma and Stephen Kelly. Summary --- Text format of the note can't be changed while the note is empty, so I add a space and I change the text format. This work around is rather stupid but I don't have any nicer idea. Anyway this might be a bug in KRichTextEdit so I add to this review request also steveire. Diffs - trunk/KDE/kdeplasma-addons/applets/notes/notes.h 1201054 trunk/KDE/kdeplasma-addons/applets/notes/notes.cpp 1201054 Diff: http://svn.reviewboard.kde.org/r/6005/diff Testing --- Thanks, Davide ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Notes widget: Working bold/italic/underline/strike out even when the note text is empty
--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6005/#review9041 --- More likely a Qt Bug. Seems similar to this one which I filed a few years ago and which seems to be out of scope now: http://bugreports.qt.nokia.com/browse/QTBUG-1474 I don't have any opinion on the patch. I suggest you create a Qt only test case and file a bug in Qt. - Stephen On 2010-11-28 20:23:45, Davide Bettio wrote: --- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6005/ --- (Updated 2010-11-28 20:23:45) Review request for Plasma and Stephen Kelly. Summary --- Text format of the note can't be changed while the note is empty, so I add a space and I change the text format. This work around is rather stupid but I don't have any nicer idea. Anyway this might be a bug in KRichTextEdit so I add to this review request also steveire. Diffs - trunk/KDE/kdeplasma-addons/applets/notes/notes.h 1201054 trunk/KDE/kdeplasma-addons/applets/notes/notes.cpp 1201054 Diff: http://svn.reviewboard.kde.org/r/6005/diff Testing --- Thanks, Davide ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: How to get Akonadi notes onto Plasma?
Aaron J. Seigo wrote: On October 30, 2009, Stephen Kelly wrote: would prefer to only show the actual notes in the stack on click so they could be dragged elsewhere. Obviously the background svg of it should not be as it is, or the size it currently is. Additionally I need to give some visual indication of colour in the notes, either the notes themselves being a different colour, or having a strip of a colour that can be set etc. these are all doable; i just wonder if it's the best we can do for a UI. i'm not getting any inspired thoughts right now (too early in the day still, i think :) but maybe if i think on it or if someone else comes up with a great idea we could device a nicer more plasma approach to showing stacks of notes. Would having one master applet and each note as a satellite applet work? it would probably fail in some situations or just be more difficult than necessary to get working properly. when the notes are separated by the user into individual pieces, they should probably just become individual applets. So could a combined approach work? When new notes are inserted elsewhere and should be represented in plasma too, could it be put into an extender, and then if the extender is dragged out it becomes another plasma applet? Would it then be possible to drag a detached note back to the stack and into an extender? I'm going to take an idea from Thomas Olsens mail and try to make notes always collapsed in the stack, with the first part of the content in a tooltip. I'm also going to try to make it so that the extender is only shown on click even when on the workspace as is true of the clock/calculator. Hopefully it won't be too much work to change it if a combined approach would work better. Then I'll have to see about custom painting the extenderitems to give them a specific color. I need to get a working prototype of the above together for a few weeks from now. If anyone can give me pointers about it, please do let me know. I might be reading it wrong, but I seem to be getting advice to go in many different directions from many different people. All the best, Steve. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: How to get Akonadi notes onto Plasma?
Marco Martin wrote: On Monday 02 November 2009, Stephen Kelly wrote: Aaron J. Seigo wrote: On October 30, 2009, Stephen Kelly wrote: would prefer to only show the actual notes in the stack on click so they could be dragged elsewhere. Obviously the background svg of it should not be as it is, or the size it currently is. Additionally I need to give some visual indication of colour in the notes, either the notes themselves being a different colour, or having a strip of a colour that can be set etc. these are all doable; i just wonder if it's the best we can do for a UI. i'm not getting any inspired thoughts right now (too early in the day still, i think :) but maybe if i think on it or if someone else comes up with a great idea we could device a nicer more plasma approach to showing stacks of notes. Would having one master applet and each note as a satellite applet work? it would probably fail in some situations or just be more difficult than necessary to get working properly. when the notes are separated by the user into individual pieces, they should probably just become individual applets. So could a combined approach work? When new notes are inserted elsewhere and should be represented in plasma too, could it be put into an extender, and then if the extender is dragged out it becomes another plasma applet? Would it then be possible to drag a detached note back to the stack and into an extender? i think no point in making them extenders if they are going to be full applets once detached. best idea is probably the one rfom sebas, making the notes applet there is now to manage akonadi urls drop, so in that case would be connected to akonadi and save there there would be another applet that would show a simple list view of the notes text where is possible to drag notes out (same thing should be possible also from kjots to look really killer) Yeah, that sounds pretty good. This is the kind of thing I meant when I wrote about a master applet with satellites applets, which Aaron wrote would fail in some situations. I'm not certain if this is what he meant, but some issues that I see are: * Can the master applet or list applet know when a note it is listing is dropped onto the workspace and should not be shown in the list anymore. * Can the master applet know when a note applet was closed/dismissed and should be shown in the list again. * Can the master applet notify the note if it gets deleted in akonadi. (in the kjots application for example). There is another solution for this one in akonadi if not. * Would it be possible to drag one of the note applets back into the master applet? However, reading it again, this: when the notes are separated by the user into individual pieces, they should probably just become individual applets. looks like you, he and I are talking about the same thing. It might have been a misunderstanding about what I meant by master widget with satellites. I meant one widget to hold those notes in a list which are not otherwise on the canvas, and individual notes, one for each widget which has been dragged out. Are we talking about the same thing? Steve. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: How to get Akonadi notes onto Plasma?
Sebastian Kügler wrote: On Monday 02 November 2009 15:08:31 Stephen Kelly wrote: Marco Martin wrote: Yeah, that sounds pretty good. This is the kind of thing I meant when I wrote about a master applet with satellites applets, which Aaron wrote would fail in some situations. I'm not certain if this is what he meant, but some issues that I see are: * Can the master applet or list applet know when a note it is listing is dropped onto the workspace and should not be shown in the list anymore. Are you sure you want this behaviour? I'd just keep the list complete and not move around notes, but pass references to notes and just create additional views. (I also don't like kmail's behaviour which removes emails from the listview that you open, makes it really hard to find something when you have 10 email windows open). Well, yes that's a good point. Maybe it would make sense to not remove them when dragged, but just to create a reference. That would make it possible to have the same note on the workspace/containment twice. Is that desired behaviour? I can't think of any technical blocks to that, so that's more just a UX question. * Can the master applet know when a note applet was closed/dismissed and should be shown in the list again. * Can the master applet notify the note if it gets deleted in akonadi. (in the kjots application for example). There is another solution for this one in akonadi if not. You can do that using the item, no? Yes, I can create an Akonadi::ItemMonitor for each dropped note on the workspace which will tell me when the note gets updated/deleted. * Would it be possible to drag one of the note applets back into the master applet? Yes, just implement the dropevent. A non issue though really if notes do not get removed from the list on drag. All the user would have to do is close/dismiss the note applet. However, reading it again, this: when the notes are separated by the user into individual pieces, they should probably just become individual applets. looks like you, he and I are talking about the same thing. It might have been a misunderstanding about what I meant by master widget with satellites. I meant one widget to hold those notes in a list which are not otherwise on the canvas, and individual notes, one for each widget which has been dragged out. Are we talking about the same thing? Yep :) Cool, well I'll look into this more in that case. By the way, There's now a discussion on kde-pim@ about the more long term plan for notes I mentioned before which you may find interesting: http://markmail.org/thread/s5obkiwql5bvyr66 All the best, Steve. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: How to get Akonadi notes onto Plasma?
Stephen Kelly wrote: i think in this case, maybe start with the intended user experience. i'm not sure what you are actually envisioning for the user experience. e.g.: should notes appear automatically on your desktop / panel when they appear in Akonadi, so if i add a note in Kontact it would appear somewhere on my desktop as well? I think so, yes. At least, new notes should easily be able to appear on the desktop. After discussing it on IRC, I think what I'll try is this: There is one plasma akonadi notes widget. It is like a stack of real world post-it sticky notes. Actual notes containing data are extender items, which can be moved around the workspace. If a new note is added in kontact, a new extender item is added to the master widget. No notification is given about that happening. The user can then open the extender to access the new note and drag it anywhere. That way new notes do not appear in random positions on the workspace, as someone suggested would be a bad idea. I have some start on this and made a video here: http://officespace.kdab.net/~stephen/notes_plasma.ogv I was having a lot of trouble with Xephyr-my keyboard, but you get the idea. The good part is that I can create a plasmoid which shows a particular collection of notes. Updating, removing and inserting notes is instantly propagated. Notes can be dragged from the stack of notes onto the workspace. The bad part is that I have 0 knowledge of how to make it look right. I would prefer to only show the actual notes in the stack on click so they could be dragged elsewhere. Obviously the background svg of it should not be as it is, or the size it currently is. Additionally I need to give some visual indication of colour in the notes, either the notes themselves being a different colour, or having a strip of a colour that can be set etc. Currently the stuff is implemented as extenders so that the applet is able to create/destroy/update them. If the above appearance stuff is not possible with extenders, then I may have to go with a different approach. Would having one master applet and each note as a satellite applet work? Aaron does this clarify any of your previous questions? All the best, Steve. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: How to get Akonadi notes onto Plasma?
Hi, busy day. Aaron J. Seigo wrote: On October 22, 2009, Stephen Kelly wrote: In Akonadi I just create an EntityTreeModel which has api for all of that stuff. If I can forward those calls to plasma somehow, that would be good, but I need a starting point. Do I create my model in a Applet, or a Data Engine etc? you're actually asking two different sets of questions here: * how do you get to the data * how do you display the data OK. i think in this case, maybe start with the intended user experience. i'm not sure what you are actually envisioning for the user experience. e.g.: should notes appear automatically on your desktop / panel when they appear in Akonadi, so if i add a note in Kontact it would appear somewhere on my desktop as well? I think so, yes. At least, new notes should easily be able to appear on the desktop. After discussing it on IRC, I think what I'll try is this: There is one plasma akonadi notes widget. It is like a stack of real world post-it sticky notes. Actual notes containing data are extender items, which can be moved around the workspace. If a new note is added in kontact, a new extender item is added to the master widget. No notification is given about that happening. The user can then open the extender to access the new note and drag it anywhere. That way new notes do not appear in random positions on the workspace, as someone suggested would be a bad idea. should notes be individual widgets, or should they be grouped? Hopefully the above answers this. I'm not certain, as I've also seen extendergroups in the plasma api. I don't think that's what you mean though. should only notes created by the user in plasma-desktop be shown on plasma- desktop? or only notes tagged in some way? The idea is that notes from a particular collection in akonadi would be available. Possibly with different master applets in different activities. The user would be able to select a particular collection whose notes should be displayed. This could be a virtual collection showing only notes tagged with akonadi development or notes I created in July containing the word 'giraffe'. is this meant to be replacement / augmentation for the current notes plasmoid, or something quite different? The short term plan (within the next few days) is to get a demo together with some stuff hardcoded if necessary to show that I can get notes on the desktop where their data comes from akonadi. In a few weeks I have to have a more functional prototype together with a couple of extra features. Long term view is replace/augment the current notes plasmoid, and also try to do more data sharing with other note taking solutions on KDE. Right now though, my priority is a demo by the middle of next week :) Any more thoughts on the plan and intentions above? All the best, Steve. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
How to get Akonadi notes onto Plasma?
Hi, I'm trying to get notes from Akonadi onto a plasma workspace. I've been reading some of the apidocs and I can't figure out if I need a data engine, whether I need one Plasma::Applet per note, whether I need a 'manager' plasmoid that manages all others, keeping them up to date, and adding/removing etc. In Akonadi I just create an EntityTreeModel which has api for all of that stuff. If I can forward those calls to plasma somehow, that would be good, but I need a starting point. Do I create my model in a Applet, or a Data Engine etc? Also, if that's completely the wrong track, please set me straight. All the best, Steve. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 4.2: the binary compatible release
Aaron J. Seigo wrote: for those wondering what binary compat means for us, in a nutshell: * we can't add new members to the public classes (the dptr makes that unecessary in the first place, of course =) Are you sure about this one? Techbase says you can: http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++#The_Do.27s_and_Don.27ts You can add new non-virtual functions including signals and slots and constructors. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 4.2: the binary compatible release
Aaron J. Seigo wrote: yes, functions or methods. not data members (which i usually shortcut to just members, versus methods ... probably what caused confusion; sorry.) You're right. I read methods instead of members. Sorry for the noise. Steve. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
KJots on Plasma
Hi, One of the things I wanted to do in the KDE 4.2 timeframe for KJots was to make a plasmoid for it. As time is running fast, I'm going to cheat and ask people who are already familiar with plasma for help on how it could work. For those who have never seen/used KJots, it is a simple note taking application in which pages are arranged in a heirarchy of books and sub-books. It's in the kdepim module if you want to try it out. Pradeepto B has already been working on putting an icon in the system tray for kjots, but I'd prefer a plasmoid. The idea would be that the plasmoid would display either all of your kjots notes, or only a particular kjots book, or notes tagged with a particular tag (if I get that to work: http://thread.gmane.org/gmane.comp.kde.nepomuk/147). The plasmoid would probably work the same way as the standalone application in terms of editing and viewing, but would not have user interface for export, or searching etc (which would be available only when running the application). Syncronization: KJots has been a KUniqueApplication since before I started working on it. This is presumably so that two running KJots instances can not have out of sync edits to the same page. However if pages can be edited in a plasmoid, that would be possible. I *think* that if I write an akonadi resource for kjots, akonadi would keep all views on the data up to date ( http://thread.gmane.org/gmane.comp.kde.devel.pim/22743). If someone else is more familiar with this kind of thing and whether akonadi is needed at all, please let me know. Using existing code: There is already a KJotsComponent which is a QWidget contains all the functionality in kjots. It is used by the standalone application and by the kpart which gets loaded in kontact. I think I read that plasma can use QWidgets directly because of QGraphicsView(?). Does that mean that I can simply put that widget into a plasmoid and I'll be finished? Thanks for any help, and if there's any other issues that I haven't mentioned here, please let me know. Steve. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: KJots on Plasma
Aaron J. Seigo wrote:
On Thursday 25 September 2008, Stephen Kelly wrote:
The idea would be that the plasmoid would display either all of your
kjots notes, or only a particular kjots book, or notes tagged with a
particular
cool!
(i actually maintined kjots in kde3 and gave it its current
tree-on-the-left- content-on-the-right interface with things like full
book overview, etc .. Jaison took it further with the start of rich text
editting and the initial kde4 port .. so cool to see this app continue on!
it got its start in kde1 .. yes *ONE*.. =)
Yep, 11 years: http://websvn.kde.org/?view=revrevision=155 That's probably
before 1.0.
Syncronization:
KJots has been a KUniqueApplication since before I started working on it.
This is presumably so that two running KJots instances can not have out
of sync edits to the same page.
yes, that's correct.
However if pages can be edited in a plasmoid,
that would be possible. I *think* that if I write an akonadi resource for
kjots, akonadi would keep all views on the data up to date (
http://thread.gmane.org/gmane.comp.kde.devel.pim/22743). If someone else
is more familiar with this kind of thing and whether akonadi is needed at
all, please let me know.
that'd be a question for the pimsters.. i *think* the answer is yes,
that's correct but they'd know better than me =)
Seems to be it exactly. I asked about the case where you have two plasmoids
displaying the same page for edit, and you drag text from one to the other.
steveire Does akonadi take care of a case where I have two plasmoids
displaying the same page for edit, and I drag text from one to the other?
till steveire: if you use the models in both plasmoids, yes, but I guess
the data bakcends for the plasmoid need to handle it too
Using existing code:
There is already a KJotsComponent which is a QWidget contains all the
functionality in kjots. It is used by the standalone application and by
the kpart which gets loaded in kontact. I think I read that plasma can
use QWidgets directly because of QGraphicsView(?). Does that mean that I
can simply put that widget into a plasmoid and I'll be finished?
yes, that's about it; i'd recommend using a Plasm::PopupApplet, so when it
is in the panel you'll get a button to click on that will show the content
in a popup.
I tried putting the KJotsComponent into a plasmoid. I got it to compile, but
I didn't get it to work. I just get a black box when I try to load it with
plasmoidviewer.
It might just be that that component is not suitable to be used in this way.
I could possibly use the plasma widgets if that's the case. I've attached
my attempt in case I've done anything obviously wrong.
Cheers,
Steve.
Index: kjots-plasmoid.h
===
--- kjots-plasmoid.h (revision 0)
+++ kjots-plasmoid.h (revision 0)
@@ -0,0 +1,33 @@
+// Here we avoid loading the header multiple times
+#ifndef KJOTSPLASMOID_H
+#define KJOTSPLASMOID_H
+// We need the Plasma Applet headers
+#include KIcon
+
+#include Plasma/PopupApplet
+#include Plasma/Svg
+
+
+class KJotsComponent;
+
+
+// Define our plasma Applet
+class KJotsPlasmoid : public Plasma::PopupApplet
+{
+Q_OBJECT
+public:
+// Basic Create/Destroy
+KJotsPlasmoid(QObject *parent, const QVariantList args);
+virtual ~KJotsPlasmoid();
+
+virtual QWidget *widget();
+
+private:
+KJotsComponent *c;
+QWidget *w;
+};
+
+// This is the command that links your applet to the .desktop file
+K_EXPORT_PLASMA_APPLET(kjots, KJotsPlasmoid)
+
+#endif
Index: CMakeLists.txt
===
--- CMakeLists.txt (revision 861669)
+++ CMakeLists.txt (working copy)
@@ -64,3 +64,49 @@
install( FILES kjotspartui.rc DESTINATION ${DATA_INSTALL_DIR}/kjots)
install(TARGETS kjotspart DESTINATION ${PLUGIN_INSTALL_DIR} )
+
+
+#
+# Plasmoid SECTION
+#
+
+find_package(Plasma REQUIRED)
+
+add_definitions (${QT_DEFINITIONS} ${KDE4_DEFINITIONS})
+include_directories(
+ ${CMAKE_SOURCE_DIR}
+ ${CMAKE_BINARY_DIR}
+ ${KDE4_INCLUDES}
+ )
+
+# We add our source code here
+set(kjots_plasmoid_SRCS
+kjots-plasmoid.cpp
+kjotsentry.cpp
+kjotsedit.cpp
+kjotsbookmarks.cpp
+bookshelf.cpp
+kjotscomponent.cpp
+kjotsreplacenextdialog.cpp
+kjotsbrowser.cpp
+kjotslinkdialog.cpp
+flatcollectionproxymodel.cpp
+kjotsbookshelfentryvalidator.cpp
+KJotsSettings.cpp
+)
+
+# Now make sure all files get to the right place
+kde4_add_plugin(plasma_applet_kjots ${kjots_plasmoid_SRCS})
+target_link_libraries(plasma_applet_kjots
+ ${PLASMA_LIBS}
+ ${KDE4_KDEUI_LIBS}
+ ${KDE4_KIO_LIBS}
+ )
+
+install(TARGETS plasma_applet_kjots
+DESTINATION
