Ultra Recall settings scope

[Spliff]

Please, could we discuss settings scope in general, and hopefully once-and-for-all? Or then at least post additional scope questions here? Scope is spread all over the place, for settings, help, forum - I'm lost.

INTRO

The base problem is the so-called Object Model, with its concepts of Inheritance, and Overriding: Higher-up settings are inherited by elements deeper-down in the hierarchy (if not overridden down there, one of the questions that arise then being, is that overriding possible, in that specific case / on that specific "position", or not), but when I say, "hierarchy", it's the programming hierarchy, whilst for the user, the "hierarchy" they see on the screen (DBs > Tree > Tree entries = "Items" > with their various elements), is not necessarily quasi-identical with the former one, and there is a third hierarchy, mostly hidden in UR (!!!!!), and which is the hierarchy of the physical settings the user can access on-screen, i.e. "WHERE to set WHAT, with WHICH scope?... which more often than not, depends on what currently might be selected within the tree, or even what DB is open, or even in which order then the user closes the open DBs"...

SQLITE NOT BEING SERVER-CLIENT

Whilst for server-client databases (groupware, etc), the aim is to store everything within one big, in case very big DB (incl. sharding and all), SQLite databases (incl. UR) are stored in just one file that grows bigger and bigger.

Thus, I had to distribute my data into several DBs ("database" is the concept, "DB" is the physical implementation), in order to avoid a 300,000-items-plus DB, and once you do that, you have to do it in a somewhat logical way, in which some of the distributed data is then to be "combined" somewhat with several other DBs, not just one, and that's why, in my case, whilst for UR, it would have been "sufficient" to spread my 300,000 items into perhaps 4 or 5 DBs, I ended up with some 30 DBs, in order to combine any data with any other data where it is needed, and in this way, I always have between 3 and 6 DBs open; some of my problems certainly arise from that setting, but far from all of them.

NAVICAT EXAMPLE (not transferrable) vs. UR being OVER-SPECIFIC

What a database frontend like Navicat (which also, just like UR, allows for holding open several DBs concurrently) needs for settings, is much simpler, since it's just "Navicat settings" = "(default / start) settings for all DBs" vs. "specific settings for the current DB" (which then override the former ones, and given that such specific settings are available only for SOME of the former ones).

Now, the general settings are available from the Navicat MENU, whilst for the DB-specific settings, there are tabs within a sidebar (I don't speak of the tree on the left, but of a sidebar on the right, and which is hidden by default), so the scope of every setting is clearly distinct. I'm fully aware of the fact (see above) that UR settings are much more "complicated" so that such a perfectly (!) clear scope distinction is not possible, but the current state of affairs of UR settings scope is endured as "nightmarish" by me, also because of the interaction of two aspects:

a) Will my setting be overridden, against my wish, by "something higher-up"? i.e. do I do the setting "high enough"? This is my main problem; "all the time", I encounter the non-persistency of my "settings".

b) Will my setting also affect other elements, against my wish (since my inadvertently doing it "too high-up"), i.e. do I do the setting "deep enough"? This is a much lesser problem, I even can't remember any persistency-against-my-will situation, the term "Non-persistency" describing, in fact, the non-reaching of "similar scopes" after having done some setting, obviously "too specifically":

I understand UR wants to make available to the user VERY SPECIFIC, extremely fine-grained settings, too, but again and again, this works for me against my wish to set "general" settings, i.e. for the current DB, or even for all my DBs - manual replication for 30 DBs being a real chore BUT if, at least, after doing so, they would be all set, that really would be fine with me! (For example, with Navicat (we could do it with any other SQlite frontend, too), I was able to replicate my Flag settings (for all flags) from one DB to all the others.)


So, let's try to do it systematically:

A)

For UR in general, i.e. affecting all DBs, overriding any "specific" setting in case: Which are those settings? (Ideally, there would not be a single Main Menu which would then mix, in its commands or sub-menus, any of these general settings with the next TWO categories.

General UR settings should, by definition, be persistent whenever we make them, independently of which DB is open, and in which order we close open DBs when we shut down UR.

AB)

Here, the "nightmare" starts, since many "general UR settings" (which belong into A)) obviously are in this category AB) which is affected by the "closing order": I do some setting, with some DBs open, necessarily while one of those open DBs is the "active", "current" one, and then, what do I need to do?

a) I make certain that this "current" DB when I make the settings, is also the "current" one, when I close UR (Alt-F4), but this means that UR first leaves this one upon closing down, then, in any order, leaves the other (i.e. non-current) ones, and thus, the settings may be lost, or just some of them?

b) Must I, instead, after having done such "general AB settings" (i.e. settings which should be in the A) category but which in fact (and unfortunately) are in AB) and thus dependent on the closing order), a) FIRST CLOSE all the other DBs manually, and THEN only, i.e. as the very last one, close the DB which had been the "current" one when I made the settings which I wanted to be "general"?

B)

Settings for the current DB. Here again, we seem to have a mix-up with the category AB), because of a "persistence" problem: Settings which should be general for the current DB but ONLY for the current DB, seem to be lost (even for the current DB) if I make them, then continue to work in other open DBs, and then, finally, close down UR with another DB "current", or without leaving (i.e. closing) all other DBs before finally closing this specific one? i.e. the same question a) vs. b) as for AB).

And logically - since I can only "leave UR the correct way for the preservation of the settings" for just ONE DB, not for several ones, it seems that it is never ever possible to make DB-specific settings (i.e. settings with scope "current DB and current DB only") for MORE than just one DB in one "session", since except for just one DB (for which, according to a) or b), according to which one is the right one, I then "leave" UR in the only correct way in order to preserve the settings), the settings made in every other DB will be lost?

C)

a) Settings for all future items of the current DB (i.e. all items created AFTER having made the setting), especially the "Templates", and probably other settings, too.

b) If I want to set these settings also for existent items, I have to SELECT ALL items, then try to make those settings. Here again, both for a) and/or b), these settings may be lost if I then make a "closing-down-mistake" (AB a) vs. AB b)).

And also, the fact (? or just my assumption?) that I have to select ALL the existent items, in order to get ALL items those settings, seems contrary to the inheritance concept since the latter one would just ask for me to select the SOURCE ITEM of the tree = of the current DB, then do the settings, and all those settings would be propagated to ANY item in the tree (except for the Templates, hopefully?), even OVERRIDING more specific settings I might have done for some sub-trees before (those specific settings having made before, on purpose or, in my case, inadvertently: since I use different DBs for different subjects, within the DB, everything is coherent, but that's just me: I fully understand the need for sub-tree specific settings).

D)

Settings for just the "current" sub-tree, i.e. settings for the "active" item and any, existent or future (? in fact, these again are two distinct sub-categories in their own right...) sub-items ("children" of any level-down) of the current item. And here again, how to preserve these settings, do I really do AB) a) or AB) b) for everything if I work with several UR DBs concurrently, or are there just some settings which WILL be preserved without such additional fuss?

E)

And finally, settings for just the current item; the "which-icon" (i.e. icon-ID), and the "which-flag" (i.e. flag-ID) settings come to mind, as expected, these settings don't neither affect the item's "children (category D)) nor the "looks" of the icon or flag (which are preset-for-all, i.e. the existing and the future ones, with the same ID, more generally).


And now, ideally, we would need a (quite complicated indeed, since it would have to comprise both the elements-settings AND the (in case, "multiple" (several), ways-of-settings) table, indicating both the persistance-over-sessions (especially if more than one UR DB is "open" when the setting is made, made that specific way in case), and the double inheritances, both for existing "children", and for future "children" of the element (UR, DB, "parent item" i.e. item with sub-tree ), and for other elements ("Search", etc, and other "overlay" elements), always also indicating possible different "behavior" when the setting is made in different / specific "situations".

The "good news" in this seemingly "chaos" being that if the explanations / indications for every element are done "top-down" (i.e. in programmatical inheritance order) AND complete in themselves (incl. possible behavioral exceptions for different "situations" or "user-side ways-of-doing", i.e. for triggering the command(s)), THEN the explanations / indications "further down" this "inner hierarchy" (i.e. programmatical inheritance hierarchy) can become more and more sparse, any "information" given "higher-up" deemed to be knowledge for any information "further down", i.e. if done right, even the information can be given according "inheritance" lines.

At the very moment though, almost everything I do, is trial-and-error, and UR settings seem to be a real "black box" to me, with just rare exceptions, hence my multiple problems and questions, and, unfortunately, any indications for persistence and inheritance (since it all comes down to these two concepts, and which don't even go in parallel but are mixed up somewhat currently), spread all over the help subjects, are so sparse and so non-systematic that I simple "don't get it" from over there, for, as has become obvious, most of the sub-problems I face.

(And, assuming from "general web comments" which all convene in the line of, "It's the best information manager there is, for individuals (and by some way, and, or perhaps even small work groups, I'd both add), BUT its access to its elaborate functions is obscure", I very much hope that my questions are deemed to be "in the general interest". ;.) )

In the meanwhile, thank you very much for any hint that would put me some "definite step ahead" off my general and endless trial-and-error!!!!

[kinook]

Settings configured in Tools | Options are stored in the registry under

HKEY_CURRENT_USER\Software\Kinook Software\Ultra Recall

(or in UltraRecall.ini in the EXE path for the portable version)

and changes are written when the Ultra Recall process exits.

Settings such as column customizations are stored in the .urd file for the selected item (or for the parent template if setting/restoring to defaults) and are updated immediately in the database.

UR is not an object model and doesn't really have inheritance and overriding in a programming sense.