I
As stated before, we NEED a TOGGLE "Switch between tree and editor" which does NOT go to the search results / attributes pane when that pane is open; in fact, I even avoid searching by this behaviour of "Switch between tree and editor" to go to the search results pane, when focus is in the editor, instead of going to the tree pane instead. So the going to a third pane of this command, as it is, is a terrible thing for me since I cannot overcome it by any macro.
II
Many times, this above command, when focus is in the editor pane, goes very well to the tree pane (= when the search results pane is not shown that is) but there it changes the display to "Filter" instead of displaying the tree as it was before. That is, even when there aren't but those two panes displayed, the command does not function as a toggle but changes the content of the tree pane. This happens often but is in no way predictable, the encoding would have to be revised there, please.
III
One of many little things: When the title of your item contains an ampersand, a "&" that is, and in fact that's not an idiosyncrasy for "and" but is contained in many businesses' names (= corporation names) and thus has to appear correctly in letters, etc., please have a look at that ampersand in the title ABOVE the text / editor! There, the program tries to interprete it as a formatting thing!
IV
Elsewhere, I explained why it was important to give us an option to avoid to have to do TWO "Enter" when entering a "known" tag (whereas that second "Enter" gives us an unwanted new item after entering a "known" tag) - well, I discovered that you can enter, instead of 1 or 2 "Enter", the command "Show Tree" immediately after your (known or unknown) tag, and the tag dialog closes correctly without any more fuss. But two remarks apply: First, I am very new to MI, and I'm astonished that in years of use, no other user has seen this "way around"... or when they have, why don't they be as kind as SHARING their knowledge with fellow users? And secondly, having to finish any tag with the command "Go to Tree" is awkward since on the contrary, after having given a tag (or some tags) to your item, most of the time, you want to edit your item, so by doing this command, you're in the BAD pane, most of the time, and thus, you must do the command "Switch between tree and editor / from tree to editor" right afterwards - not elegant at all! (Doing ONLY that last command will NOT solve the problem, by the way.)
V
Whenever you insert an item (or a group of items) into the tree, the tree MOVES, it scrolls, that is, but unfortunately to the BAD direction: Instead of giving you more sight of it where you want to see it after that inserting, it HIDES that new part from you... and other quirks in scrolling away from your sight. Is it a known issue that will be attended soon, or do I have to develop? In fact, I have already written some details about the various problems raised here, so could publish the details in case of need. ADDENDUM : COPIED TO "TREE"
VI
We need a third dimension, on macro level and on micro level. On macro level, that should be rather easy to implement, on micro level, it's almost impossible; in fact, ALL information management systems struggle with this problem. Since on the macro level, it's easy, I would like to develop the solution (where I do with macros at this time, which is not beautiful but is working at least). ADDENDUM : COPIED TO "THIRD DIMENSION"
VII
The search functionality (= a third party add-on I suppose) does NOT work in an always reliable way. Non-english words are "found" even as parts of words, and that without entering any asterix, and that is true for single characters (vowels with accents, etc.) and for short words. For example, the french "il" and "elle" - "he" and "she" - are "found" within any word where those 2 or 4 characters are contained. ADDENDUM : COPIED TO "SEARCH RESULTS" - Attention, that subject is in the "Suggestions" category, not in the "General discussion & support" category.
VIII
There have been some weeks without any real response of Petko's with regard to my suggestions, so my initial delight with MI has been a little bit reduced by my fear that all those little quirks could perhaps not be addressed, and that would be acceptable for the time being, but not on long range - other programs bring many sophistications any day AND are developed and improved in a way that one day they will be without fault. But if the faulty parts of MI will be addressed, and if MI will be optimized, I have NO intention to "crimp", to transfer my data to any other program, even in the long range.
IX
I see two things: Petko has answered many threads, on Sept15 - I'll read those answers now (= I did not read them writing this); people are referring to that mythical Mac application that will come to Windows in a few weeks, Scrivener. So, well, let's speak frankly:
- It IS possible to export all your data from MI to other programs, just chose Export - TreePad Plus (!), and then, in Ultra Recall, Import - TreePad. IT WORKS. And it works WITH your jpg's, it does NOT blow up your data, etc. - I would NOT have imported all my data into MI if I did not had worked this way out of MI, in case of... And so, if perfect importing into UR is possible, exporting / importing your MI data into other outliners, etc. should be possible... à la limite, by exporting / importing from MI to UR first, and by exporting from there afterwards.
- But I'm NOT leaving; why should I? OK, I'm dreaming of a combination of UR and MI, but I will not get it by transferring my data to UR, but, perhaps, by sharing my thoughts how to improve MI.
- And then, Scrivener is NOT a real alternative - except for fiction writers, when I prefer to have a UNIVERSAL program doing ALL my stuff! -, but perhaps that Mac thing DEVONTHINK is the real powerhouse... not having access to a Mac, I cannot say.
- When you see the access numbers to this forum, you could easily develop some anguish about the future of MI, but then, MI just needs to be really improved in two ways, to be cleared by all those "amateurish" faults like those I stated above, and to be improved by additional functionality which gives you real work flow instead of hindering your work, and if Petko does this, sales WILL MULTIPLY since that work flow enhancements will be instantly PROVABLE, AND we could swear there are no hidden faults.
- For example, that third party search add-on, well, for each such components, there are dozens of them available, and if the one bought / implemented does not work correctly, well, it has to be replaced... but replacement costs are about 400 to 800 dollars for each such a component (and not a fortune, as some users might think), and they can easily be found, and thus, as soon as you are a fine programmer such as Petko is, it's easy to constitute a real fine program... which is without fault AND will give you a real work flow... and then, thousands of new users will buy since dozens of publications will be happy to tout that fine program. We are finishing 2010; "amateurish" quirks are not accepted anymore, they have to be exterminated; work flow hindrances are everywhere, so nobody is willing to tout any other such a hindrance except for big ad money... but just have a look at Scrivener ( literatureandlatte.com ): As soon as something craves your eyes, people are GLAD to tout it, free, and MI HAS that potential if Petko does a lot of work. I'm here to second. About February, UR will again be half price... well, I'm NOT leaving, and I'll not be leaving then.
Miscellaneous
Miscellaneous
Last edited by Fred on Wed Oct 13, 2010 1:23 pm, edited 2 times in total.
For the time being, the status line does not give me any useful info, so I would like to hide it in order to have that screen real estate for my tree and my text. Please give us the option to hide it.
Fred, just to let you and all other people here, the work on MyInfo 5.50 is already in progress, so I will "bump" some of the topics discussed here for more information on the features that we are currently working on.
Of course, I want to be able to implement almost all of the changes right now, but it will be not possible. Some things require major rework, which will prolong the work on 5.50 too much, so these major new features (or changes) will be postponed for the next major version of MyInfo (6). Anyways, if we manage to fix the small things and add some of the bigger soon, I think that everybody will benefit.
Of course, I want to be able to implement almost all of the changes right now, but it will be not possible. Some things require major rework, which will prolong the work on 5.50 too much, so these major new features (or changes) will be postponed for the next major version of MyInfo (6). Anyways, if we manage to fix the small things and add some of the bigger soon, I think that everybody will benefit.
Hi Petko,
But that's exactly what I have in mind, I'm doing sort of an inventory (which in part at least should have been done by common efforts of fellow users, but mentioning that has just been a mood of 2 seconds, I'm a just criticizing a tiny bit, I'm not bringing up charges), and of course, doing tiny bits first, implementing big improvements afterwards.
What bothers me most, at this time, is:
- The "go back to last item" is not working in a useful way; as stated, it brings up too many intermediate items you do not want to go back to; UR allows for your entering the milliseconds an item must have had focus in order to be included in that list, the default there being 4,000 ms = 4 sec, which is a good thing. And there must be a real toggle between two items, not just "backwards" and "forward": 1 key should suffice to jump back and forth between two items
- The absence of a real toggle between tree and text pane. As mentioned before, when the search pane is displayed, the "Switch forward" and the "Switch backward" commands take a (useless) round between the three panes. Just ONE key should suffice to really toggle between tree and text, independently if there is any other pane displayed or not.
- The absence of a command "go back to last used tab"; of course, this absence is felt so much because of the absence of a real useful "go back to last used item" command.
Do I overlook here some very important point? Then I'll join it, but these are the basics for me.
Again, don't feel pressurized into doing too many things in a minimum of time. I'm trying to trigger discussions on real enhancements, but I'm not expecting to see them in maintenance releases.
And I'm not going back to AS either!
But that's exactly what I have in mind, I'm doing sort of an inventory (which in part at least should have been done by common efforts of fellow users, but mentioning that has just been a mood of 2 seconds, I'm a just criticizing a tiny bit, I'm not bringing up charges), and of course, doing tiny bits first, implementing big improvements afterwards.
What bothers me most, at this time, is:
- The "go back to last item" is not working in a useful way; as stated, it brings up too many intermediate items you do not want to go back to; UR allows for your entering the milliseconds an item must have had focus in order to be included in that list, the default there being 4,000 ms = 4 sec, which is a good thing. And there must be a real toggle between two items, not just "backwards" and "forward": 1 key should suffice to jump back and forth between two items
- The absence of a real toggle between tree and text pane. As mentioned before, when the search pane is displayed, the "Switch forward" and the "Switch backward" commands take a (useless) round between the three panes. Just ONE key should suffice to really toggle between tree and text, independently if there is any other pane displayed or not.
- The absence of a command "go back to last used tab"; of course, this absence is felt so much because of the absence of a real useful "go back to last used item" command.
Do I overlook here some very important point? Then I'll join it, but these are the basics for me.
Again, don't feel pressurized into doing too many things in a minimum of time. I'm trying to trigger discussions on real enhancements, but I'm not expecting to see them in maintenance releases.
And I'm not going back to AS either!
I
I do all my URL links in the form "www.xyz.com", i.e. without a "http://" before.
Thus, many, many links will NOT automatically be identified by MI as URL links, not by importing, not when entering them manually in the editor, independantly of the suffix (.com, .de., be., .fr and so on), but which is real weird, it's not at all predictable if such a link will be identified (=and thus automatically formatted) or not.
This is something that is really unhandy if I might say so since it's interfering with your work ten or more times a day.
II
Normal behaviour of a search term entering field is, when it gets focus, the last entry (=search term) there is marked / seledted, and then, you can either do a RightArrow which preserves the term, ready to enter some additional term, or to change parts of the term, or, when you don't do such a RightArrow (or other arrow command or mouse click), the term vanishes, allowing for a new entry from scratch.
MI's search field only sometimes reacts this way, but most of the time, it just gets focus, without the last entry there being marked / selected, which is to say it is not easily dispendable by pressing any new key, like normal behaviour, in order to enter a new search term.
Thus, I replaced my F6 = "search" command by a macro triggering a control-alt-F6 command "search" (=which so I never use manually) (=cursor at the end of the former search term), then doing a shift-home, then doing a delete, and finally, I can enter my new search term.
Since most people do NOT use macro programs with MI, I suppose, this behavior of the MI search term field is also quite unhandy I dare say.
I do all my URL links in the form "www.xyz.com", i.e. without a "http://" before.
Thus, many, many links will NOT automatically be identified by MI as URL links, not by importing, not when entering them manually in the editor, independantly of the suffix (.com, .de., be., .fr and so on), but which is real weird, it's not at all predictable if such a link will be identified (=and thus automatically formatted) or not.
This is something that is really unhandy if I might say so since it's interfering with your work ten or more times a day.
II
Normal behaviour of a search term entering field is, when it gets focus, the last entry (=search term) there is marked / seledted, and then, you can either do a RightArrow which preserves the term, ready to enter some additional term, or to change parts of the term, or, when you don't do such a RightArrow (or other arrow command or mouse click), the term vanishes, allowing for a new entry from scratch.
MI's search field only sometimes reacts this way, but most of the time, it just gets focus, without the last entry there being marked / selected, which is to say it is not easily dispendable by pressing any new key, like normal behaviour, in order to enter a new search term.
Thus, I replaced my F6 = "search" command by a macro triggering a control-alt-F6 command "search" (=which so I never use manually) (=cursor at the end of the former search term), then doing a shift-home, then doing a delete, and finally, I can enter my new search term.
Since most people do NOT use macro programs with MI, I suppose, this behavior of the MI search term field is also quite unhandy I dare say.
(This being my second post here today, so please don't overlook my previous one.)
I
TREE SCROLLING PROBLEMS
(...) ( ADDENDUM : SHIFTED TO "TREE" )
II
SIMILAR PROBLEMS WITH THE EDITOR
(...) ADDENDUM : ALSO SHIFTED TO "TREE"
I
TREE SCROLLING PROBLEMS
(...) ( ADDENDUM : SHIFTED TO "TREE" )
II
SIMILAR PROBLEMS WITH THE EDITOR
(...) ADDENDUM : ALSO SHIFTED TO "TREE"
Last edited by Fred on Wed Oct 13, 2010 1:09 pm, edited 1 time in total.
Fred wrote:- The "go back to last item" is not working in a useful way; as stated, it brings up too many intermediate items you do not want to go back to; UR allows for your entering the milliseconds an item must have had focus in order to be included in that list, the default there being 4,000 ms = 4 sec, which is a good thing. And there must be a real toggle between two items, not just "backwards" and "forward": 1 key should suffice to jump back and forth between two items
Fred, your suggestion made me wonder if the items history can be improved and I tried many applications (browsers, outliners, OneNote, Outlook and so on), but all these applications remember all visited items, just like MyInfo. I agree that you can accidentally hit a document by mistake, but it should be not an issue most of the time.Fred wrote:- The absence of a command "go back to last used tab"; of course, this absence is felt so much because of the absence of a real useful "go back to last used item" command.
However, what differs MyInfo from other applications that use tabs (only UR works the same way as MI) is that they keep separate history for each open tab. So, I agree that there should be a way to move back and forth between topics without going through all intermediate documents. I think that I have found a remedy for this problem: there will be Go to Previous/Next Topic commands in the next release. It will look like something like this:
I agree about that one too.Fred wrote:- The absence of a real toggle between tree and text pane. As mentioned before, when the search pane is displayed, the "Switch forward" and the "Switch backward" commands take a (useless) round between the three panes. Just ONE key should suffice to really toggle between tree and text, independently if there is any other pane displayed or not.
Hi Petko,
I
Indeed, I thought - but lately was afraid that I had not mentioned it clearly enough - that a history of "visited" tabs / topics would be a fine thing ON TOP of an optimized item history, not something that could replace it, so having both is exactly what I had been wanting for.
Of course, there is always the possibility to do a history for each tab / topic seperately, but then again, I have often 40 topics / tabs open, which means, your array holding those items would be something like histories[64][64] - and what if there are more than 64 tabs open? Of course, you could set a limit: Whenever 64 tabs are open, and one would try to open another one, MI could give an error message; the other alternative: MI could give a warning that the 65th tab would replace tab 1's history? (= too complicated in programming and not worthwile for 1 case in 10,000 it seems)
And within each topic / tab, what about users juggling with more than 64 items? And what a pity when, by closing MI, all those arrays would be lost! (? OR you must not only store stem, but synch them with every again-opened topic in the next session, deleting the then not-again-opened topic histories...)
II
I even wonder if mandatory tabs are such a perfect idea. In fact, tab present that major inconvenient - see UR on this behalf, there it's going crazy - that you just open some tabs, and you are lost in your horizontal scrolling space. So I resolved this problem with my very short (= 1, 2, 3 digit-) file names, and this way, I can open more than 40 tabs at the same time, without scrolling... but this way, I'm that heavy into doing my file comments without which I'd be completely lost, regarding even the content of most of my files, let alone their current state of affairs. (And since UR does not show file names in the tabs but item names, UR is useless for me even for this one and only criterion, 5, 6 tabs there, and it's becoming more than just difficult to identify the tabs' content.)
Thus, perhaps not a toggle "show tabs yes / no" like today would be the best solution to this problem (nor that other alternative to do several rows of tabs), but a toggle "tabs vs. list", and when the user options for "list", he'll get, in another pane (that he could dock on top or on bottom of the search results / "action" pane for example), a clickable and scrollable list containing the open "tabs" = the open topics.
This way, users could use "normal length" file / topic names, thus giving expressive names to their topics, without being hindered from that by those space consideration when there are only tabs for a list of open topics. Of course, when you do a mouse-over over such a listed item, the full name would be displayed; thus, the list box would not take a lot of screen space.
I know many people prefer tabs, that's why I suggest this toggle, this alternative presentation: A real list in a box for power users juggling with many topics at once, and "normal" (= for today) tabs for that majority of users who just work on 2, 3 or 4 topics at the same time.
III
This way, the otherwise necessary comments for file names to which I refer in my thread "Third Dimension - Super Tree" (= where super tree could also be called "Master Tree" of course, since "super" is meant this way there), could be avoided: If power users could open many topics at the same time, AND give them expressive names clearly identifying their respective content, since those names would not necessarily be squeezed any more into tabs, but would be displayed in a list, then my comments there with respect to the necessity of comments would not be mandatory any more.
But there HAS to be a (medium term) solution to this problem "good visibility of, even many, files", since that third dimension is mandatory for power users. In fact, where UR has "car insurance" under "car" AND under "insurance" and "house insurance" under "house" and, again, under "insurances" (which there is no problem, by their state of the art cloning feature parallelled nowhere - their problem is the 2 GB database limit and yet before reaching that limit, not satisfying response times),
MI has "assurances" (= general and other), "car(s)", "house(s)", "car insurance" and "house insurance",
- and whenever you load "car", "car insurance" is loaded with it, by this "project level", this "super / master tree";
- whenever you load "house", "house insurance" is loaded with it, as a "project" / "working environment";
- when you load "insurances", "car insurance" and "house insurance" are loaded with it, as above;
- and so on ad infinitum (= as I explained ibidem, you could also have "children's assurance", which would be loaded with "children", together wich "school", etc., and even their doctor's medical reports and invoices, etc., and which would be loaded with "assurances", and when you load a child's "dossier" = all files regarding this child, it would be 6 or 8 systematically different files concerning that child; on the other hand, "health" would load all your health assurances, doctors' addresses, medical reports for the whole family, etc., etc.) : This way, you always have all your stuff together, but it's sort of "automatic hoisting" since your 6 or 8 topics would be in the same number of different tabs - or in your topic list box...!
IV
In any case, those lists would need to be maintained and updated automatically: Whenever the user deletes a topic, it should be deleted in all those projects; whenever the user renames a topic, it should be renamed in all those projects...
(And this is another reason to avoid comments, in order to keep it as simple as possible, but then it's necessary to have that toggle "tab vs. files as list".)
And the same applies to those history arrays! So having 64 items multiplied by 64 topics, and whenever the user renames any topic... MI would have to maintain...?!
That's technically possible, but not evident! And then, whenever the user not just deletes a topic, but shuffles it between two open topics?!!! That's a lot of synch problems, for a lot of sub-items perhaps!
And those synch routines would have to be triggered whenever somebody does the slightest thing with anything...
V
Again, UR has NOT that "different tab problem" as a "different file problem", most of the time what's displayed in multiple tabs, are hoisted parts of the original tree! Whereas you'd do all this with multiple open files...
Again, in the options of UR, there is an option for NOT including any "intermediate" (= "orientation") items into the history list, and this is done by letting the user choose the time delay after which an item is included in that list, the default being 4 sec. - just include this 4 sec. delay. Since we do click on a lot of items just in order to collapse or expand an item, just to go somewhere else, or just to access some sub-item, and at this time, in MI, all those intermediate items are included in the history, which by this is made useless: Many times I tried to use this history, by "GoLastUsedItem", I had to trigger the command 5 or 6 times, in order to go the "last" item... and then, goind "forward", going to the item I came from, it was again 5 or 6 clicks / key pressings since all those intermediate items were included in two directions.
Everytime an item is clicked on or otherwise displayed = its content shown in the editor pane, trigger a counter, and when the counter has reached 4 sec., put the item into the history, but not a second before. This way, users can freely navigate between a lot of items, and just have those items in their history that they are interested otherwise than only in navigational points... and then, if a user WANTS to have such a navigational point in his history, he just needs to "look" upon it's "content" (= even when there is no content, the navigational item just serving as a "container" item for its sub-items) for more than 4 sec., before going anywhere else, and voilà, it's included in his list!
And this list could easily updated (cf. above) since it only would contain some let's say 32 items, the latest replacing the first - 32 items suffice I think (or this list would have to be displayed in order to be useful), and could even be searched every time, since whenever it contains the latest item to be added, at any other position, there it would automatically be deleted (= instead of the item on position 1 to be deleted); thus, every item would be in the list not more than once, BUT at the latest position if it was looked upon (more than 4 sec. that is) latest.
In this way, the command "GoBackLastUsedItem" would also be a real toggle, I think, since, whenever you flip between two items (= be they in one filoe or in two different files), they would, again and again, replace one another at the latest position (= 32) of the list, the one replaced there replacing the other at position 31. Thus, for going back and forth, back and forth, you'd only trigger the first of the two commands = a real toggle for this. (And for going further back in the list, you just would have to trigger one of the two commands WITHIN those 4 seconds...)
VI
I hope very much that your programming language does offer such a timer command, but most of them do. Without such a timer, the history CANNOT be designed in a satisfying way, since it would include "navigation items" in a list that's precisely there in order to OVERCOME / abolish any navigational hindrance between two or more items (= wherever they might be) for a session.
When I was new to MI, in June, I said elsewhere, good software / MI makes you RUN smoothly, instead of settomg iè HURDLES in your way. Well, what we're doing here is exactly what I had in mind, PERFECTING a very, very good software, abolishing all hurdles, eliminating all occasions it might make us stumble.
And when that is done, such a software will be of evident excellence, making it sellable to the most demanding of minds.
Good week-end, everyone. (I know that I might be too technical, too specific for casual readers, but then, thoroughness is the essence of programming.)
I
Indeed, I thought - but lately was afraid that I had not mentioned it clearly enough - that a history of "visited" tabs / topics would be a fine thing ON TOP of an optimized item history, not something that could replace it, so having both is exactly what I had been wanting for.
Of course, there is always the possibility to do a history for each tab / topic seperately, but then again, I have often 40 topics / tabs open, which means, your array holding those items would be something like histories[64][64] - and what if there are more than 64 tabs open? Of course, you could set a limit: Whenever 64 tabs are open, and one would try to open another one, MI could give an error message; the other alternative: MI could give a warning that the 65th tab would replace tab 1's history? (= too complicated in programming and not worthwile for 1 case in 10,000 it seems)
And within each topic / tab, what about users juggling with more than 64 items? And what a pity when, by closing MI, all those arrays would be lost! (? OR you must not only store stem, but synch them with every again-opened topic in the next session, deleting the then not-again-opened topic histories...)
II
I even wonder if mandatory tabs are such a perfect idea. In fact, tab present that major inconvenient - see UR on this behalf, there it's going crazy - that you just open some tabs, and you are lost in your horizontal scrolling space. So I resolved this problem with my very short (= 1, 2, 3 digit-) file names, and this way, I can open more than 40 tabs at the same time, without scrolling... but this way, I'm that heavy into doing my file comments without which I'd be completely lost, regarding even the content of most of my files, let alone their current state of affairs. (And since UR does not show file names in the tabs but item names, UR is useless for me even for this one and only criterion, 5, 6 tabs there, and it's becoming more than just difficult to identify the tabs' content.)
Thus, perhaps not a toggle "show tabs yes / no" like today would be the best solution to this problem (nor that other alternative to do several rows of tabs), but a toggle "tabs vs. list", and when the user options for "list", he'll get, in another pane (that he could dock on top or on bottom of the search results / "action" pane for example), a clickable and scrollable list containing the open "tabs" = the open topics.
This way, users could use "normal length" file / topic names, thus giving expressive names to their topics, without being hindered from that by those space consideration when there are only tabs for a list of open topics. Of course, when you do a mouse-over over such a listed item, the full name would be displayed; thus, the list box would not take a lot of screen space.
I know many people prefer tabs, that's why I suggest this toggle, this alternative presentation: A real list in a box for power users juggling with many topics at once, and "normal" (= for today) tabs for that majority of users who just work on 2, 3 or 4 topics at the same time.
III
This way, the otherwise necessary comments for file names to which I refer in my thread "Third Dimension - Super Tree" (= where super tree could also be called "Master Tree" of course, since "super" is meant this way there), could be avoided: If power users could open many topics at the same time, AND give them expressive names clearly identifying their respective content, since those names would not necessarily be squeezed any more into tabs, but would be displayed in a list, then my comments there with respect to the necessity of comments would not be mandatory any more.
But there HAS to be a (medium term) solution to this problem "good visibility of, even many, files", since that third dimension is mandatory for power users. In fact, where UR has "car insurance" under "car" AND under "insurance" and "house insurance" under "house" and, again, under "insurances" (which there is no problem, by their state of the art cloning feature parallelled nowhere - their problem is the 2 GB database limit and yet before reaching that limit, not satisfying response times),
MI has "assurances" (= general and other), "car(s)", "house(s)", "car insurance" and "house insurance",
- and whenever you load "car", "car insurance" is loaded with it, by this "project level", this "super / master tree";
- whenever you load "house", "house insurance" is loaded with it, as a "project" / "working environment";
- when you load "insurances", "car insurance" and "house insurance" are loaded with it, as above;
- and so on ad infinitum (= as I explained ibidem, you could also have "children's assurance", which would be loaded with "children", together wich "school", etc., and even their doctor's medical reports and invoices, etc., and which would be loaded with "assurances", and when you load a child's "dossier" = all files regarding this child, it would be 6 or 8 systematically different files concerning that child; on the other hand, "health" would load all your health assurances, doctors' addresses, medical reports for the whole family, etc., etc.) : This way, you always have all your stuff together, but it's sort of "automatic hoisting" since your 6 or 8 topics would be in the same number of different tabs - or in your topic list box...!
IV
In any case, those lists would need to be maintained and updated automatically: Whenever the user deletes a topic, it should be deleted in all those projects; whenever the user renames a topic, it should be renamed in all those projects...
(And this is another reason to avoid comments, in order to keep it as simple as possible, but then it's necessary to have that toggle "tab vs. files as list".)
And the same applies to those history arrays! So having 64 items multiplied by 64 topics, and whenever the user renames any topic... MI would have to maintain...?!
That's technically possible, but not evident! And then, whenever the user not just deletes a topic, but shuffles it between two open topics?!!! That's a lot of synch problems, for a lot of sub-items perhaps!
And those synch routines would have to be triggered whenever somebody does the slightest thing with anything...
V
Again, UR has NOT that "different tab problem" as a "different file problem", most of the time what's displayed in multiple tabs, are hoisted parts of the original tree! Whereas you'd do all this with multiple open files...
Again, in the options of UR, there is an option for NOT including any "intermediate" (= "orientation") items into the history list, and this is done by letting the user choose the time delay after which an item is included in that list, the default being 4 sec. - just include this 4 sec. delay. Since we do click on a lot of items just in order to collapse or expand an item, just to go somewhere else, or just to access some sub-item, and at this time, in MI, all those intermediate items are included in the history, which by this is made useless: Many times I tried to use this history, by "GoLastUsedItem", I had to trigger the command 5 or 6 times, in order to go the "last" item... and then, goind "forward", going to the item I came from, it was again 5 or 6 clicks / key pressings since all those intermediate items were included in two directions.
Everytime an item is clicked on or otherwise displayed = its content shown in the editor pane, trigger a counter, and when the counter has reached 4 sec., put the item into the history, but not a second before. This way, users can freely navigate between a lot of items, and just have those items in their history that they are interested otherwise than only in navigational points... and then, if a user WANTS to have such a navigational point in his history, he just needs to "look" upon it's "content" (= even when there is no content, the navigational item just serving as a "container" item for its sub-items) for more than 4 sec., before going anywhere else, and voilà, it's included in his list!
And this list could easily updated (cf. above) since it only would contain some let's say 32 items, the latest replacing the first - 32 items suffice I think (or this list would have to be displayed in order to be useful), and could even be searched every time, since whenever it contains the latest item to be added, at any other position, there it would automatically be deleted (= instead of the item on position 1 to be deleted); thus, every item would be in the list not more than once, BUT at the latest position if it was looked upon (more than 4 sec. that is) latest.
In this way, the command "GoBackLastUsedItem" would also be a real toggle, I think, since, whenever you flip between two items (= be they in one filoe or in two different files), they would, again and again, replace one another at the latest position (= 32) of the list, the one replaced there replacing the other at position 31. Thus, for going back and forth, back and forth, you'd only trigger the first of the two commands = a real toggle for this. (And for going further back in the list, you just would have to trigger one of the two commands WITHIN those 4 seconds...)
VI
I hope very much that your programming language does offer such a timer command, but most of them do. Without such a timer, the history CANNOT be designed in a satisfying way, since it would include "navigation items" in a list that's precisely there in order to OVERCOME / abolish any navigational hindrance between two or more items (= wherever they might be) for a session.
When I was new to MI, in June, I said elsewhere, good software / MI makes you RUN smoothly, instead of settomg iè HURDLES in your way. Well, what we're doing here is exactly what I had in mind, PERFECTING a very, very good software, abolishing all hurdles, eliminating all occasions it might make us stumble.
And when that is done, such a software will be of evident excellence, making it sellable to the most demanding of minds.
Good week-end, everyone. (I know that I might be too technical, too specific for casual readers, but then, thoroughness is the essence of programming.)
Did I say so before? It bothers me for some months now, but I think I've never had time to mention it: Of course, the FAVORITES should be accessible by keys / key combinations / "accelerators" as they call them, and NOT by assigning them such a key in the Menu "Tools" - "Keyboard Shortcuts", but immediately, i.e. when doing the command "this item as a favorite please" (= "Favorites" - "Add current topic").
I know there's the problem that users could mix up those short keys with any other, command, short key, in the aforementioned options menu, but let's take that risk, with an "overwrite" warning if ever possible.
Because, if you, Petko, let us assign favorites only to a certain group of shortkeys, let's say, shift-alt-xxx, we'd be seriously limited to such a group, first, and could not use such combinations to any command shortcuts, second. Thus it would be nice to not restrict our command assignment possibilities by this, and nethertheless give us the possibility to assign favorites to shortcuts.
Thus, another piece of work where a new feature will have to be integrated into another, the command assignments, but having given an extra access to it, in the "Make it a favorite" dialogue.
Technically, those favorites assignments could be restricted to a number of 20, let's say, that would be accessible (= reassignable / deletable) in the above-mentioned options menu, like any "command assignment", but they should be assignable (AND reassignable) in the favorite dialogue.
I know that by accessing the favorites menu, then a single shortkey, by position of the favorite entry, this accessing a favorite could be implemented in a simpler way, technically, but it would not be mnemonic for the user, since, depending on position in the tree, the short key would be a "1" or a "t", when in fact, the item begins with, e.g., with an "e", and thus you would like to assign it something like alt-shift-e.
This is a very important enhancement for every user. At this time, I do NOT use ANY favorites, for their lack of assignable short keys.
I know there's the problem that users could mix up those short keys with any other, command, short key, in the aforementioned options menu, but let's take that risk, with an "overwrite" warning if ever possible.
Because, if you, Petko, let us assign favorites only to a certain group of shortkeys, let's say, shift-alt-xxx, we'd be seriously limited to such a group, first, and could not use such combinations to any command shortcuts, second. Thus it would be nice to not restrict our command assignment possibilities by this, and nethertheless give us the possibility to assign favorites to shortcuts.
Thus, another piece of work where a new feature will have to be integrated into another, the command assignments, but having given an extra access to it, in the "Make it a favorite" dialogue.
Technically, those favorites assignments could be restricted to a number of 20, let's say, that would be accessible (= reassignable / deletable) in the above-mentioned options menu, like any "command assignment", but they should be assignable (AND reassignable) in the favorite dialogue.
I know that by accessing the favorites menu, then a single shortkey, by position of the favorite entry, this accessing a favorite could be implemented in a simpler way, technically, but it would not be mnemonic for the user, since, depending on position in the tree, the short key would be a "1" or a "t", when in fact, the item begins with, e.g., with an "e", and thus you would like to assign it something like alt-shift-e.
This is a very important enhancement for every user. At this time, I do NOT use ANY favorites, for their lack of assignable short keys.
Fred, it is purely a technical reason why favorites have no shortcuts yet, but there should be a solution for this problem.
Petko, For the above-discussed feature of a timer for the "visited items list", please see my post in "Timers" since one timer function behind the scenes could be made useful for many such derivated timer functions, including a BIG "visited items list" enhancement.
I just had an access violation. I'm not going to try to repeat it, but can say how it was going to it. I wanted to search something, had adjusted the search options (= by mouse clicks), the focus was in the search field (containing no text) then.
Then I thought it a good idea to save again and pressed control-shift-s for "save all loaded files" - and I got the access violation. I finally had to kill MI in order to reopen my files.
I just lost few add-ons from this site since I had been shuffling around between MI and here, and I had saved some minutes ago, so no problem for me this time. But then, I had said often I just save after 2 or 3 hours' editing and shuffling around, and then I would have a big problem now, so it's worthwile to have a look; indeed, my changes were lost (but nothing else I hope).
Normally, I think, focus = cursor is in tree or in text pane when I do "save all", not in the search field as it was now, so I suppose this triggered the malfunction. (Memory issues are always possible but then, I very rarely get access violations, last time at the very beginning with MI, 5 months ago, I have quality memory, 2 GB for XP, and my memory was not heavily loaded, just 4 tabs in IE, nothing big not even in MI, no other program.)
ADD-ON:
No, it wasn't just an idea, it's replicable.
Since I didn't lose any other data last time, I saved all, then put an additional character in a text field, in order for the "save all" command really having to save anything. Then I put the cursor into the search field and got rid of any text there, the cursor being always in that field. Then I did control-shift-a for "save all" again...
and this time, access violation like last time when by saving all, the cursor was in the search field.
Problem identified, problem half-resolved, they say in German.
Then I thought it a good idea to save again and pressed control-shift-s for "save all loaded files" - and I got the access violation. I finally had to kill MI in order to reopen my files.
I just lost few add-ons from this site since I had been shuffling around between MI and here, and I had saved some minutes ago, so no problem for me this time. But then, I had said often I just save after 2 or 3 hours' editing and shuffling around, and then I would have a big problem now, so it's worthwile to have a look; indeed, my changes were lost (but nothing else I hope).
Normally, I think, focus = cursor is in tree or in text pane when I do "save all", not in the search field as it was now, so I suppose this triggered the malfunction. (Memory issues are always possible but then, I very rarely get access violations, last time at the very beginning with MI, 5 months ago, I have quality memory, 2 GB for XP, and my memory was not heavily loaded, just 4 tabs in IE, nothing big not even in MI, no other program.)
ADD-ON:
No, it wasn't just an idea, it's replicable.
Since I didn't lose any other data last time, I saved all, then put an additional character in a text field, in order for the "save all" command really having to save anything. Then I put the cursor into the search field and got rid of any text there, the cursor being always in that field. Then I did control-shift-a for "save all" again...
and this time, access violation like last time when by saving all, the cursor was in the search field.
Problem identified, problem half-resolved, they say in German.