KFileDialog is deprecated in KF5, so it should be ported to get rid of KDELIBS4SUPPORT.
This patch is just a quick fix to discuss a way to create QFileDilaog with a custom widget. Is it possible that subclassing works better?
aacid | |
mkoller |
KDE Applications |
KFileDialog is deprecated in KF5, so it should be ported to get rid of KDELIBS4SUPPORT.
This patch is just a quick fix to discuss a way to create QFileDilaog with a custom widget. Is it possible that subclassing works better?
Press Ctrl+Shift+S.
The new dialog is not native but resembles the original one.
Lint Skipped |
Unit Tests Skipped |
mainWindow/kpMainWindow_File.cpp | ||
---|---|---|
889 | Why not use the native dialog? |
mainWindow/kpMainWindow_File.cpp | ||
---|---|---|
889 | From Qt 5.11 documentation:
|
The ported dialog looks bad, both because the layout of the new widget is not where you would want it to be and because it has much less functionality than the native dialog.
It's an interesting problem though which i don't know how to fix. Maybe it could be a post save dialog? Like "ok, since now you chose to save as jpeg i'll ask you which quality you want to use"
Which seems to be like how gimp does it. What do you think?
Implementing additional "Save Options" dialog to avoid adding custom widgets into QFileDialog.
Just to be sure if I'm moving in an acceptable direction (resizing does not work for some reason yet). Screenshot:
See above. QFileDialog does not allow adding custom widgets (like KolourPaint's saveOptionsWidget) in the native mode.
I like the separate window you've implemented, that seems like a good approach and then we can use the standard dialog.
Looks almost good, but the spacings seem a bit off, the spinbox is too close to the top and then there's too much space between spinbox and the image itself.
Spacing can be easily fixed with lay->setMargin(10);.
But somehow I have messed up when merging this good old code from the option widget and preview window. I cannot figure up quickly what is wrong and why it is impossible to resize the picture label and rewrite the existing image. Sorry.
I would be very obliged if someone can just give a little hint on what I have done wrong. Thanks in advance for your possible help.
Meanwhile, I will try to find the bug by myself (it cannot be committed now as it does not work).
Some more comments:
New version.
Fixed:
Known bugs:
What I see is that selecting "Save As..." opens without suggesting a file name and a format (empty file name, format shows "all supported files").
The original version suggested the original name and format.
Also, the combobox showing all supported formats in "Save as" does not add the file name suffix as is done in the "open" file dialog - which it seems
is the same as it was in the original version ... still inconsistent, which might be good to look into also now. The list should alway shows the filename extension.
Fix "Save as..." dialog and glitches with a selection of existing files.
The globs in save dialogs (afaik) cannot be added easily with the current scheme of the code interaction. @mkoller , as an author of askForOpenURLs rewrite, you might already know this. We may look at it, but simple solutions (MIME filter <-> File name filter) seem to be very fragile. Any suggestions?
Abandoned because in the distant future there might be better solution (or will be no KolourPaint at all).
Yuri, you really need to stop with your trolling, this is like the third time i've asked you to be polite and you keep trolling with no reason.
Also why are you abandoning this? It seemed to be in relative good shape.
I have lost the will to continue with KolourPaint. Nothing more, no trolling. It seems that we are trying to find some ideal solution and I just feel that my life is too short for this.
I have learned from the above discussion that this problem (with KFileDialog) and the other problem (with KMimeType) from 3 last unported things are closely related, maintainer knows about them and can solve them without my intrusion. For me, on the other hand, it all reminds the grook:
A bit beyond perception's reach
I sometimes believe I see
that KolourPaint is two locked boxes, each
containing the other's key.
;)
And once more, in short, I did not want to insult anyone. The problem is just too complex. I cannot solve it now in the current state. So I just do not want to waste your time anymore.
Sorry for the already wasted time, just think that I have lost more time than you if it makes it easier.
If some code from this patch can be reused somehow, anyone can commandeer this revision and finish the porting.
Useful link for the courageous:
Thanks Yuri for your work. You already did much more than what we can ask for from a translator.
When I had ported KolourPaint to KF5, I couldn't solve these issues, and left them as they are in the hope that underlying frameworks (Qt5 or KF5) re-gain the missing functionality. If the coming Qt6 port would still need stuff from KDELibs4Support, I am sure we find a way to port these to Qt6, so that we don't need to abandon it.