-
Notifications
You must be signed in to change notification settings - Fork 92
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
Is glabels unmaintained? #182
Comments
That would be unfortunate if the program would not be continued, it has been used by me for a long time. And I appreciate it very much. |
Le jeu. 3 nov. 2022 à 15:23, ZeroDot1 ***@***.***> a écrit :
That would be unfortunate if the program would not be continued, it has
been used by me for a long time. And I appreciate it very much.
I second that 🙏
|
Same for me. |
I am currently on hiatus from working on gLabels. A lot going on in my life at the moment. I do not know when I will be able to pick it up again. |
jimevins, totally comprehensible. I hope you or someone in the community will bring on the project, since glabels can be put with ease inside a must-have swiss-knife free software selection. Top notch! |
gLabels is, AFAIK the only feasable OSS label software? Or does anyone know of an alternative? The 3.99 Windows build seems to work okay-ish, but seems to be missing a LOT of barcode symbologies. Is there a way to add e.g. 2of5? Also: does anyone have expierence building the 4.00 version for windows? Is it better than the 3.99 one? |
I've been looking at it and contacted Jim a while back via private email on the subject. I have no intention to usurp Jim's work. I'm retired (sorta) so I don't need the work but can help when needed. My motivation is to get my Dymo labelwriters to work... I've scanned through the forks of this repo and have gotten remotes to the relevant new work and have considered merging some of the latest into my "next" branch. Note that I've only considered forks that are/were based on Jim's 'master' and have new work on top of it. I've already pushed a 'qt5' branch which is a few behind my 'next' (pkess/MergeViewNewlineDisplay). I've looked at a number of template and docs updates that would be useful and quick to merge. As you can see, qt5 is almost a year old (built on Fedora 35, x86-64). Phrxmd, have you pushed a branch? I see your 'brother' branch. If not, push what you've packaged so I can look at it. I don't mind rolling up a bunch of this stuff and then hand it back to Jim when he's up to it. See my repo https://github.com/lieb/glabels-qt. I have enabled issues on it and should be able to take pull requests so long as they have been rebased on Jim's 'master' or my 'qt5'. If it is interesting enough for a pull request, it should at least be a current rebase. BTW, my style from my nfs-ganesha release manager days is to keep my 'next' current during the release cycle just for this purpose. Signal me as to what you'd like me to do (within reason) by opening an issue on my repo. Jim, this is your code and therefore, your call. |
I have merged various changes rebased on jimevins/Master just to get them checked. You can find them in my "next" branch. The template updates look clean although I don't have the forms and/or printer to test (I only have Dymo LW 400/450 turbos and a Brother laser printer). I did not merge the Brother TZe templates because they don't conform to the xml indenting for the rest of the template files. Re-indent to match and I'll merge. I also merged the MergeViewNewlineDisplay addition and libzint regex error patches. I've tested the newline patch and it seems ok but can't test anything mac/win10 the submitter can test them to see if they still work. I did not merge the MACOS Build instructions updates. The patches from knewg and mmitevski conflict. Again, since I have no MacOS, someone else can clean this up and re-submit. I did not merge the nix flake patches. This is new stuff that may be out of scope so it is Jim's (and others) call to include. It seems clean but, again, I can't test. I have put this notice here to let everyone know what I'm up to wrt keeping things moving and publishing the state of my changes. This is just an announcement to this issue. Please reply to me as an issue/pull request to github/lieb/glabels-qt from now on for work that I'm doing. I publish my "next" so people have something to rebase on as things march on. Do not assume it is ready for anything. The "master" branch (unchanged atm) is working code and will get a merge from "next" only after testing. If you are sending a pull request, please rebase your request to the tip of my "next". That way we can keep this repo and its issues/pull request queues clean. Thank you Jim |
May I just add here (with hopes in my mind ;-) ) that contrary to common opinion ("there are hundreds of label printer apps to chose from") there is in fact none (that I found) that do not either tie a customer to a certain brand (P-touch editor or Dymo etc) or draw them into some subscription plan, the fairness of which ranges from "it's a nuisance" to "outrageous" (or funny). One could say, well, use Inkscape or Libreoffice, but I think that a dedicated app with a clear and transparent feature set is still very useful (until noone prints labels any more, which is still some years ;-) ). Glabels fits the bill perfectly and I dearly miss it on Windows and Mac. It would be lovely if some mode (a friendly, cooperative fork) could be found to recover the work here. Atm Glabels-qt doesn't build on MacOS (I didn't try Windows, but it's likely similar), but I am happy to generate and post build errors ;-) to help if someone wants to shoulder the actual task. |
Le jeu. 5 janv. 2023 à 08:36, Rainer Schütz ***@***.***> a
écrit :
May I just add here (with hopes in my mind ;-) ) that contrary to common
opinion ("there are hundreds of label printer apps to chose from") there is
in fact none (that I found) that do not either tie a customer to a certain
brand (P-touch editor or Dymo etc) or draw them into some subscription
plan, the fairness of which ranges from "it's a nuisance" to "outrageous"
(or funny). One could say, well, use Inkscape or Libreoffice, but I think
that a dedicated app with a clear and transparent feature set is still very
useful (until noone prints labels any more, which is still some years ;-)
). Glabels fits the bill perfectly and I dearly miss it on Windows and Mac.
It would be lovely if some mode (a friendly, cooperative fork) could be
found to recover the work here. Atm Glabels-qt doesn't build on MacOS (I
didn't try Windows, but it's likely similar), but I am happy to generate
and post build errors ;-) to help if someone wants to shoulder the actual
task.
I second that on all points !
|
I also agree that GLabels is a very useful piece of software that fills a niche, on Linux it is without alternative. I think what @lieb has proposed is exactly this friendly fork, at least until the next maintainer/s of GLabels as a whole or until @jimevins can step in. Let's use it to collect issues and PRs. Thanks for offering to host this. I've moved my OpenSuSE RPMs to track the |
There are several types of label software out there for Windows that work on any printer. I've been using Wasp Label Maker for barcoded labels since easily 2004. https://www.waspbarcode.com/barcode-software/wasplabeler-2d-633808105266#fullDescription gLabels-QT is VERY close to matching functionality. Thankfully, Wine supports Wasp Label Maker 6.0 (for which I have a license for). But I would gladly pay for a license of gLabel-QT, too! |
I wonder if this project is now unmaintained?
I've just packaged this for OpenSuSE and added some of the more recent MRs als patches - especially #162. But as an unfinished development version it's always a bit unsatisfying. It would be really good to get at least a basic 4.0 release out - according to #43 it seems like not much has been missing.
The text was updated successfully, but these errors were encountered: