Open FriedrichFroebel opened 2 years ago
@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
@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.
@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.
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.
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).
@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.
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:
status
subcommand that shows information such as what labels are installed, fetched directly from the printerAs for developer-facing improvements:
devicedependent
module you would currently always get deprecation warnings aboutThere 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/
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 https://github.com/matmair/brother_ql-inventree/pull/44?
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
Yes when I figure out how it works
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.
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.
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.
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?
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
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.
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.
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.
Can I clarify the difference/reason behind having 2 seemingly active forks: brother_ql_next
and brother_ql-inventree
?
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.
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: https://github.com/pklaus/brother_ql/compare/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?