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

Project status #135

Open
FriedrichFroebel opened this issue Aug 26, 2022 · 18 comments
Open

Project status #135

FriedrichFroebel opened this issue Aug 26, 2022 · 18 comments

Comments

@FriedrichFroebel
Copy link

It seems like the project does not involve any current activity. The last commit is from nearly 2.5 years ago, while there are quite some PRs and some folks already started forking the project to continue development.

There have been some commits to the master branch as well, where no corresponding release is available: v0.9.4...master. This includes disabling the warning about the devicedependent module being deprecated, although users of plain brother_ql cannot do much about it.

What is the current status of the project? Can we expect further development here?

@matmair
Copy link

matmair commented Dec 31, 2022

@FriedrichFroebel I have a fork with some of the PRs from here merged in. I need brother_ql as a dependency https://github.com/matmair/brother_ql-inventree

@FriedrichFroebel
Copy link
Author

@matmair I have already been aware of this fork due to one of your (misplaced) PRs against this upstream repository (which led to the creation of this issue to be honest). In the best case, I would like to see this upstream project to become active again, but given the current situation, this does not appear to be really likely. I personally considered working on a fork as well, but did not yet start with it - the first step would probably be to tackle #134 to ensure not to break anything first.

@matmair
Copy link

matmair commented Dec 31, 2022

@FriedrichFroebel there needs to be a lot of mocking done for #134 - if you want to make a PR to this repo I will gladly merge that into my fork too :-) .
I test the changes in my fork against the 3 printers I have before release, I do not think more can be done.

My hope that this project returns are small. I understand, life sometimes takes you into other ventures and nobody is owed anything here.

@FriedrichFroebel
Copy link
Author

Yes, I am aware that sufficient automated tests mean lots of work, but at least for me increases the trust for the actual code and when doing any changes/refactoring. For now, I do not have any direct plans for working on this due to other general workload. I might reconsider this later on, but as the code basically works for me at the moment, this does not have a high priority on my own to-do list.

@FriedrichFroebel
Copy link
Author

With the latest activity in https://github.com/matmair/brother_ql-inventree being in January, it does not seem like the fork is under active maintenance either (for example considering the Pillow filter changes which require modifications).

@matmair
Copy link

matmair commented Nov 5, 2023

@FriedrichFroebel we are actively using the project in hundreds of deployments now so I’m only changing things that need to change and only after careful testing.

@LunarEclipse363
Copy link

Hi, I have started a fork that has a bunch of improvements here https://github.com/LunarEclipse363/brother_ql/

It has 2 new tagged releases currently, bringing in stuff from matmair/brother_ql-inventree and a lot of my own work.

It currently brings many user-facing improvements such as:

  • a changelog
  • support for new printers from the inventree fork (QL-600, QL-1100, QL-1100NWB and QL-1115NWB)
  • support for new labels from the inventree fork (103mm - DK-11247, DK22246; 54x29mm - DK-3235; 60x87mm - DK-1234;
  • an entirely new status subcommand that shows information such as what labels are installed, fetched directly from the printer
  • the program now prevents you from printing a label shorter than the minimal length allowed by the printer documentation (preventing labels from getting stuck inside the printer)

As for developer-facing improvements:

  • machine-readable output for some subcommands, for easier integration with other tools
  • a big refactor to move all code to the new internal API and remove the devicedependent module you would currently always get deprecation warnings about
  • the minimum supported python version has been bumped to 3.10 to take advantage of new features

There currently is no PyPi package but you can still install a tagged version with pip with a single command:

pip install --upgrade https://github.com/LunarEclipse363/brother_ql/archive/refs/tags/v0.11.0.zip

I also used it to create a program that emulates a networked printer and allows you to use a non-networked printer (like a QL-570) as if it was a network-enabled printer (like a QL-580N) which will work with both brother_ql and Brother's "iPrint&Label" Android app https://gitlab.com/LunarEclipse363/brother-ql-net-emulator/

@matmair
Copy link

matmair commented Jun 26, 2024

Looks intresting.

  1. How married are you to 3.10? I have a lot of users on 3.9 for the foreseeable future
  2. Do you plan to release to pypi?
    Me submitting patches probably does not make sense seeing the extensiveness of code structure changes. Also are you aware of the changes in Support for PT-E550W and corresponding label fixes. matmair/brother_ql-inventree#44?

@LunarEclipse363
Copy link

LunarEclipse363 commented Jun 26, 2024

  1. I think it's mostly match statements, don't remember anything else specific to it, would have to test, but if it's that much it should be relatively easy to support 3.9

  2. Yes when I figure out how it works

  3. I dropped PT series support for now because after reading a few raster documentations I realized it requires per-printer label offsets (the printers have varying resolutions) which doesn't fit neatly into the current data model of the program (for the QL series the offsets are always the same for a label regardless of the specific printer) and properly supporting multiple PT printers would require adding a module for printer-specific labels.
    Interpreting status responses would also get more complicated because the PT series has more values and IIRC some are printer specific.
    I don't think implementing this would be too difficult but it would probably take a full day of work for a basic printing-only support for one PT series printer and the groundwork for adding more of them much faster later on.

@LunarEclipse363
Copy link

I spent the past hour figuring out how PyPi works, and here's the result: https://pypi.org/project/brother-ql-next/

I also changed the match statements to some ugly if/else chains and reduced the minimal required Python version to 3.9, I couldn't find any other 3.10 specific features used in the project but it should be good, let me know if there are any issues.

@LunarEclipse363
Copy link

Small update: I learned that a nearby hackerspace recently got one of the PT series printers, so I will probably work on adding support for those properly eventually, no ETA for now though.

@mkildemaa
Copy link

Small update: I learned that a nearby hackerspace recently got one of the PT series printers, so I will probably work on adding support for those properly eventually, no ETA for now though.

Hey. I am currently scouting the whole internet to find anything that can work with PT series printers (I need to use cassette tapes for my project). Do you have any news of your support to PT series printers or at least some leads to somewhere where I can research on how to print on PT printers programmatically?

@LunarEclipse363
Copy link

LunarEclipse363 commented Aug 1, 2024

I didn't have time to work on that yet, but I've seen a fork that has some initial support for some PT printers, you might have some luck with that. Though you might have to edit it to adjust the label offsets for your printer model (the author said they were picked by trial-and-error) https://github.com/hbrylkowski/brother_ql

@mkildemaa
Copy link

I didn't have time to work on that yet, but I've seen a fork that has some initial support for some PT printers, you might have some luck with that. Though you might have to edit it to adjust the label offsets for your printer model (the author said they were picked by trial-and-error) https://github.com/hbrylkowski/brother_ql

Thanks for the reference! I also tried brother_ql-inventree which does print successfully but doesn't auto-cut the label when the model is set as any PT. It only successfully cuts the labels when the model is set as QL but then it prints blank labels.

I will check out your provided fork.

@vulpes2
Copy link

vulpes2 commented Aug 5, 2024

The offsets for the PT series printers are indeed very annoying. I've fixed the cutter in brother_ql-inventree but there isn't much I can do about the offsets without access to a lot of different printers.

@vulpes2
Copy link

vulpes2 commented Aug 6, 2024

brother_ql-inventree now supports basic printer model detection, media size reporting, and retrieving/changing printer power settings for most PT and QL series printers.

@mfreeborn
Copy link

Can I clarify the difference/reason behind having 2 seemingly active forks: brother_ql_next and brother_ql-inventree?

@LunarEclipse363
Copy link

LunarEclipse363 commented Aug 13, 2024

Slightly different goals, inventree needs a rock stable version for their main software deployments while I have done a bunch of major work on the internals and added a bunch of features that aren't as well tested yet.

Also my version doesn't support PT series printers yet because that will require a bunch of extra work to add in a clean way.

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

No branches or pull requests

6 participants