GNOME Bugzilla – Bug 116487
FeatReq: Sticky Notes to read knotes files too.
Last modified: 2020-11-07 12:26:50 UTC
I'll post the reversed suggestion to the kde bugzilla. Make StickyNotes read any possible knotes files with their settings and thus make it easier for ppl to switch between the environments.
I MAY considering reading knotes files, but I probably won't be automatically reading it's configuration files. UNLESS, of course, it becomes a standard on freedesktop.org. My sticky notes contents file is a very simple self explanatory XML file called ~/.gnome2/stickynotes_applet. Where can I find information on knotes? I haven't used KDE in years and don't even have it installed. I suppose I could use the source. :-) I might email the maintainer, and agree on a standard file format (XML DTD) for stickynotes (perhaps saved as ~/.stickynotes) that we can both use.
What ever became of this? We're still using the same file, so were the KDE people not interested?
Yes, I am. I am the author of KNotes and I would like to be able to import stickynotes. However, my time is too limited at the moment, unfortunately :-(( All the effort goes into porting to Qt/KDE 4 at the moment and fixing the resource framework. In KDE we are using the resource framework to locate the notes, the notes themselves are stored in an iCalendar file, the default being ~/.kde/share/apps/kntoes/notes.ics. Each note has a unique UID and the corresponding file in ~/.kde/share/apps/knotes/notes/ holds the display configuration, like color, size, position. I hope to be able to import gnome notes for KDE 4. Cheers, Michael
Interesting. How do you actually use the iCalendar spec to do notes. Are they then able to appear as Todo list items in $calendaring-app? I am very interested in joining forces on this. Moving the file to a common location (I believe that there are some common fd.o locations). Perhaps we can store all of that position information and such in the iCal file using X-XDG-Notes-FGColor headers and such. To save the requirement for multiple files. Then a plugin that did some magic to make stickynotes appear as TODO items in Evolution, perhaps (I don't know if something like that is useful).
No, not as TODO, we store the notes as journals (VJOURNAL). I have already added three custom headers to be able to use notes with kolab/imap, for instance: X-KDE-KNotes-BgColor:#ff9b18 X-KDE-KNotes-FgColor:#000000 X-KDE-KNotes-RichText:true With Qt4 it might not be necessary anymore to include the last one, but I do think it is still useful to have, e.g. if you want to store html source in a note. I'll be working on that. I don't know about standard locations for notes yet, due to lack of time. But since the user can configure his resources to load notes from imap, local ics file, directory with several files (soon), kolab, etc. it might be a bit of a challenge to import notes in GNOME without using the KDE resource framework, or at least its configuration files... What do you think?
BTW, it would certainly be possible to change the custom headers names (at least I hope so). The only problem I see is with _one_ standard location due to the flexibility in KDE.
Well, I see two basic solutions for this. Have a standard config file that says where to look for the information; or simply only share the same on disk format and default on disk location.
Hm... I don't quite understand the second one. The first one: you will be able to find the location in .kde/share/config/kresources/notes/ in the file stdrc (or any other file, should it be in there). This will be possible in KDE 4 only, though. The patch was too late for KDE 3.5 :( The second one: you suggest changing form iCalendar to something else for KNotes? I don't think that's gonna happen, keeping in mind the applications that depend on iCalendar already. I don't want to break kolab for instance.
When I say common file. I mean something not in .kde. A simple XML file somewhere in one of the XDG directories that could be read. For the second one: iCal is certainly interesting, assuming it doesn't suck more than what we're currently using. I assume you're going to have some kind of option that specifies a default location for notes, right, or are you just going to let users enter any filename they like? I was suggesting that we needn't share config, but simply have the same data store and the same default location for the file.
I see, thanks for the clarification. Yes, that sounds good, a default location that we could share would be great, assuming we would be able to share iCal. It actually doesn't suck btw, we can have alarms, hierarchical notes (that I have yet to implement), categories, etc. And we can have links and images in a note using external files or, say, mime-encoded inline data. You see, you get a lot more stuff for free than with XML :-) Regarding locations, yes, the user can choose any filename and location, although the content always will and has to be iCalendar. If you have KDE 3.5 you can try by opening the KControl center, KDE Components->KDE Resources->Notes->select/edit notes resource. (It was not too late for 3.5 apparently :))
It seems that using iCal certainly has some available benefits. I certainly like the idea of embedding images and setting alarms (I recall something like that in the original post-its program for Win 3.11). Ok. So what custom headers do we have? Here are some ones I've thought of: X-XDG-Note-Geometry: wxh+x+y X-XDG-Note-Workspace: int X-XDG-Note-FGColor: #hex X-XDG-Note-BGColor: #hex X-XDG-Note-Font: fontconfig name X-XDG-Note-Locked: boolean X-XDG-Note-Visible: boolean X-XDG-Note-RichText: boolean I assume titles are handled in the existing VJOURNAL headers. I guess Locked and Visible could be as well. I'm not incredibly familiar with the spec. Thoughts on file location? FWIW, I think we were using XML because it's easy to parse. I'll have to find out what is involved in using whatever Evolution is using for iCal parsing. All I know is that iCal is the spec that no one likes to parse.
hehe... yeah, iCal is a nice one to parse ;) We (and I think Evolution as well) are using libical to parse it, seems to work well. Recently we upgraded our copy and put some more fixes in, especially with regards to the recurrence stuff. Maybe we can even share the whole lib? AFAIK this was the idea somewhen already... Yes, titles are handled using the Summary: header, the note itself using the Description: header. The custom headers should not include the display configuration, IMHO. That is, the workspace, the position, and the visibility (encoded with workspace 0 if invisible in KNotes). There's the possibility of encoding the visibility in iCal already, though. Another header I could think of is X-XDG-Note-ResourceLocation: url unless we also standardize the url where to store images and similar data, which I'd recommend. BTW, do you prefer FGColor or FgColor? ATM I'm using the latter. File location -- no idea or preference, really... if there are other common locations like calendars already, let's just put the notes in a similar one. Maybe we should aim for a common calendar location as well if there is none yet.
It seems that VJOURNAL support was added to Evolution-Data-Server. If we can agree on a format, then we could possibly convince E-D-S that it wants to use that file for its VJOURNAL entries. I'm not entirely sure that we need an X-XDG-Note-ResourceLocation header. With other iCal entry types (at least with VEVENT) it seems that you can base64 attach files (or at least, Evolution is offering a way to attach files to calendar entries). Perhaps we could use the same mechanism here? Setting visibility with iCal would allow greater interoperation with other note taking applications. I am overly fond of the idea of storing everything in the same file, it would make things easier to backup and administer. It would really suck if you backed up ~/.share/notes.vjournal (say via exporting from Evolution), but forgot to backup ~/.share/notes.xml, so you lost all of your geometry and so on.
> It seems that VJOURNAL support was added to Evolution-Data-Server. If we > can agree on a format, then we could possibly convince E-D-S that it wants > to use that file for its VJOURNAL entries. See below, I am currently in a KDE PIM meeting where we discussed our issues about a shared pim storage service. The evolution people have indicated that they would be very much interested in this once it takes off. > I'm not entirely sure that we need an X-XDG-Note-ResourceLocation header. > With other iCal entry types (at least with VEVENT) it seems that you can > base64 attach files (or at least, Evolution is offering a way to attach > files to calendar entries). Perhaps we could use the same mechanism here? Yes, that is one way I like and something I have thought about already. Also, the new Akonadi PIM Storage Service we designed here will encapsulate this (resource location) problem. So we will have the GNOME and KDE apps that use a library which wraps the storage access protocol (probably IMAP, possibly also D-BUS) of Akonadi. The library will provide all those features we need and thus we would almost not have to worry about storage anymore. It would be great if you guys could have a look at the required APIs and give some input on what you want it to look like and what you need. Have a look at http://pim.kde.org/playground/osnabrueck4/ > Setting visibility with iCal would allow greater interoperation with other > note taking applications. yes, if we'll store geometry info in iCal then we could most probably store visibility as well. The only somewhat ugly thing is that not every app knows about the concept of visibility, like Kontact. > I am overly fond of the idea of storing everything in the same file, it > would make things easier to backup and administer. Well, and I keep getting reports from users who want KNotes to be able to store every note in its own file (which is not supported yet). > It would really suck if > you backed up ~/.share/notes.vjournal (say via exporting from Evolution), > but forgot to backup ~/.share/notes.xml, so you lost all of your geometry > and so on. I don't know yet. The question has now changed to "Store geometry info in Akonadi or separately". We would have to store it separately if it should be possible to have the same note on different screens or sessions with different geometry or desktop data. But I start to be able to accept storing the data in Akonadi/iCal.
(In reply to comment #14) > Also, the new Akonadi PIM Storage Service we designed here will encapsulate > this (resource location) problem. So we will have the GNOME and KDE apps that > use a library which wraps the storage access protocol (probably IMAP, > possibly also D-BUS) of Akonadi. The library will provide all those features > we need and thus we would almost not have to worry about storage anymore. So Akonadi PIM is similar to our Evolution-Data-Server? A process that you talk some manner of IPC to and you can get information back from it? > It would be great if you guys could have a look at the required APIs and give > some input on what you want it to look like and what you need. Have a look at > http://pim.kde.org/playground/osnabrueck4/ Will do. Have you also sent this on to the Evolution-Data-Server guys? > > Setting visibility with iCal would allow greater interoperation with other > > note taking applications. > yes, if we'll store geometry info in iCal then we could most probably store > visibility as well. The only somewhat ugly thing is that not every app knows > about the concept of visibility, like Kontact. Surely this is an issue that requires resolution in Kontact? > > I am overly fond of the idea of storing everything in the same file, it > > would make things easier to backup and administer. > Well, and I keep getting reports from users who want KNotes to be able to > store every note in its own file (which is not supported yet). Perhaps here an 'Export' feature would be useful. Something that will export a note of your choosing. I think Tomboy has a similar feature. > > It would really suck if > > you backed up ~/.share/notes.vjournal (say via exporting from Evolution), > > but forgot to backup ~/.share/notes.xml, so you lost all of your geometry > > and so on. > I don't know yet. The question has now changed to "Store geometry info in > Akonadi or separately". We would have to store it separately if it should be > possible to have the same note on different screens or sessions with > different geometry or desktop data. The idea of storing the same note for different monitor geometries is interesting. It would allow users to mount the same home directory from multiple machines, where those machines may have different resolutions. The q
Oops... continuing from comment 15. The question is whether or not it is useful to the user to have an entirely different geometry for each computer (they may find this highly confusing as it will mess up their spatial awareness, eg. "I know that I dragged my note over to the right hand side of the screen yesterday, now where is it, oh wait, that was on another computer") or whether if we have limitations to our geometry, we should just move the notes somewhere they will remain visible.
yes, I have the same question you mention above, not sure about the answer. Currently it's not possible for one user to have different note geometries. And I was thinking about two users sharing the same notes with different geometry information, which is (theoretically) possibly already. Regarding visibility in Kontact---it just doesn't make sense. You have all your notes embedded in the app's iconview (or listview, for that matter) and can click on one of them to edit it. Hiding/Showing a note seems not to be a useful concept there. Export: that's there already. The requests were more along the lines of storing notes like mail in a maildir. EDS: Akonadi PIM is similar, but quite different as well. Akonadi will use a protocol (IMAP) instead of IPC and Corba to make it scale. That is needed because Akonadi will also handle mail in addition to calendar, tasks, and notes. And it will support offline mode and syncing. Akonadi can be seen as the local cache that connects to a remote imap server for mail etc. and manages the local data for locally stored mail and notes. I have not talked to the EDS guys personally, but Shreyas (Evolution) knows about it (he's on IRC #Akonadi).
I think this bug can be closed now since there's been no activity for the last six years and this user has at least left the linux world for good.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old feature requests in Bugzilla which have not seen updates for many years. If you still use gnome-applets and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-applets/-/issues/ Thank you for reporting this issue and we are sorry it could not be implemented.