Hey everyone. We're going to have a hard time keeping KDE a release-blocking spin if the QA team doesn't get more active help from KDE SIG folks. I know many of you are active and involved, but we're getting into a sitation where a lot of fairly bad bugs are found at the last minute because no one looked before the QA person running through the final battery of tests.
Particularly, the "everything installed by default must basically function" criteria is really hard. KDE installs a lot more than Workstation does, so a lot of testing is required. Paring down this list would obviously help, but so would simply going through everything using nightly builds once F27 branches in about a month (see the schedule here: https://fedoraproject.org/wiki/Releases/27/Schedule) and marking anything that should be a blocker as such -- and then repeating that again at Final Freeze. That way, it won't come down to discovering big problems literally on the day we want to send the release out the door -- which forces us to make hard decisions.
Thanks!
On Friday, 7 July 2017 4:25:54 AM AEST Matthew Miller wrote:
Hey everyone. We're going to have a hard time keeping KDE a release-blocking spin if the QA team doesn't get more active help from KDE SIG folks.
With the recent discussion about lack of testing etc and the state of the KDE live boot, I would like to propose a set of changes to simplify the live image as we start thinking about F27.
The idea is to strip the current bloat to give a more manageable Live Image - while keeping in mind that after you install to HDD, you can install any package you like.
Proposal #1: We currently ship 3 browsers in the Live image: * Firefox * Konqueror * Qupzilla
I propose that we strip all out except Konqueror. IMHO, Konqueror is the KDE browser - and should feature on the KDE Spin live image. It allows us to keep a simple target of *ONE* working browser that has to meet the blocker requirements.
Proposal #2: We currently ship 2 'package managers' (3 if you count PackageKit).
I propose we drop kde-discover - and keep dnfdragora (and PackageKit) in the live image.
Proposal #3: We currently ship 3 image programs in the live image. Okular & Gwenview as viewers, Kolourpaint as an editor.
I propose we drop Gwenview and keep Okular and Kolourpaint in the image.
On the same note, are there any other obvious duplication in functionality that we should look to streamline for the F27 release?
We probably still need work on automated testing to at least meet the basics of the QA process - ie make sure at least all the apps launch - but I feel the streamline is more important to give us a better target.
On Friday, 7 July 2017 14:29:07 CEST Steven Haigh wrote:
On Friday, 7 July 2017 4:25:54 AM AEST Matthew Miller wrote:
Hey everyone. We're going to have a hard time keeping KDE a release-blocking spin if the QA team doesn't get more active help from KDE SIG folks.
With the recent discussion about lack of testing etc and the state of the KDE live boot, I would like to propose a set of changes to simplify the live image as we start thinking about F27.
The idea is to strip the current bloat to give a more manageable Live Image
- while keeping in mind that after you install to HDD, you can install any
package you like.
Proposal #1: We currently ship 3 browsers in the Live image:
- Firefox
- Konqueror
- Qupzilla
I propose that we strip all out except Konqueror. IMHO, Konqueror is the KDE browser - and should feature on the KDE Spin live image. It allows us to keep a simple target of *ONE* working browser that has to meet the blocker requirements.
I'm not goin to touch this for now, but:
Proposal #2: We currently ship 2 'package managers' (3 if you count PackageKit).
I propose we drop kde-discover - and keep dnfdragora (and PackageKit) in the live image.
Proposal #3: We currently ship 3 image programs in the live image. Okular & Gwenview as viewers, Kolourpaint as an editor.
I propose we drop Gwenview and keep Okular and Kolourpaint in the image.
At most we should remove Kolourpaint, if any, but...
On the same note, are there any other obvious duplication in functionality that we should look to streamline for the F27 release?
We probably still need work on automated testing to at least meet the basics of the QA process - ie make sure at least all the apps launch - but I feel the streamline is more important to give us a better target.
The only thing that I agree is that we need more automation for the testing. The main question here is: which applications are problematic and lead to their testing to be at the end of the process?
On Friday, 7 July 2017 14:58:56 CEST Luigi Toscano wrote:
On Friday, 7 July 2017 14:29:07 CEST Steven Haigh wrote:
Proposal #3: We currently ship 3 image programs in the live image. Okular & Gwenview as viewers, Kolourpaint as an editor.
I propose we drop Gwenview and keep Okular and Kolourpaint in the image.
At most we should remove Kolourpaint, if any, but...
It's worth noting that the Workstation live image (aka Gnome) has Image viewer, Shotwell, Evince AND Gnome Documents.
I think that the deduplication is a good idea, but, in my opinion, Firefox should be the default choice. I know that it is not a part of KDE project (and only God know why it is not Qt), but it is a very good and customizable browser. And about Okular and Gwenview, besides Okular can open a great variety of file formats it's meant to be a reader and Gwenview an image viewer and editor for simple tasks. So, they both should stay.
2017-07-07 10:31 GMT-03:00 Luigi Toscano luigi.toscano@tiscali.it:
On Friday, 7 July 2017 14:58:56 CEST Luigi Toscano wrote:
On Friday, 7 July 2017 14:29:07 CEST Steven Haigh wrote:
Proposal #3: We currently ship 3 image programs in the live image. Okular & Gwenview as viewers, Kolourpaint as an editor.
I propose we drop Gwenview and keep Okular and Kolourpaint in the
image.
At most we should remove Kolourpaint, if any, but...
It's worth noting that the Workstation live image (aka Gnome) has Image viewer, Shotwell, Evince AND Gnome Documents.
-- Luigi _______________________________________________ kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org
On Fri, Jul 07, 2017 at 11:04:03AM -0300, Guilherme Luciano Marques wrote:
I think that the deduplication is a good idea, but, in my opinion, Firefox should be the default choice.
I don't have a strong opinion here, but one advantage of choosing Firefox is that it will also be tested as part of the Workstation testing, rather than requiring something separate. If you all decide you want to do the work to make something else work, that's fine with me.
On Friday, 7 July 2017 16:18:58 CEST Matthew Miller wrote:
On Fri, Jul 07, 2017 at 11:04:03AM -0300, Guilherme Luciano Marques wrote:
I think that the deduplication is a good idea, but, in my opinion, Firefox should be the default choice.
I don't have a strong opinion here, but one advantage of choosing Firefox is that it will also be tested as part of the Workstation testing, rather than requiring something separate. If you all decide you want to do the work to make something else work, that's fine with me.
Talking about changes, you mentioned that there are many applications and they are tested at the end of the cycle. Can you please share more details about it? Is it a matter of the number of the applications in the Live image, or there are some of them which are more troublesome to test. Or maybe the applications by KDE simply don't have automated tests, while there are some of them for Gnome applications? Or a combination of all of them?
If we need to decide whether to cut something and where to add testing, it would be better to know which parts the QA team finds more critical.
Ciao
On Saturday, 8 July 2017 12:26:00 AM AEST Luigi Toscano wrote:
On Friday, 7 July 2017 16:18:58 CEST Matthew Miller wrote:
On Fri, Jul 07, 2017 at 11:04:03AM -0300, Guilherme Luciano Marques wrote:
I think that the deduplication is a good idea, but, in my opinion, Firefox should be the default choice.
I don't have a strong opinion here, but one advantage of choosing Firefox is that it will also be tested as part of the Workstation testing, rather than requiring something separate. If you all decide you want to do the work to make something else work, that's fine with me.
Talking about changes, you mentioned that there are many applications and they
are tested at the end of the cycle. Can you please share more
details about it? Is it a matter of the number of the applications in the Live image, or there are some of them which are more troublesome to test. Or maybe the applications by KDE simply don't have automated tests, while there are some of them for Gnome applications? Or a combination of all of them?
If we need to decide whether to cut something and where to add testing, it would be better to know which parts the QA team finds more critical. Ciao
To bridge the gap between IRC and mailing list, I'll post a bit of conversation today:
02:31 < adamw> pino|work: we don't do detailed functionality testing of every app 02:31 < adamw> the test case is to run each app, make sure it at least doesn't crash entirely on startup, and make sure it seems at least basically capable of doing *something* without crashing 02:32 < adamw> the reason we do this is that we noticed a while back reviewers tend to be quite superficial, *they* don't have time to test everything extensively either; but if they happen to run something and it's clearly utterly broken they get very angry 02:32 < adamw> it's basically a 'oh my god did they even test this AT ALL?!' defence 02:32 < adamw> so the sheer volume of...stuff...that's launchable in KDE does have a big effect 02:33 < tosky> adamw: out of curiosity, so it's a matter of number of applications available by default in the Plasma menus? 02:33 < tosky> or are some applications more complicated than others? 02:33 < adamw> mainly the sheer number. 02:34 < adamw> it's not like we're going to write an entire novel to test the word processor, or setup a FreeIPA domain so we can really give kmail a workout 02:34 < tosky> uhm 02:34 < tosky> but isn't there an email client in the Workstation too? 02:34 < tosky> at least, libreoffice is there 02:35 < adamw> sure 02:36 < adamw> those were just examples 02:36 < adamw> the point is, KDE has something like 3-4x as many things in its default launcher menus as Workstation does 02:36 < adamw> (rough number, I have not counted)
I'm not certain my proposals are the best - but hey - that's why its a proposal - and my aim was to start getting people talking about this as an issue.
Everyone should weigh in on these, and maybe a short case about what should stay, what should go.
Remember, this is purely about the Live boot image - which then becomes the default install. Things that can be reasonably expected to be installed via DNF *after* installing to a HDD are a prime candidate to be removed from the live image. As such, I'd love more suggestions.
I believe we need to get in early to start making progress - otherwise we'll find ourselves in the F27 release cycle before we know it!
On Fri, Jul 07, 2017 at 04:26:00PM +0200, Luigi Toscano wrote:
Talking about changes, you mentioned that there are many applications and they are tested at the end of the cycle. Can you please share more details about it? Is it a matter of the number of the applications in the Live image, or there are some of them which are more troublesome to test. Or maybe the applications by KDE simply don't have automated tests, while there are some of them for Gnome applications? Or a combination of all of them?
See Steven's other reply to this for some context. Here is the release criterion:
https://fedoraproject.org/wiki/Fedora_26_Final_Release_Criteria#Default_appl...
which says:
All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test.
Basic functionality means that the app must at least be broadly capable of its most basic expected operations, and that it must not crash without user intervention or with only basic user intervention.
From this, I think sheer number is an issue. In Workstation, there are GUI 36 applications available on the Live image, not counting Anaconda. That's already a lot, really -- but in KDE, I count *79* in the menu at the bottom left.
On Saturday, 8 July 2017 4:12:54 AM AEST Matthew Miller wrote:
On Fri, Jul 07, 2017 at 04:26:00PM +0200, Luigi Toscano wrote:
Talking about changes, you mentioned that there are many applications and they
are tested at the end of the cycle. Can you please share more
details about it? Is it a matter of the number of the applications in the Live image, or there are some of them which are more troublesome to test. Or maybe the applications by KDE simply don't have automated tests, while
there are some of them for Gnome applications? Or a combination of all of them?
See Steven's other reply to this for some context. Here is the release criterion:
https://fedoraproject.org/wiki/Fedora_26_Final_Release_Criteria#Default_app lication_functionality
which says:
All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test.
Basic functionality means that the app must at least be broadly capable of its most basic expected operations, and that it must not crash without user intervention or with only basic user intervention.
From this, I think sheer number is an issue. In Workstation, there are GUI 36 applications available on the Live image, not counting Anaconda. That's already a lot, really -- but in KDE, I count *79* in the menu at the bottom left.
In other news, I installed Arch Linux the other day, then sddm / plasma- desktop and was quite surprised to see how clean it was.
Yes, just about everything isn't installed by default - but being able to then just install the bits I need was somewhat refreshing.
While I'm not for a moment suggesting that the live image should be a bare bones solution, I feel there needs to be some agreement that the current level of stuff in the live image is somewhat excessive.
In somewhat related news: https://www.reddit.com/r/Fedora/comments/6jqysp/can_we_talk_about_spins/
On Fri, Jul 07, 2017 at 11:04:03AM -0300, Guilherme Luciano Marques wrote:
I think that the deduplication is a good idea, but, in my opinion, Firefox should be the default choice. I know that it is not a part of KDE project (and only God know why it is not Qt), but it is a very good and customizable browser.
it used to be very customizable. Once old style addons are turned off much of the customizability will be gone.
Richard
Ok, but the main ones is always benn updated to the new methods.
2017-07-08 8:36 GMT-03:00 Richard Z rz@linux-m68k.org:
On Fri, Jul 07, 2017 at 11:04:03AM -0300, Guilherme Luciano Marques wrote:
I think that the deduplication is a good idea, but, in my opinion,
Firefox
should be the default choice. I know that it is not a part of KDE project (and only God know why it is not Qt), but it is a very good and customizable browser.
it used to be very customizable. Once old style addons are turned off much of the customizability will be gone.
Richard
-- Name and OpenPGP keys available from pgp key servers _______________________________________________ kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org
On Sat, Jul 08, 2017 at 10:22:22AM -0300, Guilherme Luciano Marques wrote:
Ok, but the main ones is always benn updated to the new methods.
There were quite some changes in addon programming for Firefox in the last decades but I don't ever remember a change so radical as now.
Some of the important plugins are already ported but many will cease to exist. Some of the things that I have programmed will never be possible with the new api.
Richard
Guilherme Luciano Marques wrote:
I think that the deduplication is a good idea, but, in my opinion, Firefox should be the default choice.
Please no! Can we finally stop that nonsense? The main reasons why Firefox is not a good fit for the KDE Plasma Spin from the old discussion are still valid (I slightly updated the list where needed): * We do not control the packaging of Firefox. It is not even open to provenpackager! We are completely at the mercy of the Firefox maintainers. * In particular, the Fedora Firefox package will most likely NOT include the KDE integration developed by openSUSE, ever. That means the package will integrate extremely poorly into our Plasma setup (e.g., no KDE file dialogs). * Firefox also does not pick up native icons, not even GTK+/GNOME ones. * Firefox also has unwanted GNOME dependencies such as (lib)startup-notification. * Shipping Firefox means we have to ship another HTML engine just for Firefox! Firefox takes a lot more space on the live image than a browser that reuses Qt/KDE components. * Users who absolutely want Firefox can simply install it from the repository. Or they could use one of the several spins that default to Firefox. * I don't buy the argument that there is "no alternative" to Firefox. There are perfectly fine Qt/KDE alternatives, that just work on almost all websites out there. (And even Firefox doesn't work on 100% of the web.) QtWebEngine even has a higher website compatibility rate (by being based on Chromium) than Firefox. The KDE SIG plan has always been to prefer Qt/KDE applications wherever possible. Here, it is clearly possible. Shipping non-Qt/KDE applications is acceptable if those are specialized applications with no KDE alternative (think, e.g., Blender). A browser is not specialized, it's a core part of the desktop. And the Qt/KDE alternatives exist and work. * Firefox also has some "features" that are worrisome for Fedora as a whole: - The anti-malware and anti-phishing protection (enabled by default!) sends a hash of every URL you visit to Google (yes, Google!). - Firefox Health Report sends some additional data to Mozilla. It is also enabled by default! - For some time, Mozilla also showed client-side advertisements on some pages generated by it. I believe it stopped doing that, at least, but who says it won't come back? - Speaking of ads on the web, both Konqueror and QupZilla support ad blocking out of the box, Firefox doesn't. QupZilla even enables it by default. - Add-ons can only be installed if they are signed by Mozilla (an iOS-style restriction completely incompatible with Free Software), and they are also restricting the add-on API, throwing away their main selling point. And the Firefox trademark and packaging situation are such that we have no control over these "features", nor any future ones that get added.
I know that it is not a part of KDE project (and only God know why it is not Qt), but it is a very good and customizable browser.
But it does not integrate into a KDE Plasma environment and is thus a poor choice for a KDE Plasma spin.
Firefox was picked in Fedora 23 as a stopgap because Konqueror was deemed not good enough at the time. Now we actually have TWO viable Qt/KDE alternatives: * QupZilla, a Qt-only browser with nice KDE Plasma integration (native dialogs, native icons, native progress report, etc.), is well-tested and perfectly suited for production. It is based on QtWebEngine which is itself based on Chromium, so it is compatible with almost every website on the Internet. Security updates are also delivered with QtWebEngine releases. I have been using QupZilla as my main browser for months, and the features that were initially missing (e.g. printing support) have been implemented. * Konqueror, the native KDE browser, was ported to Qt5/KF5 and can now use QtWebEngine and the revived (up to date with security fixes as well) Qt(5)WebKit. There are still some issues with the port, and unfortunately there is not much work going on upstream to fix them, but it needs to be considered. Maybe even a Fedora KDE developer can look into the regressions? But failing that, QupZilla is still there to be used!
Both are in fact already on the spin. So what is the spin still shipping Firefox for? The stopgap is no longer needed!
Kevin Kofler
On pátek 7. července 2017 14:29:07 CEST Steven Haigh wrote:
On Friday, 7 July 2017 4:25:54 AM AEST Matthew Miller wrote:
Hey everyone. We're going to have a hard time keeping KDE a release-blocking spin if the QA team doesn't get more active help from KDE SIG folks.
With the recent discussion about lack of testing etc and the state of the KDE live boot, I would like to propose a set of changes to simplify the live image as we start thinking about F27.
The idea is to strip the current bloat to give a more manageable Live Image
- while keeping in mind that after you install to HDD, you can install any
package you like.
Proposal #1: We currently ship 3 browsers in the Live image:
- Firefox
- Konqueror
- Qupzilla
I propose that we strip all out except Konqueror. IMHO, Konqueror is the KDE browser - and should feature on the KDE Spin live image. It allows us to keep a simple target of *ONE* working browser that has to meet the blocker requirements.
Proposal #2: We currently ship 2 'package managers' (3 if you count PackageKit).
I propose we drop kde-discover - and keep dnfdragora (and PackageKit) in the live image.
I wouldn't drop kde-discover (plasma-discover). It's a good equivalent to gnome-software, with many backends (PackageKit, Snap, Flatpak) and also with integration of ODRS (Open Desktop Rating System). It might not be sometimes working as it should, but it is getting better with every release.
Proposal #3: We currently ship 3 image programs in the live image. Okular & Gwenview as viewers, Kolourpaint as an editor.
I propose we drop Gwenview and keep Okular and Kolourpaint in the image.
On the same note, are there any other obvious duplication in functionality that we should look to streamline for the F27 release?
We probably still need work on automated testing to at least meet the basics of the QA process - ie make sure at least all the apps launch - but I feel the streamline is more important to give us a better target.
Jan Grulich wrote:
On pátek 7. července 2017 14:29:07 CEST Steven Haigh wrote:
Proposal #2: We currently ship 2 'package managers' (3 if you count PackageKit).
I propose we drop kde-discover - and keep dnfdragora (and PackageKit) in the live image.
I wouldn't drop kde-discover (plasma-discover). It's a good equivalent to gnome-software, with many backends (PackageKit, Snap, Flatpak) and also with integration of ODRS (Open Desktop Rating System). It might not be sometimes working as it should, but it is getting better with every release.
I think Dnfdragora is much closer to the user experience we want to deliver to our users:
Dnfdragora shows all packages in the repository, not just those that are picked up by the Fedora AppStream data generator, which by design filters out everything it does not like. It does not show non-packages such as Flatpaks that have no business being offered in a package manager, especially without a warning that what you are about to install is not a package.
Dnfdragora also shows the dependencies that are going to be installed. With Discover, you have no warning whatsoever that you are going to install some GNOME application and tons of GNOME libraries. Dnfdragora can show you (with one click) the complete list of dependencies (so you can easily identify the toolkit that the application uses even if you have it installed already), and it always asks you before installing new dependencies that you don't have installed yet.
Dnfdragora also interoperates better with the tool recommended to command- line users (dnf). Hardly any command-line user uses pkcon, and I don't think any command-line user uses AppStream tools.
While Dnfdragora is not a KDE application, it uses QtWidgets through libyui and thus does not look less native than Discover's Kirigami UI.
Kevin Kofler
On Tue, 2017-07-11 at 12:44 +0200, Kevin Kofler wrote:
Jan Grulich wrote:
On pátek 7. července 2017 14:29:07 CEST Steven Haigh wrote:
Proposal #2: We currently ship 2 'package managers' (3 if you count PackageKit).
I propose we drop kde-discover - and keep dnfdragora (and PackageKit) in the live image.
I wouldn't drop kde-discover (plasma-discover). It's a good equivalent to gnome-software, with many backends (PackageKit, Snap, Flatpak) and also with integration of ODRS (Open Desktop Rating System). It might not be sometimes working as it should, but it is getting better with every release.
I think Dnfdragora is much closer to the user experience we want to deliver to our users:
Dnfdragora shows all packages in the repository, not just those that are picked up by the Fedora AppStream data generator, which by design filters out everything it does not like. It does not show non-packages such as Flatpaks that have no business being offered in a package manager, especially without a warning that what you are about to install is not a package.
Dnfdragora also shows the dependencies that are going to be installed. With Discover, you have no warning whatsoever that you are going to install some GNOME application and tons of GNOME libraries. Dnfdragora can show you (with one click) the complete list of dependencies (so you can easily identify the toolkit that the application uses even if you have it installed already), and it always asks you before installing new dependencies that you don't have installed yet.
Dnfdragora also interoperates better with the tool recommended to command- line users (dnf). Hardly any command-line user uses pkcon, and I don't think any command-line user uses AppStream tools.
While Dnfdragora is not a KDE application, it uses QtWidgets through libyui and thus does not look less native than Discover's Kirigami UI.
I had a quick look at dnfdragora since I hadn't heard of it before Rex mentioned it (I normally just run dnf from the command line). Two things struck me:
* No way to see what packages depend on the one you're looking at. * No way to resize panes to see more descriptive text and less of the package list.
As I say, this was just a quick look so I may have missed something.
poc
Patrick O'Callaghan wrote:
I had a quick look at dnfdragora since I hadn't heard of it before Rex mentioned it (I normally just run dnf from the command line). Two things struck me:
- No way to see what packages depend on the one you're looking at.
If you try to remove the package, it will tell you. And Discover cannot tell you this at all.
- No way to resize panes to see more descriptive text and less of the
package list.
Discover does not have such panes to begin with.
Kevin Kofler
On Tue, 2017-07-11 at 21:03 +0200, Kevin Kofler wrote:
Patrick O'Callaghan wrote:
I had a quick look at dnfdragora since I hadn't heard of it before Rex mentioned it (I normally just run dnf from the command line). Two things struck me:
- No way to see what packages depend on the one you're looking at.
If you try to remove the package, it will tell you. And Discover cannot tell you this at all.
If it will tell you when you try to remove the package, then clearly it can give this information.
- No way to resize panes to see more descriptive text and less of the
package list.
Discover does not have such panes to begin with.
The main window is divided into a number of regions, all of fixed size, i.e. the borders between these regions cannot be moved. Only the main window itself is resizable. This is poor UI design.
poc
On Tue, Jul 11, 2017 at 4:37 PM, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Tue, 2017-07-11 at 21:03 +0200, Kevin Kofler wrote:
Patrick O'Callaghan wrote:
I had a quick look at dnfdragora since I hadn't heard of it before Rex mentioned it (I normally just run dnf from the command line). Two things struck me:
- No way to see what packages depend on the one you're looking at.
If you try to remove the package, it will tell you. And Discover cannot tell you this at all.
If it will tell you when you try to remove the package, then clearly it can give this information.
The information is solved just-in-time as the query is sent. dnfdragora just gives you what dnf tells it.
- No way to resize panes to see more descriptive text and less of the
package list.
Discover does not have such panes to begin with.
The main window is divided into a number of regions, all of fixed size, i.e. the borders between these regions cannot be moved. Only the main window itself is resizable. This is poor UI design.
The code is on GitHub, feel free to contribute a fix: https://github.com/manatools/dnfdragora
On Tue, 2017-07-11 at 20:09 -0400, Neal Gompa wrote:
On Tue, Jul 11, 2017 at 4:37 PM, Patrick O'Callaghan pocallaghan@gmail.com wrote:
On Tue, 2017-07-11 at 21:03 +0200, Kevin Kofler wrote:
Patrick O'Callaghan wrote:
I had a quick look at dnfdragora since I hadn't heard of it before Rex mentioned it (I normally just run dnf from the command line). Two things struck me:
- No way to see what packages depend on the one you're looking at.
If you try to remove the package, it will tell you. And Discover cannot tell you this at all.
If it will tell you when you try to remove the package, then clearly it can give this information.
The information is solved just-in-time as the query is sent. dnfdragora just gives you what dnf tells it.
I never imagined otherwise. However dnf can run in test mode, which would appear to be the obvious way to deal with this.
- No way to resize panes to see more descriptive text and less of the
package list.
Discover does not have such panes to begin with.
The main window is divided into a number of regions, all of fixed size, i.e. the borders between these regions cannot be moved. Only the main window itself is resizable. This is poor UI design.
The code is on GitHub, feel free to contribute a fix: https://github.com/manatools/dnfdragora
Not interested. As I said, I don't use any of these tools. I was simply commenting on a couple of aspects that struck me when I looked at this one.
poc
Neal Gompa wrote:
On Tue, Jul 11, 2017 at 4:37 PM, Patrick O'Callaghan wrote:
The main window is divided into a number of regions, all of fixed size, i.e. the borders between these regions cannot be moved. Only the main window itself is resizable. This is poor UI design.
The code is on GitHub, feel free to contribute a fix: https://github.com/manatools/dnfdragora
I think splitters would have to be added to libyui first, I don't see them there.
Kevin Kofler
Steven Haigh wrote:
Proposal #1: We currently ship 3 browsers in the Live image:
- Firefox
- Konqueror
- Qupzilla
I propose that we strip all out except Konqueror. IMHO, Konqueror is the KDE browser - and should feature on the KDE Spin live image. It allows us to keep a simple target of *ONE* working browser that has to meet the blocker requirements.
+1
There were mainly 2 issues with the new Qt5/KF5 Konqueror: https://bugs.kde.org/show_bug.cgi?id=370177 https://bugs.kde.org/show_bug.cgi?id=372777
KDE#370177 is fixed in 17.04 (a one-line fix). KDE#372777 is a missing feature in the KWebEnginePart (missing KWallet / password saving support). It can be worked around by defaulting to the KWebKitPart instead, which is still available and can now use the revived Qt5WebKit with all its security fixes and new features (instant fix, just tweak the packaging and/or comps to drag it in and patch the priority in the .desktop file). Or somebody can look into porting the missing methods to the KWebEnginePart (by looking at the code in QupZilla, I think it should not be hard, but of course harder than just switching the default backend).
Alternatively, QupZilla is also a good default. Firefox is not and should just finally go away.
Proposal #2: We currently ship 2 'package managers' (3 if you count PackageKit).
I propose we drop kde-discover - and keep dnfdragora (and PackageKit) in the live image.
+1, though if you decide to default to Dnfdragora (which I would endorse completely), you should also consider using the Dnfdragora updater instead of plasma-pk-updates for consistency (but it is not a necessity, just something to consider).
Proposal #3: We currently ship 3 image programs in the live image. Okular & Gwenview as viewers, Kolourpaint as an editor.
I propose we drop Gwenview and keep Okular and Kolourpaint in the image.
I think this should also be considered. Okular can actually view a lot of image types. But of course it does not offer the kind of functionality the specialized Gwenview offers.
Kevin Kofler
-
Guilherme Luciano Marques -
Jan Grulich -
Kevin Kofler -
Luigi Toscano -
Matthew Miller -
Neal Gompa -
Patrick O'Callaghan -
Richard Z -
Steven Haigh