Proposal for managing modules

[a1ex]

Okay guys, proof of concept working:

https://bitbucket.org/hudson/magic-lantern/pull-request/407/module-tags-ratings-wip

(theory tomorrow, specs for new tags here: http://www.magiclantern.fm/forum/index.php?topic=7989.msg72855#msg72855 )

[stevefal]

Maybe already mentioned, but another idea is a field for known issues. Would help clarify the 'stability' field with concrete info.

[a1ex]

Good idea, added: https://bitbucket.org/hudson/magic-lantern/commits/9e9e19f3605a73f48008e0849aa6883eeecc1bc0

[a1ex]

some other thoughts:
beside the "category selection", add one option for loading modules:
 Allow unsafe plugins: YES/NO  (WARNING: Some experimental modules may crash your cameras)

process the modules in that order:
 - if a module is tagged as "known not working" for a model, it will be hidden (extra menu point "incompatible modules" may show/summarize the modules that were hidden due to that?)
 - when a module is not considered "stable" for your model, it will be hidden/grayed out if "unsafe" isn't enabled.
 - depending on the stability level, the module is colored in green/blue/yellow or some warning for that level is added

so the proposed category tags are used for visual filtering and the stability tags are used for functional filtering/coloring.

rookie users only see the modules that are stable for their camera.
advanced users can enable the "usable" and "unstable" modules from menu after accepting a "i agree" nag screen.
devs can alter module's "not working" tags if they want to test/port it on their cameras.

I've tried to implement this in a simpler way: the stability rating is also checked at loading stage (no modules with lower rating will be loaded), and the tag filter is just for decluttering (so you don't get lost in a long list of modules).

The only nag screen is a ugly red marker for the experimental modules.

Note that "diagnostics" is not considered dangerous; these are just safe troubleshooting tools that anyone can run (but they are not that useful for actual photo/video shooting). The extra care should be IMO for experiments (research tools) and things that are known not to work.

There is some behavior that might be confusing: loaded modules are always displayed, no matter what the filter selection is.

[Audionut]

The labels on right (?, +, ++) are a little confusing since they are not clearly defined in the menu unless you have that filter selected.  Can you make the ratings color coded when pressing set to choose, rather then only when selected?

It would be much preferred IMO, if only those modules with that tag, are displayed when filtering by tags.

[a1ex]

Both solved.

[eyeland]

I think that this a very productive development which could greatly add to the maturity of ML.
Especially the aspect of /2, making it easier to get started on developing appeals to me (and surely many other lurking potential contributors)

[Audionut]

Nanomad did some good progress with building modules outside the main tree, but it was kinda silent and not yet in a "just works" state. I still like this idea of regarding modules as user apps, so each module author can work on it without restrictions. For visibility, at least the good ones do deserve a place on the nightly builds page though.

Proposals are welcome (in the original thread, to keep things organazized), for example, about how they should appear on the download page.

Functionality like the "Show Older Builds" would work well IMO.




Inside the build details, you could have creator, forum link, maybe a short description of the module.

[dmilligan]

A response I posted on another thread, that applies to this one:

Since these are both modules, they don't "know" about each other. Perhaps something like a "Conflicts" tag could be added for https://bitbucket.org/hudson/magic-lantern/pull-request/407/module-tags-ratings-wip That could also be used for mlv_rec, raw_rec.

[a1ex]

A "conflicts" tag would prevent the modules from being loaded at the same time. Probably useful in some cases.

However, most conflicts appear once you enable both modules in the main menu (but if you load both modules and only enable one of them, it's all fine). So, a conflict handler may be interesting in the menu backend or even in the config variables, for example with this idea as a starting point: http://magiclantern.fm/forum/index.php?topic=12076.msg117037#msg117037

[Marsu42]

So, a conflict handler may be interesting in the menu backend or even in the config variables

+1, that sounds like a sound proposal, though there should be some gui backend asking the user which of the conflicting features to enable or at least clearly notify about what is about to be turned auto-turned off to prevent conflicts.

[a1ex]

The GUI part can be simply the first feature enabled being left enabled, and the second one grayed out, with an explanation (you need to turn off XYZ or whatever). So, you'll notice it right away when you attempt to enable a conflicting feature.

[dmilligan]

what about something sort of like a semaphore?

Code: [Select]

mlv_rec.c:

static struct menu_entry raw_video_menu[] =
{
    {
        .name = "RAW video (MLV)",
        .priv = &mlv_video_enabled,
        .max = 1,
        .update = raw_main_update,
        .submenu_width = 710,
        .depends_on = DEP_LIVEVIEW | DEP_MOVIE_MODE,
        .help = "Record 14-bit RAW video. Press LiveView to start.",
        .semaphore = "RawRecording"
...
}

raw_rec.c:

static struct menu_entry raw_video_menu[] =
{
    {
        .name = "RAW video",
        .priv = &raw_video_enabled,
        .max = 1,
        .update = raw_main_update,
        .submenu_width = 710,
        .depends_on = DEP_LIVEVIEW | DEP_MOVIE_MODE,
        .help = "Record 14-bit RAW video. Press LiveView to start.",
        .semaphore = "RawRecording"
...
}

The menu backend would not allow any two menu entries with the same .semaphore to be enabled at the same time.

[a1ex]

Looks clean; however, right now, the config variable has to be enabled even if the menu is grayed out. I'd like a way to have a feature enabled in menu, grayed out, but inactive in the worker code - and this behavior should be without duplicating the checing code in both menu and worker code.

Will think about it.

[Marsu42]

The GUI part can be simply the first feature enabled being left enabled, and the second one grayed out, with an explanation (you need to turn off XYZ or whatever). So, you'll notice it right away when you attempt to enable a conflicting feature.

Ok, might be the simplest solution, though you'd need to really search for dependencies when learning ML and it gets complicated if there are chain dependencies a disables b disables c. If the dependencies are in a table somewhere anyway, probably printing them in the Q help menu screen might be feasible - as there are nearly no docs atm, it the help might look less empty :-)

[a1ex]

I don't expect too many people enabling lots conflicting features at the same time, so it shouldn't be an issue IMO.

And when they do, something like "turn off auto exposure" when trying to enable ETTR, or viceversa, should be straightforward to understand (since the user enabled the first conflicting functionality himself, so he should know where's that).

[stevefal]

If a semaphone namespace is flat and 1:1 per module, that’s not rich enough to capture the potential conflicts. A module could create conflicts not envisioned by the original developer and therefore not be accounted for by the semaphore. Or, if the original developer realizes the multiple potential conflicts and overloads his semaphore, it will be unique and might as well just be the module name – so developers will just have to know which modules conflict with their own.

Probably a list of semaphores would be needed, if at all. And then the module name should by default be the first one:

“MyModule”, “UsesAudio”, “RawRecording”, “UsesShutterButton”,  “HasAStateThatPreventsAnyNumberOfOtherOperations”, “OnlyGodKnows"

Describing dependencies within an open platform is hard. At very least, the most common dependency classes would need to be designed centrally and documented carefully in order to be useful and not generate false positives. Slippery slope problem.

[dmilligan]

If a semaphone namespace is flat and 1:1 per module, that’s not rich enough to capture the potential conflicts. A module could create conflicts not envisioned by the original developer and therefore not be accounted for by the semaphore.

I think you're missing the point. The point is not to catch "conflicts not envisioned by the original developer " but to simply catch known conflicts and warn the user. At least that's the way I see it.

[a1ex]

Nope, stevefal did not miss any point

[dmilligan]

I don't expect too many people enabling lots conflicting features at the same time, so it shouldn't be an issue IMO.

[a1ex]

I was talking about the GUI. Stevefal is talking about modeling known conflicts in the backend.

[dmilligan]

I thought all we were talking about is the GUI