|
|
|
|
#1
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...) 
|
|
#2
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).
|
|
#3
06-29-2023, 07:56 AM
|
|||
|
|||
|
The large # of flags quickly became a problem (see https://www.kinook.com/Forum/showthread.php?t=5825), so I have made a few changes:
1) Ctrl+Shift+M flag menu will be limited to 12 flags 2) The Item | Flag menu (and keyboard shortcuts) will be limited to 20 flags 3) The default # of flags created in the Flags dialog will be 20 You can still create additional flags if needed, see above.
|
|
#4
12-22-2023, 02:32 AM
|
|||
|
|||
|
Tiny problem in UR, or in my system (Windows 10, keyboard; of course I checked AutoHotkey as the possible source of the problem, but it is not)?
Since we have 20 flags, the "natural" way to assign shortcuts to them would be: - flags 1 to 10 by shift-control-1...0 (if I remember well, the original default shortcuts were shift-control 1...7 for 1...7, and shift-control-8 for "None") - (and then, if needed, flags 11 to 20 by control-alt 1...0) - and shift-control-' (the key right to the 0) for "None" But I can't assign shift-control-0 to any flag, or to "None"; of course that's a tiny problem, but if the cause is in UR, it might be overcome? (UR has got some specifics / idiosyncrasies with the keyboard (= with any keyboard), e.g. F6 and shift-F6 are "fixed" in UR for "Next/Prev db", so if I want to use F6 to something else, I must assign e.g. control-F6 in UR instead for that, then assign "control-F6" to F6 in Autohotkey; assigning F6 in UR to that other function seems to work in the assignment dialog, but later on, it's back to "Next db", for an example.) EDIT: Users who use more than just a few flags will need custom colors, in order to make those colors distinct AND clearly readable. Unfortunately, the "Custom colors" assignment in the UR dialog is not ideal, and from what I have seen = tried to understand, you first click on a "Custom colors" field (the first one), then on "Define Custom Colors", and then it gets complicated, the UR color picker not being as helpful as it might get. Instead, I just open that, AND https://www.rapidtables.com/web/color/index.html , and I then choose the (always RGB) color range from that page, then refine by the more specific page's specifics, then enter the RGB data into UR dialog's respective fields numerically, then refine the data from what I then see in the UR dialog rectangle. Then I click on "Add to [sic!] Custom Colors", and this CHANGES the currently selected "Custom color" (e.g. the very first "Custom color" square, for another color you first click the second square, and so on, and then only you click on "Add...") instead, so the dialog's wording is misleading, since clicking on "Add..." does NOT put that color into some new field, but once you "got" that, it becomes much more easy. Most of the time, your colors will be too light, since for regular text, you'll need darker colors than for a rectangle on screen, so you will have to do some trial-and-error, forth and back between the web page and the UR dialog / Data Explorer in order to check the "end result" of your choice, but from that web page, I got acceptable text colors much easier than just from within the UR dialog only. Last edited by Spliff; 12-22-2023 at 03:56 AM.
|
|
#5
12-22-2023, 05:08 AM
|
|||
|
|||
|
The default flag shortcuts are documented here:
https://kinook.com/UltraRecall/Manua...plorerpane.htm And I was able to assign Ctrl+Shift+- and Ctrl+Shift+<num> shortcuts via Tools | Customize | Keyboard.
|
|
#6
12-23-2023, 12:30 PM
|
|||
|
|||
|
This is a slight misunderstanding; my question was for shift-control-0 (the zero above the abc keys) which on my system can't be assigned (when shift-control-1...9 and then ' (the key right to the 0 key) are without problems, but that's allegedly a Windows, not a UR problem?
|
 |
|
|
Hybrid Mode
