Open tomek-szczesny opened 4 months ago
@tomek-szczesny that would be great! At the moment, I think we should focus more on the component's hierarchy, i.e. which widget is grouped with which other widgets, and less on the styling details such as move something few pixel to any direction. Today we work hard on supporting multiple devices, etc. In the future, we might shift towards label design. Maybe you can get some inspiration here: https://youtube.com/watch?v=gaUUnGjAhvQ
Note that there could be two different approaches to design a label:
Currently we support the 2nd method. We might support the other in the future. You should take this into account when designing the label editing UI.
Agreed that we're not quite ready for UI, but with that understood, some sketches may still be interesting.
I propose that we explicitly avoid taking any inspiration from that source with Labelle. I think we can do way better, and I really want to prevent any suggestions of impropriety.
Also, I'm not so convinced that we should put much more effort towards a native UI. I think a web UI would be way cooler. Like in an office setting, you could have a shared printer, and then anyone could open the web UI from any device or phone and print something out.
Thanks for your inputs.
I think that a well-thought GUI is very important, as the vast majority of Labelle users will prefer it over a command line. I agree that copying any portion of Dymo software is a no-no and I believe we can do better than that. However the comments section contains some information on what to avoid in a good GUI.
My first job was designing test procedures in a factory, and GUI was a big part of it. I spent countless hours chatting with workers and listening to their comments. I like to bring up one example: Enlarging fonts in pop-up windows reduced average test duration by a few percent. Every detail matters, and every piece of feedback is important. I made these GUIs in LabVIEW, a skill that is irrelevant to Labelle.
I'm not fond of web UIs but I accept the reasoning in favor. Ideally I'd keep both Python and Web GUIs, but that would probably mean twice as much work?
@tomek-szczesny, since we are using QT, you better try to play with QT Creator - https://www.qt.io/download. I am not familiar with that app, but you should be able to create some layout files which we can then mimic in our code. Loading this files dynamically is also supported BTW, but I guess we should not do it for now. This app should not require programming knowledge.
Regarding web UI, once we stabilize our code base, and we're far from that TMHO, then we can try to create an API. Once we have good API, we can create a basic web UI to use it, and create dockers for the backend and frontend (even a single docker for both will do).
I read somewhere in PR discussions that perhaps one day we'd like to overhaul the GUI portion of Labelle. I'm not too handy with programming but designing intuitive interfaces is something I learned quite well in the past.
If nobody opposes this idea then I could sketch a design with comments and remarks how things should look and work. I cannot promise any code though, I've never written a GUI in Python.
This is also a good place to write down any additional features that aren't present in Labelle GUI at the moment.