Originally from https://www.kinook.com/Forum/showthread.php?t=5716
I had suggested augmenting the number of available flags; I understand this would imply some work, unfortunately, but just 7 flags is a much too tiny number, in two senses:
1) For one, it would oh so much convenient to have some "real" number of flags, say, 20, 24, 32, all the more so since such a number - ONLY would permit to COMBINE more than just one "category", in the way (I explained then already) of:
- category value "red"
- the same category value "red" but "bolded" = with some additional "ToDo" value
- ditto, but italicised instead, for some other "ToDo" or other "hint"
- as before, but italicised additionally to being bolded
Since these 3 or 4 would already "eat" 3 or 4 different ones, from those 20, 24, or 32, since I fully understand from your current "item tree format" implementation, a "second-level" technical combination, i.e. the same "red" value, then in variants "bolded", "italicised", etc., would ask for LOTS of work, changes to the tables of existing UR DBs included!
Thus, I understand that we cannot hope for such an "elegant" solution, and will have to multiply the "flags" (i.e. StatusIDs), whenever we want / need to combine some color plus bolding, etc. - hence, as said, a quite "high" number, 20, 24, 32, would come really, really handy indeed.
2) On the other hand though, even just SOME MORE flags would be an exponential (sic!) step ahead, since that awful number of "just seven" simply does NOT even suffice for the simplest (sic!) of needs: not even for the most stringent tries to REDUCE the "needed" flag number to the max!
We all know that "7" is a mythical number, but it's simply not enough, and WHEN I try to "reduce my needs to the max, and by all means indeed", I need 9, 10, 12 (according to the respective "situation")... but not 20, 24, 32: such a number would be "near ideal" (20, 24) or really "ideal" (30, 32), i.e. would permit "freely" working, i.e. without having to restrain your needs...
but as said, even 10, 12 possible flags, instead of just 7, would make our work "a world apart" from the impossibility to make serious use of flags today, since please consider:
- we need (regular-black) bolding for important items, important by hierarchy (levels 1, 2, 3), or by "weight", by "inherent importance"
(it would be ideal to have a sufficiant flag number available to then also bold category items (red, blue...), but it's obvious that with just 10, 12 flags in total, we would (as we have now) to DECIDE: do we apply the category, OR the importance, so the importance "outweights", and the category attrib vanishes)
(and ideally, we would prefer two degrees of importance: "important", and "very important"...)
- we need an attribute-by-flag for "must do something about it"; here again, the ideal would be to have available a "larger" number of flag formats, in order to differentiate: "must edit again", "must get info for it", "redo it totally", and so on, similar to GTD "contexts" or ToDo categories; it's obvious that currently, or then with just 10, 12 flags in total, we can either differentiate those ToDo's, OR we can use some categorization, not both, so:
"importance" and "ToDo" will each just have ONE value, all sub-values combined, and for those, we must then rely on our memory, or put some comment into the Item Notes field, or the like...
- then, we need a flag "discarded", and here again, ideally, we would need several degrees, i.e. "definitely discarded" (which, according to our "project", is NOT to be thrown into the item bin, BUT to be preserved in its original - or near its original - location), then "probably to discard", and even just "might be discarded in case"
and here again, with 10, 12 flags in total, if we have categories in our db, we would be forced to just apply one single "discard" for all those degrees of (in case just possible) "filing-away", and for all these we obviously would need today's "Done" flag, in spite of the fact that we would greatly prefer to have one flag "Done", and at least one distinct flag "Discard".
As we can see, the strict minimum of "ToDo" flags is already 3 or 4, and that currently leaves us with just 3 or 4 flags to categorize... and, boom: Not even that mythical, fallacial number of "7" is available anymore...
and that's why I've said, above, that even 10 or 12 flags, instead of the current 7, would open up another "world" of "workflow":
- since for one, we would have the absolute minimum of "ToDo" indicators (3 or 4),
- AND we would have preserved the mythical number "7" for categorization
at the same time, whilst, obviously, most categorization efforts will FAIL with just 3 or 4 flags left for that, and that's my hitherto, and current situation with UR, in spite of e.g. your absolute marvelous "Tree - Show - Level" command group:
In your - mostly fantastic! - design of UR, some 20 years ago, you obviously fell into the "mythical 7 fallacy" trap, not considering in time that the "7" applies, if ever, to homogeneous, not disparate entity groups, and there are those "ToDo"s and similar, and there are attributions, like ontological highlight needs (what I call "categorization" above), or then attributions to some members of a team, etc.
And, as said, those formats would have ideally been attributable combined, but I fully understand that we either will have to dismiss combinations altogether (in case of 10, 12 instead of 7), or then do them ourselves (in case of 20...32), since otherwise, you would have to do real hard work, for quite little effect, since, if we have got the necessary number of available (default) formats to "fill up" then with the values of our needs, we CAN do it ourselves indeed.
HENCE:
I have had a look into the alleged work that would imply on your side, Kyle:
StatusID, in table Status: Null or 994...1000 (7 entries); technically, there does not seem to be a problem to continue the range with 1001...1005 (=12 flags instead of 7, fixed list display length), or with e.g. 1001...1025 (=32 flags) (cf. those AttributeIDs "above 1000" in the table "Attribute" where counting from 964 upward to 1000 also showed an insufficient number range after all)
When I look up the tables, etc, with "IconID", I get the tables/indexes/views/triggers:
Item
Status (see above)
idxItem_StatusID (order: ascending, no problem here)
view0Template (similar to table Status, no problem here)
triggers for status / icon changes, no problem here again:
trigItem_RIAI
trigItem_RIAU_StatusID
trigStatus_RIBD
trigStatus_RIBU (and the error message in case)
None of these, except for the addition of the 1001... numbers in table "Status", will have to be changed it seems, see below.
The context menu in Data Explorer, entry "Flag": fixed length and fixed order currently: "None", then 994...1000; just adding 5 more (i.e. leaving the order unchanged) would by hyper-simple (fixed length again, then just 13 entries instead of 8).
The dialog window available from menu Tools - Flag: the pane is resizable even today (which for the user perspective doesn't make sense currently, obviously), ditto for the list component in it, so I suppose both already (!) and automatically adapt to the number of entries (and the same may even by true for the Data Explorer context menu above).
Columns in that dialog: Name, and (checkbox) Hide; now the interesting thing "here" is that there is NO "Hide" column in table "Status" (but Name, StatusBlob, UncompressedSize and Color, on top of StatusID, obviously), so the "Hidden" status is NOT preserved in the respective db, but (volatile again, from the db's pov) in the UR program itself...
which arises the question if you might perhaps change this design, since obviously, a specific (but inherently volatile indeed) "hidden" status will be needed, specifically to the db in question - as, very thankfully!!!, the flag formatting already is... and yes, it's evident that our flag number needs will vary from one db to another one...
Currently though, if you add more flags, you would have to adapt the UR code, too, as far as the "Hidden" array (I suppose) is concerned, but you would probably more or less just have to enlarge the array.
As for the additional default values, this could be done very simply: You might take the color and the statusblob values from 994 ("Red"), and rename them Red2...Red32 (ideally), and it'll be up to the user then to adjust them for real use in case.
You would also have to add the necessary (empty) shortkeys; up to the user then to assign them as far as they are "important" enough (also "important" enough to remember the shortkeys then, the rest of them just being available by context menu: see below (but let's remember the strain on user's memory strain would not be exaggerated if they assigned, e.g., ^1...9 to colors, and then +^1...9 to the same colors, but boldened, and !^1...9 to the same colors again, but italicised))
Thus, this quick-n-dirty solution would take 90 minutes of coding time, admitted that it would be simplified:
- either you just add 5 more flags, and nobody would complain about those, stretching the context menu list and the list in the dialog
- or you, ideally, add up to 25 more flags, and then, some people might complain about the exaggerated length/height of the (then 33 items long!) list in the tree context menu...
BUT with just some (15?) minutes more (You're a
brilliant software engineer, as we all know!), you might do a 14-entries context sub-menu instead, with "None", flags 1 to 12, and "More...", which sub-sub-menu then would display 20 more flags (total: 32). (Alternative: the flags "over 12" would only be available by their respective shortcuts, in case, but the "More..." solution, from the necessary additional code, would be just a minimal additional effort.)
And everybody would be oh so happy! ;-)