Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#23 UI 4 config proc #1341

Open
wants to merge 282 commits into
base: master
Choose a base branch
from

Conversation

thiagofuer
Copy link

This is the first part of issue #23 implementation for review and suggestion.
Layout content:
-Home page with logo and options buttons ("Open case" button not implemented yet)
-Config menu (by now it only read properties and do not write)
-New case menu
tab case info: read data but don't save
tab evidences: only "add disk" is missing
tab process options: not implemented yet
-"Start processing" is being implemented now

no internationalization ready (it's in pt-br only)
To test the new UI implementation go to iped.app.home.MainFrame and run main method
you need to setup iped properties location manually (by now its hard coded)

@lfcnassif
Copy link
Member

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

@lfcnassif lfcnassif mentioned this pull request Oct 31, 2022
@patrickdalla
Copy link
Collaborator

patrickdalla commented Nov 1, 2022

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

@thiagofuer
Copy link
Author

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...

@lfcnassif
Copy link
Member

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.

@thiagofuer
Copy link
Author

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.

@patrickdalla
Copy link
Collaborator

"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.

@patrickdalla
Copy link
Collaborator

patrickdalla commented Nov 1, 2022

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.

@lfcnassif
Copy link
Member

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.

@patrickdalla
Copy link
Collaborator

@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):

image

@patrickdalla
Copy link
Collaborator

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.

@lfcnassif
Copy link
Member

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
Copy link
Author

@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):

image

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.

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

@patrickdalla
Copy link
Collaborator

patrickdalla commented Nov 1, 2022 via email

@lfcnassif
Copy link
Member

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?

@patrickdalla
Copy link
Collaborator

patrickdalla commented Nov 4, 2022 via email

@patrickdalla
Copy link
Collaborator

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.

@lfcnassif
Copy link
Member

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.

@patrickdalla
Copy link
Collaborator

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?

@lfcnassif
Copy link
Member

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.

@patrickdalla
Copy link
Collaborator

Right

@patrickdalla
Copy link
Collaborator

@thiagofuer I tried to push my updates to a new branch in your FORK, but it seems I don't have permission.

image

@patrickdalla
Copy link
Collaborator

I kept the table UI and created a tabbed panel interfaces to each task. The tabs implements an created abstract ConfigurablePanel class. I have implemented subclasses of this class for UTF8Properties, String and generic Bean objects. I have also implemented profile selection and new profile creation code. Not complete yet, though.

@patrickdalla
Copy link
Collaborator

Should distributed defined profiles be editable, removable?

@lfcnassif
Copy link
Member

I kept the table UI and created a tabbed panel interfaces to each task. The tabs implements an created abstract ConfigurablePanel class. I have implemented subclasses of this class for UTF8Properties, String and generic Bean objects. I have also implemented profile selection and new profile creation code. Not complete yet, though.

Great!!! Thank you @patrickdalla! I haven't seen your code yet, but I thought about some dynamic UI to handle common property types automatically (e.g. String -> JTextField, Boolean -> RadioButton, Integer -> ScrollButton, Enum -> JCombobox, etc), so devs wouldn't need to always implement config panels, although they could override them, maybe you have also implemented that too...

Just a final comment (again I haven't seen your code, sorry if this does not fit) AbstractTasks should run on environments without screens, so no Swing or AWT classes should be instantiated from them.

@lfcnassif
Copy link
Member

lfcnassif commented Nov 10, 2022

Should distributed defined profiles be editable, removable?

I think they should be read only (save button disabled), non removable and new profiles could be created based on existing ones. If anyone disagrees, please let us know.

@thiagofuer
Copy link
Author

@thiagofuer I tried to push my updates to a new branch in your FORK, but it seems I don't have permission.

image

i sent you an invite to my repo access.

@lfcnassif
Copy link
Member

Hi @marcus6n, how are your tests with this PR going?

@marcus6n
Copy link
Contributor

Hi @lfcnassif, I'll finish the tests this afternoon and get back to you with the results.

@marcus6n
Copy link
Contributor

marcus6n commented Jun 18, 2024

  1. The error that appeared in the log when running iped.exe no longer occurs.

  2. In addition, the error that appeared when clicking on "Load case data" and then canceling has also been resolved.

  3. Now the cases are being processed correctly, since previously they were stuck in "Starting ParsingTask".

  4. Error in “Add a case to the list”

    image

iped.app.home.newcase.tabs.caseinfo.CaseException: IPED-SearchApp not found.
        at iped.app.home.newcase.tabs.caseinfo.CaseInfoManager.validateCasePath(CaseInfoManager.java:21)
        at iped.app.home.opencase.OpenCasePanel.lambda$createTableButtonsPanel$0(OpenCasePanel.java:92)
        at java.desktop/javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
        at java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
        at java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
        at java.desktop/javax.swing.DefaultButtonModel.setPressed(Unknown Source)
        at java.desktop/javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
        at java.desktop/java.awt.Component.processMouseEvent(Unknown Source)
        at java.desktop/javax.swing.JComponent.processMouseEvent(Unknown Source)
        at java.desktop/java.awt.Component.processEvent(Unknown Source)
        at java.desktop/java.awt.Container.processEvent(Unknown Source)
        at java.desktop/java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.desktop/java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.desktop/java.awt.Component.dispatchEvent(Unknown Source)
        at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
        at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
        at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.desktop/java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.desktop/java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.desktop/java.awt.Component.dispatchEvent(Unknown Source)
        at java.desktop/java.awt.EventQueue.dispatchEventImpl(Unknown Source)
        at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
        at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
        at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
        at java.desktop/java.awt.EventQueue$5.run(Unknown Source)
        at java.desktop/java.awt.EventQueue$5.run(Unknown Source)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
        at java.desktop/java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.run(Unknown Source)

Cause: This error occurs when the system tries to validate the case path and cannot find the IPED-SearchApp application, even though the application is located within the case folder.

  1. The case process is not finished.
iped.app.home.newcase.tabs.caseinfo.CaseException: The case process is not finished
        at iped.app.home.newcase.tabs.caseinfo.CaseInfoManager.validateCasePath(CaseInfoManager.java:23)
        at iped.app.home.opencase.OpenCasePanel.lambda$createTableButtonsPanel$0(OpenCasePanel.java:92)
        at java.desktop/javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
        at java.desktop/javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
        at java.desktop/javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
        at java.desktop/javax.swing.DefaultButtonModel.setPressed(Unknown Source)
        at java.desktop/javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
        at java.desktop/java.awt.Component.processMouseEvent(Unknown Source)
        at java.desktop/javax.swing.JComponent.processMouseEvent(Unknown Source)
        at java.desktop/java.awt.Component.processEvent(Unknown Source)
        at java.desktop/java.awt.Container.processEvent(Unknown Source)
        at java.desktop/java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.desktop/java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.desktop/java.awt.Component.dispatchEvent(Unknown Source)
        at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
        at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
        at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.desktop/java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.desktop/java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.desktop/java.awt.Component.dispatchEvent(Unknown Source)
        at java.desktop/java.awt.EventQueue.dispatchEventImpl(Unknown Source)
        at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
        at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
        at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
        at java.desktop/java.awt.EventQueue$5.run(Unknown Source)
        at java.desktop/java.awt.EventQueue$5.run(Unknown Source)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
        at java.desktop/java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.run(Unknown Source)

Cause: This error occurs when the system tries to validate the case path, but the process associated with the case has already been completed.

PS: @lfcnassif, can you check and confirm these errors I found?

@lfcnassif
Copy link
Member

Thanks @marcus6n for testing. Unfortunately this week I'm with no available time to work on this. @patrickdalla could you take a look at the errors pointed by @marcus6n?

@lfcnassif
Copy link
Member

@marcus6n, I just fixed error 5 and other issue when opening multicases. Error 4 didn't happen to me.

@lfcnassif
Copy link
Member

I would like to discuss with other DEVs the case information fields displayed to the user:
image

I know just the output folder is required, but I think there are too much fields, making that panel annoying to fill. What would be the minimum fields to display in this step (the user may complement them when creating the report):

  • Examiner
  • Case Number (or Name, or ID)

Any others?

@wladimirleite
Copy link
Member

Examiner and Case ID.

@lfcnassif
Copy link
Member

Stopping for today. Documenting to don't forget:

  • Every time a task is enabled or disabled in the main task table selection, a NPE is printed:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
        at java.desktop/javax.swing.plaf.basic.BasicTableUI$Handler.setValueIsAdjusting(Unknown Source)
        at java.desktop/javax.swing.plaf.basic.BasicTableUI$Handler.mouseReleased(Unknown Source)
        at java.desktop/java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
        at java.desktop/java.awt.Component.processMouseEvent(Unknown Source)
        at java.desktop/javax.swing.JComponent.processMouseEvent(Unknown Source)
        at java.desktop/java.awt.Component.processEvent(Unknown Source)
        at java.desktop/java.awt.Container.processEvent(Unknown Source)
        at java.desktop/java.awt.Component.dispatchEventImpl(Unknown Source)
        at java.desktop/java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.desktop/java.awt.Component.dispatchEvent(Unknown Source)
        at java.desktop/java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
        at java.desktop/java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
        at java.desktop/java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
        at java.desktop/java.awt.Container.dispatchEventImpl(Unknown Source)
        at java.desktop/java.awt.Window.dispatchEventImpl(Unknown Source)
        at java.desktop/java.awt.Component.dispatchEvent(Unknown Source)
        at java.desktop/java.awt.EventQueue.dispatchEventImpl(Unknown Source)
        at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
        at java.desktop/java.awt.EventQueue$4.run(Unknown Source)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
        at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
        at java.desktop/java.awt.EventQueue$5.run(Unknown Source)
        at java.desktop/java.awt.EventQueue$5.run(Unknown Source)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(Unknown Source)
        at java.desktop/java.awt.EventQueue.dispatchEvent(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.desktop/java.awt.EventDispatchThread.run(Unknown Source)
  • If I enable OCR or some other tasks and create a new profile, processing fails at the beginning with:
java.lang.ArithmeticException: / by zero
	at iped.engine.core.Statistics.printSystemInfo(Statistics.java:409) ~[iped-engine-4.2-snapshot.jar:?]
	at iped.engine.core.Manager.process(Manager.java:246) ~[iped-engine-4.2-snapshot.jar:?]
	at iped.app.processing.Main.startManager(Main.java:193) [iped.jar:?]
	at iped.app.processing.Main.execute(Main.java:255) [iped.jar:?]
	at iped.app.processing.Main.main(Main.java:323) [iped.jar:?]
  • Enabling some tasks and saving a new profile, it sometimes still freezes on ParsingTask initialization

@patrickdalla
Copy link
Collaborator

"Every time a task is enabled or disabled in the main task table selection, a NPE is printed:"
this was solved by commit [b3ef5c9]

@patrickdalla
Copy link
Collaborator

patrickdalla commented Jul 1, 2024

"If I enable OCR or some other tasks and create a new profile, processing fails at the beginning with:"
This didn't seem to be a problem of OCR config, but of number of threads configured as "default", which wasn't being correctly recognized. If I am right, it was solved by [18711ab].

@lfcnassif
Copy link
Member

this was solved by commit [b3ef5c9]

Thanks @patrickdalla!

This doesn't seemed to be a problem of OCR config, but of number of threads configured as "default", which wasn't being correctly recognized. If I am right, it was solved by [18711ab].

Yes, it seemed an issue with LocalConfig->numthreads parameter not being handled/saved correctly.

@gfd2020
Copy link
Collaborator

gfd2020 commented Jul 4, 2024

I have some suggestions.

Place a parameter in LocalConfig.txt to save the default directory for case output folder when clicking the directory choice button.
Another parameter to save the default directory where the images will be chosen for processing ( Add file/folder button).
I have these two parameters in the custom interface that I use and they are very useful.

Fix buttons with icons without tooltip...

Add the option to choose "portable" processing...

The "Evidence Details" and "Choose the disk to be processed" windows should be modal...

@lfcnassif
Copy link
Member

I have some suggestions.

Thanks @gfd2020.

Place a parameter in LocalConfig.txt to save the default directory for case output folder when clicking the directory choice button.
Another parameter to save the default directory where the images will be chosen for processing ( Add file/folder button).
I have these two parameters in the custom interface that I use and they are very useful.

Yes, opening the dialogs always in user home directory is annoying, I noticed that. But I would save those last selected folders in a new file in user.home/.iped folder.

Add the option to choose "portable" processing...

This is important.

Unfortunately I'm not sure if I'll have time to implement those enhancements, since I'm becoming the head of the central digital forensic lab in my agency. I'll be on vacation on the next 2 weeks and I will try to finish the very minimum for 4.2.0 version, because it will be impossible to accomplish that during my work hours from now on...

If you have available time to help us finish this PR (we need more tests and more tests, and to finish the UI translation to all 6 supported languages) that would be appreciated very much.

@gfd2020
Copy link
Collaborator

gfd2020 commented Jul 5, 2024

If you have available time to help us finish this PR (we need more tests and more tests, and to finish the UI translation to all 6 supported languages) that would be appreciated very much.

hi, @lfcnassif .

I found this GUI test automation tool.
Is it viable to use to test the GUI?

https://github.com/dotxyteam/SwingTestingToolkit

@lfcnassif
Copy link
Member

hi, @lfcnassif .

I found this GUI test automation tool. Is it viable to use to test the GUI?

https://github.com/dotxyteam/SwingTestingToolkit

Hi @gfd2020. I'm not sure, I never used that project. UI testing is a bit difficult to automate and to cover all user interation possibilities, but what I meant was just doing more manual testing with more features/options combinations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
4.2
In progress
Development

Successfully merging this pull request may close these issues.

None yet

7 participants