Feature Store breakfast summoning settings as character preferences

[fronobulax]

Layouts certainly are one of swing's worst offenders, but in its marginal defense the more complex layout managers were meant to be used with GUI builder tools. The fact that I've personally hand-coded stuff in GridBagLayout and SpringLayout mostly speaks to my questionable sanity levels.

There are tools to build Swing GUIs? When I first encountered Swing I was expected to do everything from a command line with my trusty text editor. GUI Builders cost money and the bean counters treated my labor as a fixed cost whereas they actually had to write a check to buy tools. In their accounting world, how efficiently I worked did not matter because I was on salary.

On the point at hand, if the behavior in post #3 is correct then I say let's move the preferences from GLOBAL to user. The only downside I can see is making some entries obsolete and that is being discussed elsewhere. While I found the code that gets a preference for a named user, I'm not sure it works the way I fear.

 

[Fluxxdog]

Does the phrase "grid bag" sound like something meaningful?

No, but it sounds like it should. Can you explain that one?

 

[fronobulax]

The organizing idea of Swing components is a layout. Grid Bag is one of the available layouts and is often recommended as the most powerful and flexible. With power and flexibility come a lot of niggling parameters. http://docs.oracle.com/javase/tutorial/uiswing/layout/gridbag.html is an example of doing things the hard way.

 

[eviltwinskippy]

Is there a reason preferences MUST be global OR user? (I am asking, I have no clue here).

If a setting is not found at the user level, could it just not look at global instead? And if a user makes a change, could it not just update that user?

To update the globals, you would do them without being logged in.

Anyway, if I missed that being discussed in this thread... whoops. If it is in another thread, sorry I didn't find it.

 

[roippi]

Is there a reason preferences MUST be global OR user? (I am asking, I have no clue here).

Yes, that's how they're defined in defaults.txt, one entry per line.

Even if you put two entries in, they all go into some hashmaps and then when you use get/set it looks in some order to see if each hashmap's keyset contains the property. I think it looks at GLOBAL first so putting it in there twice is the same as making it GLOBAL. If I have that backwards, it's just the other way around. Either way, trying to make it both won't work.

Someone needs to thoroughly test what changing this from GLOBAL to USER does. It's super trivial to code, but not trivial to test, which is why I haven't done/won't do it personally.

 

[eviltwinskippy]

Ah that is not what I meant.

I was asking if this boolean behavior was important going forward or if it could be changed?
I am pretty sure that right now, it does do as you say and look at global first.

 

[roippi]

I honestly don't understand what you were proposing then. Something being global sometimes and user other times makes no sense to my brain.

 

[heeheehee]

My guess is that eviltwinskippy wants preferences where the user preference, if present, overrides the global preference (which would be a customizable "default").

Of course, in that case, I don't see how you'd know which one you're setting unless you changed the behavior of [sg]et_property.

 

[roippi]

That's not really what global preferences are for. A preference in defaults.txt marked USER is the "global default" for any new user.

Global preferences are for things that need to be loaded before login occurs. When you query a global pref, it always works; when you query a user preference you get a blank string back if you're not logged in. That's fundamental to the contract of the two things.

 

[eviltwinskippy]

Gotcha, thanks for answering my question on it

edit:

Based on that contract, aren't they misclassified as global then? I realize fixing it may cause trouble, but inherently they should be user preferences right?

 

[roippi]

No prob.

I do appreciate people trying to suss out if we're addressing the wrong problem; quite often the reflexive solution is to fix the immediate symptom without considering if we're fixing the Right Thing. Taking that extra mental step - even if it doesn't go anywhere - is good.

In response to your edit: yes, these ones are misclassified as global. A lot of things in mafia have been left as-is for legacy compatibility reasons (see: some preferences that don't start with _ that reset daily) since breaking peoples' scripts is kind of a big deal. These were originally coded as global, and so they have remained until now. If migrating is fairly painless, I say push the button and don't look back, but I'm admittedly more willing to break things than some other devs.

 

[lostcalpolydude]

The biggest change would probably affect people that start using mafia after it is changed. The first thing that pops up for them is a Preferences window that includes breakfast summoning. I'm pretty sure that changing anything there before logging in the first time won't do what anyone would hope.

I don't think there will be any meaningful negative effect for people that already have things set up.

 

[eviltwinskippy]

The biggest change would probably affect people that start using mafia after it is changed. The first thing that pops up for them is a Preferences window that includes breakfast summoning. I'm pretty sure that changing anything there before logging in the first time won't do what anyone would hope.

Should doing that change default.txt for user preferences then? (or is that intended to be the "reset to untouched by anyone" file?

edit: grrr, that is not a file that makes it to the install.


Does setting breakfast before logging in make sense logically to a new user? (I am unsure... Just talking it out.)

 

[eviltwinskippy]

Ok, I did some testing.

Existing install:

First user gets settings migrated from GLOBAL_prefs.txt to <users>_prefs.txt and the entries in GLOBAL vanish.

Second user gets settings from default.txt since they are no longer in GLOBAL.


New install:

Pre-first login settings don't get saved anywhere if they relate to a user setting (which these would be).

First and all other users get settings from default.txt.


So there are a few differences if this were changed.

1. Changing breakfast settings for *all* your accounts would need to be done individually instead of just once.

2. Any attempt to change the default breakfast for new users (by setting up preferences before logging in) would have no effect.

Scripts call get/set preferences but don't seem to know/care which file they are in. So the impact there seems small.

So, options I can think of:

1. Leave it alone. (problem for users with mutlis with wildly different needs.)
2. Just change it to user. (Problems detailed above.)
3. Have "user level" settings that are changed when not logged in save settings to a users_defaults.txt file. (Changing things here will not "update" any existing user settings, but would only effect a new user logging into this instance of mafia.)

 

[Rinn]

Just keep the globals file as is and just make user settings override global settings, and save the old globals to user settings. If the user settings overwrite the global settings I don't foresee any issues aside from leaving the old values in that file. You could also add some functionality to manually clean up the file if someone was really bother by it.

 

[Theraze]

After a point release with the global->user conversion without cleanup, the next point release could have the global removed after the individual conversions...

 

[eviltwinskippy]

Just keep the globals file as is and just make user settings override global settings, and save the old globals to user settings. If the user settings overwrite the global settings I don't foresee any issues aside from leaving the old values in that file. You could also add some functionality to manually clean up the file if someone was really bother by it.

Do you mean copying the globals file to a users_default file or just having user settings allowed to override ANY global setting. If the second option, what would need cleaning up in the global file later? (Would it not still matter for a new user?)

Just making sure I understand what is being considered.

 

[ereinion]

I'd quite like if the feature asked for here was implemented, but I don't really have the skill to write up a patch for it myself. Is there anything else I can do to get someone to want to try to implement this?