Bug 41341

I support this request too.  
 
Knotes is a very nice program for lots of little notes we need everyday. 
 
Having lots of notes renders usage difficult especially while left clicking on the menubar on 
knotes icons and having all this space listing the notes whithout any organization. 
 
If we could at least organize the notes as a tree folder it would be a great feature. 
 
Thanks for all this nice work. kde is beginning more and more a killer app. :) 

maybe subfolder should be manage like the bookmark are in konqueror.
if any notes have a notes ID, we only have to make an XML that organize those 
ID and a gui app like konqueror have for his bookmark.

after this is done, it will be fun to make operation to a subfolder.
for example:
   erase all notes
   open all notes
   sort notes in subfolder.

Subject: Re:  sub folder in knotes ?

That's cool, thanks for all your comments and ideas! :) I'll definitely 
implement subfolders and categories in KNotes. However, I'll be in Australia 
this year and have to finish iCalendar support first (to make it compile 
again ;) So I'm not sure when it'll be done since I have no idea how much 
time I'll have for coding in Melbourne. Maybe February or March...

Thanks,
   Michael

Now that knotes is include in kontact/kmail/korganizer, what happen to our knotes. 
 
it will have two knotes, one in my mail and one in my systray ? or there is one that 
will die ? and the survivor will do both job. i need to know that, because if i want to 
look into the code and try to implemente subfolder, I would be very disapointed if 
the knotes source code i work on die, and everythings is done elsewhere. 
 
well, in any case this is important. 
 

Subject: Re:  sub folder in knotes ?

It will be some work but both will be merged. KNotes itself in the systray 
will definitely not die and you can start implementing subfolders there if 
you want. If you got somewhere, please send me patches for review. Also, 
don't forget to use the resource framework :-) And once you started spending 
a considerable amount of time, just drop me a note so that I don't start 
working on it at the same time. Because I have holidays now---only between 10 
and 20 days, but that's a start ;)

Thanks,
  Michael

I also would like to have "folders" as a kind of category. However just one top-level subfolder.

Why?

If you sync knotes with your Palm via KPilot this could be the category mapping, which currently is ignored.

I also love the "folders" support.. and I would really like an "open all notes" action in subfolders. 

Thanks.  

I was looking at the code of knotes a bit... since I have a bit of time ...

and I have a few question/ideas.

first : the file format notes.ics + libkcal-$UID, is it gonna change again ?
it probably change a lot since kontact integration... i was wondering if its a standard format ? does the format is in use anywhere else in KDE ? in other project ? I'm only thinking to add a PID under notes.ics

I was thinking of that and... i think we dont need to create folders,... we should just give "folders-capabilities" of notes.

instead of having number of functions about folders, "create new, delete, etc."
A folder would simply be a note, which bunch of children... that reduce the amount of change.

to map a note to his new parent, I was thinking of drag & drop,...
if you click on a note, of course, no change, it open the notes
but if you dont release the button, and drag it over a other notes, that write the UID of the parent(dest) in the PID var of the child(src), and you call a redisplay...

the display need a recursive call and... that's about it for the changes...

if we want to change the file format again ??? then, maybe  something in XML would be easier... instead of using parent,.. we would do something like ...

<note>
   <var>blabla</var>
   <note>
      <var>child</var>
   </note>
</note>

i dont know... does anything of this make sens ?

can we right click, drag&drop, etc. on a menu like in use by knotes,... or it would need more change ?
would you guys prefer having folders being a different entity than a note ?

thanks for your feedback

> I was looking at the code of knotes a bit... since I have a bit of time ...
> and I have a few question/ideas.
Excellent.

> first : the file format notes.ics + libkcal-$UID, is it gonna change again?
no, I do not intend to change it anymore.

> it probably change a lot since kontact integration... i was wondering if 
> its a standard format ? does the format is in use anywhere else in KDE ? in
> other project ?
yes, it is standard. The notes.ics is iCalendar, the libkcal-UID is knotes' 
configuration.

> I'm only thinking to add a PID under notes.ics 
no need to, KNotes is a KUniqueApplication.

> I was thinking of that and... i think we dont need to create folders,... we
> should just give "folders-capabilities" of notes.
Definitely.

> instead of having number of functions about folders, "create new, delete,
> etc." A folder would simply be a note, which bunch of children... that
> reduce the amount of change.
Yes, agreed again. That's exactly what my plans are up to now.

> to map a note to his new parent, I was thinking of drag & drop,...
> if you click on a note, of course, no change, it open the notes
> but if you dont release the button, and drag it over a other notes,
...it'll be the new child of the note you droped it on, right? Very nice idea! 
I like that.

> that 
> write the UID of the parent(dest) in the PID var of the child(src), and you
> call a redisplay...
>
> the display need a recursive call and... that's about it for the changes...
However, I don't understand these two sentences at all.

> if we want to change the file format again ??? then, maybe  something in
> XML would be easier... instead of using parent,.. we would do something
> like ...
No, not at all. iCalendar already supports parent-child relations and we need 
to use that. It is also implemented in libkcal (hopefully); if you want to 
learn more about that please see RFC2445.

> can we right click, drag&drop, etc. on a menu like in use by knotes,... or
> it would need more change ?
Not at the moment. Dunno how much work that'd be.

> would you guys prefer having folders being a 
> different entity than a note ?
No, not really. However, I'm not 100% sure we can use the parent-child 
relation _only_, because in the notes list menu I want to have submenus for 
each folder. The folder name can thus be no note itself....

I'll think about this more on LinuxTag and aKademy, I've got too much work for 
uni at the moment.

Thanks heaps for your feedback!

Cheers,
  Michael

> > I'm only thinking to add a PID under notes.ics 
> no need to, KNotes is a KUniqueApplication. 

> > that write the UID of the parent(dest) in the PID var 
> > of the child(src), and you call a redisplay... 
> > 
> > the display need a recursive call and...
> > that's about it for the changes... 
> However, I don't understand these two sentences at all. 
 
Sorry for the confusion with Unix PID ;)

inside notes.ics, there is a field name UID which is like "748519783.336"
by PID I meant Parent UID, which is like the UID of the parent. 
inside the child note, you put the P_UID, if you prefer.
it's obvious of course, was just to document my thought.

and As I describe and you understood,... parent is the destination of the DND, child is the source. (what you drag) : of course.

oh I see. there is a RFC, I'll take a look.

i dont understand the hand of the message, I'll try to figure out the parent-child thing in the RFC and the DND.

thanks for the support.

i'm not sure yet, which one would be easier/best between keeping the parent ID in the child, or the list of children in the parent ?

but KPopupMenu support DND, i think I gonna just need to create a class that inherit KPopupMenu, to implement the DND method.

for the submenu though, i think we can't use the ActionList
KXMLGUIClient::plugActionList() only accept QPtrList, so i guess we gonna have to not use actionlist anymore.

am i right ?

im trying to find some information about KCal::Journal

i finally want to store the list of child in the parent notes

CHILDREN=x,y,z

anyone can give some help, so that I don't break the RFC2445 compliance....

its a bit too much for my small experience.

> i finally want to store the list of child in the parent notes
Yes, definitely agreed.

> anyone can give some help, so that I don't break the RFC2445 compliance....
Not really at the moment, my time is too limited. Just use libkcal and you 
should be alright, it takes care of being RFC2445 compliant. If you need an 
extension to the libkcal-API just implement it or ask for it on 
kde-pim@kde.org.

> for the submenu though, i think we can't use the ActionList
> KXMLGUIClient::plugActionList() only accept QPtrList, so i guess we gonna
> have to not use actionlist anymore. 
Oh, that's bad. So we either need to extend the KXMLGUI class(es) or find a 
substitute...

Thanks!

im sorry, i think this is quite complicated for me.

the logic is all there, but I don't know how to not break iCal stuff and its hard for me to go through the code so... 

*** Bug 134627 has been marked as a duplicate of this bug. ***

*** Bug 150217 has been marked as a duplicate of this bug. ***

Hello,

I would like to ask if there are any plans to implement "sub folders" to knotes?

Best regards

*** Bug 80876 has been marked as a duplicate of this bug. ***

This features would be still useful. 
Personally, I would like to list the notes with the details, as the mails in a mail folder. 
Now, I use my Draft folder in Kmail as an equivalent for Knotes, but this would be better placed in KNotes. 
The other issues about subfolders would be nice too. 

keeping this open to see the longest living bug alive ! 
will close in 2022 when it celebrate its 20th anniversary

I mean, subfolders in knotes would still be awesome, no?