|
|
|
|
#1
06-24-2023, 06:45 AM
|
|||
|
|||
|
Add more flags
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! ;-) 
|
|
#2
06-25-2023, 02:57 AM
|
|||
|
|||
|
Yesterday, I forgot to mention a very important aspect (HINTS):
UR users may have done analysis/synthesis tasks with so-called "flowcharters"; they are either expensive (e.g. MS doesn't include Visio in their "Office" anymore) or (or even "and") quite bad, functionally, since most of them slow down (!) your thinking process, since creating the "right" symbol ("shape") in any such situation isn't as fast as you'd wish; you might download VUE though (free) in case, which visually at least is very pleasing, and with lots of (immediately available) color shades (see above for "degrees (sic!) of (possible) discarding" and similar); as for its symbol Notes (i.e. the very important "developments" texts which inferior programs like "Scapple" continue to lack), they can be correctly exported / re-imported (into UR e.g.) from its XML output (and then just a minimum of regex) whilst pdf output is highly problematic, as with pdf output of many other programs (paragraphs can't be identified from each other anymore). On the other hand, it's perfectly possible to do most of these tasks, and much speedier, in a program like UR, on the condition that - it comes, as UR does (and not many such programs do...), with perfect, and immediately available item (and even sub-tree in case) cloning - you make use of that cloning, and you also make use of "separator items", in order to create clusters (just create an item with 10, and another with 20 (e.g.) underlines (_), then copy those to wherever in the (sub-) tree they are needed - you make use of the sub-tree creation functionality, obviously, and you might benefit greatly from the newly implemented Tree - Show - Level ... command group, and as said before, in both directions, i.e. "going down" and "going up" - you will have 2 dozen (or so) item formats, in order to distinguish the different element kinds of your decision / analysis process, hence my asking for 32 flags, instead of just 10 or 12 (whilst my personal, immediate problem in UR would be resolved with just 10 or 12, i.e. the "mythical 7" PLUS the minimum of "ToDo"s) As for the necessary terminology, there are books on the subject(s) of course, but you might refer to pages 49 to 59 in particular, of the (free) pdf "(The) Elements of Southbeach Notation 0.9.6" which you can download from a link "Southbeach Notation 0.9" right at the very bottom of https://www.southbeachinc.com/index.html , or you can click on the first "Gallery" screenshot thumbnail on https://www.southbeachinc.com/product.html , then on the screenshot, click for the next one, and so on, to get some ideas (I would not endorse their "Modeller" though since after a brief trial, I can't say it's "intuitive", and I was unable to export the above-mentioned "Notes", but that might have been my fault then). Especially from the pdf pages, you'll get all terms you'll need, together with plenty of handy synonyms - as implied, those 11 pdf pages are a real gold mine (Roget's Thesaurus on speed for that subject) -, to employ then, as far as your individual situation is concerned, within your UR decision / analysis tree(s). (EDIT: Clarification / Additions: I didn't want to say you should employ the terms within the tree: Of course, you could do that even today, e.g. PROB: the problem in case, or RISK: ..., CHANCE: ..., and so on, but that would not really promote your thinking; you should instead create a list of your preferred / best suited terminology (see the synonyms), together with base color scheme (e.g. risks = violet) and a (consistent) hue scheme (e.g. lighter = less probable, whilst italics would e.g. mean "less important, less needed, less harmful") - or rather the other way round: lesser probability by italics, lesser importance / impact by lighter hue, and/or you might additionally use leading characters like exclamation points and question marks (the latter for doubts, obviously), simple, or then double ones, in order to "weight" the remark's claim (and which would "free" some such hues for more kinds of elements, and possibly you could employ even some symbols (big dots or squares, etc., from special "smiley" collections, but only as far as they are "allowed" = correctly represented within UR's Data Explorer...) and of course, just a simple, leading "> " would indicate effects -, and then you would, after a while, intuitively "recognize" the element kinds and their respective significance while "musing", thinking about the elements; while rearranging existing, adding new ones: while finding better approaches, solutions even, etc. - and indeed, I'd claim, and since the temporal dimension (i.e. from one situation to the next) is quite badly represented in the flowcharts paradigm, "doing it" within the above-describe workflow instead (i.e. in UR, with separators and cloning) will be as effective in most cases, since at the end of the day, that's what flowcharts will have to do, too: separate new / alternative situations from old / previous ones, i.e. minimize the number of elements in every sub-scenario, since otherwise any (re-) thinking process will seriously be hampered (if not outright stalled) by what you could call "element number overflow".) As said, for most such tasks, the flowcharter paradigm is not needed, but can conveniently be replaced by the above-described UR workflow, smartly deploying some base colors, formatting (bolding, italicizing), and then color shades (i.e. tones, hues) for "degrees"; about two dozen (or just a very little bit more) should be sufficient indeed, since immediate, intuitive recognition would be capital. Last edited by Spliff; 06-25-2023 at 12:02 PM.
|
|
#3
06-25-2023, 03:17 PM
|
|||
|
|||
|
It might seem simple, but it's not. The DB part is fairly easy (and the hidden flag is already stored in the Color column, along with color, icon, & font info), but the UI is another matter.
Just a few of the things that have to be dealt with 1) allowing flags to be added, removed, and re-ordered. 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. 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. 4) changes in the UI in many places to handle a variable # of flags. 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 6) ensuring backward compatibility with existing data 7) optimizations could be necessary to handle 4x as many flags as before without lag. More like a couple hundred hours than a couple. Increasing the max supported is not a bad idea, although 32 would be a lot, and it seems as though what you're really after is an importance attribute that would alter the behavior of each flag value. There already is a Priority attribute defined -- I'm thinking a better way to approach this would be to leverage that (or possibly a new Importance attribute), something like: Be able to configure some properties for each Priority value, via a new dialog, similar to the Flag/Flag properties dialogs 1) Font styling (i.e., bold, italic, underline, etc.) 2) Background color override 3) Label used in submenus Then add a submenu and keyboard shortcuts, again similar to Flag, to set the Priority item attribute value. The Priority would then be used in conjunction with the Flag attribute to format the item's font style and background. I could see a use for that, but it's not so simple to implement either.
|
|
#4
06-26-2023, 05:11 PM
|
|||
|
|||
|
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"))
|
|
#5
06-26-2023, 05:12 PM
|
|||
|
|||
|
THIRD
"Increasing the max supported is not a bad idea, although 32 would be a lot, and it seems as though what you're really after is an importance attribute that would alter the behavior of each flag value. There already is a Priority attribute defined -- I'm thinking a better way to approach this would be to leverage that (or possibly a new Importance attribute), something like: Be able to configure some properties for each Priority value, via a new dialog, similar to the Flag/Flag properties dialogs 1) Font styling (i.e., bold, italic, underline, etc.) 2) Background color override 3) Label used in submenus Then add a submenu and keyboard shortcuts, again similar to Flag, to set the Priority item attribute value. The Priority would then be used in conjunction with the Flag attribute to format the item's font style and background." It is my conviction that in almost every aspect - perhaps with the exception of 7) above -, the number, be it 7 or 20, 32 or 40 ("good heavens!", I hear you now!), will not make any difference, code-wise, since those lists, of 7, or "n", elements, would be contained in arrays, and you would have to adjust the respective dimensions indeed. The code integration (i.e. adaptive Favorites code re-use upon Flags) described in the second part of 5) above would indeed cost some hours, but there again, the number, be it 12, 20 or 32, should not make any difference. BUT you are perfectly right: Whilst "just 6" for categorization are way too few (#7 is "Done", i.e. a "ToDo", which is another "dimension" altogether), perhaps 12, 14 would be the ideal number for categorization in one dimension, or in several, similar dimensions, not 32 or more - we're perfectly d'accord here. But by analyzing "how you do it", currently, i.e. how you have organized, in code, and in table(s), your categorization-plus-ToDo-by-flag, it seemed, and seems, to me that to also technically, i.e. code-wise, separate the different dimensions, would need quite some new code to be written, whilst just - and then sufficiently though - enlarging the number of the current flags would enable the USER to introduce different dimensions into their (code-wise, one-dimensional) system, hence hues, and even (since that alone would not be sufficient) leading special characters - which, unfortunately, can then NOT being searched alone for, so no "filtering" for them would be possible (single > or ! or similar are not "searchable" with your current FTS, but that could be implemented after all since it seems that for SQLite fts, it's the developer who has to do lots of work on their side, so they also have quite some means of influencing the "results"...). As for "2) Background color override", let's face it: Background coloring-per-line is awful as hell; it's possible in UR (as well as in "Scrivener", e.g.), but it's so ultimately aggressive that no user will bear such formatting for long, and not even speaking of several such background colors - But I understand what you mean by "override": Some OTHER command, overriding the regular, current flag setting, ditto your "1) Font styling (i.e., bold, italic, underline, etc.)", and for the dimension of (different) ToDo's and the like, that would have been, or would be, an IDEAL solution; it would not nessarily override a flag setting, but it would be combined with a (insofar sparser) flag setting, i.e. the flag would not (have) include(d) the formatting, too, but just the color(ing) (and perhaps a possible background color, different from the default background color). Now my VUE example above was on purpose, since in there, lots of hues (i.e. shades of the same base color) are immediately available (functionally though, VUE is quite inferior, since there is no filtering by color, let alone by combinations, etc.), and so, it's easy to implement "degrees", but here again, "shading" can represent just ONE dimension, not two, and thus it either represents importance (and the like = "weight" of a factor), OR urgency (and the like, but e.g. "desirability" of a factor even might be different from its urgency, so we would have to cope with THREE dimensions here, not just two, whilst the color's hue just represents ONE). Thus, even special background color (but in "decent tones", instead of crying yellow and the like) would sometimes be needed, in order to represent a dimension not to be mixed up with the one which would be represented by the hue, and the same, i.e. both remarks, are true for underlining - it's awful, but sometime it would be needed, but then not for importance, since that would imply that it would have to be deployed much too often... and so on: it's really a problem to do it all right and straight, and without (!) creating yourself a work environment asking you to leave by becoming visually unbearable. Now it's clear as day that the ideal solution would be to have "enough base (text) colors", then another "switch" = command for hues (the same, in degrees, to then be applied to different colors), a third switch for bolding, a fourth switch for italic, and even a fifth switch for underline, and a sixth switch for background; underline and background would be rarely used but would then be of help, all of the switches would be independent of each other, and color and background color would not really be switches but palettes, since they would comprise several colors, and the "hue" "switch" would also be a range of 3 or 5 switches in some range, the middle = "no effect", and the outer settings to intensify, or then to "lighten" the base color upon which it is / those settings are applied. Obviously, this seems to create chaos, but then, 20 or so years ago, you unfortunately made a design mistake: you combined bolding, italicising and underlining with the font / flag / color, and albeit I understand that in print, etc., "bold" and "italics" are different font, on screen, lots of programs "do it simple", and allow the application for all three, ^b, ^i and ^u upon tree elements - perhaps, partly, then selecting different fonts "behind the scenes", or just manipulating the rendering - btw, your speed considerations 7) above might become pertinent indeed if the user, with 32 flags, uses 15, 20 different fonts, but hopefully not so much when users just use the same font, then also in bold and italics (and perhaps in bold-italics which would make a fourth font, technically, indeed, but not dozens of them). Thus, in order to COMBINE formatting (bolding, italicing, underlining, also in combination in case: remind yourself: that's already 5 "formats" here) with color(ing), in today's UR flag system we need 4 flags (instead of just do ^b e.g., to some vanilla, or then flagged, item), for in fact just one and only font, in default black, and if we then also want the font in just one grey tone, AND we want to apply different ToDo's to it, we're at 10, for blue at 15, for red at 20, for orange at 25, for green at 30... and if we then want scarlet, also, for "risks", "dangers", even 32 flags would NOT be sufficient if we insist to make available all 4 ToDo's (remember, we also have the vanilla, "regular" font, for "no action needed") upon our different categories... In other words, I arrived at the the number of 32 by 2x2x2... of course, but also since I think that at least for the "main categories" (= base colors, "7" being a good number here ;-) ), and then for some "derived categories" (i.e. "tinted colors"), we'd need at least the most important ToDo's... and then, 32 flags are just "sufficient, if you plan well that is"... oh yeah! I suppose that if you want to get out the font formattings (bold, italics, underline, NOT speaking of the special, little formats up/down not needed here of course, and instead of strikeout, I use grey, well: strikeout might multiply the needs again for some users then...) out of the flags, leaving just the colors (incl. the to flags, you would have an immense work to do - but I might be mistaken here? -, but it's obvious that IF you could do that, some 12, 16 colors (incl. the tinted ones) would be sufficient, and be more convenient than the current system... but then, is it worthwhile, supposed it'd be LOTS of work, of rehaul of core parts of UR? Possibly not! On the other hand, given that you already have a good code base for a big enhancement of the current flag system, JUST by "updating" the flags number, and by applying Favorites code to Flags, including user's possibility to re-order, i.e. to SORT their flags into groups (blue regular, blue bold, blue bold-italics..., then red regular, red bold, etc...), the enhanced (!) flag system would, on the user side, be almost as good as if we were able to create the needed "combined formats" by "clicking together" the dimensions by separate switches (flag plus bold ^b plus italics ^i and so on), on the fly, instead of combining them as preset "sets"... the difference on the user side consisting mainly in sacrificing, for the "everything by flag" solution, quite some shortcuts (key combinations), but in the condition that we could SORT 32 flags, it would be perfectly possible to use'em seemingly! Again, that might be 10, 12 hours indeed, but not dozens of hours I very much hope. And then, a "major updates" period of about 4 years is very long in comparison, especially considering if / that in-between, there are major improvements... ;-) (Oh, and I had obviously not been aware that you "hide" the "Hidden" status within the flag formatting, so it's individual and persistent for the db: smart! And if you shared further ideas / considerations on that matter, I'd be happy to add mine again...)
|
|
#6
06-28-2023, 10:48 PM
|
|||
|
|||
|
That didn't end up being as bad as I thought it would. More than a couple hours but not too much more (if you want to buy a few more licenses to fund the development and provide some motivation to keep at it, feel free to do so
 ). Your suggestion about the database versioning was helpful. I recalled that such a capability exists in UR, but it hadn't been used in over 12 years, so I had to refresh my memory.I expanded the system to have 32 flags defined by default. The additional flags do not show in the right-click menu because it looks a bit jarring, and it would affect the tear-off toolbar (which can be created by dragging the sizer at the top of the Flag popup menu). They do show in the 1) Item -> Flag submenu 2) Flag menu that can be shown in the tree via Ctrl+Shift+M 3) Flags dialog 4) drop-downs in the Item Attributes pane, Advanced Search grid, and on forms 5) keyboard shortcuts can be defined for them via Tools | Customize | Keyboard | Category -> Item You can actually add more if you really want them (which will not show in menus but will be functional and available via #3 and #4) by running commands like this via SQLite: Code:
INSERT INTO Status(StatusID,Name,StatusBlob,UncompressedSize,Color) VALUES (1026,'Flag 33',NULL,0,NULL); This implemented is in the latest download (v6.3.0.2).
|
 |
|
|
Hybrid Mode
