T10812: KDE Applications

2019-04-20 Thread Albert Astals Cid
aacid added a comment.


  In T10812#182242 , @cfeck wrote:
  
  > I agree with Albert.
  >
  > The actual problem is that users still think that there is one "KDE 
version". They are looking at the "About KDE..." menu to find the version of 
the KDE (applications).
  >
  > If you are asking for my personal opinion, I propose to split current KDE 
Applications into parts:
  >
  > - Base/essential applications (Dolphin, Ark, KCharSelect, KCalc, 
Kate/KWrite, Konsole, Spectacle, Gwenview, Okular, thumbnailers, more?). Ship 
them together with Plasma[1]. I really love the Fibonacci release cycles of 
Plasma for bug fixes. Also, Plasma developers sometimes decide to do an LTS 
release, and the base applications would also benefit from LTS support. All of 
them should use the same 5.x (later 6.x) version number.
  > - KDEPIM (Kontact, Akonadi, etc.). It's a separate big project that could 
benefit from either faster (for bug fixes) or smaller release cycles (for 
feature releases). With the huge amount of work that Laurent is doing, I 
sometimes feel he could better decide when he thinks a partical snapshot is 
ready for release. Rushed commits for Akonadi also sometimes make KDEPIM 
unstable. Reports on IRC that KDEPIM broke from one version to another 
accumulate. More time for stabilization would really help. Regarding version 
numbers, KDEPIM long used the 5.x versions. "Marketing" name could be "KDE 
PIM", "KDE Kontact", or whatever.
  > - Maintained applications (such as Lokalize, Cantor, Kdenlive) get their 
own releases, decided by the maintainers[2]. If maintainers failed to do a new 
release within, say, 8 or 12 months, the project would move to "KDE Extras" 
(see below) and last known working branch would in turn get scheduled (bundled) 
maintainance updates. If someone steps up again to do separate releases, they 
remove it again from "KDE Extras" to avoid scheduled releases.
  > - KDE Edutainment, all games and educational apps, which are all 
practically unmaintained, and could need a slower release cycle, maybe back to 
two or even one per year. Version numbers would be individual, but the bundle 
would be called "KDE Edutainment YY.MM".
  > - KDE Extras (not to be confused with Extragear): Basically all the rest 
from KDE Applications, minus the already listed packages. These would include 
rarer stuff such as K3b, KWave, etc. In other words, everything else, which has 
no one to do releases. Again, they would be released twice or once per year, 
each one with their own version number, but the bundle called "KDE Extras 
YY.MM".
  >
  >   The proposed juggle between maintained applications and unmaintained (but 
still useful and working) applications would also solve the "Extragear 
problem". Either an application has a maintainer doing separate releases (e.g. 
KMyMoney, LabPlot, Tellico), or they don't, and the project would automatically 
join "KDE Extras" (e.g. KTorrent or Choqok; they have no maintainer, but fixes 
are piling up).
  >
  >   Footnotes:
  >
  >   [1] I would even go as far and to also merge KF5 Frameworks - after all 
these years we have to admit that the "Frameworks idea" (people using them 
outside of KDE) has never materialized. All people currently doing Plasma, 
Apps, and KF5 releases could turn around to do the new "Plasma" releases. Give 
users the "old KDE" back, but only with selected base applications.
  >
  >   [2] When I was proposing to split KStars from the bundle, I really feared 
that the project would starve. What happened is the reverse: I see more 
phabricator requests for KStars than ever before. Cantor might also benefit 
from a separate release cycle. I believe the KDE Applications release cycle 
hindered Kdenlive development ("should we merge now or wait another four 
months?")
  
  
  This is a very radical proposal :)
  
  Problems i see :
  
  - moving back applications to desktop release is not a good idea
  - Having "less maintained" applications released less often is not a good 
idea, the fact that no bugfixes have been made in po2xml in years doesn't mean 
i want to wait for a whole year for the bugfix we just made there gets released.
  - This adds 3 more "release groups". Our release calendar is already ultra 
crowded and our release team small enough, so i'm not sure that'd really work 
out

TASK DETAIL
  https://phabricator.kde.org/T10812

To: ngraham, aacid
Cc: xyquadrat, jtamate, vkrause, lbeltrame, ltoscano, cfeck, aacid, #yakuake, 
#okular, #dolphin, #kate, #spectacle, #konsole, #gwenview, #kde_pim, 
#kde_games, #kde_applications, ngraham


T10812: KDE Applications

2019-04-20 Thread Albert Astals Cid
aacid added a comment.


  In T10812#182215 , @ngraham wrote:
  
  > In T10812#182213 , @aacid wrote:
  >
  > > No, we just need to get users away from bad distros.
  >
  >
  > I find this really insulting. :/
  
  
  That is your personal problem, i didn't insult you at all.
  
  > I think discrete release distros can be great.
  
  That's fine, i don't totally agree, but i don't feel insulted by our 
disagreement.
  
  > It's also unrealistic. The "bad distros" are the ones actually used by huge 
numbers of people. In my last job, almost all the engineers used Linux on their 
desktop. Did they use Arch? No. OpenSUSE Tumbleweed? No. They all used CentOS 
or Ubuntu LTS versions, because those are the distros that their enterprise 
customers are using. We can't increase our market penetration by ignoring these 
distros.
  
  Those distros are 450 years old, having an LTS version of KDE Applications is 
not going to help either. you'd need *a lot* of LTS versions, Ubuntu 16.04 
still supported until next year has KDE Applications 15.12.
  
  RHEL 7 (that i guess that will be supported for a while still) has 4.10.5
  
  So i don't see how we can catter to those distributions with *one* LTS 
version, flatpak is the right answer for them in my opinion.
  
  > Please correct me if I'm wrong, but one of the major reasons why we do 
releases in the first place is for the benefit of distros. If they wanted to, 
they could just package snapshots of our sources, right? We're already 
providing a nice-to-have service by even doing releases.
  
  I am not old enough to answer why we started doing releases, but if you ask 
my opinion, no we don't do releases for distros, we do releases for us, having 
a "this is x.y.z" point makes it easier when talk to users when they report 
bugs, etc.

TASK DETAIL
  https://phabricator.kde.org/T10812

To: ngraham, aacid
Cc: xyquadrat, jtamate, vkrause, lbeltrame, ltoscano, cfeck, aacid, #yakuake, 
#okular, #dolphin, #kate, #spectacle, #konsole, #gwenview, #kde_pim, 
#kde_games, #kde_applications, ngraham


[okular] [Bug 406713] Wrong PDF rendering

2019-04-20 Thread Albert Astals Cid
https://bugs.kde.org/show_bug.cgi?id=406713

Albert Astals Cid  changed:

   What|Removed |Added

 CC||aa...@kde.org

--- Comment #2 from Albert Astals Cid  ---
nye, rendering is not really broken, well yes but not really.

It just there's a stamp and since we suck at rendering stamps it looks bad, if
you go to reviews and delete all the stamps (or right click while on F1 mode
and delete the stamp) it'll look fine.

At some point we should fix stamp rendering.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[okular] [Bug 406575] Stopping an Activity should not attempt to close Okular, even with tabs opened

2019-04-20 Thread Albert Astals Cid
https://bugs.kde.org/show_bug.cgi?id=406575

Albert Astals Cid  changed:

   What|Removed |Added

 Resolution|NOT A BUG   |---
 Status|RESOLVED|REPORTED

--- Comment #6 from Albert Astals Cid  ---
> Should I report this as a separate bug?

Yes

-- 
You are receiving this mail because:
You are the assignee for the bug.

[okular] [Bug 406713] Wrong PDF rendering

2019-04-20 Thread Elvis Angelaccio
https://bugs.kde.org/show_bug.cgi?id=406713

--- Comment #1 from Elvis Angelaccio  ---
Created attachment 119533
  --> https://bugs.kde.org/attachment.cgi?id=119533=edit
Okular VS Firefox

Comparison between Okular and Firefox opening the attached PDF file.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[okular] [Bug 406713] New: Wrong PDF rendering

2019-04-20 Thread Elvis Angelaccio
https://bugs.kde.org/show_bug.cgi?id=406713

Bug ID: 406713
   Summary: Wrong PDF rendering
   Product: okular
   Version: 1.7.0
  Platform: Archlinux Packages
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: PDF backend
  Assignee: okular-devel@kde.org
  Reporter: elvis.angelac...@kde.org
  Target Milestone: ---

Created attachment 119532
  --> https://bugs.kde.org/attachment.cgi?id=119532=edit
PDF file not rendered correctly by okular

The attached PDF file is not rendered correctly in okular, while it works fine
in firefox.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[okular] [Bug 406575] Stopping an Activity should not attempt to close Okular, even with tabs opened

2019-04-20 Thread Øystein Steffensen-Alværvik
https://bugs.kde.org/show_bug.cgi?id=406575

--- Comment #5 from Øystein Steffensen-Alværvik  ---
(In reply to Albert Astals Cid from comment #4)
> I have never used activities myself so when you said  "Scratch the shutdown
> bug, it seems to be unrelated." i thought you meant this wasn't an actual
> bug and you got confused with something else.
> 
> Did I misunderstand what you mean? Should I reopen the bug?

I can still confirm the bug. The 'shutdown bug' I meant as a side-effect of
this bug, so it's related but I didn't mean that the bug I reported was fixed.

You know how, when you try to shutdown Okular with multiple tabs open, a dialog
is shown to confirm that you really want to close the tabs? Well, as long as
that dialog is displayed, I cannot shutdown the system. I have to choose either
'Yes' or 'No' in the dialog, and then I can shutdown. That's what I meant by
'shutdown bug'. Should I report this as a separate bug?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[okular] [Bug 406646] Page background color changing feature should affect large solid-fill objects with the background's color as well, not just the background itself

2019-04-20 Thread Nate Graham
https://bugs.kde.org/show_bug.cgi?id=406646

Nate Graham  changed:

   What|Removed |Added

 Status|REOPENED|CONFIRMED
Summary|Okular Can not really   |Page background color
   |change page color   |changing feature should
   ||affect large solid-fill
   ||objects with the
   ||background's color as well,
   ||not just the background
   ||itself

--- Comment #12 from Nate Graham  ---
Albert, I think I understand that it's the PDF file authior's fault for adding
an opaque white square on top of the background, but it would be nice of Okular
could detect this type of thing and handle is so that the background changing
effect works more reliably.

To the user, the background is the background. Whether there's an unnecessary
white square on top of it is irrelevant; from the user's perspective, the color
changing feature does not work with this PDF.

I think it's a fairly reasonable request since the user shouldn't have to
understand the structure of the PDF file itself, nor should the feature only
work with perfectly-structured PDFs.

Changing the title to reflect the technical change needed to implement this
feature request.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[okular] [Bug 406646] Okular Can not really change page color

2019-04-20 Thread widon1104
https://bugs.kde.org/show_bug.cgi?id=406646

--- Comment #11 from widon1104  ---
Try to learn from non Free software will make free software better.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[okular] [Bug 406646] Okular Can not really change page color

2019-04-20 Thread Albert Astals Cid
https://bugs.kde.org/show_bug.cgi?id=406646

--- Comment #10 from Albert Astals Cid  ---
(In reply to widon1104 from comment #9)
> Do you try foxit reader ? This software change backgroud color perfectly
> without a lot of restriction.

No, i try not to use non Free software if i don't have to. This is one of the
cases when i don't have to.

> Okular change background color function with a lot of restriction makes this
> feature almost useless.
> 
> This bug already exist for many years.

It's not a bug.

> I will not happy If this bug do not fix.

I am not responsible for your happiness. Only you are.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[okular] [Bug 406646] Okular Can not really change page color

2019-04-20 Thread widon1104
https://bugs.kde.org/show_bug.cgi?id=406646

--- Comment #9 from widon1104  ---
Do you try foxit reader ? This software change backgroud color perfectly
without a lot of restriction.

Okular change background color function with a lot of restriction makes this
feature almost useless.

This bug already exist for many years.

I will not happy If this bug do not fix.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[okular] [Bug 406575] Stopping an Activity should not attempt to close Okular, even with tabs opened

2019-04-20 Thread Albert Astals Cid
https://bugs.kde.org/show_bug.cgi?id=406575

--- Comment #4 from Albert Astals Cid  ---
(In reply to Øystein Steffensen-Alværvik from comment #2)
> Why was this marked not a bug? It prevents stopping an Activity when using
> Okular with tabs, so the user can't resume the Activity with the documents
> (which is possible when using Okular *without*

I have never used activities myself so when you said  "Scratch the shutdown
bug, it seems to be unrelated." i thought you meant this wasn't an actual bug
and you got confused with something else.

Did I misunderstand what you mean? Should I reopen the bug?

-- 
You are receiving this mail because:
You are the assignee for the bug.

[okular] [Bug 406646] Okular Can not really change page color

2019-04-20 Thread Albert Astals Cid
https://bugs.kde.org/show_bug.cgi?id=406646

Albert Astals Cid  changed:

   What|Removed |Added

   Severity|normal  |wishlist

--- Comment #8 from Albert Astals Cid  ---
It's not a bug, if it makes you happy this is open, let's just leave it open

-- 
You are receiving this mail because:
You are the assignee for the bug.

D20678: Ensure compatibility with Qt <5.10

2019-04-20 Thread Albert Astals Cid
aacid added a comment.


  Thanks :)

REPOSITORY
  R223 Okular

REVISION DETAIL
  https://phabricator.kde.org/D20678

To: awilcox, aacid
Cc: okular-devel, joaonetto, tfella, ngraham, darcyshen, aacid


D20678: Ensure compatibility with Qt <5.10

2019-04-20 Thread Albert Astals Cid
This revision was automatically updated to reflect the committed changes.
Closed by commit R223:29ac9b2302d4: Fix build with Qt 5.10 (authored by 
awilcox, committed by aacid).

CHANGED PRIOR TO COMMIT
  https://phabricator.kde.org/D20678?vs=56573=56615#toc

REPOSITORY
  R223 Okular

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D20678?vs=56573=56615

REVISION DETAIL
  https://phabricator.kde.org/D20678

AFFECTED FILES
  shell/main.cpp

To: awilcox, aacid
Cc: okular-devel, joaonetto, tfella, ngraham, darcyshen, aacid


D20678: Ensure compatibility with Qt <5.10

2019-04-20 Thread Albert Astals Cid
aacid accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R223 Okular

REVISION DETAIL
  https://phabricator.kde.org/D20678

To: awilcox, aacid
Cc: okular-devel, joaonetto, tfella, ngraham, darcyshen, aacid