Re: How to get Akonadi notes onto Plasma?
On Monday 02 November 2009, Stephen Kelly wrote: > 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. i think it should always be shown in the list if you follow this approach -- Marco Martin ___ 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?
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). > * 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? > * Would it be possible to drag one of the note applets back into the master > applet? Yes, just implement the dropevent. > 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 :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ 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?
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) not even sure if the listview applet should permit editing at all. another idea would be an applet that looks like the notes (perhapps that looks like a stack, another modality for the list view one?) one but has next/prev buttons and is possible to switch between them Cheers, Marco Martin ___ 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?
On 30/10-2009 19:10 "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. Just from the top of my head without thinking about how it should be implemented. (it's difficult for me to explain in English in any way :) I see a stack of notes - like a deck of cards - as the main widget. Each note is slightly askewed and has a tool tip showing it's title. You can drag a note out of the stack (deck) and put it elsewhere on the desktop and you can put a disconnected note back in the deck. You should also be able to somehow flip through all the notes. I think what I'm saying is basically what Stephen wrote. -- Best Regards / Med venlig hilsen Thomas Olsen ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: How to get Akonadi notes onto Plasma?
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. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 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: dropped URL handling in containment, was: Re: How to get Akonadi notes onto Plasma?
On Wednesday 28 October 2009 19:47:13 Aaron J. Seigo wrote: > On October 28, 2009, Sebastian Kügler wrote: > > On Wednesday 28 October 2009 16:39:41 Aaron J. Seigo wrote: > > > On October 27, 2009, Sebastian Kügler wrote: > > > > On Tuesday 27 October 2009 17:19:24 Aaron J. Seigo wrote: > > > > > On October 27, 2009, Sebastian Kügler wrote: > > > > > > Is this something I should pursue? It sounds simple enough ... > > > > > > > > > > sure; i don't see any downside to it and the results could be > > > > > interesting; worst case is we'd have a failed experimnt on our > > > > > hands and one more way not to do it (in the words of Edison ;) but > > > > > i think this could work out very well.. > > > > > > > > The attached patch seems to work. I've not really tested it, just > > > > confirmed that it works at least in one case (emailmessage, added > > > > X-Plasma-DropUrlPatterns=akonadi:* to its desktop file) -- it's late > > > > and I should sleep. If it's conceptually OK, I'll clean it up and > > > > submit it to review board. > > > > > > doing: > > > > > > KPluginInfo::List allApplets = KPluginInfo::fromServices(offers, "exist > > > [X- Plasma-DropUrlPatterns]") > > > > > > should eliminate all the entries that don't have any DropUrlPatterns > > > without having to create and then cycle through all the plasma > > > applets installed. > > > > Good, good. That part felt icky... > > > > > this shouldn't be needed: > > > > > > QHash dropPlugins; > > > > > > the URL can be retrieved in mimeTypeRetrieved with job->url() > > > > We the list of plugins (not the URL, I'm retrieving that from the job > > indeed) for the following case: > > > > - a URL is dropped > > - applets matching DropUrlPatterns are found > > - the TransferJob returns an error > > the same thing could be achieved by calling the method that fetches the > matching plugins in each place that needs it (including the error path) > rather than caching those values. that would mean calling it twice on > success, or twice on error or three times on error-that-isn't-an-error. > > it's not a hot path and finding the matching plasmoids shouldn't be very > slow at all. i'd prefer to keep the bookkeeping for drops simple as long > as it isn't a performance problem. I've removed the private member, and found that we can actually do with calling listAppletInfoForUrl() only once. We simply don't cop out on job->error() in dropResult() and call the slot anyway, the counting and stuff now happens only there, looks a bit cleaner as well. :) I've also changed the other bits, cleaned up a bit and sent it to reviewboard. Thanks for the feedback! -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: dropped URL handling in containment, was: Re: How to get Akonadi notes onto Plasma?
On October 28, 2009, Sebastian Kügler wrote: > On Wednesday 28 October 2009 16:39:41 Aaron J. Seigo wrote: > > On October 27, 2009, Sebastian Kügler wrote: > > > On Tuesday 27 October 2009 17:19:24 Aaron J. Seigo wrote: > > > > On October 27, 2009, Sebastian Kügler wrote: > > > > > Is this something I should pursue? It sounds simple enough ... > > > > > > > > sure; i don't see any downside to it and the results could be > > > > interesting; worst case is we'd have a failed experimnt on our hands > > > > and one more way not to do it (in the words of Edison ;) but i think > > > > this could work out very well.. > > > > > > The attached patch seems to work. I've not really tested it, just > > > confirmed that it works at least in one case (emailmessage, added > > > X-Plasma-DropUrlPatterns=akonadi:* to its desktop file) -- it's late > > > and I should sleep. If it's conceptually OK, I'll clean it up and > > > submit it to review board. > > > > doing: > > > > KPluginInfo::List allApplets = KPluginInfo::fromServices(offers, "exist > > [X- Plasma-DropUrlPatterns]") > > > > should eliminate all the entries that don't have any DropUrlPatterns > > without having to create and then cycle through all the plasma applets > > installed. > > Good, good. That part felt icky... > > > this shouldn't be needed: > > > > QHash dropPlugins; > > > > the URL can be retrieved in mimeTypeRetrieved with job->url() > > We the list of plugins (not the URL, I'm retrieving that from the job > indeed) for the following case: > > - a URL is dropped > - applets matching DropUrlPatterns are found > - the TransferJob returns an error the same thing could be achieved by calling the method that fetches the matching plugins in each place that needs it (including the error path) rather than caching those values. that would mean calling it twice on success, or twice on error or three times on error-that-isn't-an-error. it's not a hot path and finding the matching plasmoids shouldn't be very slow at all. i'd prefer to keep the bookkeeping for drops simple as long as it isn't a performance problem. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: dropped URL handling in containment, was: Re: How to get Akonadi notes onto Plasma?
On Wednesday 28 October 2009 16:39:41 Aaron J. Seigo wrote: > On October 27, 2009, Sebastian Kügler wrote: > > On Tuesday 27 October 2009 17:19:24 Aaron J. Seigo wrote: > > > On October 27, 2009, Sebastian Kügler wrote: > > > > Is this something I should pursue? It sounds simple enough ... > > > > > > sure; i don't see any downside to it and the results could be > > > interesting; worst case is we'd have a failed experimnt on our hands > > > and one more way not to do it (in the words of Edison ;) but i think > > > this could work out very well.. > > > > > > The attached patch seems to work. I've not really tested it, just > > confirmed that it works at least in one case (emailmessage, added > > X-Plasma-DropUrlPatterns=akonadi:* to its desktop file) -- it's late and > > I should sleep. If it's conceptually OK, I'll clean it up and submit it > > to review board. > > doing: > > KPluginInfo::List allApplets = KPluginInfo::fromServices(offers, "exist [X- > Plasma-DropUrlPatterns]") > > should eliminate all the entries that don't have any DropUrlPatterns > without having to create and then cycle through all the plasma applets > installed. Good, good. That part felt icky... > this shouldn't be needed: > > QHash dropPlugins; > > the URL can be retrieved in mimeTypeRetrieved with job->url() We the list of plugins (not the URL, I'm retrieving that from the job indeed) for the following case: - a URL is dropped - applets matching DropUrlPatterns are found - the TransferJob returns an error I Didn't make it up, this happens for the akonadi case if you don't have the KIO akonadi slave. My solution is to check first if we have DropUrlPattern matches and then only clean up without showing a menu if - no applets are there for this mimetype - no DropUrlPattern matches So in the mechanism, I think we really need it. The overhead should be negligible, since the memory is cleaned up after the popupmenu exits (note: forget that cleanup bit in the patch). Does it make sense now? > but in general it could be an interesting addition... I think so, too. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: dropped URL handling in containment, was: Re: How to get Akonadi notes onto Plasma?
On October 27, 2009, Sebastian Kügler wrote: > On Tuesday 27 October 2009 17:19:24 Aaron J. Seigo wrote: > > On October 27, 2009, Sebastian Kügler wrote: > > > Is this something I should pursue? It sounds simple enough ... > > > > sure; i don't see any downside to it and the results could be > > interesting; worst case is we'd have a failed experimnt on our hands and > > one more way not to do it (in the words of Edison ;) but i think this > > could work out very well.. > > The attached patch seems to work. I've not really tested it, just confirmed > that it works at least in one case (emailmessage, added > X-Plasma-DropUrlPatterns=akonadi:* to its desktop file) -- it's late and I > should sleep. If it's conceptually OK, I'll clean it up and submit it to > review board. doing: KPluginInfo::List allApplets = KPluginInfo::fromServices(offers, "exist [X- Plasma-DropUrlPatterns]") should eliminate all the entries that don't have any DropUrlPatterns without having to create and then cycle through *all* the plasma applets installed. this shouldn't be needed: QHash dropPlugins; the URL can be retrieved in mimeTypeRetrieved with job->url() but in general it could be an interesting addition... -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: dropped URL handling in containment, was: Re: How to get Akonadi notes onto Plasma?
On Tuesday 27 October 2009 17:19:24 Aaron J. Seigo wrote:
> On October 27, 2009, Sebastian Kügler wrote:
> > Is this something I should pursue? It sounds simple enough ...
>
> sure; i don't see any downside to it and the results could be interesting;
> worst case is we'd have a failed experimnt on our hands and one more way
> not to do it (in the words of Edison ;) but i think this could work out
> very well..
The attached patch seems to work. I've not really tested it, just confirmed
that it
works at least in one case (emailmessage, added
X-Plasma-DropUrlPatterns=akonadi:* to
its desktop file) -- it's late and I should sleep. If it's conceptually OK,
I'll
clean it up and submit it to review board.
Cheers,
--
sebas
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Index: applet.h
===
--- applet.h (revision 1041410)
+++ applet.h (working copy)
@@ -306,6 +306,13 @@
static KPluginInfo::List listAppletInfoForMimetype(const QString &mimetype);
/**
+ * Returns a list of all known applets associated with a certain URL.
+ *
+ * @return list of applets
+ **/
+static KPluginInfo::List listAppletInfoForUrl(const QUrl &url);
+
+/**
* Returns a list of all the categories used by installed applets.
*
* @param parentApp the application to filter applets on. Uses the
Index: applet.cpp
===
--- applet.cpp (revision 1041410)
+++ applet.cpp (working copy)
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2074,6 +2075,32 @@
return KPluginInfo::fromServices(offers);
}
+KPluginInfo::List Applet::listAppletInfoForUrl(const QUrl &url)
+{
+QString constraint;
+//kDebug() << "listAppletInfoForMimetype with" << mimetype << constraint;
+KService::List offers = KServiceTypeTrader::self()->query("Plasma/Applet", constraint);
+offers << KServiceTypeTrader::self()->query("Plasma/PopupApplet", constraint);
+
+KPluginInfo::List allApplets = KPluginInfo::fromServices(offers);
+KPluginInfo::List filtered;
+foreach (const KPluginInfo &info, allApplets) {
+kDebug() << "=>URL" << info.name() << info.property("X-Plasma-DropUrlPatterns").toStringList();
+QStringList urlPatterns = info.property("X-Plasma-DropUrlPatterns").toStringList();
+foreach (const QString &glob, urlPatterns) {
+QRegExp rx(glob);
+rx.setPatternSyntax(QRegExp::Wildcard);
+if (rx.exactMatch(url.toString())) {
+kDebug() << "showing (match) ..." << glob << url;
+filtered << info;
+} else {
+kDebug() << "No Match:" << glob << url;
+}
+}
+}
+return filtered;
+}
+
QStringList Applet::listCategories(const QString &parentApp, bool visibleOnly)
{
QString constraint = "exist [X-KDE-PluginInfo-Category]";
Index: private/containment_p.h
===
--- private/containment_p.h (revision 1041410)
+++ private/containment_p.h (working copy)
@@ -161,6 +161,7 @@
Containment::Type type;
QHash dropPoints;
QHash dropMenus;
+QHash dropPlugins;
QTimer *showDropZoneDelayTimer;
bool drawWallpaper;
};
Index: data/servicetypes/plasma-applet.desktop
===
--- data/servicetypes/plasma-applet.desktop (revision 1041410)
+++ data/servicetypes/plasma-applet.desktop (working copy)
@@ -76,6 +76,9 @@
[PropertyDef::X-Plasma-DropMimeTypes]
Type=QStringList
+[PropertyDef::X-Plasma-DropUrlPatterns]
+Type=QStringList
+
[PropertyDef::X-Plasma-DefaultSize]
Type=QSize
Index: containment.cpp
===
--- containment.cpp (revision 1041410)
+++ containment.cpp (working copy)
@@ -1296,6 +1296,7 @@
kDebug() << "can decode" << mimeName << args;
kDebug() << "protocol:" << url.protocol();
KPluginInfo::List appletList = Applet::listAppletInfoForMimetype(mimeName);
+appletList << Applet::listAppletInfoForUrl(url.url());
KPluginInfo::List wallpaperList;
if (q->drawWallpaper()) {
wallpaperList = Wallpaper::listWallpaperInfoForMimetype(mimeName);
@@ -1305,6 +1306,7 @@
KIO::JobFlags flags = KIO::HideProgressInfo;
KIO::TransferJob *job = KIO::get(url, KIO::NoReload, flags);
dropPoints[job] = dropEvent->pos();
+dropPlugins[job] = appletList;
QObject::connect(job, SIGNAL(result(KJob*)), q, SLOT(dropJobResult(KJob*)));
QObject::connect(job, SIGNAL(mimetype(KIO::Job *, const QString&)),
Re: dropped URL handling in containment, was: Re: How to get Akonadi notes onto Plasma?
On October 27, 2009, Sebastian Kügler wrote: > Is this something I should pursue? It sounds simple enough ... sure; i don't see any downside to it and the results could be interesting; worst case is we'd have a failed experimnt on our hands and one more way not to do it (in the words of Edison ;) but i think this could work out very well.. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
dropped URL handling in containment, was: Re: How to get Akonadi notes onto Plasma?
On Monday 26 October 2009 00:39:14 Sebastian Kügler wrote: > In 4.4, you can drag and drop URLs onto Plasma, and it will try to find the > mimetype using KIO and offer an applet based on that (the URL is passed > as argument to the applet), the applet defines in its .desktop file which > mimetype it accepts. I'm not sure if the mimetype of a note (text/html? > text/plain) will tell you "this is an akonadi note, that's something we > haven't solved yet). As a kludge, I have just special-cased dropped > akonadi:/ URLs in kdelibs/plasma/containment.cpp to add an email applet. > That's not committed to KDE SVN though, if you want I can try to find that > small patch. Thought about this a bit. How about we add an entry to the applet's .desktop file, called URLPatterns (or something like this). This is orthogonal to the mimetypes the applet supports. We could then make containment list the applets that have one of the globs matching the URL. For the email applet to be able to recognize akonadi URLs. this would look like (in it's plugin .desktop file): X-Plasma-URLPattern=akonadi:/* Other usecases are specific protocols, think of man:/ adding a webview pointing at the manpage. Selkie could use this to decide wether or not to offer a Selkie Plasmoid for a given URL (for example X-Plasma-URLPattern=http://gitorious for a gitorious selkie), I'm sure you can come up with more use cases... Is this something I should pursue? It sounds simple enough ... -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ 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: > branches/work/akoports/kdepim/kjots/plasmoid This should be branches/work/akonadi-ports/kdepim/kjots/plasmoid ___ 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: > Hey Steve, > > On Friday 23 October 2009 20:01:17 Stephen Kelly wrote: >> Any more thoughts on the plan and intentions above? > > What you probably want is to be able to display interesting collections of > notes, for example an itemview with notes with some specific tag, and > being able to display notes separately as individual applets. I'm not sure > if extenders is what you actually want here. Slapping 20 extenders on top > of each other is visual overkill. Also, dragging an extender from a group > (popup applet in the panel, for example) should probably not remove it > from that list. I'm experimenting with this at the moment. I can create new extenderitems, but when I try to move them about the screen, they pop back into the applet. > > Here's what came to my mind, partly based how I've done things in Lion > Mail, including question marks I've run into... > The most flexible way to display a collection of notes is using the models > akonadi already provides, that gives searching and sorting goodness. Think > for example of a listview of (expandable) notes on your desktop. You might > have separate "notes collection" applets there, or on different > activities. Notes should be draggable. The nicest way I've found to do > that was using akonadi:/ URLs pointing to an item. Yes, I plan to try to make this kind of thing possible. > This way, you can just > drag and drop notes, also across applications (think of dragging a note > from kontact/kjots onto plasma). A quick way to create such an applet is > do use a Plasma::PopupApplet and putting a (QWidget-based) listview onto > Plasma using a QGraphicsProxyWidget. Longer term, it probably makes more > sense to use Plasma Widgets and QGraphicsWidgets for that, but ... Yes, I do something like that for the kjots plasmoid. > > Something I've been wondering, and maybe someone here shed some light on > it, is how we can generally map models onto Plasma. Is creating separate > QGraphicsItems on a QGraphicsScene smart? I've heard that QGraphicsView is > optimized for many items, but slapping 5000 email widgets into a > popupapplet (most of them never ever visible) just doesn't sound right to > me. I think the itemviews used in kmail re-use the delegates, right? I don't know much about GraphicsView yet, so I can't really say. What I have currently is a filtered model. When new rows are inserted into the model, I create a new ExtenderItem for it. > > Adding support for the notes in the dataengine would be useful, it > supports email, contact and microblogging right now. It's not using > EntityTreeModel yet though, but it could be cool if it offered search for > notes by, for example requesting "Notes- MyLittleTag", "Notes-Recent10" or > something like that. These kinds of things should be fairly easy with virtual collections. It just needs a nice config UI. > The big benefit here is that this makes it easy to > display notes, it's not quite suitable for editing though. > (Plasma::Service might help here). Supporting notes in the dataengine > means that scripted applets can easily access the data without needing to > know about akonadi specifically (or have bindings to akonadi libs). Yes, that would be nice in the future, but from the information I got in IRC it would be better to have just one applet with extenders. One reason I think is that when plasma gets a notification that a new note was added to akonadi and must be displayed in plasma, there isn't really anything that can create a new applet for the new note. Currently, there I have one applet that contains an EntityTreeModel. when the model says a new note from akonadi should be shown, it is put into the extender. From looking at the api, I should also be able to react to removes and data changes. > > Another interesting thing is styling of the notes. You'll likely want > different stylesheets for displaying notes content on Plasma than on > KJots, and I assume you're using GrantLee for that :)). I've written a > small class that gets the Plasma::Theme's color palette and puts those > colors into a stylesheet. This is actually something that would be very > useful for Plasma, I'm thinking of a Plasma::StyleSheet here, which > provides a basic stylesheet in plasma coloring. That's basically what the > stylesheet class in lion mail does, no fancy templating though. We could > probably brush this up and put it into libplasma, if it's of any interest. I'm not certain Grantlee will be used for the sticky notes, but for other uses, that looks like a good approach. The only things that should be available in the stickynotes is: edit the text and title, and change the background colour. > > In 4.4, you can drag and drop URLs onto Plasma, and it will try to find > the mimetype using KIO and offer an applet based on that (the URL is > passed as argument to the applet), the applet defines in its .desktop file > which mimetype it accepts. I'm not sure if th
Re: How to get Akonadi notes onto Plasma?
On Monday 26 October 2009, Sebastian Kügler wrote: > Hey Steve, > > On Friday 23 October 2009 20:01:17 Stephen Kelly wrote: > > Any more thoughts on the plan and intentions above? > > What you probably want is to be able to display interesting collections of > notes, for example an itemview with notes with some specific tag, and > being able to display notes separately as individual applets. I'm not sure > if extenders is what you actually want here. Slapping 20 extenders on top > of each other is visual overkill. Also, dragging an extender from a group > (popup applet in the panel, for example) should probably not remove it > from that list. it depends how big is usually the data set in real use case scenario i suppose, but yes, an itemview where is possible to drag one outside transforming in actual notes applets sounds sensible (closing them would delete the note from akonadi? just delete the applet?) > Here's what came to my mind, partly based how I've done things in Lion > Mail, including question marks I've run into... > The most flexible way to display a collection of notes is using the models > akonadi already provides, that gives searching and sorting goodness. Think > for example of a listview of (expandable) notes on your desktop. You might > have separate "notes collection" applets there, or on different > activities. Notes should be draggable. The nicest way I've found to do > that was using akonadi:/ URLs pointing to an item. This way, you can just > drag and drop notes, also across applications (think of dragging a note > from kontact/kjots onto plasma). A quick way to create such an applet is > do use a Plasma::PopupApplet and putting a (QWidget-based) listview onto > Plasma using a QGraphicsProxyWidget. Longer term, it probably makes more > sense to use Plasma Widgets and QGraphicsWidgets for that, but ... > > Something I've been wondering, and maybe someone here shed some light on > it, is how we can generally map models onto Plasma. Is creating separate > QGraphicsItems on a QGraphicsScene smart? I've heard that QGraphicsView is > optimized for many items, but slapping 5000 email widgets into a > popupapplet (most of them never ever visible) just doesn't sound right to > me. I think the itemviews used in kmail re-use the delegates, right? the standard qt itemview has a single instance of a delegate, that gets used to paint all items. that saves memory but is also a limitation, since any rich input with it is pain(tm) and also one ofthe reasons itemviewsng is being developed. the way to go (and also what itemviewsng does afaik, even if i didn't really looked at the code) is: -use a qgraphicswiget per item -put them in a clipped parent -have actually instanced only the qgraphicswidgets needed to fit the displayed part, plus a bunch offscreen ones in all scrolling directions, to have smooth scrolling -when the view scrolls, recycle the ones that are gone too much off screen and put on te other side, miking them load the data of the proper item this way it takes a bit more memory than usual itemviews but not that much. now, doing that ourselves is an hell of a job, and i'm still confident some day we will be able to use itemviewng the problem is that we now have several half baked reimplementations of that, one totally item based in the netbook sal, one model based in the mediacenter, but none of them do the item recycling. now, i was looking into adding also the possibility to the sal one of hooking a model into it (since has slighltly better layout and keyboard navigation), if it's -really- needed, but i really really hate to export it ever, since i want to throw it away mercilessy the very same moment i can :D Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: How to get Akonadi notes onto Plasma?
Hey Steve, On Friday 23 October 2009 20:01:17 Stephen Kelly wrote: > Any more thoughts on the plan and intentions above? What you probably want is to be able to display interesting collections of notes, for example an itemview with notes with some specific tag, and being able to display notes separately as individual applets. I'm not sure if extenders is what you actually want here. Slapping 20 extenders on top of each other is visual overkill. Also, dragging an extender from a group (popup applet in the panel, for example) should probably not remove it from that list. Here's what came to my mind, partly based how I've done things in Lion Mail, including question marks I've run into... The most flexible way to display a collection of notes is using the models akonadi already provides, that gives searching and sorting goodness. Think for example of a listview of (expandable) notes on your desktop. You might have separate "notes collection" applets there, or on different activities. Notes should be draggable. The nicest way I've found to do that was using akonadi:/ URLs pointing to an item. This way, you can just drag and drop notes, also across applications (think of dragging a note from kontact/kjots onto plasma). A quick way to create such an applet is do use a Plasma::PopupApplet and putting a (QWidget-based) listview onto Plasma using a QGraphicsProxyWidget. Longer term, it probably makes more sense to use Plasma Widgets and QGraphicsWidgets for that, but ... Something I've been wondering, and maybe someone here shed some light on it, is how we can generally map models onto Plasma. Is creating separate QGraphicsItems on a QGraphicsScene smart? I've heard that QGraphicsView is optimized for many items, but slapping 5000 email widgets into a popupapplet (most of them never ever visible) just doesn't sound right to me. I think the itemviews used in kmail re-use the delegates, right? Adding support for the notes in the dataengine would be useful, it supports email, contact and microblogging right now. It's not using EntityTreeModel yet though, but it could be cool if it offered search for notes by, for example requesting "Notes- MyLittleTag", "Notes-Recent10" or something like that. The big benefit here is that this makes it easy to display notes, it's not quite suitable for editing though. (Plasma::Service might help here). Supporting notes in the dataengine means that scripted applets can easily access the data without needing to know about akonadi specifically (or have bindings to akonadi libs). Another interesting thing is styling of the notes. You'll likely want different stylesheets for displaying notes content on Plasma than on KJots, and I assume you're using GrantLee for that :)). I've written a small class that gets the Plasma::Theme's color palette and puts those colors into a stylesheet. This is actually something that would be very useful for Plasma, I'm thinking of a Plasma::StyleSheet here, which provides a basic stylesheet in plasma coloring. That's basically what the stylesheet class in lion mail does, no fancy templating though. We could probably brush this up and put it into libplasma, if it's of any interest. In 4.4, you can drag and drop URLs onto Plasma, and it will try to find the mimetype using KIO and offer an applet based on that (the URL is passed as argument to the applet), the applet defines in its .desktop file which mimetype it accepts. I'm not sure if the mimetype of a note (text/html? text/plain) will tell you "this is an akonadi note, that's something we haven't solved yet). As a kludge, I have just special-cased dropped akonadi:/ URLs in kdelibs/plasma/containment.cpp to add an email applet. That's not committed to KDE SVN though, if you want I can try to find that small patch. If you want to re-use the existing notes applet, that makes sense IMO for displaying and editing individual notes. Currently, the notes applet stores its contents in the config file, which is quite ugly IMO. It would make a lot of sense if those notes were transparantly stored in akonadi. That means that when you create a new note, a new akonadi note item is created. Closing the note applet won't delete it (just closes this view on the note), but there could be a separate "delete this note" option. For the Notes applet, it might make sense to not use the dataengine, btw. Hooking this up using the akonadi libs makes it much easier. I hope this is not too much information at a time. If you've questions, just ask. :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: How to get Akonadi notes onto Plasma?
> 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? +1 :) sharing is good. being able to have notes related to my current activity is good. just one comment... different notes programs have different features and ways of organizing their notes. personally I'd prefer a plasmoid that presents a simple interface to one that tries to support every possible feature. heck, I've been tempted to make a plaintext version of the current notes widget. the one line of space eaten by the font bar I never use hasn't bugged me enough, though ;) -- This message brought to you by eevil bananas and the number 3. www.chani3.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 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
Re: How to get Akonadi notes onto Plasma?
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 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? should notes be individual widgets, or should they be grouped? should only notes created by the user in plasma-desktop be shown on plasma- desktop? or only notes tagged in some way? is this meant to be replacement / augmentation for the current notes plasmoid, or something quite different? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: How to get Akonadi notes onto Plasma?
On Thursday 22 October 2009, Stephen Kelly wrote: > Marco Martin wrote: > > On Thursday 22 October 2009, Stephen Kelly wrote: > >> 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. > > > > you can directly use it, or wrap around a dataengine (and doing a service > > for writing new ones) not sure what makes more sense here. > > Directly using it might be good. But what do I need to implement to get the > notes onto plasma? Should I implement a plasma applet as you describe > below, create the model in that, and connect its signals to slots that > create new extenders? a plus of doing a dataengine is that it could be recicled around for other applets too > > > for the notes i would do a sngle applet, with an extenderitem per note, > > so by default they would all look stacked but they could be detached and > > dragged around > > Apparently that has other drawbacks that the notes don't look like notes or > something. The conclusion from getting help on irc is not to take that > approach. the only roblem is that this way should have the standard background, but for me that's a plus, custom drawn applets should be avoided as much as possible > What is the alternative? > > All the best, > > Steve. > > >> ___ > >> Plasma-devel mailing list > >> Plasma-devel@kde.org > >> https://mail.kde.org/mailman/listinfo/plasma-devel > > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > -- Marco Martin ___ 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 Thursday 22 October 2009, Stephen Kelly wrote: >> 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. > > you can directly use it, or wrap around a dataengine (and doing a service > for writing new ones) not sure what makes more sense here. Directly using it might be good. But what do I need to implement to get the notes onto plasma? Should I implement a plasma applet as you describe below, create the model in that, and connect its signals to slots that create new extenders? > > for the notes i would do a sngle applet, with an extenderitem per note, so > by default they would all look stacked but they could be detached and > dragged around Apparently that has other drawbacks that the notes don't look like notes or something. The conclusion from getting help on irc is not to take that approach. What is the alternative? All the best, Steve. > >> >> ___ >> Plasma-devel mailing list >> Plasma-devel@kde.org >> https://mail.kde.org/mailman/listinfo/plasma-devel >> > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: How to get Akonadi notes onto Plasma?
On Thursday 22 October 2009, Stephen Kelly wrote: > 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. you can directly use it, or wrap around a dataengine (and doing a service for writing new ones) not sure what makes more sense here. for the notes i would do a sngle applet, with an extenderitem per note, so by default they would all look stacked but they could be detached and dragged around > > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
