Haven't tested the patch, but the change looks good to me.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Aug 24 2019
Aug 22 2019
P.S.: Some steps still have to be done, like the ones that Nikita commented "It will be great to have starting steps for each type of work (for example, want to do Bug Triaging - go to the specific bugzilla link showing the list of not triaged bugs and try to repro bugs one by one, and then post your comments in the bugs)" or mentioning that a linked page is in English.
I suppose that today you have received a "Invitation to participate in a survey" mail from Lydia Pintscher. It reminds of when she wrote in https://phabricator.kde.org/T9581 about Krusader on Windows and "have you thought about using this as an opportunity to recruit someone new? Maybe a blog post or mailing list post asking if there is someone with the will and knowledge to drive this forward?", which has something to do with the subject of the present code review.
In D23309#516348, @nmel wrote:@yurchor, in any case, the changes to the docs shall be made only in master, since stable is in the doc-freeze mode, correct?
In D23309#516339, @pino wrote:In D23309#516337, @yurchor wrote:The only problem with https://krusader.org/get-involved/ is that it is even more conservative than our user docs
https://cgit.kde.org/websites/krusader-org.git/
Just open a review request for that repository (or commit directly), it is not complicated...
Please always open a review! Committed and pushed changes are deployed directly to live site. People make mistakes, it's normal, and reviews reduce the likelihood of a mistake.
Thanks everyone!
It seems that we need some thoughts from developers on how to proceed.
In D23309#516337, @yurchor wrote:The only problem with https://krusader.org/get-involved/ is that it is even more conservative than our user docs
Yes, Pino is right on the general level. The only problem with https://krusader.org/get-involved/ is that it is even more conservative than our user docs (slowly updates, no translations, etc.). So I'd better leave the things as is. Just my 2 cents.
Aug 21 2019
Changes that were suggested.
In D23309#515733, @asensi wrote:Note: There are some reasons why Krusader users have documentation available in their computers, maybe Yuri Chornoivan can give more information about it.
Personally, I think that there will be no harm if we have as many ways to engage new developers as we can.
In D23309#515717, @pino wrote:TBH I'd just add the instructions to https://krusader.org/get-involved/, and not to the user documentation.
TBH I'd just add the instructions to https://krusader.org/get-involved/, and not to the user documentation.
Just like we do not add compilation/build instructions to documentations anymore, IMHO it makes sense to not add contribution instructions either: they are generally not related to "using the application", and thus the old documentation shipped with an old version would show outdated links. Some of the changes in this patch perfectly show this: imagine that users installing krusader in stable distros have outdated links to freshmeat and linux-apps in the documentation they read.
Aug 20 2019
Some spaces were added, as Yuri suggested.
Aug 19 2019
How do you think a person is going to search whether kde4 version of krusader is getting updates? Will she likely go to a search engine and type something like "krusader kde4" where the mentioned repo will be in top positions due to good naming?
For example, you can fork krusader on github or other platform [...]. What do you think about this idea, Toni?
I don't think people would find it, Nikita.
Aug 18 2019
It looks OK for me, thanks for it, Nikita!
It looks OK for me, thanks for it, Nikita!
For example, you can fork krusader on github or other platform [...]. What do you think about this idea, Toni?
Accepted for my part. Thanks.
For my part, I accept the proposal, Thanks for it, Nikita!
Well, some months have passed since Davide's commit :-( , let's see when normal Krusader users can take profit.
In D22957#513827, @nmel wrote:This is a very serious change because now #ifndef Q_OS_WIN or #else block after #ifdef Q_OS_WIN will include the code that previously was ignored. We must look at all those code paths and test features it affects. BTW, does it mean that some of those code paths do not work correctly in the current state?
When I see the usage of the method, like
const float fontWidth = (fm.QFONTMETRICS_WIDTH("WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW") - fm.QFONTMETRICS_WIDTH("W")) / 99.0;
or
headerView->resizeSection(KrViewProperties::Ext, QFontMetrics(_viewFont).QFONTMETRICS_WIDTH("tar.bz2 ")); headerView->resizeSection(KrViewProperties::KrPermissions, QFontMetrics(_viewFont).QFONTMETRICS_WIDTH("rwx ")); headerView->resizeSection(KrViewProperties::Size, QFontMetrics(_viewFont).QFONTMETRICS_WIDTH("9") * 10);
which are all dirty hacks, I doubt we need to care too much about the differences mentioned. This code needs to be refactored properly but it's not a goal of this change. QFONTMETRICS_WIDTH will actually become a good marker of the places that need review if someone will find time and courage to make it right one day...
This is a very serious change because now #ifndef Q_OS_WIN or #else block after #ifdef Q_OS_WIN will include the code that previously was ignored. We must look at all those code paths and test features it affects. BTW, does it mean that some of those code paths do not work correctly in the current state?
Good catch, Toni! No objections for the new shortcut. Please look into
- Making the commit headline shorter. Something like "Changed shortcut for the embedded terminal emulator". It's easier to read in the graph view. Please keep everything else, it's very good to have a detailed explanation in the commit message!
- Specifying CHANGED: tag, so this is not missed in the ChangeLog on the next release.
I have no problem when someone is trying to improve a dead branch. If the person finds this useful and wants to share their changes to others — he or she is welcome to do so. It's an Open Source after all. In the same time, I understand what Luigi is saying that it might send a wrong signal to users. In addition, commits we push to the official repo are reviewed and tested, and should be only pushed when approved by at least another dev and no objections from others (unfortunately, it's not enforced due to a weak infrastructure). It means someone needs to test the changes you propose in 10 code reviews. Personally, I have no interest in kde4 commits anymore and even have no environment to test it. I doubt you'll find another dev who has.
Related review: D23197 (same changelog)
Aug 17 2019
Hi Toni,
Aug 16 2019
Thanks, Nikita! Because it's very handy, and it has been already tried a lot, it looks like a good idea to add the "Shortcuts to move tab" commit to the stable branch, and add to the ChangeLog file:
FIXED: [ 328937 ] Shortcuts for move tab
Aug 12 2019
Ok. Thanks, Alex and Davide!
In D22434#508964, @asensi wrote:An article about it has been published recently:
About deprecation of QFontMetrics::width() https://kdepepo.wordpress.com/2019/08/05/about-deprecation-of-qfontmetricswidth/by @cfeck (Christoph Feck, who has commited some changes to the repository of Krusader).
Aug 10 2019
Aug 9 2019
Thanks, Nikita!
Updated AppStream files. Thanks Luigi and Toni!
- Updated AppStream files with previous and upcoming release info
Aug 8 2019
An article about it has been published recently:
About deprecation of QFontMetrics::width() https://kdepepo.wordpress.com/2019/08/05/about-deprecation-of-qfontmetricswidth/
by @cfeck (Christoph Feck, who has commited some changes to the repository of Krusader).
Please also add the versioning data to the appdata file (maybe also add the information for the previous version this time):
Aug 7 2019
Hi, Luigi! Well, I was referring to the virtual machines running prior operating systems (and physical machines, I remember that the LTS support of Ubuntu 14.04 ended at the end of April and I still saw some of those machines). Sometimes the reason is that some programs do not run in recent versions of operating systems, other causes may exist.
There's also the case of Lliurex 16, an operating system installed in thousands of computers, I had to work with it and there I could only build the "kde4" version of Krusader.
I'm not a Krusader developer, but from the global point of view, the kde4 branch is basically dead. It's not tracked for translations, it's not tracked by the sysadmin/repo-metadata repository.
Please also add the versioning data to the appdata file (maybe also add the information for the previous version this time):
https://community.kde.org/ReleasingSoftware#Versioning_in_AppStream_files
@yurchor, this was fast! Thanks!
Please review by August 10, EOD. Thanks!
Aug 5 2019
The new code works using Kubuntu 18.04 and 19.04. Krusader behaves as expected when it's asked to be closed:
- when its internal editor is not used,
- when its internal editor has a file that is not saved,
- when its internal editor has a file that is not saved and the computer is asked to reboot.
Aug 4 2019
the target audience of Krusader are more advanced users
If any developer is reading this, he'll probably know that those developments end up being a very complex subject. Thank you for all the source code, Alex!
I'm unsure about this. In contrast to Dolphin the target audience of Krusader are more advanced users. We should have more confidence in them imo. On the other hand a confirmation doesn't hurt...
Okay, I'm not against adding comments:)
Ah, FileItem::isDir() can also return true for symlinks. Thanks again for fixing the bug i introduced, Toni!
Hmm, when looking at my commit I cannot say what caused setting the "current" item before.
Anyway, thanks for fixing Toni!
Aug 2 2019
Aug 1 2019
Minor changes were performed.
I think the same, Nikita, and thanks for testing and informing!
I agree with you, Nikita. Thanks for testing and all the information!