New plugins: color tools

[micheus]

Something that can be then improved is the context menu be shown the options correctly.
It has long time I noticed that we only get access to the menu if we are over a color square. but the only option that would require this is the Edit. For the others if we invoke the menu outside the square it should pop-up.

Since you are playing around on it and learning about menus, maybe you would be interested to fix this behaviour.
For that the menu creation will probably need to be broke into two functions: one that include the Edit and other that build everything else depending on where the RMB was clicked (on color square or client area).

What do you think?

[edb]

I've made the changes to the palette patch so everything is in the submenu, it does look much cleaner this way. I've also added a fix for accessing the menu when right clicked outside the square.

Palette patch build:
wings_palette_patch.tar


I've added a preview color square in the corner, and also I've added the ability to delete individual colors by clicking on them and right clicking to delete.

Color panel plugin:
wpc_color_panel.tar

[micheus]

I've made the changes to the palette patch so everything is in the submenu, it does look much cleaner this way. I've also added a fix for accessing the menu when right clicked outside the square.

Perfect! Thanks.

I've added a preview color square in the corner, and also I've added the ability to delete individual colours by clicking on them and right clicking to delete.

Preview looks OK, but maybe it would work a little different.
When we have LMB pressed and move around looking for the nice color we want it's OK it to be shown, but after we release the button it would be good if it was hidden again. I thought this because I noticed I was unable so see the colours behind it if I want to pick one (although it keep showing then correctly based on mouse position). And, in this case, If I was clicking on that region of the panel it would be interesting the preview be shown on the opposite side (left).


Possible additions:
- Since it's fast to get many colours in the local lists it would be nice if the window would to be automatically resized (down) to accommodate and show all the colours we have chosen;
- It can depends on the mesh density, because of the performance, but thinking about to use this panel to speed up the vertex painting it would be nice we have an option to apply the preview color directly on a selection instead of just after release the LMB. Also, because in this process we are looking for a nice color to the object it can flood the color history with unnecessary colours - since by now we need to release the LMB first.

You could add a menu option which shows a checkmark in case of enabled the "direct preview" (each click will switch the option). So, if is there any selection available you can apply the preview color direct to it.
I just updated the reorganized the menu "how to" to include that.

I'm starting to like it as an independent tool.

[tkbd]

hi!edb, Thank you for upadte!
I checked color delete feature,It works fine

So,I made a mini online tool support for assist the exported color data(column/hex data).
It can sort the color order by hue.(But it is experimental not perfectly)
https://brace.client.jp/wings3d_141/sort.html

I used the following page as a reference.
https://era86.github.io/2011/11/15/group...ue-in.html

[edb]

Hello micheus and tkbd,

Preview looks OK, but maybe it would work a little different.
When we have LMB pressed and move around looking for the nice color we want it's OK it to be shown, but after we release the button it would be good if it was hidden again. I thought this because I noticed I was unable so see the colours behind it if I want to pick one (although it keep showing then correctly based on mouse position). And, in this case, If I was clicking on that region of the panel it would be interesting the preview be shown on the opposite side (left).

The preview square will need more changes. I can have the preview square move to opposite sides when it is in the way of the cursor. I'll see what I can do for when the color preview is dismissed. It currently dismisses when the cursor leaves the window as I notice Krita keeps a preview square open even after mouse release until the cursor leaves its color selector (though its preview square has its own borderless window).

Since it's fast to get many colours in the local lists it would be nice if the window would to be automatically resized (down) to accommodate and show all the colours we have chosen;

I'll see what I can do, the color panel also docks it's worth mentioning (it didn't for 2.2.9 for the first build but its now fixed). I could add a compact scroll bar button [v] [^] like InkScape has next to its horizontal palette.

It can depends on the mesh density, because of the performance, but thinking about to use this panel to speed up the vertex painting it would be nice we have an option to apply the preview color directly on a selection instead of just after release the LMB. Also, because in this process we are looking for a nice color to the object it can flood the color history with unnecessary colours - since by now we need to release the LMB first.

That would be neat, there's also the red selection coloring would make sense to have it somehow turn off temporarily during direct preview.

I'm starting to like it as an independent tool.

I'm glad its turning out good, thanks!

I checked color delete feature,It works fine

Thanks for letting me know it works tkbd.

So,I made a mini online tool support for assist the exported color data(column/hex data). It can sort the color order by hue.(But it is experimental not perfectly)

Access as plain text colors is very convenient especially for tools.

Palette Patch

There is no significant changes in this latest patch, just a string typo changed and some source commenting (wouldn't change the compile actually) that were made for the pull request.
wings_palette_patch.tar

[tkbd]

I got a weird segmentation fault11 crash just after Wings3D quit in MacOS.
I haven't tested on Windows, does it happen on Windows too?
I installed last patches to Wings3D, so it caused by the plugin.

How to recreate it

1. Run Wings3D and open/close a Color panel window (Window > Color Panel window open)
   
2. Create a Cube object in 3D geomerty window.(or do some operation for Wings3d)
   
3. Quit Wings3D
   
4. MacOS crash log window appear by segmentation fault.
   

his phenomenon seems to have stopped once Wings3D is closed with the ColorPanel window open.
But when do something and quit Wings3D, it reoccurs.

Code:

Process:               beam.smp [2538]
Path:                  /Applications/Wings3D.app/Contents/Resources/bin/beam.smp
Identifier:            com.wings3d.wings3d
Version:               2.2.9 (2.2.9)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           beam.smp [2538]

Date/Time:             2023-05-29 00:02:20.303 +0900
OS Version:            Mac OS X 10.14.6 (18G9323)

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [2477]


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   com.apple.vImage                  0x00007fff3dc6f917 vPremultipliedAlphaBlendWithPermute_RGBA8888_CV_avx2 + 1447
1   com.apple.CoreGraphics            0x00007fff417c8e62 CGSBlend8888toRGBA8888 + 308
2   com.apple.CoreGraphics            0x00007fff417c7ee4 argb32_image + 7228
3   com.apple.CoreGraphics            0x00007fff417c629f ripl_Mark + 22
4   com.apple.CoreGraphics            0x00007fff417c6274 RIPLayerBltImage + 1018
5   com.apple.CoreGraphics            0x00007fff417c5bb6 ripc_RenderImage + 228
6   com.apple.CoreGraphics            0x00007fff417b9831 ripc_DrawImage + 812
7   com.apple.CoreGraphics            0x00007fff417b94f6 CGContextDelegateDrawImage + 41
8   com.apple.CoreGraphics            0x00007fff417b8cd4 CGContextDrawImageWithOptions + 432
9   com.apple.CoreGraphics            0x00007fff417b8b0f CGContextDrawImage + 51
10  com.apple.AppKit                  0x00007fff3ead28d3 __74-[NSImageRep drawInRect:fromRect:operation:fraction:respectFlipped:hints:]_block_invoke + 949
11  com.apple.AppKit                  0x00007fff3ead232b -[NSImageRep drawInRect:fromRect:operation:fraction:respectFlipped:hints:] + 976
12  com.apple.AppKit                  0x00007fff3efdfc5b __71-[NSImage drawInRect:fromRect:operation:fraction:respectFlipped:hints:]_block_invoke.1317 + 1007
13  com.apple.AppKit                  0x00007fff3ea22933 -[NSImage _usingBestRepresentationForRect:context:hints:body:] + 156
14  com.apple.AppKit                  0x00007fff3ead17a8 -[NSImage drawInRect:fromRect:operation:fraction:respectFlipped:hints:] + 1436
15  com.apple.AppKit                  0x00007fff3eb20bc7 -[NSImage drawInRect:fromRect:operation:fraction:] + 81
16  wxe_driver.so                     0x0000000106ff5e50 wxOSXDrawNSImage(CGContext*, CGRect const*, NSImage*) + 272
17  wxe_driver.so                     0x0000000106fe3121 wxMacCoreGraphicsContext::DrawBitmap(wxBitmap const&, double, double, double, double) + 113
18  wxe_driver.so                     0x00000001070965b8 wxGCDCImpl::DoStretchBlit(int, int, int, int, wxDC*, int, int, int, int, wxRasterOperationMode, bool, int, int) + 808
19  wxe_driver.so                     0x000000010709627c wxGCDCImpl::DoBlit(int, int, int, int, wxDC*, int, int, wxRasterOperationMode, bool, int, int) + 60
20  wxe_driver.so                     0x0000000107091547 wxBufferedDC::UnMask() + 327
21  wxe_driver.so                     0x0000000106d01ced wxBufferedPaintDC::~wxBufferedPaintDC() + 29
22  wxe_driver.so                     0x0000000106d01b9f EwxBufferedPaintDC::~EwxBufferedPaintDC() + 15
23  wxe_driver.so                     0x0000000106ce1614 WxeApp::delete_object(void*, wxeRefData*) + 244
24  wxe_driver.so                     0x0000000106e931fe WxeApp::destroyMemEnv(wxeMetaCommand&) + 494
25  wxe_driver.so                     0x000000010731b5cd wxEvtHandler::SearchDynamicEventTable(wxEvent&) + 317
26  wxe_driver.so                     0x000000010731b2cb wxEvtHandler::ProcessEventLocally(wxEvent&) + 59
27  wxe_driver.so                     0x000000010731b180 wxEvtHandler::ProcessEvent(wxEvent&) + 96
28  wxe_driver.so                     0x000000010731ae8d wxEvtHandler::ProcessPendingEvents() + 493
29  wxe_driver.so                     0x0000000107235ab5 wxAppConsoleBase::ProcessPendingEvents() + 277
30  wxe_driver.so                     0x00000001072f7502 wxCFEventLoop::OSXCommonModeObserverCallBack(__CFRunLoopObserver*, int, void*) + 66
31  com.apple.CoreFoundation          0x00007fff413d5c34 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23
32  com.apple.CoreFoundation          0x00007fff413d5b69 __CFRunLoopDoObservers + 451
33  com.apple.CoreFoundation          0x00007fff413781a0 __CFRunLoopRun + 1136
34  com.apple.CoreFoundation          0x00007fff41377ade CFRunLoopRunSpecific + 455
35  com.apple.HIToolbox               0x00007fff405d61ab RunCurrentEventLoopInMode + 292
36  com.apple.HIToolbox               0x00007fff405d5ded ReceiveNextEventCommon + 355
37  com.apple.HIToolbox               0x00007fff405d5c76 _BlockUntilNextEventMatchingListInModeWithFilter + 64
38  com.apple.AppKit                  0x00007fff3e96de89 _DPSNextEvent + 1135
39  com.apple.AppKit                  0x00007fff3e96cb77 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1361
40  com.apple.AppKit                  0x00007fff3e966c94 -[NSApplication run] + 699
41  wxe_driver.so                     0x0000000107029f8e wxGUIEventLoop::OSXDoRun() + 174
42  wxe_driver.so                     0x00000001072f7dbc wxCFEventLoop::DoRun() + 44
43  wxe_driver.so                     0x0000000107263bbe wxEventLoopBase::Run() + 158
44  wxe_driver.so                     0x0000000107234ea3 wxAppConsoleBase::MainLoop() + 99
45  wxe_driver.so                     0x0000000106fd596a wxApp::OnRun() + 26
46  wxe_driver.so                     0x000000010729c738 wxEntry(int&, wchar_t**) + 56
47  wxe_driver.so                     0x0000000106e92670 wxe_main_loop(void*) + 528
48  beam.smp                          0x0000000104c49c4f erts_sys_main_thread + 319
49  beam.smp                          0x0000000104afba8e erl_start + 11838

Thread 1:: sys_sig_dispatc
0   libsystem_kernel.dylib            0x00007fff6d5a1eee read + 10
1   beam.smp                          0x0000000104c49e0a signal_dispatcher_thread_func + 90

Thread 2:: sys_msg_dispatc
0   libsystem_kernel.dylib            0x00007fff6d5a3866 __psynch_cvwait + 10
1   libsystem_pthread.dylib           0x00007fff6d66256e _pthread_cond_wait + 722
2   beam.smp                          0x0000000104cc1f36 ethr_cond_wait + 6

Thread 3:: async_1
0   libsystem_kernel.dylib            0x00007fff6d5a3866 __psynch_cvwait + 10
1   libsystem_pthread.dylib           0x00007fff6d66256e _pthread_cond_wait + 722
2   beam.smp                          0x0000000104cc50d1 wait__ + 305

[edb]

Hello tkbd,

It could be to be that while drawing the bitmap, something (maybe the window) is gone. I'm not completely sure.

I might need someone more knowledgeable of erlang runtime and wx module than me. The call stack seems to mention wxBufferedPaintDC::~wxBufferedPaintDC() so this seems it happens during wxBufferedPaintDC being destroyed (and probably painting its buffer to the drawing context).

The problem is likely only to the color panel and not the palette patch which only provides some menus to wings_palette and only does file io (doesn't use wx).

[edb]

I wonder if the wxBufferedPaintDC crash happens on linux, I haven't seen a crash on windows but I know some of the windows api like GDI is forgiving of using released handles.

---

I'm going to try using wxPaintDC for non-win32 os, I notice this is used for ww_color_slider.erl so mac os and linux might already be double buffered.

[edb]

I've made a change, let me know if this helps:
wpc_color_panel.tar

[micheus]

Thanks for the update.

Docking is working now as well as the gradient when the window get narrow (it was trunking a little at right side).