Thank you very much @thiagofuer for helping with this! I plan to review this next week.

Tasks dependecy/order are not declared in any interface or method. Is this important to order the tasks configuration panel?

maybe sort in alphabetical order by default
or a option to sort by click on column name but i believe it is not mandatory now.
I'm planing back to code beginning November 14...

Tasks dependecy/order are not declared in any interface or method

This can be found in iped.engine.config.TaskInstallerConfig class.

The user shouldn't be able to change task sorting, since the execution order/task dependency is VERY sensitive.

but the task sort could be done only on the config view without reflect on the execution order. It could be only to be easy to user found.

"order/task dependency is VERY sensitive"
Yes, but we have to define if the user will be able to disable/enable a task on the config UI, and if so, which other tasks should be included together with the selected task (and the order they will be included) to it function properly.

but the task sort could be done only on the config view without reflect on the execution order. It could be only to be easy to user found.

Mainly the dependency structure needed is not for task list visual ordering. I think the best is to to exhibit on the correct execution order. It is to automatically include dependent tasks (in the correct order) when a task is checked to be included in the processing.

It could be only to be easy to user found.

I prefer to always display the processing pipeline execution order.

which other tasks should be included together with the selected task

Good point, this is important. Notice this situation can already occur without the configuration UI, only changing config files today. Some modules check their dependencies and, if not met, they abort or disable itself printing a warning message in the Console. This approach could be improved for the UI.

@thiagofuer, a specific task can have more than one configurable. For example, ParsingTask has ParsingTaskConfig, CategoryToExpand, Parsers and ExternalParsers configurables.

Maybe a Tree instead of table can be more suitable. Something like this (pardon for the bad UI of the tree, you can improve later):

Or the table could be kept, and each configurable of the task could be presented as a TAB in the corresponding Task config UI dialog.

Or the table could be kept, and each configurable of the task could be presented as a TAB in the corresponding Task config UI dialog.

This is exactly how I thought about it. I think this is more user friendly.

@thiagofuer, a specific task can have more than one configurable. For example, ParsingTask has ParsingTaskConfig, CategoryToExpand, Parsers and ExternalParsers configurables.

Maybe a Tree instead of table can be more suitable. Something like this (pardon for the bad UI of the tree, you can improve later):

To use a tree certainly is the easy way to show tasks config, but i think that could not be the best solution for unexperienced user.

Or the table could be kept, and each configurable of the task could be presented as a TAB in the corresponding Task config UI dialog.

this is the more user friendly UI option. Most of effort spent in this job is to create a interface that can do IPED "easy" to operate.

On my opinion, we should think on how to add all additional tasks configurables on this dialog. Tabs is a good one!!

Sorry, I'm a bit busy now...

@lfcnassif , I could not find a way to identify which Configurable objects are used by each AbstractTask. I think in put it as a static method of class AbstractTask with the signature Set>> getConfigurables(). So we can identify which configurable classes is used to instantiate the Task, and look for this kind of objects in the ConfigurationManager object.

This already exists, but the method is not static. Wouldn't it be enough?

This method (getConfigurables) is implemented in the AbstractTask descendants classes to return empty configurable objects. Not the loaded one from the files.
This should be corrected? The Idea is to return the corresponding object registered in ConfigurableManager, and if none (null), create a new one. What do you think?

Maybe they are implemented in a little different way from what the Config UI may need. Config UI must know which kind of configurable a Task (or other kind of objects) needs, so it can create the appropriate UI.

This method (getConfigurables) is implemented in the AbstractTask descendants classes to return empty configurable objects. Not the loaded one from the files. This should be corrected? The Idea is to return the corresponding object registered in ConfigurableManager, and if none (null), create a new one. What do you think?

Maybe they are implemented in a little different way from what the Config UI may need. Config UI must know which kind of configurable a Task (or other kind of objects) needs, so it can create the appropriate UI.

Yes, this should be better. Currently they return a new instance that then is populated by ConfigurationManager. Reusing already existing ones should be better.

Although the great majority of current AbstractTask implementations is instanced once, ScriptTask and PythonTask is instanced more than once, one for each script file. Maybe, other future AbstractTasks will permit to be instanced more than once.
So, the UI that exhibits a checkbox to install or uninstall an AbstractTask may not be the best.

@lfcnassif , what do you think? Do we keep the checkbox style task installation on UI, making some kind of exceptions only to script tasks that needs to be installed more than once, or should find another kind of UI?

Hi @patrickdalla, this week I'm attending 7th DFEG Interpol Conference, so I may be slow to respond.

@lfcnassif , what do you think?

I think we should keep the checkbox list layout and write custom code to handle ScriptTasks and PythonTasks. Actually each Worker thread creates his own Tasks instances, so all of them are instantiated more than once on most machines. I think we should avoid putting the same Tak twice in the processing pipeline, that could be confusing.

I couldn't think on a more user friendly layout, but I'm open for suggestions.

Sorry, my fault doing the merge. I don't know when I'll have time to fix this, since I'm very busy today and will travel tomorrow, but I'll try to fix as soon as possible...
no prob.
I can continue the activity regardless of this correction

TODOs before this can be merged (I'll update the list as I find more things...):

* [x]  Finish the Portuguese localization

* [x]  Prepare the localization for all languages to send them to foreign collaborators

* [x]  Remove from task table those tasks that cannot be disabled (always enabled). Just FragmentLargeBinaryTask has configuration options, but since they are advanced configs, I think it is fine to hide them in this UI.

* [x]  Avoid moving Script Tasks (at least the default ones) in execution pipeline, user can break them easily

* [x]  Some Script Tasks configurations are not being shown (e.g. FaceRecognition), their codes are being shown instead

* [x]  Avoid user changing default script Tasks code, they can break them easily. Actually, in my opinion, this UI for beginners shouldn't display any code. Maybe even avoid addition of custom scripts, at least for now...

* [x]  Show as tooltips the txt config files comments for each Task and for their configurations in their config panels

* [x]  Show proper UI components for booleans (checkboxes), numbers (spinners), enums (comboboxes) configurations instead of text boxes for all of them

* [ ]  Translate all config files comments to Portuguese, so they can be displayed as tooltips properly. Please, don't do this right now, I'll review all English comments in configs before.

* [x]  In the final screen, change the "View Console Log" button to "View Processing Log"

* [x]  show FileSystemConfig somewhere in the Tasks panel, but not in the table since it is not a Task, it is a very important config and the user should be able to change it.

* [x]  Simplify/Unify the Case Info model with the Report Info model, it should be the same to avoid duplication. Users should also be able to change case info before generating the report in the report dialog.

* [x]  Remove the new created iped-gui.jar, we can reuse the old iped.jar and open the new UI if no parameter is passed and if a screen device is available.

i have finished the first report integration version.
Now the Home app and the ipedsearchapp report popup uses the same code to handle the report info.
i still need do some tests to find possible bugs but by now you can do your avaliation.

@lfcnassif I have a question... I don't analyzed all code and, to save some time, i would appreciate if you could told-me how the iped-search-app generates the HTML report without to enable "enableAutomaticExportFiles" on IPEDConfig.txt and the "CategoriesToExport" ?

i have finished the first report integration version.
Now the Home app and the ipedsearchapp report popup uses the same code to handle the report info.

Thank you @thiagofuer!

@lfcnassif I have a question... I don't analyzed all code and, to save some time, i would appreciate if you could told-me how the iped-search-app generates the HTML report without to enable "enableAutomaticExportFiles" on IPEDConfig.txt and the "CategoriesToExport" ?

The iped.app.ui.ReportDialog class saves checked bookmarks to a temp report.iped file and calls the processing again passing -d report.iped as parameter.

Please convert this draft to "Ready for Review" when you finish all your planned changes, so we can schedule some time to start the review, thanks!

The iped.app.ui.ReportDialog class saves checked bookmarks to a temp report.iped file and calls the processing again passing -d report.iped as parameter.

i've tried to do the same but i do not reach the same result. Even creating the .iped file was necessary to change the parameters but it is not a "required modification" i was trying to do that to create a basic report HTML with the case information.
By now i only added the -asap parameter pointing to the caseinfo.json to the processing command

• Translate all config files comments to Portuguese, so they can be displayed as tooltips properly. Please, don't do this right now, I'll review all English comments in configs before.

Before to change to "Ready for Review" i need to know how to proceed with this topic? or he isn't a required topic to release this version?
and i need to know your review of the caseinfo json file, so then i can do a more accurate code to final user.
maybe a test with a real "asap" file to know if has any impact

Before to change to "Ready for Review" i need to know how to proceed with this topic? or he isn't a required topic to release this version?

Translating all config files comments to all supported languages will need a lot of work from foreign collaborators and I'm not sure if they will be able to help us in the near future. So I think we may delay this to 4.3, what other devs think?

and i need to know your review of the caseinfo json file, so then i can do a more accurate code to final user.
maybe a test with a real "asap" file to know if has any impact

Sure! I'll try to take a look and test with a real asap file soon.

Hi @lfcnassif and @patrickdalla.
I've made some tests and adjustments on the code.
I tried to solve all them but one caught my attention. When i try to process using a user created profile the app crash..
since I've getting some machine problems (the python parsing tasks stuck to me) could you guys to do a test on your pc?
so if it is running without problem i can change the branch to "ready for review"

Hi @lfcnassif and @patrickdalla. I've made some tests and adjustments on the code. I tried to solve all them but one caught my attention. When i try to process using a user created profile the app crash.. since I've getting some machine problems (the python parsing tasks stuck to me) could you guys to do a test on your pc? so if it is running without problem i can change the branch to "ready for review"

I tested it on another machine and I was able to see that the problem was probably the environment on my PC.
So i will change to ready for review

Thank you @thiagofuer for all your work on this great contribution! When I get some reasonable time slot available, I'll try to start the review.

Suggestion:
I follow a discussion group on the use of the IPED tool. I see that less advanced users have great difficulty dealing with memory problems. Especially if you need to pass the -Xmx parameter to the JVM. Sometimes they think they need to change computers when a memory problem occurs. In this sense, I believe that a more user-friendly memory configuration option would be interesting, such as a slider to increase and decrease memory. The slider would start at the default memory defined by java and could increase to the maximum physical memory or to the maximum available memory

Suggestion:
I follow a discussion group on the use of the IPED tool. I see that less advanced users have great difficulty dealing with memory problems. Especially if you need to pass the -Xmx parameter to the JVM. Sometimes they think they need to change computers when a memory problem occurs. In this sense, I believe that a more user-friendly memory configuration option would be interesting, such as a slider to increase and decrease memory. The slider would start at the default memory defined by java and could increase to the maximum physical memory or to the maximum available memory

This is a good idea. But I don't agree to allow using all the physical memory as Xmx. The OS needs memory, IPED opens several other processes that need memory (imagemagick, mplayer, tesseract, robustImageReaders, java and non java external parsers, python processes). As a rule of thumb, I would allow using half the physical memory and possibly limit it to 32GB, as more than that causes java pointers to go from 4 bytes to 8 bytes, wasting much more memory just to manage object references. Traditional JVMs also have trouble to garbage collect huge heaps, not sure about more recent JVMs.

This is a good idea. But I don't agree to allow using all the physical memory as Xmx. The OS needs memory, IPED opens several other processes that need memory (imagemagick, mplayer, tesseract, robustImageReaders, java and non java external parsers, python processes). As a rule of thumb, I would allow using half the physical memory and possibly limit it to 32GB, as more than that causes java pointers to go from 4 bytes to 8 bytes, wasting much more memory just to manage object references. Traditional JVMs also have trouble to garbage collect huge heaps, not sure about more recent JVMs.

Yes, as you said, allowing all physical memory can be bad because the system can run out of memory. That's why I said "or available memory" in the sense of memory that is free for use and the OS is not using it. In the graphical interface that I use, I leave the maximum possible as the physical one, but I know not to set the maximum. That said, it would be a matter of defining what would be a default value for maximum memory, which could also be configurable as a parameter.