Crop widget crop list not following common patterns

Attaching a patch with the first draft of the new widget. Work in progress...

Current status in the attached screenshots.

TO-DO: Actual cropping of the image and display of the cropped image in the table.

Initially the idea was to offer an ui a little more "sexy" than what we had in the old crop module.
Currently this is a good interface to better integrate drupal it's true, but for user expérience, I think this UX loses much the side "sexy" of the widget.

What may be possible it would be to find an interface for the plugin to be able to keep the basic interface system (Drupal Way) and a more graphical and intuitive interface (and therefore able to offer a really cool features that will add custom interfaces to the crop module). The idea that would provide a system of LIKE as media_entity providers, who will be in charge of rendering elements and necessarily generate within PROCESS.

What are your views on the subject?

Together with @miro_dietiker, @slashrsm and @Lukas we discussed about it. We thought about implementing a completely new UI, but that would take too much time and complexity to figure out how to restructure everything. Since the current solution is very similar to the vertical tabs (used in core), we can use that as a starting point and implement the same features as we have currently. So we will have all the tabs with ratios and in the content a checkbox to enable and disable it, together with the image to crop (or with the current cropping applied). This would also solve the broken responsive design that we have now and with it, we could get rid of all the custom CSS and javascript.

We will start working on it shortly and post some mockup screenshots.

Thank you for that overview , I actually partler with slashrsm so we'll see for a redesign more "standard" . My idea for doing this would be to do like what I propose with IEF .

woprrr> Therefore so we can adapt ImageWidgetCrop a fully integrated drupal, and kind of "Fork" with the current interface? this sounds good solutions.
slashrsm, Otherwise we can offer two widgets, a standard and complex.
yes

Thus we can keep the original class and move the formatting function "process" current widget in a "complex" and see for a "standard" version of what we 'd FieldWidget " Complex " & "Standard". We could also take a class like " Manager " to keep all common areas in both widgets in one place and spread it in the various widgets.

What do you think ?

@sasanikolic and I replaced the ratio list with vertical tabs. The cropping itself is broken because now we will have a cropping area per ratio.

@woprrr: what do you think?

To simplify the synchronization and advancement, I was creating a specific branch redesign and standardization of the UI,

https://github.com/woprrr/image_widget_crop/tree/standardize-ui

@Lukas von Blarer

I have not had time to move forward on the JS part, but I have noticed that you remove the items ('thumb-w', 'thumb-h') it is important not !! it's elements are essential to the calculation of dimenssions out of the way to real thumbnail size picture. @see getThumbnailCropProperties(). We must add this, we can ping me in IRC.

I created a final pull request for this: https://github.com/woprrr/image_widget_crop/pull/14

There are several follow-up issues which I will file in the next days.

    //@TODO: $properties['thumb-h'] should be calculated here. It also prevents crops being saved the first time since this is not set.
    $delta = $original_height / $properties['thumb-h'];

I just have a comment about this TODO. For the record we have no means in the code to find the final size of the thumbnail before its creation, because we will not know the dimenssions This is due to the scale of the width. That's why I used jQuery to give me the size of the thumbnail and fournisait has the calculation function. I think we naurons no other way to guess the height to retrieve the delta load image.

Attaching the patch of all the changes we did last week at the sprint. Lets get this committed and move forward with follow-ups.

@miro_dietiker

Tonight I will finish the review of the "standardized" version and the merge with the different tickets. In terms of the solution that we have seen done for coehexister both interfaces, I'll go on a simple way. Merge the standard version and once I finalize the version with a more complex interface with cropper I merge into a second widget after.

There is a problem now, the corp has the record is not taken into account. If I edit the content and I made a new area when the crop is considered. I think having remove $ verification entity-> new () is not a very good idea.

A publishing corp zone for the first element, it is very small. @see screenshots.

@woprrr What browser are you using?

Here are the requested screenshots of the working UI.

Widget after uploading the image:

Widget after opening the cropping accordion:

Widget after cropping:

I v fixed all "criticals" bugs for provide an version fonctional with standardization ui.

Setting to RTBC. Lets create follow-ups for the remaining issues.

Great job all ! Thanks !