search

eoyilmaz / displaycal-py3

DisplayCAL Modernization Project
https://eoyilmaz.github.io/displaycal-py3/
GNU General Public License v3.0
877 stars 61 forks source link

Move the UI to ``Qt`` #7

Open eoyilmaz opened 2 years ago

eoyilmaz commented 2 years ago

This issue is probably for the very distant future.

I feel very much comfortable to work with Qt than wxPython (which I still have no idea other than just trying to fix some function calls which are apparently changed in 4.1.x series).

As far as I see, Florian did and excellent job to fix the quirks of wxPython by patching a ton of functions/methods of wxPython widgets. Thus, I believe the code will probably shorter and simpler with Qt.

kamikaze commented 2 years ago

Yep, +1 for Qt. Btw I'm not familiar with the codebase well. Is there a more or less separation between UI and actual functionality? It would be nice to have core functionality as a separate module so it would be possible to switch between UIs if needed. or to support multiple

Doomsdayrs commented 2 years ago

-1 on QT

This is a major undertaking and will break the UI language that users are already used to.

There is far to much broken already, don't need to overcomplicate the possible bugs.

Once the application has moved onto a more stable codebase with a proper architecture (such as MVVM), then it would be a good idea to start investing in creating a QT UI alongside the current GTK UI.

eoyilmaz commented 2 years ago

@Doomsdayrs don't worry, if we move to Qt at some point, the UI should be 100% matching the current version (apart the little differences in styles of widgets) and we are nowhere near to that point yet. But I think DisplayCAL would extremely benefit from such a move, there are a ton of hackery around how wxPython is used in DisplayCAL (heck, there is even a module called wxFixes which itself is around 2000 lines of code just to fix some quirks of wxPython).

Doomsdayrs commented 2 years ago

@eoyilmaz

The statement of 100% matching the current version is not true.

QT applications follow the KDE guidelines. GTK applications follow the GNOME guidelines.

Because of this, the very way you would have to design the UI to fit the themes of the platforms will be different.

In regards to hackyness,

As I am noticing in #54 , Such a decision to swap UI kit currently would be a monumental effort to undertake. It is better to slowly migrate to proper architecture first before undertaking hefty UI re-implementations.

funlw65 commented 2 years ago

@eoyilmaz

The statement of 100% matching the current version is not true.

QT applications follow the KDE guidelines. GTK applications follow the GNOME guidelines.

Because of this, the very way you would have to design the UI to fit the themes of the platforms will be different.

In regards to hackyness,

As I am noticing in #54 , Such a decision to swap UI kit currently would be a monumental effort to undertake. It is better to slowly migrate to proper architecture first before undertaking hefty UI re-implementations.

@eoyilmaz is talking about functionality, you are talking about appearance.

As an example. Lazarus IDE has the same GUI (LCL - Lazarus Component Library) which is built on top of many widget sets, as gtk2, gtk3, qt4, qt5, and a few more. Same functionality, only very subtle differences, as the linux distro is providing an uniform theme for both main widgets, gtk and qt.

I wrote apps in Pascal and C, same core code, but then different widget sets for the same GUI, mainly for portability and fun: lcl gtk, msegui, raygui (an immediate mode gui for which I slightly altered the core code, but keeping the same functionality).

The core code I can rewrite in different languages and the UI using different widget sets, as long as the functionality and the GUI remains the same - the client/user won't notice any difference. One of the applications written in Pascal (a visual tool for configuring a Nucleo board based on an STM32 microcontroller), I completely rewrote it in GDScript of GODOT game engine, the GUI becoming a little prettier but keeping the same functionality,

It is also what @eoyilmaz says because he can do the same.

eoyilmaz commented 2 years ago

@funlw65 exactly :+1:

Agilulfo commented 1 year ago

Btw I'm not familiar with the codebase well. Is there a more or less separation between UI and actual functionality? It would be nice to have core functionality as a separate module so it would be possible to switch between UIs if needed. or to support multiple

Hey I've noticed this fork of the original project. First of all thanks for trying to keep it alive :bow: . I've managed to install and get a profile for my display with some hiccups here and there.

I was considering giving back by fixing some of the issues I've encountered.
I've started looking at the codebase but I could not manage even to identify where the logic taking care of what I wanted to fix is located. (does not help the fact that I have very little experience with gui libraries/components)

My first impression is that there is not much separation between logic and UI handlers. If that's the case I feel that any effort to maintain, fix, test, extend this tool for somebody that was not the original author becomes a very difficult task.

I'm also curious to know if there is anybody with some degree of understanding of the guts of this project and that has an idea on how to proceed. Also is there anyone with enough experience to estimate if the refactoring effort is worth or if maybe a rewrite might be more convenient? :thinking:

p5k369 commented 1 year ago

Hey @Agilulfo

My first impression is that there is not much separation between logic and UI handlers. If that's the case I feel that any effort to maintain, fix, test, extend this tool for somebody that was not the original author becomes a very difficult task.

That is very true indeed on top of that it is kind of hard to read because there werent followed much style guides and also at the beginning there were no tests at all so breaking the code was quite easy (and is still).

and that has an idea on how to proceed.

I think a good starting point is to have tests for at least the major functionality of displaycal and then write new code that fulfills those tests. Last year I took a small part (the visual white point editor) of displaycal and rewrote it out of curiousity in pyqt6. There are way less hacks needed and the signal/slot mechanism is where qt really shines compared to wxpython. It's not perfect by any means but take a look at https://github.com/p5k369/VisualWhitepointEditor if you're interested.

This year I am very involved in my work and I have the feeling that this is also true for Erkan but after all everyone is invited to contribute.

Agilulfo commented 1 year ago

@p5k369 thank you very much for your insight! I'll definitely have a look with calm to your proof of concept.

For now I'm trying to get a picture of what is the actual situation and to evaluate if and how I can contribute to it.

I don't have much experience with GUI applications. I'll give a look at this to try to understand if some flavor of tests can actually help in this situation.

I'm currently wondering if for somebody like me that lack familiarity with the codebase, with GUI frameworks and in general that has a very minimal understanding of color management it would not be more effective to instead start from scratch and aim to have very minimal but working and maintainable application that simply take care of invoking Argyll for the average user that just want to get a color profile for a display.

I'm also a bit hesitant because I've also started to scratch the surface of Argyll and it also looks to be a one man project that might at some point face the same fate of DisplayCal. :disappointed: