Version: (using KDE 4.0.83) OS: Linux Please add the ability to have recursive pages in Kontact's wonderful Notebooks feature. This would be in a fashion similar to Knowit (unmaintained) and Basket (so overengineered that it is useless for simple notekeeping). Ideally, a page's icon would be slightly different if there is text in the page or not, as was the case in Knowit. Empty pages are common when recursion is possible. Thanks.
This is kind of possible already, but not in a very obvious way. You can create two notebooks, then use drag and drop to make one book a child or sub-book of another. For KDE 4.2 I may add a 'Add book here' option which adds a sub-book to the selected book, rather than adding it to the top-level bookshelf.
I did notice that books can be dragged under one another. However, books cannot contain content, only pages can. Often I need a page of content to have a subpage (talking from experience in the wonderful Knowit and the frustrating Basket applications). For instance, I have a 'book' (or 'basket') of pages (or 'subbaskets') where each page contains info on a different program that I use. There is a Firefox page, an Open Office page, a Maxima page, and so on. However, the Firefox page has subpages, one for each extension. This is currently not possible in the Notebooks application because books (or subbooks) cannot have their own content. Steve, I have lots of notes regarding the design of a Knowit-type application, if you would like we could communicate in private mail. I would certainly love to help develop the application, and of course I would give the app very heavy beta testing. I literally have hundreds of notes in Basket, and I regret the day that I abandoned Knowit. Thus, however, an import feature from Basket would be necessary. Lots of Basket features would obviously be lost in translation to Notebook, but so long as the text, hierarchy, and basic formatting such as bold and Italic stay intact then that is fine.
Notebooks are deliberately purely containers of pages, just like your paper notepad is. I don't think it makes sense for books to have text content directly as books do, and as knowit pages allow. Any ideas you have are welcome though, and if we discuss them in private mail we might be able to fill some solid wishlist items that way.
For this issue I will respond here, other ideas I will send to you in private mail, Stephen. Thanks. I understand that you are copying the behaviour of real paper with Notebooks. That is great, as other attempts such as Basket have gone way to far with features making the app unwieldy. However, you not need limit the app with the real-world limitations of paper when unnecessary. Here, you can improve upon the paper. Having subpages is not only a wish that I have here, my personal notebook also has pages taped in where necessary. A real world analogy would be that one could write on the cover of books, and inside the covers. Unlike most book lovers, I regularly write in and highlight my books. Even my Tanack (Bible) has highlights and notes, and yes, even on the cover. That may upset some people who feel that a book could be sacred, but for me it is an instruction manual, and the contents are sacred, not the book. I went too far, but I think that I made my point.
You'll need to give me mockups or explain how you think it would work, what the user sees, what actions the user can take, whether it should be configurable, what should be configurable and how it changes how KJots currently works. I have trouble visualising how you want the interface to change. Also I don't know if this is really so different to a structure something like Firefox |-> Main application |-> Adblock ... Open Office Maxima or even Firefox |-> Main application |-> Themes |-> Noia |-> Extensions |-> Adblock ... or even Firefox |-> Main application |-> Themes |-> Main page about themes |-> Noia |-> Extensions |-> Main page about extensions |-> Adblock ... in the current system of books and pages. Is there really an advantage to adding text to books?
> Is there really an advantage to adding text to books? Yes. For one thing, on entries with a 'main page' you are saving the user a click by having the main page loaded when the book icon is clicked. Note that for terminology purposes in this bug, we are confusing the terms 'page' and 'book'. So I will just use the term 'page' with the assumption that a 'page' could be either a node or a leaf. The current behaviour of the app is that nodes are called 'books' and cannot contain text. Leafs are called 'pages' and can contain text. If on the Thunderbird page I have information regarding Thunderbird usage and tricks, and on the Maxima page I have information regarding Maxima usage and tricks, the I would like the Firefox page to have information regarding Firefox usage and tips, regardless of the fact that there is a subpage for Firefox concerning it's extensions. With the current setup I need either: 1) Both a Firefox Page and a Firefox Book. The gets unwieldy very quickly. -or- 2) A Firefox book, with a page that I consider the 'main page'. Then, in other instances where I would have a 'main page' I will have to remember the name that I used for the 'main page'. Did I call them Index? Did I call them Home? Did I call them Main? If I have Index under Thunderbird, and Home under Firefox, are they both the 'main page' for those apps? Maybe the Index page under Thunderbird relates to the file index, and maybe the Home page under Firefox refers to my homepage? In both these cases the folder tree becomes longer then it would otherwise be. Might I ask, what is the advantage to _not_ being able to write on a tree node (book), only a tree leaf, other than the fact that it is the current behaviour? Thanks, Stephen, I appreciate the fact that you are considering this wish.
Sorry I didn't get back to you sooner. I'm still not sure how you would expect this to work (from the perspective of what the user sees on screen etc) and how the current interface should change to accommodate it. Currently when you click a book the panel on the right becomes a read-only representation of the contents of the book. Do you want me to split that in half and put an editor in there too? Should it be only an option when you right click a book, bringing up a new dialog? Maybe take a screenshot of kjots and draw on it with kolourpaint with any additional buttons you think are needed, what should be where etc. Doesn't have to be pretty, just some way I can grasp how you think this would work. A list of additional menu items required might also help. I am interested in the idea, but I need to know more about it.
Created attachment 25955 [details] mockup > Currently when you click a book the panel on the > right becomes a read-only representation of the > contents of the book. Do you want me to split that > in half and put an editor in there too? Should it be > only an option when you right click a book, bringing > up a new dialog? I suppose that the books could remain books, that is, that they would show a summary of their contents. The pages would have subpages, though. And pages with content would have their icon show that. See screenshot, which shows a page with two subpages. The blank pages have the current Kjots page icon, while pages with content have a pencil in the icon to indicate that they are not empty. > Maybe take a screenshot of kjots and draw on it with > kolourpaint with any additional buttons you think are > needed, what should be where etc. Doesn't have to be > pretty, just some way I can grasp how you think this > would work. A list of additional menu items required > might also help. Done, attached. I only touched the tree view, I did not see a need to change the menus. > I am interested in the idea, but I need to know more > about it. Thanks, Stephan. You work is very, very much appreciated.
Created attachment 26028 [details] Mockup of KJots with introduction/foreward/book text area I see. That's just like the KnowIt functionality alright. However, that would mean that books can have child books, and pages can have child pages. I think that's redundant, unless a usability expert tells me otherwise. Your input is valuable, but I'm not going to implement pages with subpages. I made a mock-up that might help you get a similar workflow, however. If I can figure out a sensible way to make the user input some foreward/intro text, I might add this functionality for KDE 4.2. This might be as simple as adding a splitter on the right hand side, and putting a edit area above the display area. What do you think of that?
> That's just like the KnowIt functionality alright. However, that would > mean that books can have child books, and pages can have child pages. > I think that's redundant, unless a usability expert tells me otherwise. That's why I simply referred to nodes and leafs in my earlier post. At what point is a node a book, and at what point a page, if they both have subcontent? I suppose in the case of Kjots the TOC would make the difference, but it still leaves the definition undefined. > Your input is valuable, but I'm not going to implement pages with > subpages. That's fine, she's your baby! And I trust you to do with her what you feel is best. > I made a mock-up that might help you get a similar workflow, however. It looks functional. I like it, the only suggestion that I have would be some sort of indicator on the book icon when there is introduction text present. > If I can figure out a sensible way to make the user input some > foreward/intro text, I might add this functionality for KDE 4.2. Yes, there would need to be some sort of read mode / write mode switch, and I am certain that you don't want to reimplement VI! Maybe upon click the 'fixed' text would turn into a text box. I do not know if Qt can do that. In any case, that would add yet another distinction between books and pages: pages are always textboxen, where as books are 'set' until clicked. > This > might be as simple as adding a splitter on the right hand side, and > putting a edit area above the display area. I really don't like the idea of another splitter. Even in Kmail / Akregator I don't like the three-pane approach (not that there is much choice in those apps due to their very nature). > What do you think of that? I think that the idea (and Kjots in general) is maturing. If an intuitive read / write switch can be developed, then I really think that you've found the winning combination. I actually am a bit excited about the idea that the nodes with subnodes will have a summary of those subnodes, I can imagine this being very useful. I will try to brainstorm intuitive switches as well. I have a few users that I can ask to edit that text, without telling them that it is impossible. I'll see what they try, and from that we could deduce an intuitive solution.
In my opinion, books and pages should be unified into nodes, just like the gtk based "notecase". There should also be options to sort the nodes recursively.