Clean up difflib

[ddkwork]

remove min and max,go-difflib

[ddkwork]

Can you get rid of the min and max functions entirely instead of commenting them out and run go mod tidy again? Thanks!

I tested all the examples under the examples folder of goki and there are no exceptions, because min and max are functions of the go1.21 standard library, which are built-in functions of the compiler. I'm working on window drag-and-drop file support, I looked at the implementations of Unison and Fyne, they both call glfw, their implementation logic is like this: get the coordinates of the mouse, call the window of glfw related to the other api call before the cursor position of the mouse to get the coordinates and area of the drag-and-drop file, how to implement it later I'm still looking at the code.

[ddkwork]

After implementing the file drag-and-drop function, we can drag and drop the packet capture history file in the packet capture interface to render the previous packet capture records, similar to the function of mitmproxy loading the packet capture record, we can also drag and drop the go file in the code editor, and at the same time calculate the parent directory of the drag-and-drop file and load it to the left view area of the filetree

[kkoreilly]

Sorry for the misunderstand: I was saying to just remove the min and max function definitions instead of commenting them out, as they are already defined in the standard library and we do not need to redefine them. We can still obviously use those functions provided by the standard library, I am just saying that you should remove the lines you commented out for the min and max functions.

[kkoreilly]

We already have some logic for handling drag-and-drop events, it just isn't complete. You can see the glfw event handling here: https://github.com/goki/goki/blob/main/goosi/driver/desktop/event.go#L140.

[kkoreilly]

To implement native drag-and-drop support, you need to need to update that code to send drop events, which you can do with the events.NewDragDrop function.

[ddkwork]

Sorry for the misunderstand: I was saying to just remove the min and max function definitions instead of commenting them out, as they are already defined in the standard library and we do not need to redefine them. We can still obviously use those functions provided by the standard library, I am just saying that you should remove the lines you commented out for the min and max functions.

Oh no, sorry my bad English.

[ddkwork]

We already have some logic for handling drag-and-drop events, it just isn't complete. You can see the glfw event handling here: https://github.com/goki/goki/blob/main/goosi/driver/desktop/event.go#L140.

I will try.

[ddkwork]

To implement native drag-and-drop support, you need to need to update that code to send drop events, which you can do with the events.NewDragDrop function.

I've looked at the current implementation and it seems that both drag-and-drop files and drag-and-drop widgets use the event manager and manage drag-and-drop behavior. However, drag-and-drop files require few parameters and logic, while drag-and-drop widgets require a little more information. So is it necessary to separate the logic of drag-and-drop files from drag-and-drop widgets? Drag-and-drop files require the cursor release coordinates of the mouse and the string slice variable of the file path as parameters, while drag-and-drop widgets are used for visual interface designers, dynamic adjustment of tree nodes and other application scenarios, and it is necessary to judge the type, size and style of the source and target widget and other information to be copied to the target location for rendering, which has more complex things to deal with than drag-and-drop files. However, the implementation of other libraries only supports a window to set a file drag-and-drop callback, if every control in addition to the window supports drag-and-drop files, it is still convenient to use the event manager. Take the code editor as an example, we drag and drop a go file from Windows Explorer to the code editor, I think only the main window needs to have the behavior of dragging and dropping files, code editing widgets or buttons, labels, tables and other widgets of the drag-and-drop file behavior we can get the file path slice from the drag-and-drop event of the main window. If so, then drag-and-drop files and drag-and-drop widgets need to be controlled by two pieces of logic, what do you think about that?

[kkoreilly]

I will merge your difflib changes now and we can make drag and drop a separate PR. I will think about the drag and drop structure based on your comments and then get back to you soon. Thanks!