|
Thank you very much, Kyle, for thinking this over, and for responding!
Obviously, multiple hours of programming for that would be out of the question, but perhaps, we misunderstand each other in some details, and there might be some quite easy solution?
FIRST
I admit I made a big mistake, not considering that many users will have several (or in my case, even multiple) UR DBs; of course, you could write a routine that will check any UR db when it's loaded, for "old vs. new flag number" (7 vs. 32 e.g.), and when it's the old number, it would automatically update the Status table:
(instead of "Red2...26", I already put in "Black1...25", see below)
(it seems that for Black, those "255" would have to be replaced with "1" though?)
INSERT into Status (Name, StatusBlob, UncompressedSize, Color)
VALUES
(1001, Black1, "Blobvalue", 2862, "255;0;-1;0;"),
(1002, Black2, "Blobvalue", 2862, "255;0;-1;0;"),
(1003, Black3, "Blobvalue", 2862, "255;0;-1;0;"),
(1004, Black4, "Blobvalue", 2862, "255;0;-1;0;"),
(1005, Black5, "Blobvalue", 2862, "255;0;-1;0;"),
(1006, Black6, "Blobvalue", 2862, "255;0;-1;0;"),
(1007, Black7, "Blobvalue", 2862, "255;0;-1;0;"),
(1008, Black8, "Blobvalue", 2862, "255;0;-1;0;"),
(1009, Black9, "Blobvalue", 2862, "255;0;-1;0;"),
(1010, Black10, "Blobvalue", 2862, "255;0;-1;0;"),
(1011, Black11, "Blobvalue", 2862, "255;0;-1;0;"),
(1012, Black12, "Blobvalue", 2862, "255;0;-1;0;"),
(1013, Black13, "Blobvalue", 2862, "255;0;-1;0;"),
(1014, Black14, "Blobvalue", 2862, "255;0;-1;0;"),
(1015, Black15, "Blobvalue", 2862, "255;0;-1;0;"),
(1016, Black16, "Blobvalue", 2862, "255;0;-1;0;"),
(1017, Black17, "Blobvalue", 2862, "255;0;-1;0;"),
(1018, Black18, "Blobvalue", 2862, "255;0;-1;0;"),
(1019, Black19, "Blobvalue", 2862, "255;0;-1;0;"),
(1020, Black20, "Blobvalue", 2862, "255;0;-1;0;"),
(1021, Black21, "Blobvalue", 2862, "255;0;-1;0;"),
(1022, Black22, "Blobvalue", 2862, "255;0;-1;0;"),
(1023, Black23, "Blobvalue", 2862, "255;0;-1;0;"),
(1024, Black24, "Blobvalue", 2862, "255;0;-1;0;"),
(1025, Black25, "Blobvalue", 2862, "255;0;-1;0;");
Here, it appears that ur.exe would / should (?) have some general routine for updating existing tables, upon being opened / loaded by ur.exe, "behind the scenes"? Since otherwise, since 20 or more years, UR would be limited to the table design from 20 or more years ago?
If that really was the case - invariable table design, and if you didn't want to implement such a (general, generic) update routine "check and update in case, upon loading", you could simply change the DEFAULT flag number for any NEW UR db (etc., see below), whilst we, the users, would use SQLite.exe (or another front-end) in order to update our EXISTING UR DBs one-by-one, according to the above "INSERT"; I have to say here that I do NOT know how to really write blobs, but I had said, let's just use the very first flag('s blob), for all the additional flags, and let the user then change those they need, to the values they need / choose, so those 25 additional blobs will be identical to the very first (existant) one, and there should be a solution for user-side blob creation then.
Also, my mistake, the first flag (994) will not systematically be named "Red" anymore, for existing databases, but the flag itself remains red; for example, my "yellow" flag (and which remains yellow as flag, but I don't display the flags itself, just use flags for tree item formatting) is black-bold.
So, indeed, you'd have to think about the flags themselves, and it appears a little bit "unfortunate" that at some time in the past, you "mixed up" flags, and then their assigned tree item formats: just the latter would be needed "in numbers" (ideally 32), NOT also the flag colors:
So you might "leave alone" the flag colors, for the additional flags, just make available their dialogs, as for the exitant ones, and "all the worse" then that the flag color will not correspond to the settings (see my above example of yellow flag for black-bold text); but then, it would probably be more elegant (and just some lines of additional code) if, instead of multiplying the very first flag, the red one (994), you created a "default flag", a black one (!), as 1001, and then, this (in fact, always) black flag would then be multiplied as flag 1002 to 1025 (and thus, the default names (and which the user could change, as they now can change the names, etc., for 994 to 1000) for 1001 to 1025 would be Black1... Black25 (instead of Red2... Red26) - all with (invariable) BLACK flags, but with variable names, and variable settings for the item title formatting.
(IF that might not be too much work, AND you want it to be really elegant, you might write the necessary code for all flags (1 to 7 (except 7's special "Done" symbol) to adopt exactly the (in case "individual", "custom") color which the user might have attributed to the respective item title formatting - or just, as said, leave flags 1001 to 1025 black, which will be fine for most users I think, since, at the end of the day, and since the flags do NOT come with any additional info to the item title color (except for flag "Done"), most users will probably not show the flags anyway but rely on the (sufficient) title formatting/coloring).
So, according to me here (see below though), 32 flags instead of just 7 will be no problem, AND (I continue to suppose that) just SOME flags more, or 25 flags more, will be the same programming work (see below).
But we will need a way to "update" our existing DBs indeed, in some way. (I'll treat the "empty" sub-sub context menu, for existing, not-updated DBs below.)
SECOND
"1) allowing flags to be added, removed, and re-ordered."
I don't think that's (overly) necessary; the number of flags (currently 7) should remain fixed (then ideally 32; thus, no adding / removing routines (together with all the dialogs such implementation would imply) necessary at all); currently, the flags can not be re-ordered, but I admit the user would be really happy to be able to re-order them, for a much bigger number. On the other hand, you will have simple, just VISUAL re-order routines at hand, which is to say, it's totally sufficient that the user re-orders within the dialog, whilst the processing will not be determined by the position (which is not necessary to retrieve then except for the "presentation" within the dialog), but by the flag's statusID - I admit though that applying a generic, purely visual re-ordering routine to the flag dialog, would cost an additional hour (incl. the storage of the order for "next time" opening the db in question).
"2) long lists of drop-down menus when it now extends to 20- or 30-some items. A submenu of a submenu is more work as well."
As I said above, I think it's acceptable for every user to have 32 entries within the flag dialog; as for the flag content sub-menu and its possible sub-sub-menu, the sub-menu has currently 8 entries (incl. "None") and thus has an acceptable size, the same would be true for 15 entries, and there again, on most screens, the sub-menu would "flow" just below the "Flag" entry in the context menu, whilst more entries than 15 would probably cause the sub-menu to "flow" then somewhat upward... BUT (I might be mistaken here): isn't that "move upward" automatic? would it have to be coded instead? If it's automatic, why not put all 33 (incl. "None") entries then into that sub-menu, and its "higher-up" entries would then be displayed more or less to the right of the context-menu, instead of beneath it, or in other words, a large part of the sub-menu would be displayed to the context menu, according to the user's screen size / resolution, but that would not be harmful in any way; thus, if the creation of a sub-sub-menu to a context menu is too much "fuss", code-wise, it will not be really needed after all then.
I admit though that the (preferable, indeed, but simple, just visual) re-ordering from the flag dialog would have to be replicated within the flag context menu's sub-menu, but I hope that might be technically easy, i.e. the sub-menu might not be some "fixed text" (which would be quite awful, code-wise, beginning with the shortcuts, also to be replicated here), but would be a variable (array) which would be invoked as the sub-menu text in runtime?
"3) the Flag toolbar having to dynamically size to how many are defined in the current DB, and handling switching between DBs which could have different numbers of flags."
See 1): If there is a fixed number of flags, such resizing questions / problems will be avoided; btw, I have never seen a "flag toolbar"? And in "View - Toolbars", there is no menu entry "Flags" either? And there is no need for a flag toolbar in the future whatsoever, according to me.
"4) changes in the UI in many places to handle a variable # of flags."
I fully understand your concerns but as said, let's envision a FIXED number of flags: as it is now, just a (hopefully much) greater number.
So here, I will finally have to comment upon the problem "existant DBs vs. new DBs", briefly mentioned in FIRST: If, for any reason - too much new code to write in case? -, you might discard the above-mentioned "check, and update in case, upon loading a db" routine, which would then automatically add the (e.g.) 25 new flag records to table Status, we'd have a problem indeed, I have to admit that:
Since, as I said, the (hopefully) next (major, obviously) UR version would come with (hopefully) 32 entries in the Flag dialog, and 33 entries in the Flags context menu sub-menu (most of them black flags with default "black" settings (as described above); then, if the user, for the current db, has NOT yet updated the Status table, or if we have a user who will not be able (or willing) to do so, and if that user then tries to assign any flag 1001 upward, we'll crash the db or ur.exe, OR you would have to write quite some code... so it'll be obviously be "preferable" - no: mandatory! - to have UR automatically check, and update in case, every UR db opened by ur.exe: this seems unavoidable indeed, notwithstanding my personal eagerness to do the necessary table updates myself in case: that's not viable for the user base in general.
On the other hand, I think I have read somewhere that between v3 and v4, you changed UR's db "format" indeed? So, UR's table sets have not stayed unchanged for 20 or more years, right? Thus, I suppose that the routine I suggest above, to check the flags count on any UR db upon loading, and to update the Status table in case, should be of no real problem to implement? (Alternative: check if StatusID = 1001 in table Status exists - it goes without saying that any code just would need to check to "regular" situations, not for crazy people's playing around results, e.g. adding, user side-wise, just some additional flags on their own: if you wanted to intercept risks of users' deliberate, noxious hampering with their UR DBs, your coding work would never end...) (This check would just cost some milliseconds on every UR db start, and not many more ms whenever then the (once-and-for-all) update is needed.)
"5) currently, keyboard shortcuts are available (Shift+B for blue, etc.), would have to re-think this to allow more customization and more shortcuts, possibly like what is supported for favorites, but it would become unwieldy to have and need to recall dozens of shortcuts"
Not at all, according to me, or am I mistaken? Oh, yeah!
I had said above, you just would implement, for the additional flags, the user's possibility to assign a shortcut, and that should be more or less automatic (i.e. a generic thing) for every (new) command you implement, and it would (have been) up to the user to then assign, to THOSE flags they need / would want to use on a regular basis (i.e. not just from the context sub-menu), the shortcuts of their liking, just as they do for other commands.
After your remark, I now discover that the 8 flag shortcuts (7 flags plus the "None") are NOT available from Tools - Customize - Keyboard (as I had assumed), but your assignments +^1...8 (which obviously pleased me, so that I hadn't seen the necessity = searched a way to change them!) have been FIXED by you: oops!
But, couldn't you change that, instead? And perhaps, implement another Category within the Tools - Customize - Keyboard dialog? Where then the 8 current flag shortkeys would be preset as defaults (or even would remain fixed?) but the (hopefully) 25 further entries would be freely assignable? Here again though, their (current, user-assigned) name would then be "filled in" into the dialog in runtime, from the array or similar which would also serve to fill the Flag context sub-menu... well, there would of course be the alternative to just number those instead, "Black1...25" here, and that would even become realistic IF you systematically added a number to every flag, of course not 994...1025, but just 1...32, and then, in the Flag dialog, and in the Flag context sub-menu, the entries would be (1...32) UserAssignedName, whilst in the Keyboard dialog, the entries would be called by Flag 1...32.
Anyway, many users would NOT use all 32 flags indeed, or even if they do, they would not feel the need to assign shortcuts also to rarely-used flags (I would probably assign 16 flags to shortkeys, reaching out for the other 16 by context sub-menu), so sacrifying (!) 32, and then even fixed (!!!) shortcuts for flags, would be "insane", if I may say so... ;-)
Btw, I know that the current Keyboard dialog Categories all represent one main menu entry, but so what? Since the flags would be a rather long list in themselves, they would need their own "Category" notwithstanding, but if you want to remain "consistent", Alt-l for "F&lags" would be available (but would remain an empty main menu, so I'd call that over-consistency...).
And I discover now that's it's similar, and then not (!), with Favorites indeed, since the Keyboard Category "Favorites" is almost empty - NO shortkeys for specific Favorites -, BUT within the "Favorites" main menu, there is an entry "Organize", which on its turn opens a very "rich" dialog, together WITH keyboard assignments indeed! (It becomes obvious here that I've never used Favorites myself, using my own macro system instead, for navigation, and also for moving items.)
Thus, it becomes clear as day that you should, for flag shortkey assigments, as for flag format assignments, totally enhance your current Flag dialog, using most of the code base of your Organize-Favorites dialog, and since you obviously already have the necessary routine to "mix" (additional, user-assigned!) shortkey assignments from that Organize-Favorites dialog, with (equally user-assigned) shortkey assignments, stored from the Customize-Keyboard dialog Categories (i.e. those two groups of shortkey assignments obviously "meet" somewhere, instead of mutually overriding each other), an (partial, i.e. insofar as it applies) adaptation of the Favorites settings routine (incl. its dialog) to the Flag settings routine is the only reasonable - and even quite easy if I dare say - solution to this problem.
Then, in there, you might have current flags 1...7 in initial position 1...7, with default shortcuts as currently, and (hopefully) 25 more, named Black1...25, as detailed above, and you would make the default shortcuts user-re-assignable - most users, me included, would probably not ever change them anyway, but why make those 1...7 "too special", even when it's not needed... and all of these (hopefully) 32 items would then be freely movable within the 32-items list pane, just as already are the non-fixed-number entries in the Favorites-Organize dialog - the code is obviously available, and, as said, for any other means than just the display, the items would be identified by their ID.
"6) ensuring backward compatibility with existing data"
See 4) above: Indeed, my initial leaving out the need for a "check and update in case" subroutine upon db loading was illusionary, but from then on, there should not be any problem with existing DBs.
"7) optimizations could be necessary to handle 4x as many flags as before without lag."
I understand your concern; we're not only, and not even mainly, speaking of flags, but of tree entry formatting, which implies quite some visual tree component updating, but: in regular (!) use, and with about 50 lines (rarely more) on a normal screen, just less than 10 different ones will be displayed concurrently in most instances - but we would need many more in order to choose from that is -, so the rendering time should not really be affected; as for the above-described, special, analysis and similar, tasks, while it's true that then, sometimes even 20 different formattings / colors will be present within the visible part of the tree: other software alternatives to process the same tasks (i.e. "flowcharters", "process management tools", etc.) are so cumbersome, slow down the user-pc interaction so seriously, by their demands of multiple user interactions for even tiny sub-tasks, that UR users will certainly be willing to accept slight reaction times upon scrolling, being aware of their UR tooling's advantages. (See below for my idea that your speed consideration might mainly apply to (rare) "jerks" ("kiddies"?) who multiply fonts...)
"More like a couple hundred hours than a couple."
It has become obvious from the above that my suggestion of a cost of 2 hours was ridiculous, but I know, and seriously, suggest a cost of 10, perhaps 12 hours - obviously not counting our "preparatory work" here. ;-)
(THIRD to follow ("Too long"))
|