Flutter Quill Extensions

[Jon-Salmon]

@singerdmx @freshtechtips

Discussions were getting a bit segmented in pull requests so I thought it best to move some of it here.

Firstly, if we think it would be best to transfer the ownership of flutter_quill_extensions to somebody else (who has more time than me) I have no objection to this. I would only ask that changes to this repo continue to be subjected to a sufficient level of code review to avoid too many accidental breaking issues getting released as stable.

I have had a quick review of the recent changes and have no major objections, although I want to run a few tests before I publish (probably will be tomorrow or Thursday before I can do this). Although this brings me on to what should the numbering be...

Personally, I have a very strong opinion that flutter packages should be following the semantic numbering scheme, where any breaking changes get a new major version number. We don't seem to have been doing this over this last week and the end result is that people will be getting unexpected breaking changes. We have also been publishing things that are marked in the changelog as 'not release ready' which feels super wrong. pub.dev has support for pre-release releases for this very situation.

My personal opinion is that we should redact what has been released over the last week (while we are still within the 7 day window) and then re-release it as a pre-release numbered from 8.0.0-dev, but this is ultimately up to @singerdmx

[singerdmx]

For ownership you can just add his email so he can be collaborator

[singerdmx]

Regarding version number you guys can settle this since I don't have preference

[EchoEllet]

@singerdmx @freshtechtips

Discussions were getting a bit segmented in pull requests so I thought it best to move some of it here.

Firstly, if we think it would be best to transfer the ownership of flutter_quill_extensions to somebody else (who has more time than me) I have no objection to this. I would only ask that changes to this repo continue to be subjected to a sufficient level of code review to avoid too many accidental breaking issues getting released as stable.

I have had a quick review of the recent changes and have no major objections, although I want to run a few tests before I publish (probably will be tomorrow or Thursday before I can do this). Although this brings me on to what should the numbering be...

Personally, I have a very strong opinion that flutter packages should be following the semantic numbering scheme, where any breaking changes get a new major version number. We don't seem to have been doing this over this last week and the end result is that people will be getting unexpected breaking changes. We have also been publishing things that are marked in the changelog as 'not release ready' which feels super wrong. pub.dev has support for pre-release releases for this very situation.

My personal opinion is that we should redact what has been released over the last week (while we are still within the 7 day window) and then re-release it as a pre-release numbered from 8.0.0-dev, but this is ultimately up to @singerdmx

For the development version, I suggest that as well, but publishing it directly as a release will allow us to catch the issues faster it's just one or maybe two weeks and won't take long and we already mentioned that, yes it's true that pub.dev support dev version but we have to create a different branch for the development and merge/rebase things all the time and fix conflicts so we had to choose this approach since it won't take very long, regarding of the issues we are trying to fix it in the same day and most of them after a few hours or minutes and still that doesn't sound something professional but we will do everything we can to improve everything but we don't have much time, yes we have but mostly for development and not the support and the documentation but we will move to that very soon

[EchoEllet]

@singerdmx @freshtechtips

Discussions were getting a bit segmented in pull requests so I thought it best to move some of it here.

Firstly, if we think it would be best to transfer the ownership of flutter_quill_extensions to somebody else (who has more time than me) I have no objection to this. I would only ask that changes to this repo continue to be subjected to a sufficient level of code review to avoid too many accidental breaking issues getting released as stable.

I have had a quick review of the recent changes and have no major objections, although I want to run a few tests before I publish (probably will be tomorrow or Thursday before I can do this). Although this brings me on to what should the numbering be...

Personally, I have a very strong opinion that flutter packages should be following the semantic numbering scheme, where any breaking changes get a new major version number. We don't seem to have been doing this over this last week and the end result is that people will be getting unexpected breaking changes. We have also been publishing things that are marked in the changelog as 'not release ready' which feels super wrong. pub.dev has support for pre-release releases for this very situation.

My personal opinion is that we should redact what has been released over the last week (while we are still within the 7 day window) and then re-release it as a pre-release numbered from 8.0.0-dev, but this is ultimately up to @singerdmx

As for the changes, you can leave a comment but the problem we have made too many refactorings so your package broke, we did fix most of the issues at the same time but it still doesn't follow the new flutter_quill convention, naming, and the structure of the configurations and logic

We made a lot of changes but people want to use the latest version of both and since it hasn't been published I made a quick workaround while you are not around

I clone your flutter_quill_extensions
fixing everything with the refactored code adding additional features and customizations as well as performance improvements and setting the minimum flutter version 3 to support language features like sealed class

feel free to check the repository
if you want to continue on doing changes please pull the changes from there and fix conflicts if you made any changes for example. Then make your changes and publish again

but we changed a lot of things in the folders and file names so I think it will require more time

[Jon-Salmon]

I have published flutter_quill_extensions as a pre-release package (https://pub.dev/packages/flutter_quill_extensions/versions/0.6.0-dev) and my intention is to keep the pre-release tracking master until these current changes feel suitably stable.

Also @freshtechtips the example app seems to be broken on master (at least on Windows).

[EchoEllet]

The changes we made was to different repository, can you merge them as well??

[EchoEllet]

I just tried the example and it seems to be working, the plugins might break with the Windows app binary or require additional setup

I tried the macOS one and it's also was broken so I changed things to make it work again

[Jon-Salmon]

@freshtechtips If you have changes in a different repo, please open PR to this one. I'll then rebase my branch and re-publish

[Jon-Salmon]

The example issue doesn't look like that:

══╡ EXCEPTION CAUGHT BY WIDGETS LIBRARY ╞═══════════════════════════════════════════════════════════
The following assertion was thrown building TextLine(dirty, dependencies: [_QuillPressedKeysAccess],
state: _TextLineState#9e421):
width and height must be specified
'package:flutter_quill_extensions/embeds/builders.dart':
Failed assertion: line 94 pos 11: 'width != null && height != null'

The relevant error-causing widget was:
  TextLine
  TextLine:file:///C:/Users/jonat/Documents/SongbookPro/packages/flutter-quill/lib/src/widgets/raw_editor/raw_editor.dart:984:22

When the exception was thrown, this was the stack:
#2      ImageEmbedBuilder.build (package:flutter_quill_extensions/embeds/builders.dart:94:11)
#3      _TextLineState._getTextSpanForWholeLine (package:flutter_quill/src/widgets/text_line.dart:201:24)
#4      _TextLineState.build (package:flutter_quill/src/widgets/text_line.dart:158:22)
#5      StatefulElement.build (package:flutter/src/widgets/framework.dart:5409:27)

[EchoEllet]

@singerdmx
Consider creating Telegram or Discord channel so we can have more real-time chatting

[singerdmx]

We have a slack channel

[EchoEllet]

Hi @Jon-Salmon

When upgrade flutter minimum version of flutter_quill_extensions

: Error: Member not found: 'PlatformViewRegistry.registerViewFactory'.
image_web.dart:30
    ui.PlatformViewRegistry.registerViewFactory(imageUrl, (viewId) {
                            ^^^^^^^^^^^^^^^^^^^

the import is correct

import '../../../logic/shims/dart_ui_fake.dart'
    if (dart.library.html) '../../../logic/shims/dart_ui_real.dart' as ui;

dart_ui_real.dart

export 'dart:ui' if (dart.library.html) 'dart:ui_web';

The function we are calling is dynamic and it doesn't exists

[EchoEllet]

The working code is

import 'dart:ui_web';

 PlatformViewRegistry().registerViewFactory(imageUrl, (viewId) {
      return html.ImageElement()
        ..src = imageUrl
        ..style.height = 'auto'
        ..style.width = 'auto';
    });

Edit:
We also need the if check for web otherwise the other platforms won't build

[Jon-Salmon]

Is this code that needs adding somewhere? If so please open a PR for it

[EchoEllet]

Is this code that needs adding somewhere? If so please open a PR for it

Hi @Jon-Salmon

I would like to chat with you on private
That is if you don't mind

[EchoEllet]

I will but we need to do more changes first

[Jon-Salmon]

Happy to chat on Slack

[EchoEllet]

@singerdmx @freshtechtips

Discussions were getting a bit segmented in pull requests so I thought it best to move some of it here.

Firstly, if we think it would be best to transfer the ownership of flutter_quill_extensions to somebody else (who has more time than me) I have no objection to this. I would only ask that changes to this repo continue to be subjected to a sufficient level of code review to avoid too many accidental breaking issues getting released as stable.

I have had a quick review of the recent changes and have no major objections, although I want to run a few tests before I publish (probably will be tomorrow or Thursday before I can do this). Although this brings me on to what should the numbering be...

Personally, I have a very strong opinion that flutter packages should be following the semantic numbering scheme, where any breaking changes get a new major version number. We don't seem to have been doing this over this last week and the end result is that people will be getting unexpected breaking changes. We have also been publishing things that are marked in the changelog as 'not release ready' which feels super wrong. pub.dev has support for pre-release releases for this very situation.

My personal opinion is that we should redact what has been released over the last week (while we are still within the 7 day window) and then re-release it as a pre-release numbered from 8.0.0-dev, but this is ultimately up to @singerdmx

Hi @Jon-Salmon, have a question

In the example

Why we are using embed builders for the web that are custom and not from the flutter_quill_extensions ??

The one in the example:

The one in flutter_quill_extensions:

This was still the case before the refactoring and the recent pull requests for flutter_quill_extensions in the last month

[EchoEllet]

Shouldn't it be the same?

[singerdmx]

We should update example to use flutter_quill_extensions

[EchoEllet]

This is why I suggest to remake it from scratch

[singerdmx]

Probably can redesign the whole example

[EchoEllet]

I have noticed that the video embed builder is not supported in the flutter_quill_extensions package while it’s in the example