Opening Another File / Tab Order

Legacy MyInfo versions topics and topics that are no longer relevant
Posts: 216
Joined: Wed Jun 23, 2010 8:07 pm

Opening Another File / Tab Order

Post by Fred »

Re 5.5 - Okay, Petko, that's a word... but I'm afraid January 13, the end date of the beta version, is a little bit early in order to release a final 5.5 - thus my thinking of 5.6, 5.7 - just for the little things, that's understood.

A subject that has not yet been addressed:

Whenever you open another file, as yet, and with tabs on, the new file will be "inserted" to the end of the line; after this, you must then sort the tabs if you want them to be sorted. I understand there are situations where people want to have it this way: First the "important" files, then the "additional" files. I want to have them another way: The "important" files (with tabs in a certain color) first (=mostly automatically loaded), then, when I'm working, again and again I load other files with respect TO these "master files", "sub-files" if you want. The tabs of these sub-files are normally colored, and every time, I must "manually" sort the tabs (= trigger the command for that), in order to have it my way, which is:

1 master file in red, several sub-files in blue, 1 master file in red, several sub-files in blue, etc., etc. - This gives me some order in my workspace, on an organizational level, and the optics reflect this order.

Thus, I would be very pleased to have a command = toggle: Open files at the end of the string / Open files after the current file.

Manually triggering this "sort tabs" after loading files is not really handy, since when you open several files at once, the "sort tabs" command, entered manually, can get lost, so you must wait for all those additional files to be loaded, and then only trigger the "sort tabs" command, which is user-unfriendly.

Re 5.5 - Originally, I wanted to title my post "The Good, the Bad and the Ugly", but indeed, the spectacularly ugly things seemed to prevail at first sight. All those additional frames are VERY handy, BUT they must be useable in a way that you can use MI whole-screen-wise, AND display / use those frames, WITHOUT them hiding your work!

Thus, the search field takes a LOT too much space on the screen for people like me who want to hide all (other) toolbars (and have a look at those screen resolutions of 800x600, for which such a search field is simply not possible) - if it were UNbound, I could at least put it to the right of the menu, where it would be ugly but without taking unnecessary space - the best solution would be to insert it into the main frame, by option (like in AS, oh yeah, one thing they did not in a dumb way).

The same option would apply to the search result frame, the favorites frame and, if you are really kind, the recently viewed items frame: THEY all should be BOUND (as the search field is now), i.e., they should be dockable to the right (or any other) side, and in any order, the 3 of them, one above the other, and PERHAPS - there would be more programming involved then - they could be "UNbound" WITHIN their special frame, i.e. they would all be to the right of the text pane (so as to not overlap the text!), but within their frame, they could overlap then, in any respective height, each other. (For people who would absolutely need them unbound = placeable anywhere on the screen, you could make this an option, and indeed, when people work on 2 screens at the same time, there would be some interest in this, but most users, most of the time, would like those frames be within MI's main frame (but not overlapping the text).

With the second text frame, it would be something similar, for 2-screen usage, your current unbound pane isn't bad at all, but please make it by option only. The normal behavior of it would be to automatically resize the first text frame, taking some place to the right of it, and, normally, its behavior would be to HIDE all other frames: search results / attributes, favorites and perhaps even last-viewed items list (again, normally, people should use search results, attributes, favorites and last-viewed items not concurrently, so why don't use ONE single pane for those, with tabs... and shortkeys?!). (The deluxe version would be, have two assignable frames, top and bottom, and to let the user chose to which frame he would like to assign this or that type of list... for later on, perhaps?)

You could do another toggle (assignable to shortkey), "second text hiding other panes yes / no", or a toggle, "show other panes", or the current toggle "show search results pane yes/no" would AT THE SAME TIME be a toggle for the second text pane (whenever that second text pane is activated), the main text would take the remaining space.


Tree and Text:
Tree on the left 1/4, Text on the right 3/4 (or whatever, but in this range)

Any list pane on the right, with those above:
Tree 2/8, Text 5/8, Panes (all of the same width!) 1/8 (or whatever, but in this range)

Tree, Text, SecondText:
Tree 2/8, Text 3/8, SecondText 3/8 (or whatever, but in this range)

And now, Any list pane on the right, but with SecondText displayed:
Tree 2/8, Text 3/8, SecondText 3/8 visible OVER the (invisible) list panes

And with toggle Hide/Show List Panes (instead of just toggle Hide/Show Attributes Pane):
Tree 2/8, Text 4/8, SecondText invisible (but activated, and accessible by just doing the same toggle) 0/8, List Panes 2/8

The "trick" here is twofold: Reducing the toggles to a minimum, and automatically elarging, by this toggle, the main text, and reducing its width when you show the secondary text.

Technically, this should be done by default values (depending on screen size if possible, since on a very large screen, the lists should not take too much space), and then, the user could resize the widths of those subframes at will, AND those user-defined numbers would be STORED between sessions, and of course, between the toggles...

It's not difficult to make something really useful, even when implementing just basics. What I want to say is, between the deluxe versions developed by me months ago and absence of usefulness, there is always something intermediate that is easy to implement AND really useful. As proven again here in some lines.

Thus, all list subframes should be dockable, and of the same width, and should obey to the same toggle show/hide (= toggle 1), and if there is a second text activated (=toggle 2 or rather a system variable "secondtexton=yes", which will be killed when the user closes the second window), the toggle 1 will not only hide / display those list frames, but also resize the text frames and the list frames, accordingly to the defaults first, and then accordingly to the user "numbers".

Since I do not need more than the time for writing down such a thing, it would always be a good idea to just ask me, I wanna do this, I want it simple, what's your most basic proposition? And you're done, without running into wrong directions.

Of COURSE there is "The Good" already, but I see absence of delight, of congratulations from the part of my fellow users too - we're more than 2,000 "members", as the forum site indicates...

But I'm here to give REAL advice, I think of these matters in a way that my advice is helpful. So let's work on the little things even when there will not be the GREAT APPLIC soon. ;-)