Closed kaixxx closed 2 months ago
Hi, sure they both seem like great ideas. I didn't know about the fusion style, not about the save geometry function. Regards error_dlg.py I had not thought of that. It is worth testing. I am currently working towards a code organiser function that Tobi wanted, in another branch. p.s. I notice use of bare Except: In try: ... except: code Where possible it should give the specific exceptions that occur or are expected to happen.
@kaixxx I pulled your request. Geometry works OK. I cannot see any changes re fusion yet. I also pulled in my code_organiser branch. This currently has set up a graphical interface to shuffle code tree components around (similar to MAXQDA active coding as mentioned by Tobi). My next task is to implement the graphical changes made to the code tree into the database, and this will need some testing to ensure the code tree structure is not damaged.
@kaixxx I pulled your request.
You are so quick! I was still working on some minor refinements. No problem, I'll make a second PR later. (I'm not an expert in GitHub, sorry. I was thinking I could make a seperate PR for each of the 4 aspects mentioned above. But it doesn't work like that...).
I cannot see any changes re fusion yet.
I chose to apply the 'Fusion' preset only for the 'native' style in QualCoder (and only on Windows). Also, you must make sure that you have at least version 6.5 of PyQt installed. I'm using the latest version which is 6.7.1. As mentioned above, I would suggest making the 'native' style the default for new users.
a graphical interface to shuffle code tree components around (similar to MAXQDA active coding as mentioned by Tobi)
I met Tobi in Berlin last week and showed him the 'graph'-function already implemented in QualCoder (under reports). He liked it a lot. Your 'code organiser' is based on that, right? I think that could be a very nice and intuitive feature. At a later stage, we could even try to add some AI in there, e.g. by letting the AI suggest new categories.
One thing to consider: Tobi mentioned to me that im MAXQDA, no changes made in the creative coding window are written to the database until you hit 'apply' (or something like that). This seem like a good safety measure. You could play around without destroying anything and make the changes only permanent if you like the outcome.
@kaixxx Sorry about being quick. I had anxiety with several branches to combine into one, that there would be lots of file conflicts. All good so far.
One thing to consider: Tobi mentioned to me that in MAXQDA, no changes made in the creative coding window are written to the database until you hit 'apply' (or something like that). This seem like a good safety measure.
Yes, I am matching how Maxqda does this. You actually cannot apply changes gradually, until a model is created and applied, as there is a lot of work with assigning category ids, creating links to these new ids, etc, to new categories and the flow on effect from that. Yes, I am using modified graph function code for this.
Yes AI maybe a possibility here. p.s. the Librarian at the Temple universities USA is interested in the AI aspect too, I had recent email from her. Forwarded your youtube on this.
@kaixxx With the new error dialog. One thing I am thinking is that the full traceback error should go to the log file. Usually having the short immediate error is fine, but there are times when the full track is useful to see the preceding steps that initiated the error. Update:Sorry I wrote this before testing it. It works great. Thank you.
@ccbogel The full traceback should be in the error dialog (in the scrollable box ) as well as in the log file. Or have I done something wrong here? (The error in the picture is a very simple.)
OK. Yes I tested that now. It works fine, thank you for that. (I wrote too soon before). It is an ingenous solution, thanks for finding an implementing this
I removed the pre-existing error handler in code_organiser.py to default to the ErrorDlg class: Worked fine but without the copy button.
What you see there is the old error handler, not the new dialog.
The new error handler is loaded once on program startup. If any other module with an assignment to sys.excepthook
is initiated after that, the new error handler will be overwritten and replaced by the old one.
I will go through all the modules and delete the old error handlers. They worked absolutly fine for such short tracebacks. But I had a lot of trouble with the complex, AI-related libraries and very long tracebacks.
I've now went through all the files and deleted the old exception_handlers: https://github.com/ccbogel/QualCoder/pull/932
You can easily test this with the same method described above, but now in any dialog:
(I know this seems quite an extensive code change to solve a minor problem. But I don't see any other solution and, as a bonus, the resulting code will be cleaner since all uncaught exceptions are now handled in one place.)
This was the last point on my list of "Ideas for Improved Usability". So if you consider this beeing finished, we can close it.
thank you for putting so much work into this
While working on my AI-enhanced version of QualCoder (which is close to completion) I discovered some potential enhancements for the usability of QualCoder that I would like to discuss. I can make pull requests if you like my suggestions.
1) Main Window Geometry Save & Restore: Currently, only the width and height of the main window are saved in config.ini, omitting the position and the crucial maximized/full-screen state. I recommend storing and restoring the entire geometry of the app. The typical method in PyQt involves using the
saveGeometry()
function of the main window. This would replacemainwindow_w
andmainwindow_h
in config.ini.2) Native Light/Dark Mode: Since version 3.5, PyQt6 automatically switches between light and dark mode based on the system's settings (only affects the 'native' style in QualCoder). This feature works on Windows, macOS, and the Gnome desktop. For more information, visit: https://www.qt.io/blog/dark-mode-on-windows-11-with-qt-6.5. The result looks quite nice, imho (see below). I would suggest making the 'native' style the default for new users of QualCoder. This way, people will feel more at home when they first start the app, as the styling seamlessly integrates with their system settings. If they want to try out some of the fancier styles, they can still do so by switching in the settings.
Light mode (needs a little refinement at the toolbar):
3) Fusion Style on Windows: Qt recommends using the built-in "Fusion" style as a base for any further styling on Windows, since it has the best support for native dark mode (see the link above). I have found this to be true as well and would suggest making "Fusion" the default on Windows. (The screenshots above are already using the Fusion style.)
4) More Structured Error Message Dialog: I've found it extremely helpful to include trace logs in the error messages in QualCoder. (I’m probably going to steal this idea for my other app...) However, in the case of the libraries I use for AI integration, these trace logs can become quite lengthy due to the many layers of abstraction. This results in the error message dialog expanding so much that it exceeds the screen size, making the confirmation button unreachable. I would suggest creating a new error message dialog with the actual message at the top and the trace log below in a scrollable textbox of a fixed size. Instead of implementing this dialog in the header of every single module like the current
exception_handler
, I am considering defining this dialog in a new module callederror_dlg.py
and importing it in every other module. Is there any reason why this should not work?What do you think about these ideas? Again, I can do the implementation if you find the suggestions reasonable. Best Kai