1. The word "less" should be replaced with "fewer" in all the places where you've used it. Less is used for an indeterminate quantity (e.g. less rice, less water, less bad). Fewer is used for anything you can count (e.g. fewer columns, fewer people, fewer lines of code)

2. I'm not sure this makes sense as a user-configurable option. Why not just fix the use case outlined in the bug?

In D8385#157468, @ngraham wrote:

1. The word "less" should be replaced with "fewer" in all the places where you've used it. Less is used for an indeterminate quantity (e.g. less rice, less water, less bad). Fewer is used for anything you can count (e.g. fewer columns, fewer people, fewer lines of code)
2. I'm not sure this makes sense as a user-configurable option. Why not just fix the use case outlined in the bug?

Thanks for the tip, fixed the first.
As for the second, I'm not sure, because the user can remember all previous manipulation with program. Why to distract user with something new if he/she prefers the old way? Therefore, I've made the checkbox disabled by default. But if you think, that it should be added directly, without a user confirmation, I'll add.

Here is another idea which should accommodate the use case of the bug reporter (not sure how difficult this would be to implement, though):

In the Overview columns combobox, introduce an Auto mode, which depending on zoom level and window size dynamically adapts the number of columns from 1 to m, where 1 should still allow zooming in further and m is the maximum number of columns needed to fully show the complete set of pages. The upper limit for m would be the total number of pages in non-continuous mode, e.g. 1 for a single page document. This mode would basically correspond to the behaviour you get when zooming the thumbnails in "Adobe Reader" or "Foxit Reader".

This way, we would not change the behaviour of the static overview column modes. In contrast to the bug reporter, users might have use cases for not changing the column number automatically, i.e. keeping the page zoom constant.

Apart from that idea, I'd probably prefer the automatic reduction in columns over yet another config option.

In D8385#157503, @rkflx wrote:

Here is another idea which should accommodate the use case of the bug reporter (not sure how difficult this would be to implement, though):

In the Overview columns combobox, introduce an Auto mode, which depending on zoom level and window size dynamically adapts the number of columns from 1 to m, where 1 should still allow zooming in further and m is the maximum number of columns needed to fully show the complete set of pages. The upper limit for m would be the total number of pages in non-continuous mode, e.g. 1 for a single page document. This mode would basically correspond to the behaviour you get when zooming the thumbnails in "Adobe Reader" or "Foxit Reader".

This way, we would not change the behaviour of the static overview column modes. In contrast to the bug reporter, users might have use cases for not changing the column number automatically, i.e. keeping the page zoom constant.

---

Apart from that idea, I'd probably prefer the automatic reduction in columns over yet another config option.

Ok. Yet, I'm still new to QT, but I'll try to implement that. If I correctly understand you, you want the whole pages to be as small as possible, when you scale down the document and all of them could be visible in the viewport.

Do all agree to remove the "checkbox" for the automatic reduction of columns? Or it should be user-configurable? Or I just should enable it by default (okular.kcfg:138)

If I correctly understand you, you want the whole pages to be as small as possible, when you scale down the document and all of them could be visible in the viewport.

That's right, e.g. in Continuous mode and fully zoomed out, you would see all pages of the document in a grid. Then you'd start to zoom in, and Okular would show one column less (but now with a lot of empty space between the thumbnails). Zooming in further, the thumbnail size increases until all empty space is filled up, when another column is removed and the thumbnail size increases even more. Eventually, only one page is shown, covering the whole viewport. However, there is still an aspect to think about some more: What column number to pick when viewing a document for the first time? I'd probably like to always start with only seeing a single column, and then Okular should remember how far I zoomed out afterwards (globally or per document, though?). Or should this be configurable?

That said, if this is too complicated to implement for now, I would be fine with your original approach (just without the checkbox) as long as @aacid does not put in his veto. As far as I could see, while with Fit Width the zoom would be different you could still zoom out and only instead of placing the thumbnails to the right they would now be centered.

I'm fine with the new auto-reduction in columns feature going in and not being user-configurable.

Perhaps this should be split into two patches: we can use this one for the above feature (minus to UI to turn it on and off), and a new one for a new "Auto" mode, which is really something different entirely.

In D8385#157981, @lexdem wrote:

P.P.S Could anyone link me to documentation of whole phabricator-distro process? I mean, which stages should pass the patch to be included in next update of Arch\Ubuntu?

I'm not aware of any documentation for this process specifically from KDE, but in general distros pick up new code once in a while from the releases we do:

• As Arch is a rolling release distro, they pick up new releases pretty fast after our release date and almost never skip releases.
• On non-rolling distros like Ubuntu, there is a feature freeze some time before their release date, which will determine the version of our code they ship for the entire lifetime of their distro release (except for occasional cherry-picked fixes). For example, if your patch makes it into KDE Applications 17.12, it will probably be available in (K)Ubuntu's 18.04 LTS release (but don't quote me on that).

From the Phabricator side of of things, it goes like this:

• submit diff for review
• work with your reviewers until it is accepted
• commit it to the git repo (we can help with that if you don't have commit access)
  • to the stable branch if it is a bug fix (next release: 17.08.3)
  • to the master branch if it is a new feature (next release: 17.12)
• make sure it does not break on the CI

After this, it gets some testing and is eventually released by the release team in the form of tarballs and git tags to be picked up from distros.

Any more questions?

@ngraham #onboarding #pre-developer-access-FAQ :-)

The distro process is specific to each distribution, so out of scope here.

Hera are the release schedules for some of the software developed by KDE, but not all of them (you won't find here Krita, Partitionmanager, etc):

https://community.kde.org/Schedules

rkfix explained the meaning of the schedule for the bundle known as "KDE Applications", which also contains dolphin.

@lexdem Please change your summary from

This is a patch for the following request: 355283

to

FEATURE: 355283

so the bugzilla entry will automatically get closed on commit. Also, please update the summary text to reflect the removal of the GUI options (summary and testplan will become the commit message).

@aacid LGTM me now, if we don't hear from you until October 28th, I'd suggest landing this.

@rkflx, what's the difference between FEATURE: and BUG:?

@lexdem, once you've made the above changes to the Summary, I will be happy to formally approve this.

In D8385#158005, @ngraham wrote:

@rkflx, what's the difference between FEATURE: and BUG:?

In practise, probably none? Maybe it was used (perhaps in https://commit-digest.org?) or could be used again in the future to differentiate between bugs and features. @ltoscano probably knows more…

Oh I see, https://community.kde.org/Policies/Commit_Policy#Special_keywords_in_GIT_and_SVN_log_messages says that it's used to aid whoever compiles the release notes, and should be used for actual new features. Anyone know if this is still the case?

@rkflx , Thanks, that was exactly what I wanted to know about the processes in landing of patches here, in Phabricator :)

@ngraham , changed to the "FEATURE"

@ltoscano , Thanks, got it. So, if there are a lot of products with new features, they're bundled to some new version? Like from 16.12 to 17.04 . Is this also controlled by any kind of CI, to bundle them? Sorry, if I ask too much, I'm just curious about the whole process :)

In D8385#158066, @lexdem wrote:

@ngraham , changed to the "FEATURE"

You changed it to **FEATURE**, but the tooling handling this is not part of Phabricator and probably won't understand markdown. Could you change it to just FEATURE, please?

In D8385#158072, @rkflx wrote:

In D8385#158066, @lexdem wrote:

@ngraham , changed to the "FEATURE"

You changed it to **FEATURE**, but the tooling handling this is not part of Phabricator and probably won't understand markdown. Could you change it to just FEATURE, please?

Yep, thanks. Thanks for pointing to that script :)

Sorry, you missed one more thing: Your summary still says

User toggles the checkbox

which he cannot anymore…

Yep, sorry. Fixed

Thank you, I will wait for this :)

So, if there are a lot of products with new features, they're bundled to some new version? Like from 16.12 to 17.04 . Is this also controlled by any kind of CI, to bundle them? Sorry, if I ask too much, I'm just curious about the whole process :)

You can look at the Annoucements to get a sense for what products KDE ships, what software those include and which changes are made. Note that these are time-based releases according to the Schedules, while other applications e.g. in Extragear have other release cycles, sometimes even feature-based like you were describing. See also here.

As for release automation, I believe right now this is a manual process with the help of some scripts (not sure how accurate, but this, R497 and R572 may give you some idea) and depending on product is done by the release team or the individual maintainers.

That said, you can also visit KDE's IRC channels to get questions answered in a more interactive fashion.

In D8385#160109, @rkflx wrote:

So, if there are a lot of products with new features, they're bundled to some new version? Like from 16.12 to 17.04 . Is this also controlled by any kind of CI, to bundle them? Sorry, if I ask too much, I'm just curious about the whole process :)

You can look at the Annoucements to get a sense for what products KDE ships, what software those include and which changes are made. Note that these are time-based releases according to the Schedules, while other applications e.g. in Extragear have other release cycles, sometimes even feature-based like you were describing. See also here.

As for release automation, I believe right now this is a manual process with the help of some scripts (not sure how accurate, but this, R497 and R572 may give you some idea) and depending on product is done by the release team or the individual maintainers.

That said, you can also visit KDE's IRC channels to get questions answered in a more interactive fashion.

Thanks a lot for pointing me to the right direction :)

Week already passed? :) I just waiting to continue coding and still didn't ruin the workflow for this commit :)

I had this already prepared (look at the commit timestamp), and scheduled for tomorrow. But if you want it now, you get it now :)

Thanks again for the patch, looking forward to more contributions. Just ask if you need ideas or help…

In D8385#161286, @rkflx wrote:

I had this already prepared (look at the commit timestamp), and scheduled for tomorrow. But if you want it now, you get it now :)

Thanks again for the patch, looking forward to more contributions. Just ask if you need ideas or help…

Thanks a lot for the commiting :)
Sorry, didn't know, that delayed commit is possible :)
Yep, "more questions" is about to happen. The main conversation happens in #kde-devel, right? Or there is chat in Phabricator too?

In D8385#161287, @lexdem wrote:

The main conversation happens in #kde-devel, right? Or there is chat in Phabricator too?

While Phab has a chat (icon right to the bell icon next to the Phab logo), it is not used as far as I know. Just use IRC, but there are also project specific mailinglists (e.g. okular-devel for Okular).

In D8385#161288, @rkflx wrote:

In D8385#161287, @lexdem wrote:

The main conversation happens in #kde-devel, right? Or there is chat in Phabricator too?

While Phab has a chat (icon right to the bell icon next to the Phab logo), it is not used as far as I know. Just use IRC, but there are also project specific mailinglists (e.g. okular-devel for Okular).

Okay, thanks for the hint :)