| Time |
Nick |
Message |
| 00:10 |
|
ssieb joined #minetest-dev |
| 00:30 |
|
kollaps[m] joined #minetest-dev |
| 00:36 |
|
tacotexmex joined #minetest-dev |
| 00:36 |
|
MayeulC_backup joined #minetest-dev |
| 00:36 |
|
Qiangong2[m] joined #minetest-dev |
| 00:58 |
rubenwardy |
coming soon: https://rwdy.uk/9NDfU.png |
| 01:00 |
rubenwardy |
why does CLion suck so bad |
| 01:06 |
rubenwardy |
better pic: https://rwdy.uk/wcM09.png |
| 01:09 |
rubenwardy |
I think I may make it have a simple were it just shows you what CDB has found, and then you can click [Cancel] [Edit] [Install] |
| 01:09 |
rubenwardy |
edit would then go to that screenshot |
| 01:09 |
rubenwardy |
that would only work if CDB finds everything that is required |
| 01:10 |
rubenwardy |
I may also disable the [Edit] to begin with, and only allow installed the preselected choices |
| 01:10 |
rubenwardy |
which is fine for 99.999% of mods |
| 01:29 |
rubenwardy |
here's a mock simple mode: https://rwdy.uk/J33Zi.png |
| 01:30 |
rubenwardy |
this will display if there are no problems with the selection that ContentDB choose |
| 01:30 |
rubenwardy |
ie: contentdb is able to find all hard dependencies |
| 01:31 |
rubenwardy |
actually, maybe it should always show. Advanced isn't going to be that useful if it can't find the dep |
| 02:06 |
|
Cornelia joined #minetest-dev |
| 02:37 |
|
ssieb joined #minetest-dev |
| 04:27 |
|
YuGiOhJCJ joined #minetest-dev |
| 04:49 |
|
Player-2 joined #minetest-dev |
| 06:08 |
BuckarooBanzai |
rubenwardy: oh, that looks good :) |
| 06:09 |
BuckarooBanzai |
rubenwardy: isn't that painful to implement in formspecs? :/ |
| 06:11 |
|
Taoki[laptop] joined #minetest-dev |
| 06:31 |
|
Kimapr joined #minetest-dev |
| 07:29 |
|
ssieb joined #minetest-dev |
| 08:41 |
|
nepugia joined #minetest-dev |
| 08:42 |
|
ShadowNinja joined #minetest-dev |
| 09:14 |
|
Kimapr_ joined #minetest-dev |
| 09:14 |
|
Kimapr joined #minetest-dev |
| 09:29 |
p_gimeno |
rubenwardy: I've been thinking of implementing something similar but in the mod selection dialog. The main hurdle is that with my idea, I would need something like a modal dialog containing a list, on top of another formspec. Is there any way to do something similar? |
| 09:31 |
ANAND |
p_gimeno: Check out builtin/fstk |
| 09:31 |
ANAND |
It's a Lua API created by sapier, that builds on top of the existing formspec API |
| 09:32 |
p_gimeno |
ANAND: interesting, what do you mean "builds on top"? as in, can show two formspecs simultaneously? |
| 09:32 |
ANAND |
Not sure about that |
| 09:32 |
ANAND |
See also, https://github.com/minetest/minetest/blob/master/doc/fst_api.txt |
| 09:34 |
p_gimeno |
hm, my understanding is that that's simply a structured way of creating the formspec string, it's not adding functionality to it |
| 09:35 |
|
Player-2 joined #minetest-dev |
| 09:35 |
p_gimeno |
what I need is one modal formspec on top of another (visually) |
| 09:35 |
ANAND |
There are show and hide methods, but I doubt they allow displaying two formspecs at once |
| 09:35 |
p_gimeno |
yeah |
| 09:44 |
p_gimeno |
or, well, some other way to convey the info (a list of mods) and to offer options (buttons) |
| 09:44 |
p_gimeno |
maybe it can be done by temporarily replacing elements in the existing formspec |
| 09:47 |
p_gimeno |
my initial idea was: when you activate a mod in the form and it depends on others that are installed but not active, to show a modal dialog with a list of the mods that are needed, and choose between activating them as well, or deactivate the one you've selected |
| 09:48 |
p_gimeno |
and if it depends on at least one mod that is not installed, to show a modal dialog with an error explaining what mods are missing, and only the option to deactivate it again |
| 09:49 |
|
proller joined #minetest-dev |
| 09:49 |
p_gimeno |
similarly, when deactivating a mod that others depend on, to show a modal dialog offering between deactivating the others as well, or re-enabling that one |
| 09:50 |
p_gimeno |
in other words, to keep the mod list consistent at all times when manipulating mods, instead of being able to leave it in a state where there are inactive dependent mods |
| 09:50 |
nepugia |
p_gimeno, you can't show two formspecs simultaniously, but you can probably fake your way to victory |
| 09:51 |
nepugia |
by only adding a backgroun behind elements that need it and having a gap between both sections |
| 09:54 |
p_gimeno |
nepugia: I don't get what you mean, do you think you can show an example? |
| 09:54 |
nepugia |
Well, i mean with displaying two formspecs you mean to show two side by side? |
| 09:55 |
p_gimeno |
one on top of the other, a modal dialog |
| 09:55 |
p_gimeno |
i.e. one partially hiding the other |
| 09:56 |
nepugia |
You can achieve that in an upper api indeed |
| 09:56 |
nepugia |
by modifying the "lower" formspec to cut elements to a specific size to allow the upper formspec some room |
| 09:57 |
p_gimeno |
can you have overlapping elements in a formspec? |
| 10:02 |
p_gimeno |
anyway, it's going to be big, and if it's hard to get big PRs merged, it's even harder when I'm not in GitHub |
| 10:42 |
nepugia |
p_gimeno, yes you can |
| 10:42 |
nepugia |
but it doesnt look pretty :) |
| 10:43 |
nepugia |
i dont think there is any need to merge something like this, if a mod wants somethign like that they can just depend on the mod that provides it |
| 10:44 |
p_gimeno |
nepugia: this idea is not for mods, it's for the mod selection menu when configuring the world |
| 10:44 |
p_gimeno |
the dependencies that it would read are the dependencies stated in the mod |
| 10:44 |
nepugia |
why do you need overlapping formspecs there? |
| 10:44 |
p_gimeno |
to show a modal dialog |
| 10:45 |
nepugia |
for what? :) |
| 10:46 |
nepugia |
the easiest way would be to just dismiss the underlying formspec, and bring it back once the dialog would be closed |
| 10:47 |
p_gimeno |
say you activate mesecons_luacontroller but you don't activate mesecons; the modal dialog would immediately show saying "To activate mesecons_luacontroller the following mods need to be enabled: mesecons [Activate all] [Deactivate mesecons_luacontroller]" |
| 10:47 |
nepugia |
why? just activate the dependencies |
| 10:47 |
p_gimeno |
silently? |
| 10:47 |
nepugia |
yes |
| 10:48 |
p_gimeno |
I don't like to do things behinds the user's back |
| 10:48 |
nepugia |
the users intention is to use mesecons_luacontroller |
| 10:48 |
nepugia |
dependency management is too complicated for end users, and shouldnt be shown to them normally |
| 10:48 |
p_gimeno |
this is a simple example, but in other mods the dependency chain could be larger, and they may be activating something they don't want |
| 10:49 |
p_gimeno |
(e.g. a mobs mod with unwanted mobs) |
| 10:49 |
nepugia |
then when a mod is selected show a list to the right of it with dependencies that will be activated too |
| 10:49 |
nepugia |
p_gimeno, that is moot, because you cant not activate them |
| 10:50 |
p_gimeno |
you can choose to not activate that one... take into account that once they are activate, you need to go one by one to disable them |
| 10:50 |
p_gimeno |
active* |
| 10:50 |
nepugia |
nah, you can track which ones were dependencies and immidiently deactivate them |
| 10:50 |
p_gimeno |
and maybe disable one that was enabled and you wanted... |
| 10:51 |
nepugia |
How should a user know that it is enabled if they did not enable it themselves? |
| 10:51 |
nepugia |
users dont read modal dialogs |
| 10:51 |
|
proller joined #minetest-dev |
| 10:52 |
nepugia |
also, the assumption is that all listed dependencies are absolutely required, and if the user expresses intent to use a mod then the dependencies have to be activated |
| 10:53 |
nepugia |
its like, in an office programm, you could prompt for each keypress whether it was correct, after all a user may have mistyped which could lead to more correct text, but it heavily degrades the ui |
| 10:53 |
p_gimeno |
say a mod A depends on B, C and D, and you voluntarily have C active, because you want it. Now you enable A, and automatically get B and D enabled. Now you regret that B was enabled, and go through the dependencies of A and disable B, C and D. You end up disabling a mod you wanted active. |
| 10:54 |
p_gimeno |
actually what I'm proposing is something I've seen used in the Windows service manager |
| 10:55 |
nepugia |
You mean like, a tool used by administrators that users wont touch? |
| 10:56 |
p_gimeno |
if the user expresses intent to enable a mod, but that forces them to enable another mod they didn't want, they need a chance to regret the decision |
| 10:56 |
|
Wuzzy joined #minetest-dev |
| 10:57 |
nepugia |
After they have enabled it |
| 10:57 |
nepugia |
There is no point in questioning each and every action the user takes |
| 10:58 |
p_gimeno |
but that may have unwanted consequences, many mods may become automatically enabled and they may not like that |
| 10:58 |
p_gimeno |
perhaps colour codes for the dependency list could be a substitutive |
| 10:58 |
p_gimeno |
one colour for "when you enable this mod, all these other mods will be automatically enabled" |
| 10:59 |
nepugia |
indicating what consequence their action has is fine |
| 10:59 |
p_gimeno |
another colour for "this mod depends on mod X which is not installed" |
| 10:59 |
nepugia |
questioning their actions is not |
| 10:59 |
|
tomraceror joined #minetest-dev |
| 11:00 |
p_gimeno |
that doesn't solve disabling, though, because for disabling, the list that should be shown is the list of mods that depend on the selected one, not the list of mods that the selected one depends on |
| 11:04 |
p_gimeno |
what you call questioning the actions of the user, I call giving them information they may not have thought of, before making their decision final |
| 11:10 |
nepugia |
You are supposed to provide the information beforehand |
| 11:10 |
nepugia |
not after they already made a decision |
| 11:10 |
nepugia |
it's like asking someone to buy a watch and after they agree to buy them price you tell them "oh by the way, this watch is highly radioctive, are you really sure you want to buy it?" |
| 11:11 |
nepugia |
the list of "activated" mods doesnt need to show the ones that are enabled as dependencies, their state is irrelevant to the user |
| 11:12 |
nepugia |
if they choose to disable a mod you should then list all the mods that that will disable, which includes and mods that depend on this mod, and any that are activated only because of this mod |
| 11:17 |
ANAND |
p_gimeno: Why modal tho? |
| 11:20 |
p_gimeno |
ANAND: if you enable a mod, popping up a modal window that allows you to confirm seems like the right thing to do. Kinda like the confirmation dialog you get in a save dialog when going to overwrite a file. |
| 11:22 |
nepugia |
but you /arent/ overwriting a file |
| 11:22 |
p_gimeno |
nepugia: "any that are activated only because of this mod" needs tracking which ones were activated by hand and which ones were manually enabled, kinda like the Debian package manager. That needs tracking extra info (manual vs automatic), complicating things a lot more, even for the user. |
| 11:22 |
nepugia |
and most save dialogs that overwrite files do not have one |
| 11:22 |
nepugia |
no, its just a list of automatic activations |
| 11:22 |
nepugia |
it isnt that complicated |
| 11:22 |
nepugia |
you dont need to track by whom they have been activated |
| 11:23 |
|
proller joined #minetest-dev |
| 11:23 |
p_gimeno |
sorry, I meant "and which ones were automatically enabled" |
| 11:24 |
ANAND |
p_gimeno: That doesn't strictly require the parent formspec to be visible though :) |
| 11:24 |
ANAND |
Take for example the change setting dialog |
| 11:24 |
nepugia |
p_gimeno, same response |
| 11:25 |
ANAND |
When you double-click on a setting, the adv. settings window will disappear, and you'll be shown a simple dialog box |
| 11:25 |
nepugia |
it makes it easier on the user, not more compilcated |
| 11:25 |
nepugia |
dealing with modal dialogs sucks |
| 11:25 |
ANAND |
Yea |
| 11:25 |
ANAND |
It might look cool, but... why? |
| 11:26 |
p_gimeno |
ANAND: yeah I see, but isn't the formspec recreated that way? |
| 11:26 |
nepugia |
you can "recreate" formspecs all the time |
| 11:27 |
|
twoelk joined #minetest-dev |
| 11:27 |
p_gimeno |
in the mod selection dialog there's some state, it would need to be remembered and recreated later |
| 11:28 |
p_gimeno |
I've noticed that the settings modal dialog doesn't respect the scrollbar position, it always scrolls down the selected item to the bottom of the window |
| 11:30 |
p_gimeno |
in fact, it also collapses the other options I had open; that's bad |
| 11:30 |
nepugia |
if you emulate a new formspec to get a modal dialog you will "recreate" the formspec too |
| 11:31 |
nepugia |
so if any state is lost it will happen either way |
| 11:38 |
|
Fixer joined #minetest-dev |
| 11:54 |
rubenwardy |
p_gimeno: with that formspec order pr, you could use boxes to simulate the affect |
| 11:57 |
p_gimeno |
nice |
| 11:59 |
|
Kimapr joined #minetest-dev |
| 12:04 |
p_gimeno |
rubenwardy: #8740 ? |
| 12:04 |
ShadowBot |
https://github.com/minetest/minetest/issues/8740 -- Make formspec elements real elements for draw order and clipping by DS-Minetest |
| 12:06 |
rubenwardy |
Yeah |
| 12:07 |
p_gimeno |
I might develop a PoC of the idea in LOVE instead of MT |
| 12:08 |
rubenwardy |
BuckarooBanzai: it's a real formspec, just no code to fetch and resolve dependencies yet |
| 12:16 |
|
nepugia joined #minetest-dev |
| 12:36 |
|
kilbith joined #minetest-dev |
| 12:36 |
|
proller joined #minetest-dev |
| 12:36 |
kilbith |
celeron55: may I ask why you didn't use occlusion queries from the beginning in MT? |
| 12:38 |
kilbith |
I have an (almost) working prototype, but I wonder whether it fits to MT due to its architecture |
| 12:43 |
|
Cornelia joined #minetest-dev |
| 12:48 |
celeron55 |
i don't remember |
| 12:48 |
celeron55 |
possibly because on a slow gpu everything takes away from fps |
| 12:49 |
celeron55 |
i'm pretty sure nobody is using an i945 these days anymore though |
| 12:49 |
celeron55 |
it was old 8 years ago |
| 12:49 |
kilbith |
hardware occlusion is likely faster now |
| 13:02 |
celeron55 |
as long as it helps everyone it's good |
| 13:03 |
kilbith |
so here is the problem exposed: https://github.com/minetest/minetest/issues/8894 |
| 13:16 |
|
Cornelia joined #minetest-dev |
| 13:38 |
|
Enricoo joined #minetest-dev |
| 13:40 |
|
Cornelia joined #minetest-dev |
| 14:46 |
|
proller joined #minetest-dev |
| 15:05 |
|
Enricoo joined #minetest-dev |
| 16:00 |
|
nepugia joined #minetest-dev |
| 16:04 |
|
Lone_Wolf joined #minetest-dev |
| 16:35 |
BuckarooBanzai |
celeron55: while you are here: thanks for starting the minetest project :) |
| 16:38 |
|
proller joined #minetest-dev |
| 16:50 |
|
twoelk left #minetest-dev |
| 16:58 |
|
Krock joined #minetest-dev |
| 17:05 |
|
proller joined #minetest-dev |
| 17:10 |
|
nepugia joined #minetest-dev |
| 17:28 |
|
ensonic joined #minetest-dev |
| 18:06 |
|
ssieb joined #minetest-dev |
| 18:15 |
sfan5 |
merging #8895 |
| 18:15 |
ShadowBot |
https://github.com/minetest/minetest/issues/8895 -- Fix Inventory::moveItemSomewhere() by sfan5 |
| 20:18 |
|
Taoki joined #minetest-dev |
| 21:39 |
|
pgimeno_ joined #minetest-dev |
| 21:41 |
|
pgimeno_ joined #minetest-dev |
| 21:41 |
|
pgimeno_ left #minetest-dev |
| 21:42 |
|
p_gimeno joined #minetest-dev |
| 21:44 |
|
p_gimeno joined #minetest-dev |
| 22:05 |
|
Fixer joined #minetest-dev |
| 22:30 |
|
solus88 joined #minetest-dev |
| 22:31 |
|
Ruslan1 joined #minetest-dev |
| 22:42 |
|
Lone_Wolf joined #minetest-dev |
| 23:33 |
|
Lia joined #minetest-dev |
| 23:54 |
|
Cornelia joined #minetest-dev |
